ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.11.2019
Просмотров: 468
Скачиваний: 1
Губа не дурка, мова не лопата.
Народна приказка
Лекція 14.
УПРАВЛІННЯ РОЗРОБКОЮ І АТЕСТАЦІЯ ПРОГРАМНОГО ЗАСОБУ.
Призначення управління розробкою програмного засобу і його основні процеси. Структура управління розробкою програмних засобів. Підходи до організації бригад розробників. Управління якістю програмного засобу. Атестація програмного засобу і характеристика методів оцінки якості програмного засобу.
14.1. Призначення і процеси управління розробкою програмного засобу.
Управління розробкою ПС (software management) – це діяльність, направлена на забезпечення необхідних умов для роботи колективу розробників ПС, на планування і контроль діяльності цього колективу з метою забезпечення необхідної якості ПС, виконання термінів і бюджету розробки ПС [14.1, 14.2]. Часто цю діяльність називають також управлінням програмним проектом (software project management). Тут під програмним проектом (software project) розуміють всю сукупність робіт, пов'язану з розробкою ПС, а хід виконання цих робіт називають розвитком програмного проекту (software project progress). До необхідних умов роботи колективу відносяться приміщення, апаратно-програмні засоби розробки, документація і матеріально-фінансове забезпечення. Планування і контроль припускає розбиття всього процесу розробки ПС на окремі конкретні роботи (завдання), підбір і розстановка виконавців, встановлення термінів і порядку виконання цих робіт, оцінка якості виконання кожної роботи. Фінальною частиною цієї діяльності є організація і проведення атестації (сертифікації) ПС, якою завершується стадія розробки ПС. Вплив правильної розстановки виконавців на забезпечення надійності ПС вже обговорювався в лекції 2. Питання документації обговорювалися в попередній лекції. Інші питання управління розробки ПС стисло обговоримо в справжній лекції.
Хоча види діяльності по управлінню розробкою ПС можуть бути вельми різноманітними залежно від специфіки ПС, що розробляється, і організації робіт з його створення, можна виділити деякі загальні процеси (види діяльності) по управлінню розробкою ПС:
-
складання плану-проспекту по розробці ПС;
-
планування і складання розкладів по розробці ПС;
-
управління витратами по розробці ПС;
-
поточний контроль і документування діяльності колективу по розробці ПС.
-
підбір і оцінка персоналу колективу розробників ПС.
Складання плану-проспекту по розробці ПС включає формулювання пропозицій про те, як виконувати розробку ПС. Перш за все, повинно бути зафіксовано, для кого розробляється ПС:
-
для зовнішнього замовника
-
для інших підрозділів тієї ж організації
-
або є ініціативною внутрішньою розробкою.
У плані-проспекті повинні бути встановлені загальні контури робіт по створення ПС і оцінена вартість розробки, а також що надаються для розробки ПС матеріально-фінансові ресурси і тимчасові обмеження. Крім того, він повинен включати обгрунтування, якого роду колективом повинно розроблятися ПС (спеціальною організацією, окремою бригадою і тому подібне). І, нарешті, повинні бути сформульовані необхідні технологічні вимоги (включаючи, можливо, і вибір відповідної технології програмування).
Планування і складання розкладів по розробці ПС – це діяльність, пов'язана з розподілом робіт між виконавцями і за часом їх виконання в рамках намічених термінів і наявних ресурсів. Детальніше цей процес буде розглянутий в п. 14.3.
Управління витратами по розробці ПС – це діяльність, направлена на забезпечення відповідної вартості розробки в рамках виділеного бюджету. Вона включає оцінювання вартості розробки проекту в цілому або окремих його частин, контроль виконання бюджету, вибір відповідних варіантів витрачання бюджету. Ця діяльність тісно пов'язана з плануванням і складанням розкладів протягом всього періоду виконання проекту. Основними джерелами витрат є
-
витрати на апаратне устаткування (hardware);
-
витрати на вербування і навчання персоналу;
-
витрати на оплату праці розробників.
Поточний контроль і документування діяльності колективу по розробці ПС – це безперервний процес стеження за ходом розвитку проекту, порівняння дійсних стану і витрат із запланованими, а також документування різних аспектів розвитку проекту (див. лекцію 13). Цей процес допомагає вчасно виявити утруднення і передбачити можливі проблеми в розвитку проекту.
Підбір і оцінка персоналу колективу розробників ПС – це діяльність, пов'язана з формуванням колективу розробників ПС. Наявний в розпорядженні штат розробників далеко не завжди буде відповідним по кваліфікації і досвіду роботи для даного проекту. Тому доводиться, частково, вербувати відповідний персонал, а, частково, організовувати додаткове навчання наявних розробників. У будь-якому випадку у формованому колективі хоч би одного його член повинен мати досвід розробки програмних засобів (систем), зіставних з ПС, який потрібно розробити. Це допоможе уникнути багатьох простих помилок в розвитку проекту.
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) для конкретизації якого-небудь примітиву якості іноді досить вказати, якому стандарту він повинен відповідати, в інших випадках прив'язка примітиву якості до стандарту може зажадати лише незначної додаткової конкретизації цього примітиву. Прив'язка примітивів якості до тих або інших стандартів сильно спрощує контроль і оцінку якості ПС. До стандартів ПС відносяться, перш за все, стандарти на мови програмування, на склад документації, на структуру різних документів, на різні формати та інші.