14.2. Структура управління розробкою програмних засобів.
Розробка ПС зазвичай проводиться в організації, в якій одночасно можуть вестися розробки ряду інших програмних засобів. Для управління всіма цими програмними проектами використовується ієрархічна структура управління. Традиційна структура такого роду обговорена в роботі [14.1]. Вона представлена на мал. 14.1.
На чолі цієї ієрархії знаходиться директор (або віце-президент) організації програміста, що відповідає за управління всіма розробками програмних засобів. Йому безпосередньо підпорядковано декілька менеджерів сфери розробок і одного менеджера за якістю програмних засобів. В результаті спілкування з потенційними замовниками директор ухвалює рішення про початок виконання якого-небудь програмного проекту, доручаючи його одному з менеджерів сфери розробок, а також вирішення об припинення того або іншого проекту. Він бере участь в обговоренні загальних організаційних вимог (обмежень) до програмного проекту і виникаючих проблем, вирішення яких вимагає використання загальних ресурсів організації програміста або зміни замовником загальних вимог.
Менеджер сфери розробок відповідає за управління розробками програмних засобів (систем) певного типу, наприклад, програмні системи у сфері бізнесу, експертні системи, програмні інструменти і інструментальні системи, що підтримують процеси розробки програмних засобів, та інші. Йому безпосередньо підпорядковані менеджери проектів, що відносяться до його сфери. Отримавши доручення директора по виконанню деякого проекту, він організовує формування колективу виконавців за цим проектом (зокрема, необхідне вербування і навчання персоналу). Він бере участь в обговоренні плану-проспекту програмного проекту, що відноситься до сфери розробок, за яку він відповідає, а також в обговоренні і вирішенні виникаючих проблем в розвитку цього проекту. Він організовує узагальнення досвіду розробок програмних засобів в його сфері і накопичення програмних засобів і документів для повторного використання.
Мал. 14.1. Структура управління розробкою програмних засобів.
За кожним програмним проектом призначається свій менеджер, який управляє розвитком цього проекту. Йому безпосередньо підпорядковані лідери бригад розробників. Менеджер проекту здійснює планування і складання розкладів роботи цих бригад по розробці відповідного ПС (див. наступний розділ).
Вважається украй недоцільною розробка великого ПС (програмної системи) однією великою єдиною бригадою розробників. Для цього є ряд серйозних причин. Зокрема, у великій бригаді час, що витрачається на спілкування між її членами, може бути більше часу, що витрачається на власне розробку. Негативний вплив робить велика бригада на будову ПС і на інтерфейс між окремими його частинами. Все це призводить до зниження надійності ПС. Тому зазвичай великий проект розбивається на декілька щодо незалежних підпроектів так, щоб кожен підпроект міг бути виконаний окремою невеликою бригадою розробників (зазвичай вважається, що в бригаді не повинне бути більше 8-10 членів). При цьому архітектура ПС повинна бути такій, щоб між програмними підсистемами, незалежними бригадами, що розробляються, був достатньо простій і добре певний системний інтерфейс.
Найбільш споживано три підходи до організації бригад розробників [14.1, 14.3, 14.4]:
звичайні бригади
неформальні демократичні бригади
бригади провідного програміста.
У звичайній бригаді старший програміст (лідер бригади) безпосередньо керує роботою молодших програмістів. Недоліки такої організації безпосередньо пов'язані із специфікою розробки ПС: програмісти розробляють сильно зв'язані частини програмної підсистеми, сам процес розробки складається з багатьох етапів, кожен з яких вимагає особливих здібностей від програміста, помилки окремого програміста можуть перешкоджати роботі інших програмістів. Успіх роботи такої бригади досягається у тому випадку, коли її керівник є компетентним програмістом, здатним пред'являти до членів бригади розумні вимоги і що уміє заохочувати хорошу роботу.
У неформальній демократичній бригаді робота, що доручається нею, обговорюється спільно всіма її членами, а завдання між її членами розподіляються погоджено залежно від здібностей і досвіду цих членів. Один з членів цієї бригади є лідером (керівником) бригади, але він також виконує і деякі завдання, що розподіляються між членами бригади. Неформальні демократичні бригади можуть вельми успішно справлятися з дорученою ним роботою, якщо більшість членів бригади є досвідченими і компетентними фахівцями. Якщо ж неформальна демократична бригада полягає, в основному, з недосвідчених і некомпетентних членів, в діяльності бригади можуть виникати великі труднощі. Без наявності в бригаді хоч би одного кваліфікованого і авторитетного члена, здатного координувати і направляти роботу членів бригади, ці труднощі можуть привести до невдачі проекту.
У бригаді провідного програміста за розробку дорученої програмної підсистеми несе повну відповідальність одна людина, звана провідним програмістом (chief programmer) і що є лідером бригади: він сам конструює цю підсистему, складає і відладжує необхідні програми, пише документацію до підсистеми. Провідний програміст вибирається з числа досвідчених і обдарованих програмістів. Решта всіх членів такої бригади, в основному, створює умови для найбільш продуктивної роботи провідного програміста. Організацію такої бригади зазвичай порівнюють з хірургічною бригадою [14.1, 14.4]. Ядро бригади провідного програміста складають три члени бригади: крім провідного програміста в нього входить дублер провідного програміста і адміністратор бази даних розробки. Дублер провідного програміста (backup programmer) також є кваліфікованим і досвідченим програмістом, здатним виконати будь-яку роботу провідного програміста, але сам він цю роботу не робить. Головний його обов'язок – бути в курсі всього, що робить провідний програміст. Він виступає в ролі опонента провідного програміста при обговоренні його ідей і пропозицій, але рішення по всіх обговорюваних питаннях ухвалює единолично провідний програміст. Адміністратор бази даних розробки (librarian) відповідає за супровід всієї документації (включаючи версії програм), що виникає в процесі розробки програмної підсистеми, і забезпечує членів бригади інформацією про поточний стан розробки. Ця робота виконується за допомогою відповідної інструментальної комп'ютерної підтримки (див. лекцію 16). Залежно від об'єму і характеру дорученої роботи в бригаду можуть бути включені додаткові члени, такі як
розпорядник бригади, що виконує адміністративні функції;
технічний редактор, що здійснює доопрацювання і технічне редагування документів, написаних провідним програмістом;
інструментальник, що відповідає за підбір і функціонування програмних засобів, що підтримують розробку програмної підсистеми;
тестовик, що готує відповідний набір тестів для відладки програмної підсистеми, що розробляється;
один або декілька молодших програмістів, що здійснюють кодування окремих програмних компонент по специфікаціях, розробленим провідним програмістом.
Крім того, до роботи бригади може притягуватися для консультації експерт по мові програмуванню.
Важливе місце в управлінні розробкою ПС відводиться управління забезпеченням якості. Для керівництва цією діяльністю призначається спеціальний менеджер, підлеглий безпосередньо директорові, – менеджер за якістю. Йому безпосередньо підпорядковані формовані бригади по контролю якості. Ці бригади працюють з окремими проектами, але безпосередньо відповідним менеджерам проектів не підпорядковані, зберігаючи тим самим свою незалежність від них.
Управління забезпеченням якості означає контроль якості кожної роботи, що виконується розробниками в рамках програмного проекту, контроль кожного документа, що включається в ПС. Якість ПС не може бути додане до ПС після того, як воно буде вже створено. Якість ПС формується поступово в процесі всієї розробки ПС, в кожній окремій роботі, що виконується за програмним проектом. Тому для кожної такої роботи, перш ніж вона дістане схвалення і вважатиметься завершеною, організовується огляд (review) відповідною бригадою по контролю якості. Цей огляд істотно відрізняється від контролю, здійснюваного розробниками в кінці кожного етапу розробки, оскільки останній є технічним процесом, пов'язаним з виявленням помилок, тоді як огляд по контролю якості є функцією управління розробкою і пов'язаний з оцінкою того, наскільки результати цієї роботи узгоджуються з вимогами, що декларують, щодо якості ПС.
Істотну роль в управлінні якістю ПС грають програмні (софтверні) стандарти [14.1, 14.2]. Вони фіксують вдалий досвід високо кваліфікованих фахівців з розробки ПС для різних їх класів і для різних моделей їх якості. Проходження відповідним стандартам може істотно полегшити досягнення поставлених цілей щодо якості ПС, а також спростити огляд по контролю якості. Крім того, стандарти сприяють формуванню взаєморозуміння усередині колективу розробників і спрощують процес навчання нових членів цього колективу.
Розрізняють два види таких стандартів:
стандарти ПС (програмного продукту)
стандарти процесу створення і використання ПС.
Стандарти ПС визначають деякі властивості, якими повинні володіти програми або документи ПС, тобто визначають якоюсь мірою якість ПС. При специфікації якості (див. лекцію 4) для конкретизації якого-небудь примітиву якості іноді досить вказати, якому стандарту він повинен відповідати, в інших випадках прив'язка примітиву якості до стандарту може зажадати лише незначної додаткової конкретизації цього примітиву. Прив'язка примітивів якості до тих або інших стандартів сильно спрощує контроль і оцінку якості ПС. До стандартів ПС відносяться, перш за все, стандарти на мови програмування, на склад документації, на структуру різних документів, на різні формати та інші.
Стандарти процесу створення і використання ПС визначають, як винен проводиться цей процес, тобто підхід до розробки ПС, структуру життєвого циклу ПС і його технологічні процеси. Хоча ці стандарти безпосередньо не визначають якості ПС, проте вважається, що якість ПС істотно залежить від якості процесу його розробки. Ці стандарти простіше контролювати, тому повсюдно використовуються для управління якістю ПС.
У лекції 13 вже наголошувалося, що ці стандарти можуть бути як міжнародними або національними, так і спеціально створеними для організації, в якій ведеться розробка ПС. Розробка останніх стандартів є одній з функцій управління забезпеченням якості ПС.
Бригада по контролю якості складається з асистентів (рецензентів) за якістю ПС. Вона проводить огляди тих або інших частин ПС або всього ПС в цілому з метою пошуку виникаючих проблем в процесі його розробки. Огляду підлягають всі програмні компоненти і документи, що включаються в ПС, а також процеси їх розробки. В процесі огляду враховуються вимоги, сформульовані в специфікації якості ПС, зокрема, перевіряється відповідність досліджуваного документа або технологічного процесу стандартам, вказаним в цій специфікації. В результаті огляду формулюються зауваження, які можуть фіксуватися письмово або просто передаватися розробникам усно.
Для огляду кожній конкретною програмною компоненти або документа ПС створюється комісія (група) на чолі з головою (chairman), який відповідає за організацію огляду. Він повинен мати достатній досвід конструювання ПС, щоб бути готовим прийняти відповідальність за важливі технічні рішення. У цю комісію включаються два або три асистенти за якістю ПС, один з яких повинен бути відповідальним за запис рішень, зроблених протягом огляду. До огляду зазвичай притягуються розробник досліджуваною компоненти або досліджуваного документа ПС, а також нові члени колективу розробників в цілях їх навчання.