Календар розвитку дитини до року 

Класичні моделі процесу розроблення програмного забезпечення. Огляд процесу розробки програмного забезпечення


Процес розробки програмного забезпечення (англ. software development process, software process) - структура, згідно з якою побудовано розробку програмного забезпечення (ПЗ).
Існує кілька моделей такого процесу (методологій розробки ПЗ), кожна з яких описує свій підхід у вигляді завдань та/або діяльності, що мають місце в ході процесу.

Виділяють такі основні моделі процесу чи методології розробки ПЗ:

  • Каскадна розробкаабо модель водоспаду (англ. Waterfall model) - модель процесу розробки програмного забезпечення, в якій процес розробки виглядає як потік, що послідовно проходить фази аналізу вимог, проектування, реалізації, тестування, інтеграції та підтримки. Як джерело назви «водоспад» часто вказують статтю, опубліковану У. У. Ройсом (W. W. Royce) у 1970 році; забавно, що сам Ройс використав ітеративну модель розробки і навіть не використав термін «водоспад».
  • Ітеративна розробка(англ. iteration - повторення) - виконання робіт паралельно з безперервним аналізом отриманих результатів та коригуванням попередніх етапів роботи. Проект при цьому підході в кожній фазі розвитку проходить цикл, що повторюється: Планування - Реалізація - Перевірка - Оцінка (англ. plan-do-check-act cycle).
    У процесі розробки завжди виявляються додаткові вимоги чи змінюються виявлені раніше. Також з'являються нові обмеження, пов'язані з ухваленими технічними рішеннями. Найповнішою мірою їх вдається врахувати саме в ітераційній розробці, оскільки саме за такого підходу керівництво проекту повною мірою готове до змін. Ітеративний підхід зараз є найбільш поширеним через свої очевидні переваги і різні його варіації використовуються в компанії ДПГруп.

    Ітеративні методи розробки програмного забезпечення, що їх застосовує ДПГруп:

    • Rational Unified Process(RUP) – методологія розробки програмного забезпечення, створена компанією Rational Software.

      В основі RUP лежать такі основні принципи:

      • Рання ідентифікація та безперервне (до закінчення проекту) усунення основних ризиків.
      • Концентрація на виконанні вимог замовників до виконуваної програми (аналіз та побудова моделі прецедентів).
      • Очікування змін у вимогах, проектних рішеннях та реалізації у процесі розробки.
      • Компонентна архітектура, що реалізується та тестується на ранніх стадіях проекту.
      • Постійне забезпечення якості всіх етапах розробки проекту (продукту).
      • Робота над проектом у згуртованій команді, ключова роль якої належить архітекторам.
    • Гнучка методологія розробки(англ. Agile software development).

      Більшість гнучких методологій націлені на мінімізацію ризиків шляхом зведення розробки до серії коротких циклів, які називаються ітераціями, які зазвичай тривають один-два тижні. Кожна ітерація сама по собі виглядає як програмний проект у мініатюрі, і включає всі завдання, необхідні для видачі міні-приросту за функціональністю: планування, аналіз вимог, проектування, кодування, тестування та документування. Хоча окрема ітерація, як правило, недостатня для випуску нової версії продукту, мається на увазі, що гнучкий програмний проект готовий до випуску в кінці кожної ітерації. Після закінчення кожної ітерації команда виконує переоцінку пріоритетів розробки.

      Agile-методи наголошують на безпосереднє спілкування віч-на-віч. Більшість agile-команд розташовані в одному офісі іноді званому bullpen. Як мінімум вона включає і замовників (замовники які визначають продукт, також це можуть бути менеджери продукту, бізнес-аналітики або клієнти). Офіс може також включати тестувальників, дизайнерів інтерфейсу, технічних письменників та менеджерів. Однією з найбільш відомих та передових гнучких методик є методологія

За 50 років розвитку програмної інженерії накопичилася велика кількість моделей розробки ПЗ. Цікаво провести аналогію між історією розвитку методів, що застосовуються в системах автоматичного управління літальними апаратами, та еволюцією підходів до управління програмними проектами.

"Як вийде".Розімкнена система управління. Повна довіра технічним лідерам. Представники бізнесу практично не беруть участь у проекті. Планування, якщо і є, то неформальне і словесне. Час та бюджет, як правило, не контролюються. Аналогія: балістичний політ без зворотного зв'язку. Можна, але недалеко та неточно.

«Водоспад»чи каскадна модель. Жорстке управління із зворотним зв'язком. Розрахунок опорної траєкторії (план проекту), вимірювання відхилень, корекція та повернення на опорну траєкторію. Найкраще, але не ефективно.

"Гнучке управління".Розрахунок опорної траєкторії, вимірювання відхилень, розрахунок нової траєкторії, що потрапляє, і корекція для виходу на неї. «Плани – ніщо, планування – все» (Ейзенхауер, Дуайт Девід)

"Метод частих поставок".Самонаведення. Розрахунок опорної траєкторії, вимірювання відхилень, уточнення мети, розрахунок нової траєкторії, що потрапляє, і корекція для виходу на неї.

Класичні методи управління перестають працювати у випадках, коли структура та властивості керованого об'єкта нам не відомі та/або змінюються з часом. Ці підходи так само не допоможуть, якщо поточні властивості об'єкта не дозволяють рухатися з необхідними характеристиками. Наприклад, літальний апарат не може розвинути необхідне прискорення або руйнується при неприпустимому навантаженні. Аналогічно, якщо робоча група проекту не може забезпечити необхідну ефективність і тому постійно працює в режимі авралу, це призводить не до зростання продуктивності, а до відходу професіоналів з проекту.

Коли структура та властивості керованого об'єкта нам не відомі, необхідно використовувати адаптивне керування,яке, додатково до прямих керуючих впливів, спрямоване вивчення та зміна властивостей керованого об'єкта. Продовжуючи аналогію з управлінням літальними апаратами - це розрахунок опорної траєкторії, вимірювання відхилень, уточнення мети, уточнення об'єкта управління, адаптація (необхідна зміна) об'єкта управління, розрахунок нової траєкторії, що потрапляє, і корекція для виходу на неї.

Для того щоб зрозуміти структуру та властивості об'єкта та впливати на нього з метою їх приведення до бажаного стану, у проекті має бути додатковий контур зворотного зв'язку – контур адаптації.

Відомо, що продуктивність різних програмістів може відрізнятись у десятки разів. Стверджую, що продуктивність одного і того ж програміста може також відрізнятися в десятки разів. Змусіть найкращого у світі бігуна бігати у мішку, і він покаже у 10 разів найгірший результат. Змусіть найкращого програміста займатися «сизіфовою працею»: плодити документацію (яку, як правило, ніхто не читає) на догоду «Методології» (саме з великої літери М), – і його продуктивність знизиться в 10 разів.

Тому, окрім суто управлінських завдань керівник, якщо він прагне отримати найвищу продуктивність робочої групи, повинен спрямовувати постійні зусилля вивчення та зміна об'єкта управління: людей та його взаємодії.

Моделі(або, як ще люблять говорити, методології) процесів розробки ПЗ прийнято класифікувати за «вагою» – кількістю формалізованих процесів (більшість процесів або лише основні) та детальності їх регламентації. Чим більше процесів документовано, чим детальніше вони описані, тим більше «вага» моделі.

Найбільш поширені сучасні моделі процесу розробки ПЗ представлені на рис. 2.3.

Рис. 2.3. Різні моделі процесу розробки ПЗ

ГОСТи

ГОСТ 19 "Єдина система програмної документації" та ГОСТ 34 "Стандарти на розробку та супровід автоматизованих систем" орієнтовані на послідовний підхід до розробки ПЗ. Розробка відповідно до цих стандартів проводиться за етапами, кожен з яких передбачає виконання строго певних робіт, і завершується випуском досить великої кількості формалізованих і великих документів. Отже, суворе дотримання цим гостам як призводить до водопадному підходу, а й вимагає дуже високого ступеня формалізованості розробки. На основі цих стандартів розробляються програмні системи з держзамовлень у Росії.

У середині 80-х років минулого століття Міністерство оборони США міцно задумалося про те, як обирати розробників програмного забезпечення при реалізації великомасштабних програмних проектів. На замовлення військових Інститут програмної інженерії, що входить до складу Університету Карнегі-Меллона, розробив SW-CMM, Capability Maturity Model for Software як еталонну модель організації розробки програмного забезпечення.

Ця модель визначає п'ять рівнів зрілості процесу розробки.

1) Початковий - процес розробки має хаотичний характер. Визначено лише небагато з процесів, і успіх проектів залежить від конкретних виконавців.

2) Повторюваний – встановлено основні процеси управління проектами: відстеження витрат, термінів та функціональності. Упорядковано деякі процеси, необхідні для того, щоб повторити попередні досягнення на аналогічних проектах.

3) Певний - процеси розробки ПЗ та управління проектами описані та впроваджені в єдину систему процесів компанії. У всіх проектах використовується стандартний організації процес розробки та підтримки програмного забезпечення, адаптований під конкретний проект.

4) Керований - збираються детальні кількісні дані щодо функціонування процесів розробки та якості кінцевого продукту. Аналізується значення та динаміка цих даних.

5) Оптимізований - постійне поліпшення процесів ґрунтується на кількісних даних щодо процесів та на пробному впровадженні нових ідей та технологій.

Документація з повним описом SW-CMM займає близько 500 сторінок і визначає набір із 312 вимог, яким повинна відповідати організація, якщо вона планує атестуватися за цим стандартом на 5-й рівень зрілості.

Уніфікований процес (Rational Unified Process, RUP) був розроблений Філіпом Крачтеном (Philippe Kruchten), Іваром Якобсоном (Ivar Jacobson) та іншими співробітниками компанії "Rational Software" як доповнення до мови моделювання UML. Модель RUP визначає абстрактний загальний процес, на основі якого організація або проектна команда має створити конкретний спеціалізований процес, орієнтований на її потреби. Саме ця риса RUP викликає основну критику - оскільки він може бути будь-чим, його не можна вважати нічим певним. В результаті такої загальної побудови RUP можна використовувати і як основу для традиційного водоспадного стилю розробки, так і як гнучкого процесу.

Microsoft Solutions Framework (MSF) - це гнучка та досить легковажна модель, побудована на основі ітеративної розробки. Привабливою особливістю MSF є велика увага до створення ефективної та небюрократизованої проектної команди. Для досягнення цієї мети MSF пропонує досить нестандартні підходи до організаційної структури, розподілу відповідальності та принципів взаємодії всередині команди.

Одна з останніх розробок Інституту програмної інженерії Personal Software Process/Team Software Process. Personal Software Process визначає вимоги до компетенцій розробника. Згідно з цією моделлю, кожен програміст повинен вміти:

· Враховувати час, витрачений на роботу над проектом;

· Враховувати знайдені дефекти;

· Класифікувати типи дефектів;

· Оцінювати розмір завдання;

· Здійснювати систематичний підхід до опису результатів тестування;

· Планувати програмні завдання;

· Розподіляти їх за часом і складати графік роботи.

· Виконувати індивідуальну перевірку проекту та архітектури;

· Здійснювати індивідуальну перевірку коду;

· Виконувати регресійне тестування.

Team Software Process робить ставку на самоврядні команди чисельністю 3-20 розробників. Команди повинні:

· Встановити власні цілі;

· Скласти свій процес та плани;

· відстежувати роботу;

· Підтримувати мотивацію та максимальну продуктивність.

Послідовне застосування моделі PSP/TSP дозволяє зробити нормою організації п'ятий рівень CMM.

Основна ідея всіх гнучких моделей полягає в тому, що процес, що застосовується в розробці, повинен бути адаптивним. Вони декларують своєю вищою цінністю орієнтованість на людей та їхню взаємодію, а не на процеси та засоби. По суті, так звані, гнучкі методології - це не методології, а набір практик, які можуть дозволити (а можуть і ні) домагатися ефективної розробки ПЗ, ґрунтуючись на ітеративності, інкрементальності, самоврядності команди та адаптивності процесу.

Вибір моделі процесу

Важкі та легкі моделі виробничого процесу мають свої переваги та недоліки, які представлені в табл. 2.1.

Ті, хто намагається слідувати описаним у книгах моделям, не аналізуючи їх застосування у конкретній ситуації, показання та протипоказання, уподібнюються послідовникам культу «Карго» - релігії літакопоклонників. У Меланезії вірять, що західні товари (карго, англ. вантаж) створені духами предків та призначені для меланезійського народу.

Таблиця 2.1

Плюси та мінуси важких та легких моделей процесів розробки програмного забезпечення

Вага моделі Плюси Мінуси
Важкі Процеси розраховані середню кваліфікацію виконавців. Велика спеціалізація виконавців. Нижче вимоги до стабільності команди. Відсутні обмеження щодо обсягу та складності виконуваних проектів. Вимагають суттєвої управлінської надбудови. Більш тривалі стадії аналізу та проектування. Більше формалізовані комунікації.
Легкі Менше непродуктивних витрат, пов'язаних із управлінням проектом, ризиками, змінами, конфігураціями. Спрощені стадії аналізу та проектування, основний упор на розробку функціональності, поєднання ролей. Неформальні комунікації. Ефективність сильно залежить від індивідуальних здібностей, які вимагають більш кваліфікованої, універсальної та стабільної команди. Обсяг та складність виконуваних проектів обмежені.

Вважається, що білі люди нечесним шляхом одержали контроль над цими предметами. У найбільш відомих культах карго з кокосових пальм та соломи будуються точні копії злітно-посадкових смуг, аеропортів та радіовишок. Члени культу будують їх, вірячи в те, що ці споруди залучать транспортні літаки (які вважаються посланцями парфумів), заповнені вантажем (карго). Віруючі регулярно проводять стройові вчення («муштру») і таке собі подібність військових маршів, використовуючи гілки замість гвинтівок і малюючи на тілі ордени та написи «USA». Все це для того, щоб знову з неба спустилися літаки і цих предметів побільшало.

Алістер Коуберн, один із авторів «Маніфесту гнучкої розробки ПЗ» проаналізував дуже різні програмні проекти, які виконувались за різними моделями від абсолютно полегшених та «гнучких» до важких (СММ-5) за останні 20 років. Він не виявив кореляції між успіхом чи провалом проектів та моделями процесу розробки, які застосовувалися у проектах. Звідси він зробив висновок про те, що ефективність розробки програмного забезпечення не залежить від моделі процесу, а також про те, що:

· У кожного проекту має бути своя модель процесу розробки.

· У кожної моделі – свій час.

Це означає, що немає єдиного правильного процесу розробки ПЗ, у кожному новому проекті процес повинен визначатися щоразу заново, залежно від проекту, продукту та персоналу, у відповідність до «Законом 4-х П» (рис. 2.4). Цілком різні процеси повинні застосовуватися в проектах, у яких беруть участь 5 осіб, та у проектах, у яких беруть участь 500 осіб. Якщо продуктом проекту є критичне програмне забезпечення, наприклад, система управління атомною електростанцією, то процес розробки повинен сильно відрізнятися від розробки, наприклад, сайту «відпочинь.ру». І, нарешті, по-різному слід організовувати процес розробки в команді вчорашніх студентів і в команді професіоналів.

Команда, яка розпочинала проект, не залишається незмінною, вона проходить певні стадії формування та, як правило, кількісно зростає в міру розвитку проекту. Тому процес має постійно адаптуватися до цих змін. Головний принцип: не люди повинні будуватися під обрану модель процесу, а модель процесу має підлаштовуватися під конкретну команду, щоб забезпечити її найвищу ефективність.

Рис. 2.4. "Закон 4-х П". Процес у проекті має визначатися залежно від проекту, продукту та персоналу

Перш ніж запропонувати огляд процесу розробки, що склався в результаті накопичення досвіду за останні роки, я хотів би зробити кілька загальних пояснень, які мені здаються суттєвими.

Я працюю в IT останніх 15 років, хоча програмуванням почав займатися значно раніше. Основним напрямком моєї діяльності як системного архітектора була організація розробки програм, розробка концепцій та верхньорівневої архітектури та контроль виконання концепції протягом проекту. Окрім управління розробкою ПЗ та створення архітектури, я час від часу займаюся вирішенням складних технічних проблем та написанням деяких критично важливих ділянок коду, де необхідне не тільки знання самої мови та середовища розробки, а й їхньої внутрішньої організації, що іноді підносить неприємні сюрпризи.

Проекти, над якими я працюю, найчастіше пов'язані із розробкою замовного чи інвестиційного програмного забезпечення. Також мені доводилося працювати із вбудованим ПЗ та програмами, орієнтованими на випуск «хітів» (що, з легкої руки Джоеля Спольськи, я називаю далі ігровим ПЗ, хоча насправді деякі ігрові проекти ближче до інвестиційних).

Замовне програмне забезпечення може бути призначене для внутрішнього чи зовнішнього замовника. Ексклюзивні права на розроблену систему отримує замовник, і робота над розвитком системи надалі може бути передана іншому виконавцю.

На відміну від замовлення ПЗ, робота над інвестиційним програмним забезпеченням ведеться самим виконавцем на гроші внутрішнього або зовнішнього інвестора. Як правило, права на код системи залишається у виконавця, що стимулює безперервну роботу щодо покращення свого продукту та послідовний випуск версій з більш розвиненою функціональністю.

Вбудоване програмне забезпечення поставляється разом з апаратною частиною і, власне кажучи, не підлягає супроводу, оскільки відкликання партії пристроїв виробником – справа дуже затратна і тому виняткова.

Розробка ігрових хітів також практично не містить фази супроводу. Крім того, користувачі ігрових програм, навіть зіткнувшись з помилкою у грі, дуже рідко завантажують оновлену версію. Тому розробка ігор, як правило, має свою економіку та свій процес розробки.

Нашими замовниками є органи влади, великі державні та комерційні організації та, звичайно, ми самі. Тому в сенсі замовного ПЗ у нашому процесі часто є певна різниця між процесами розробки продуктів для внутрішнього і зовнішнього замовників. Деякі нюанси вкажу в цій статті. Рівень формалізації відносин із замовником у нас варіюється від проекту до проекту дуже широко. Загалом, що більший бюджет проекту, то вище формальність. Державний замовник або великі комерційні підприємства (особливо з державною участю) зазвичай мають законодавчі обмеження на формування, розміщення замовлення та приймання результатів робіт. Ще одним обмеженням великих організацій є той факт, що їхній персонал, який є джерелом вимог і основним користувачем наших систем, має дуже обмежену доступність для виконавців, хоча б через свою зайнятість. Однак для невеликих організацій рівень формалізації падає і іноді сягає протилежної крайності, де виникає недостатній рівень відповідальності замовника в рамках проекту.

Інший бік наших замовних проектів – високі вимоги до функціональності. Це і високе навантаження на всі системи, і велика географічна розподіленість, і високі вимоги до точності обчислень при обмежених часових рамках. Часто у наших проектах з'являються елементи дослідницької роботи та творчого пошуку, спрямованого на вирішення нетривіальних проектних завдань. Іноді нам доводиться комбінувати в рамках одного процесу розробки різні методології, наприклад, вставляючи в загальний процес, близький до RUP, один або кілька етапів майже чистого scrum, породжуючи щось на кшталт проекту. Це дозволяє нам зберігати невисокий рівень залучення користувачів, пов'язаний із природою проекту, з гнучкістю розробки в умовах високої невизначеності вимог. У цьому плані для мене важливим є саме підготовчий етап, під час якого можна вибрати необхідну методологію та вибудувати оптимальний процес розробки. Один із прикладів застосування гнучкої методології я описав у статті «Застосування agile при розробці проекту для державного замовника».

Як приклад роботи над інвестиційним проектом, я можу навести розробку комплексної системи безпеки, яку ми створювали як «коробковий» продукт. Під моїм керівництвом було випущено послідовно чотири версії цієї системи, користувачами якої стали різні комерційні та державні організації, включаючи мерію Москви, АФК «Система», банки, бізнес-центри і, звичайно, наш власний офіс. Перша версія була не дуже успішною, але ми мали стратегію розвитку, яка дозволила нам успішно захопити ринок і пережити складні часи кризи. Досвід роботи над цим і ще кількома інвестиційними проектами теж був врахований при формуванні процесу розробки, що використовується мною.

Наш процес є послідовністю певних етапів. Наведена мною класифікація ПЗ зроблена тільки, щоб показати можливу різницю в організації розробки різних програмних засобів. Роблячи огляд процесу розробки, я зупинюся тільки на відмінностях саме самого процесу щодо різних видів програмного забезпечення. Проте слід пам'ятати, що різницю між процесами розробки різних видів ПО набагато глибше, тому за плануванні кожного етапу необхідно враховувати ці нюанси.

Важливо розуміти, що перехід процесу від одного етапу до іншого немає чіткої межі. Як правило, роботи наступного етапу починаються в міру виконання 80-90% робіт за попереднім етапом. Особливо це стосується розробки вимог, коли у ряді випадків зняття невизначеності відбувається лише до кінця проекту. Безумовно, наявність такої невизначеності у проекті є суттєвим ризиком і має бути під постійним контролем.

Процес розробки замовного ПЗ

Огляд процесу розробки почнемо з найбільш загального випадку – розробки програмного забезпечення. Схема процесу наведено малюнку 1.

Малюнок 1. Процес розробки програмного забезпечення.

Робота над проектом розпочинається з підготовчого етапу. Мета етапу полягає в тому, щоб на основі пропозицій замовника створити деяку концепцію майбутньої системи та, відштовхуючись від цієї концепції, провести оцінку затребуваності та реалізації проекту. Якщо рішення про залучення виконавця приймається замовником на конкурсній основі, попередній етап фактично є стадією підготовки потенційного виконавця до конкурсу, включаючи формування необхідної документації.

Не потрібно витрачати час та ресурси на проект, чия концепція визнається незатребуваною чи нереалізованою. Такий проект має бути завершено. У ряді випадків потрібна деяка ітеративна робота із замовником щодо корекції концепції проекту, доки або не буде досягнуто прийнятного балансу вимог замовника та витрат виконавця, або не буде прийнято рішення про згортання робіт.

Проект, концепція якого є прийнятною для реалізації, виходить на етап розробки вимог. На цьому етапі виконавець повинен сформувати перелік усіх явних та прихованих потреб замовника. Часто виявляється, що замовник або не визначився зі своїми потребами, або його потреби суперечать між собою, з можливостями замовника або з можливостями виконавця. Цілями етапу є виявлення всіх прихованих потреб, вирішення конфліктів вимог, формування цілісного технічного рішення та аналіз реалізованості підготовленого рішення.

Іноді уточнення вимог призводить до перегляду концепції проекту. Якщо після уточнення всіх вимог неможливо знайти прийнятного технічного рішення, проект доводиться згортати чи відкладати на деякий час в очікуванні найбільш прийнятних обставин.

Якщо технічне рішення знайдено, виконавець розпочинає розробку архітектури майбутньої системи. Мета етапу – визначення верхньорівневої логічної та фізичної архітектури, що повністю покриває всі вимоги замовника. При розробці архітектури проводиться рецензування та уточнення концепції, вимог та попереднього технічного рішення, що дає можливість запобігти найбільш небезпечним ризикам.

Після завершення проектування архітектури необхідно знову провести ревізію основних параметрів проекту і вирішити, чи виконавець може завершити проект. Корисно на стадії розробки архітектури відмовитися від зайвих та надто громіздких функцій. Оптимізація архітектурного рішення часто допомагає вписатися у прийнятні параметри проекту. В інших випадках потрібно більш радикальне скорочення функціоналу системи, що розробляється. Однак навіть зупинка проекту на цій стадії, якщо вона відбувається з вагомих причин, має сприйматися як перемога: продовження робіт у такому разі може призвести лише до ще більших втрат.

Якщо баланс було знайдено, і вдалося створити прийнятну архітектуру системи, виконавець може переходити до реалізації та постачання системи. Реалізація може відбуватися за один чи кілька етапів. Для невеликих проектів одноетапне постачання всього функціоналу системи може бути цілком прийнятним. Проте, що більше проект, то вища залежність підсистем всередині створюваної системи. У умовах слід ділити реалізацію кілька етапів те щоб наприкінці кожного етапу команда розробників мала готовий до поставки продукт. При цьому найважливіший фундаментальний функціонал повинен розроблятися на ранніх етапах, а надбудови, що працюють поверх цих основних компонентів, слід реалізовувати пізніше. У такому разі найбільш небезпечні системи помилки будуть виправлені на перших етапах, і ризик того, що прикладна функціональність системи буде заснована на нестабільній основі, буде значно знижений.
Після поставки повністю завершеної системи проект замовленого програмного забезпечення зазвичай переходить до етапу дослідної експлуатації. Мета цього етапу полягає у перевірці якості роботи розробленої системи у реальних умовах експлуатації. Як правило, на цьому етапі виконавець спільно із замовником проводить вимір кількісних метрик, що дозволяють визначити якість створеної системи. Насамперед перевіряються функціональні характеристики якості, потім – нефункціональні. За наявності невідповідностей виконавець коригує код системи.

Повністю налагоджена та налаштована система вводиться у промислову експлуатацію. Як правило, виконавець повинен супроводжувати систему принаймні протягом терміну гарантії. Невідповідності, що виявляються, повинні виправлятися. Користувачі та обслуговуючий персонал замовника мають отримати оперативну консультативну підтримку.

Нарешті, настає момент, коли система перестає влаштовувати замовника з будь-якої причини. Настає етап виведення системи з експлуатації. Втім, для замовного ПЗ цей етап не завжди актуальний, оскільки замовник може скористатися своїми ексклюзивними правами на систему та усунути виконавця від подальших робіт із супроводу та розвитку системи ще до того, як вона втратить актуальність.

Будь-який проект зрештою приходить до свого завершення. Етап припинення проекту має на меті аналіз результатів, внесення змін до процесу розробки на основі отриманого досвіду та поповнення бази знань розробників новими ефективними рішеннями та застереженнями, а також новими готовими компонентами, які можна буде використати у наступних проектах.

Залишилося відзначити ще два етапи процесу розробки. Буває, що обставини не дозволяють продовжувати реалізацію проекту, але результати виконаної роботи показують, що проект може мати майбутнє. Закривати такий проект передчасно. Тому замість повної зупинки робіт виконавець може тимчасово призупинити діяльність із проекту, зафіксувавши досягнуті результати. Як тільки обставини дозволять, проект можна буде відновити, розконсервувавши інфраструктуру, повернувши проект розробників і відновивши стан проекту. Важливо, однак, відновлювати роботу з того етапу, на якому проект було перервано, повторно провівши ревізію досягнутих результатів.

Процес розробки інвестиційного ПЗ

Процес розробки інвестиційного ПЗ відрізняється тим, що паралельно може йти робота відразу над кількома версіями продукту: поки перша версія супроводжується, друга вже реалізується, а для третьої формулюються вимоги. Процес показаний малюнку 2.


2. Процес розробки інвестиційного програмного забезпечення.

Як неважко помітити, при розробці інвестиційного ПЗ мають місце ті самі етапи, які були розглянуті вище для розробки замовного програмного забезпечення. Але відмінність у тому, що етапи ставляться не до всього продукту, а окремої версії продукту. Винятком є ​​етап припинення проекту: проект не може завершитися, поки йде робота хоча б над однією версією продукту.

Зверніть увагу на момент початку роботи над наступною версією продукту. Цей момент настає, як тільки пройдено етап створення архітектури поточної версії, що розробляється. До цього на етапах формування вимог та створення архітектури, як правило, йде обговорення, які функції слід реалізувати у поточній версії, а які перенести на майбутнє. І лише тоді, коли вимоги до поточної версії сформульовані, рецензовані та підтверджені архітектурою системи, є сенс думати про наступну версію.

Крім того, після розробки архітектури, як правило, у аналітиків та архітекторів проекту з'являється деяка свобода дій, оскільки на етапах постачання основне навантаження лягає на програмістів. Цю свободу можна використовувати для опрацювання концепції та вимог для наступної версії.

В принципі, можна перенести початок робіт над наступною версією на пізніший термін. Наприклад, цілком допустимо спочатку ввести поточну версію в дослідну чи навіть промислову експлуатацію, і лише після цього розпочати роботу над наступною версією. Але треба пам'ятати, що таке рішення не застосовується у разі високої конкуренції: вас просто випередять і видавлять із ринку. Рішення потрібно ухвалювати, виходячи з усього комплексу обставин, що впливають на ваш бізнес.

Говорячи про процес розробки інвестиційного ПЗ, треба розуміти, що робота над кількома версіями має ряд явних та прихованих взаємозалежностей між паралельними гілками процесу.

По-перше, виправлення невідповідностей, виявлених в ранній версії, повинні вноситися і в версію, де вони були виявлені, і в пізніші версії, включаючи розроблювані. Це стосується не тільки коду програми, а й усіх інших артефактів проекту: технічної та користувальницької документації, довідкової системи, оцінок та планів робіт тощо. Причому виправлення повинні вноситися негайно, оскільки зменшити вартість виправлень вам не вдасться, але якщо не внести виправлення відразу, їх вартість на пізніших стадіях може збільшитися в десятки і навіть сотні разів.

По-друге, для паралельної роботи над кількома версіями потрібна особлива інфраструктура проекту, включаючи організацію контролю версій коду та документації, контролю завдань та невідповідностей, утиліт автоматичного складання та тестування тощо. Не можна припустити, щоб робота над однією версією продукту блокувала виконання завдань за іншими версіями тільки через те, що інфраструктура проекту не дозволяє запустити два процеси збирання одночасно для різних версій продукту.

Особливу увагу потрібно приділити стендам, на яких проводиться тестування: на них повинні бути розгорнуті всі версії продукту, які були випущені раніше (щонайменше ті версії, що супроводжуються), і всі версії, розробка яких ведеться зараз.

По-третє, у роботі над кількома версіями можуть бути одночасно задіяні одні й самі учасники. Існує великий ризик, що ключовий співробітник може зануритися в роботу над однією версією програми і допустити суттєве перевищення термінів за завданнями, пов'язаними з іншою версією.

По-четверте, має місце обернена ситуація, коли персонал, який працює над однією версією, нічого не знає про те, які рішення приймаються в рамках робіт над іншою версією. Частково проблема знімається, якщо виправлення всієї документації та коду негайно поширюватимуться на пізніші версії, про що я говорив вище. Але одними виправленнями справа не повинна обмежуватись. Потрібно, щоб команда, яка працює над однією версією, розуміла, чому було прийнято ті чи інші рішення під час роботи над іншою версією. Для цього потрібна база знань для розробників – спеціальна інформаційна система, в якій повинні описуватись всі проблеми, з якими зіткнулися розробники під час роботи над тією чи іншою версією продукту, та способи вирішення цих проблем. База знань має розсилати всім учасникам проекту повідомлення про надходження нових записів. Не можна пускати на самоплив взаємодію двох команд, що працюють над різними версіями одного продукту.

Процес розробки вбудованого ПЗ

Як зазначалося вище, вбудоване ПЗ відрізняється від замовного тим, що його дуже складно супроводжувати.

Допустимо, ви випускаєте програми для холодильників. Після того, як ПЗ поставлено виробнику, десятки тисяч пристроїв починають розходитися по всьому світу, і ви уявлення не маєте, де вони опиняться. І якщо один із холодильників вийде з ладу з вини вашого софту, то простіше заплатити неустойку, ніж повертати холодильник на завод та проводити діагностику. Звичайно, можна підготувати інженерів для дилерських центрів, які зможуть провести діагностику на місці та замінити прошивку вашої системи, але це дуже дорого.

Отже, розробки вбудованого ПЗ виникає відразу кілька важливих обмежень.

По-перше, постачання виконується в рамках лише одного етапу: ніхто не вбудовуватиме в пристрої наполовину працюючу програму.

По-друге, при постачанні ви повинні приділити особливу увагу якості програми, оскільки з моменту впровадження її всередину залізної скриньки міняти її буде дуже складно. Особливу увагу потрібно приділити етапу дослідної експлуатації, коли програма впроваджується в обмежену партію пристроїв, і ці пристрої проходять комплексні випробування різних режимах експлуатації. Ви повинні зібрати максимум інформації про динаміку поведінки вашої системи, проаналізувати цю інформацію та доопрацювати програмне забезпечення.

По-третє, коли пристрій з вашим програмним забезпеченням пішло в серію, ви маєте дуже мало можливостей для виправлення помилок. За фактом, такі виправлення можливі лише у разі шлюбу ПЗ, що призводить до непрацездатності всієї партії пристроїв, через що виробник буде змушений відкликати цю партію, а ви отримаєте велику чорну пляму на свою репутацію.

Нарешті, по-четверте, етапу виведення з експлуатації у вбудованого ПЗ немає. Програму просто викидають разом із пристроєм. Тому, як тільки для партії пристроїв, в яких працює ваше програмне забезпечення, закінчується гарантійний термін, можна переходити до закриття проекту.

Процес розробки вбудованого ПЗ показаний малюнку 3.


3. Процес розробки вбудованого програмного забезпечення.

Процес розробки ігор

Ігрове програмне забезпечення було виділено мною через специфіку їх виробництва та експлуатації. Бізнес ігрового програмного забезпечення заснований на випуску хітів. Один успішний хіт оплачує витрати на створення кількох ігор, що залишаються непоміченими користувачами. Тому процес розробки однієї гри взаємопов'язаний із процесами розробки інших ігор.

Ще одним фактором, що виділяє виробництво ігор, є той факт, що гра цікава користувачеві або доки він не пройшов останній рівень, або поки у нього не відбулася фатальна помилка. Це означає, що другу версію гри він не купуватиме або навіть безкоштовно завантажуватиме лише заради виправлень кількох помилок.

Зазначені чинники позначаються процесі розробки ігрового ПЗ. Процес представлений малюнку 4.


4. Процес розробки ігрового програмного забезпечення.

Слід зазначити такі особливості процесу розробки ігрового ПЗ.

Насамперед, при виробництві ігор вкрай важлива якість концепції. Якщо концепція гри дозволяє створити хіт, то подальша робота безглузда. Ситуація, коли більшість проектів закінчуються на підготовчому етапі, для розробки ігрового програмного забезпечення типова.

При розробці вимог та архітектури для ігрового програмного забезпечення часто повторно використовуються напрацювання, отримані при роботі над попередніми проектами. У цьому плані також додаткова вага отримує етап припинення проекту, коли всі корисні напрацювання мають бути зафіксовані у базі знань розробників.

Постачання ігрового програмного забезпечення відбувається в рамках одного єдиного етапу. Навіть якщо спочатку створюється якесь ядро, «рух» ігрової системи, його роботу неможливо перевірити без реалізації всього функціоналу системи.

Для ігрового програмного забезпечення немає етапів дослідної експлуатації та виведення з експлуатації. Ігри відразу надходять у продаж, а після використання просто видаляються користувачем у міру втрати інтересу до них.

Висновок

У статті я спробував зробити огляд «верхнього рівня» процесу розробки прикладного програмного забезпечення. Кожен етап процесу, безумовно, потребує окремого обговорення з обов'язковим врахуванням особливостей програмних засобів, що розробляються.

Зазначу, що схема процесу є результатом узагальнення мого особистого досвіду розробки різних програмних засобів. Як і будь-яке узагальнення, моя схема є абстракцією. І, як будь-яка абстракція, вона має свої межі застосування. Не можна бездумно застосовувати цю схему до конкретного проекту. Важливо розуміти, кожен проект має свої нюанси, що впливають на організацію процесу розробки. І тому кожного проекту наведену тут схему необхідно адаптувати, а деяких випадках потрібно розробити принципово інший підхід.

програмне забезпечення управління

Процес створення програмного забезпечення - безліч різних видів діяльності, методів, методик і кроків, що використовуються для розробки та еволюції програмного забезпечення та пов'язаних з ним продуктів (проектних планів, документації, програмного коду, тестів, документації користувача).

Однак на сьогоднішній день не існує універсального процесу розробки програмного забезпечення - набору методик, правил та розпоряджень, що підходять для програмного забезпечення будь-якого виду, для будь-яких компаній, для команд будь-якої національності. Кожен поточний процес розробки, який здійснюється деякою командою в рамках певного проекту, має велику кількість особливостей та індивідуальностей. Однак доцільно перед початком проекту спланувати процес роботи, визначивши ролі та обов'язки у команді, робочі продукти (проміжні та фінальні), порядок участі у їх розробці членів команди тощо.

Процес створення програмного забезпечення не є однорідним. Той чи інший метод розробки програмного забезпечення, зазвичай, визначає деяку динаміку розгортання тих чи інших видів діяльності, тобто, визначає модель процесу (process model).

Модель є гарною абстракцією різних методів розробки програмного забезпечення, дозволяючи лаконічно, стисло та інформативно їх уявити. Проте, сама ідея моделі процесу є однією з ранніх програмної інженерії, коли вважалося, що вдала модель - найголовніше, що сприяє успіху розробки. Пізніше прийшло усвідомлення, що існує безліч інших аспектів (наприклад, принципи управління та розробки, структура команди), які мають бути визначені згідно один з одним. І почали розвиватися інтегральні методології розробки. Проте існує кілька класичних моделей процесу розробки програмного забезпечення.

Першою моделлю, що набула широкої популярності і дійсно структурує процес розробки, є каскадна або водоспадна. Вона була створена після конференції НATO з питань науки і техніки, що пройшла в 1968 році, де розглядалися подібні питання, і поділяє процес створення програмного продукту на послідовні етапи (слід зазначити, що вона вже тоді застосовувалася різними розробниками, проте ні кількість, ні зміст етапів не уніфікувалося).

Малюнок 1 - Модифікована каскадна модель розробки програмного забезпечення

Модифікована каскадна модель передбачала можливість повернення до попередніх етапів.

Через нетривалий час після появи каскадна модель була доопрацьована Уінстом Ройсом з урахуванням взаємозалежності етапів і необхідності повернення на попередні щаблі, що може бути викликано, наприклад, неповнотою вимог або помилками у формуванні завдання. У такому «оборотному» вигляді каскадна модель проіснувала довгий час і стала основою для багатьох проектів (рисунок 1).

Однак практичне використання цієї моделі виявило безліч її недоліків, головний з яких полягав у тому, що вона більше підходить для традиційних видів інженерної діяльності, ніж для розробки програмного забезпечення. Зокрема, однією з найбільших проблем виявилася її схильність до можливих невідповідностей отриманого в результаті продукту та вимог, які до нього пред'являлися. Основна причина цього полягає в тому, що повністю сформований продукт з'являється лише на пізніх етапах розробки, але так як роботу на різних етапах зазвичай виконували різні фахівці та проект передавався від однієї групи до іншої, то за принципом зіпсованого телефону виявлялося так, що на виході виходило не зовсім те, що передбачалося спочатку.

Для того, щоб усунути недоліки каскадної моделі, була запропонована V-подібна, або шарнірна модель розробки програмного забезпечення (рисунок 2).

Малюнок 2-V-подібна модель розробки програмного забезпечення

V-подібна модель дозволяє набагато краще контролювати результат щодо його відповідності очікуванням, оскільки сфокусована на тестуванні.

V-подібна модель дала можливість значно підвищити якість програмного забезпечення за рахунок своєї орієнтації на тестування, а також багато в чому вирішила проблему відповідності створеного продукту вимогам, що висуваються завдяки процедурам верифікації та атестації на ранніх стадіях розробки (пунктирні лінії на малюнку вказують на залежність етапів планування/постановки завдання та тестування/приймання).

Однак загалом V-подібна модель є лише модифікацією каскадної і має багато її недоліків. Зокрема, та та й інша слабо пристосовані до можливих змін вимог замовника. Якщо процес розробки займає тривалий час (іноді до кількох років), то отриманий в результаті продукт може виявитися фактично непотрібним замовнику, оскільки його потреби суттєво змінилися.

Програмне забезпечення на відміну, наприклад, від мікросхеми можна вводити в експлуатацію частинами, а значить, розробляти і постачати його замовнику також можна поступово. Саме на цьому заснована інкрементна модель, яка передбачає подрібнення продукту на відносно незалежні складові, які розробляються та вводяться в експлуатацію окремо.

Така модель вигідна як для замовника, так і для творця системи, оскільки дозволяє просуватися вперед, дотримуючись інтересів обох сторін.

Проте вона має свої недоліки. Розподіл на функціональні блоки загалом уповільнює процес, оскільки виникає необхідність забезпечення взаємодії. Для багатьох рішень цей метод не застосовується, оскільки з них не можна вичленувати окремі складові, які можуть бути поставлені та функціонувати незалежно. Істотно зростає навантаження і на керівний персонал у зв'язку з ускладненням завдань з координування робіт над окремими складовими системи, збільшується вартість внесення змін до готових компонентів, які вже встановлені та працюють у замовника.

Запропонована Баррі Боемом у 1988 році спіральна модель стала суттєвим проривом у розумінні природи розробки програмного забезпечення, хоча поєднує каскадний підхід та ітераційний процес проектування на основі створення прототипів (рис. 3).


Рис. 3.

Спіральна модель Боема сфокусована на проектуванні, розробка програмного забезпечення відбувається лише на останньому витку спіралі за звичайною каскадною моделлю, проте цьому передує кілька ітерацій проектування на основі створення прототипів - при цьому кожна ітерація включає стадію виявлення та аналізу ризиків та найскладніших завдань.

Оскільки спіральна модель в основному охоплює саме проектування, то в початковому вигляді вона не набула широкого поширення як метод управління всім життєвим циклом створення програмного забезпечення. Однак головна її ідея, що полягає в тому, що процес роботи над проектом може складатися з циклів, що проходять одні й ті самі етапи, стала вихідним пунктом для подальших досліджень і стала основою більшості сучасних моделей процесу розробки програмного забезпечення.

Вперше запропонована Філіпом Крачтеном у 1995 році, ітеративна модель поєднує головні переваги спіральної, інкрементної, каскадної моделей, а також методів розробки на основі створення прототипів та об'єктно-орієнтованого підходу (рисунок 4). Вона здобула велику популярність і в тому чи іншому вигляді використовується в багатьох сучасних проектах.


Малюнок 4- Ітеративна модель розробки програмного забезпечення

Відповідно до ітеративної моделі є чотири основні фази життєвого циклу розробки програмного забезпечення (початок, дослідження, побудова і впровадження). На кожній фазі проект проходить безліч ітерацій, що призводять до створення працездатних версій: на початкових створюються прототипи, уточнюються вимоги, опрацьовуються найскладніші проблеми; кінцеві призводять до створення продукту, його вдосконалення та розширення функціональності.

Ітеративна модель, крім основних фаз, виділяє ще дві групи процесів: робітники (управління вимогами, аналіз та проектування, реалізація, тестування, розгортання) та допоміжні (управління конфігурацією та змінами, проектом та процесом). Кількість та суть процесів варіюються залежно від потреб розробника, вони також можуть мати свої цикли, які не обов'язково навіть відповідають основним фазам. Проте результатом робочих процесів є створення версій продукту.

Ітеративна модель подібно до спіральної дає можливість успішно справлятися з ризиками. Якщо під час роботи над черговою версією буде встановлено, що трудовитрати на реалізацію необхідної функціональності надто великі, то перевищення бюджету та порушення термінів можна буде уникнути шляхом співвіднесення пріоритетів розробки та трудовитрат на початку кожної ітерації. Таким чином, дана модель добре підходить для більшості типів програмних проектів, але особливо її переваги помітні при роботі над продуктами, призначеними для виходу на вільний ринок, через початкову орієнтацію на випуск послідовних версій.

Найвідомішим та авторитетним стандартом якості слід вважати Capability Maturity Model (CMM) – модель оцінки рівня зрілості процесів розробки разом із його похідними. Він був створений SEI (Software Engineering Institute), який фінансується за рахунок Міністерства оборони США та є структурною одиницею Університету Карнегі-Меллона. Перша офіційна версія стандарту вийшла в 1993 році, хоча роботи над ним почалися набагато раніше - основні його положення були опубліковані ще в 1986 році. Успіх CMM зумовив кілька факторів. Цей стандарт був одним із перших, які спочатку враховували специфіку створення програмного забезпечення. Він виявився досить простим і прозорим як для розуміння, так і для використання, і регламентував, що, а не як робити, а тому підходив для різних моделей життєвого циклу, методологій розробки і не накладав будь-яких обмежень на стандарти документування. , інструментарій, середовище та мови, що застосовуються у проектах. І, мабуть, основним фактором, який визначив популярність CMM, стало співробітництво SEI з Міністерством оборони США, що де-факто означало використання стандарту при реалізації проектів на замовлення цього відомства.

Модель CMM (таблиця 1) передбачає п'ять рівнів зрілості, кожному з яких відповідають певні ключові сфери процесів (Key Process Areas, KPA) .

Таблиця 1-Модель СММ

Назва рівня

Ключові сфери процесу

1 - Початковий

Якщо організація перебуває на цьому рівні, то ключових областей процесів для неї не передбачено

2 - Повторюваний

Управління програмними конфігураціями. Забезпечення якості програмних продуктів. Управління контрактами підрядників. Контроль за перебігом проектів. Планування програмних проектів Управління вимогами

3 - Певний

Експертні оцінки. Координація взаємодій проектних груп. Інженерія програмного продукту Комплексний менеджмент ПЗ. Програма навчання персоналу Визначення організаційного процесу. Область дії організаційного процесу

4 - Керований

Менеджмент якості ПЗ. Управління процесом на основі кількісних методів

5 - Оптимізований

Управління зміною процесу. Управління технологічними змінами. Запобігання дефектам

Поділ на рівні та визначення KPA для кожного з них дозволяє послідовно впроваджувати CMM, використовуючи стандарт як посібник, який може забезпечити постійне вдосконалення процесу розробки.

Стандарт CMM виявився досить успішним, і згодом на його основі була створена ціла серія стандартів, а він отримав нове ім'я - SW-CMM (Capability Maturity Model for Software), що точніше відбиває його становище у досить численному сімействі стандартів.

Однак практичне застосування стандартів серії CMM показало, що вони не забезпечують беззастережного успіху у розробці програмного забезпечення. Ці стандарти не були добре узгоджені між собою - одночасне впровадження різних модифікацій CMM могло виявитися досить складним завданням, і дивувало фахівців організацій, які з цим стикалися.

Також суттєва проблема CMM полягає у необхідності «вирівнювання» всіх процесів. Якщо організація намагається сертифікуватись на певний рівень, то вона має забезпечити відповідний рівень для всіх своїх процесів. Навіть якщо специфіка, методологія чи особливості розробки не схильні до виконання певних процесів, сертифікація це вимагає.

Ще одна проблема викликана тим становищем, яке зайняли стандарти CMM у сучасній індустрії програмного забезпечення. Оскільки організація, яка має високий рівень відповідно до CMM, повинна забезпечувати більш високі показники програмних продуктів порівняно з тими, хто сертифікований на нижчих рівнях, то стандарт став застосовуватися як критерій відбору для участі в тендерах на розробку програмного забезпечення або в аутсорсингових проектах.

Подібна ситуація стала можливою завдяки недолікам процесу сертифікації. Сертифікації підлягає не вся організація загалом, лише певний проект. Ніщо не заважає організації створити «зразково-показовий» проект, який виконується з урахуванням усіх вимог високих рівнів стандарту CMM, отримати відповідний рівень сертифікації та заявити про те, що всі продукти відповідають такому рівню стандарту.

Вирішити більшість проблем CMM має новий стандарт SEI - Capability Maturity Model Integrated (CMMI) - інтегрована модель оцінки рівня зрілості процесів розробки. Стандарт CMMI спочатку створювався таким чином, щоб об'єднати існуючі варіанти CMM та виключити будь-які суперечності при його практичному застосуванні у різних сферах діяльності високотехнологічних компаній.

Для того щоб усунути необхідність «вирівнювання» процесів організації та бути більш пристосованим до її бізнес-потреб, а не навпаки, стандарт CMMI має дві форми уявлення – класичну, багаторівневу, відповідну CMM, та нову, безперервну. Безперервна форма подання розглядає не рівні зрілості (Maturity Levels), а рівні можливостей (Capability Levels), які оцінюються окремих областей процесів (Process Areas, PA).

У таблиці 2 дано відповідність рівнів зрілості стандарту CMM, а також рівнів зрілості багаторівневого подання CMMI та рівнів можливостей безперервного подання CMMI.

Таблиця 2- Відповідність рівнів зрілості стандартів CMM, CMMI

SEI відмовляється від CMM і натомість активно просуває CMMI, обіцяючи посилити контроль за процесом сертифікації, скоротити витрати на нього та зробити його більш привабливим для невеликих організацій; забезпечуючи сумісність із стандартами ISO.

У сучасних умовах наявність сертифіката певного рівня CMM/CMMI не є таким значущим фактором, як кілька років тому, і приймається без додаткових питань хіба що у проектах, які виконуються на державне замовлення.

Стандарт ISO/IEC 15504 призначений для оцінки процесу розробки інформаційних систем, зокрема програмного забезпечення. Він спочатку був спроектований таким чином, щоб значною мірою відповідати існуючим у галузі стандартам оцінки процесу створення програмного забезпечення. Саме ця вимога визначила схожість стандарту з основними принципами CMM/CMMI.

Модель зрілості процесу розробки програмного забезпечення (CMM), розроблена Інститутом програмної інженерії в університеті Carnegie Mellon, пропонує п'ять рівнів зрілості (таблиця 3). Вона допомагає організаціям підвищити зрілість своїх процесів розробки програмного забезпечення, і організації можуть бути оцінені та акредитовані відповідно до цих рівнів.

Таблиця 3-Рівні зрілості розробки програмного забезпечення

Рівень 1 – початковий рівень

Процес розробки ПЗ спонтанний, і регламентовані лише деякі процеси. Успіх розробки може залежати від окремих працівників.

Рівень 2 – рівень повторюваності

Створено основні процеси управління проектами для відстеження витрат, календарного плану та функціональних можливостей.

Рівень 3 – рівень регламентованості

Процес розробки програмного забезпечення документований, стандартизований та інтегрований зі стандартним процесом розробки програмного забезпечення організації як для операцій управління, так і для операцій розробки. У всіх проектах використається стандартизований процес.

Рівень 4 – рівень керованості

Проводиться збір докладних показників процесу розробки та якості продукту, що дозволяє зрозуміти процес і продукти і керувати ними.

Рівень 5 – рівень оптимізованості

Безперервна оптимізація процесу забезпечується кількісним зворотним зв'язком від процесу та від пілотних інноваційних ідей та технологій.

Таким чином, сучасні моделі та методи, що використовуються в реальних проектах розробки програмного забезпечення, дуже різноманітні. Кожен із них має свої переваги, які виявляються у відповідних умовах. Навіть застаріла водоспадна модель абсолютно адекватна для деяких проектів. Кожен процес має також і ряд характеристик, які обмежують область його ефективного використання. Ця ситуація є цілком типовою для розробки програмного забезпечення, де вже накопичено безліч технологій і методик, але не існує універсального методу, оптимального для будь-якого завдання.

С. Архіпенков

Моделі (або, як ще люблять говорити, методології) процесів розробки ПЗ прийнято класифікувати за "вагою" - кількістю формалізованих процесів (більшість процесів або лише основні) та детальності їх регламентації. Чим більше процесів документовано, чим детальніше вони описані, тим більше "вага" моделі.

Найбільш поширені сучасні моделі процесу розробки ПЗ представлені на Рисунку 3.

Малюнок 3 Різні моделі процесу розробки ПЗ та їх розподіл за "вагою"

ГОСТи

ГОСТ 19 "Єдина система програмної документації" та ГОСТ 34 "Стандарти на розробку та супровід автоматизованих систем" орієнтовані на послідовний підхід до розробки ПЗ. Розробка відповідно до цих стандартів проводиться за етапами, кожен з яких передбачає виконання строго певних робіт, і завершується випуском досить великої кількості формалізованих і великих документів. Отже, суворе дотримання цим гостам як призводить до водопадному підходу, а й вимагає дуже високого ступеня формалізованості розробки. На основі цих стандартів розробляються програмні системи з держзамовлень у Росії.

SW-CMM

У середині 80-х років минулого століття Міністерство оборони США міцно задумалося про те, як обирати розробників програмного забезпечення при реалізації великомасштабних програмних проектів. На замовлення військових Інститут програмної інженерії, що входить до складу Університету Карнегі-Меллона, розробив SW-CMM, Capability Maturity Model for Software як еталонну модель організації розробки програмного забезпечення.

Ця модель визначає п'ять рівнів зрілості процесу розробки.

  1. Початковий - процес розробки має хаотичний характер. Визначено лише небагато з процесів, і успіх проектів залежить від конкретних виконавців.
  2. Повторюваний – встановлені основні процеси управління проектами: відстеження витрат, термінів та функціональності. Упорядковано деякі процеси, необхідні для того, щоб повторити попередні досягнення на аналогічних проектах.
  3. Певний - процеси розробки ПЗ та управління проектами описані та впроваджені в єдину систему процесів компанії. У всіх проектах використовується стандартний організації процес розробки та підтримки програмного забезпечення, адаптований під конкретний проект.
  4. Керований - збираються детальні кількісні дані щодо функціонування процесів розробки та якості кінцевого продукту. Аналізується значення та динаміка цих даних.
  5. Оптимізований - постійне поліпшення процесів ґрунтується на кількісних даних щодо процесів та на пробному впровадженні нових ідей та технологій.

Документація з повним описом SW-CMM займає близько 500 сторінок і визначає набір із 312 вимог, яким повинна відповідати організація, якщо вона планує атестуватися за цим стандартом на 5-й рівень зрілості.

RUP

Уніфікований процес (Rational Unified Process, RUP) був розроблений Філіпом Крачтеном (Philippe Kruchten), Іваром Якобсоном (Ivar Jacobson) та іншими співробітниками компанії "Rational Software" як доповнення до мови моделювання UML. Модель RUP визначає абстрактний загальний процес, на основі якого організація або проектна команда має створити конкретний спеціалізований процес, орієнтований на її потреби. Саме ця риса RUP викликає основну критику - оскільки він може бути будь-чим, його не можна вважати нічим певним. В результаті такої загальної побудови RUP можна використовувати і як основу для традиційного водоспадного стилю розробки, так і як гнучкого процесу.

MSF

Microsoft Solutions Framework (MSF) - це гнучка та досить легковажна модель, побудована на основі ітеративної розробки. Привабливою особливістю MSF є велика увага до створення ефективної та небюрократизованої проектної команди. Для досягнення цієї мети MSF пропонує досить нестандартні підходи до організаційної структури, розподілу відповідальності та принципів взаємодії всередині команди.

PSP/TSP

Один із останніх розробок Інституту програмної інженерії Personal Software Process / Team Software Process [ , ]. Personal Software Process визначає вимоги до компетенцій розробника. Відповідно до цієї моделі кожен програміст має вміти:

  • враховувати час, витрачений працювати над проектом;
  • враховувати знайдені дефекти;
  • класифікувати типи дефектів;
  • оцінювати розмір завдання;
  • здійснювати систематичний підхід до опису результатів тестування;
  • планувати програмні завдання;
  • розподіляти їх за часом та складати графік роботи.
  • виконувати індивідуальну перевірку проекту та архітектури;
  • здійснювати індивідуальну перевірку коду;
  • виконувати регресійне тестування.

Team Software Process робить ставку на самоврядні команди чисельністю 3-20 розробників. Команди повинні:

  • встановити власні цілі;
  • скласти свій процес та плани;
  • відстежувати роботу;
  • підтримувати мотивацію та максимальну продуктивність.

Послідовне застосування моделі PSP/TSP дозволяє зробити нормою організації п'ятий рівень CMM.

Agile

Основна ідея всіх гнучких моделей полягає в тому, що процес, що застосовується в розробці, повинен бути адаптивним. Вони декларують своєю вищою цінністю орієнтованість на людей та їхню взаємодію, а не на процеси та засоби. По суті, так звані, гнучкі методології це не методології, а набір практик, які можуть дозволити (а можуть і ні) домагатися ефективної розробки ПЗ, ґрунтуючись на ітеративності, інкрементальності, самоврядності команди та адаптивності процесу.

Вибір моделі процесу

Важкі та легкі моделі виробничого процесу мають свої переваги та недоліки (Таблиця 1).

Таблиця 1. Плюси та мінуси важких та легких моделей процесів розробки ПЗ

Вага моделі Плюси Мінуси
Важкі Процеси розраховані середню кваліфікацію виконавців. Велика спеціалізація виконавців. Нижче вимоги до стабільності команди.

Відсутні обмеження щодо обсягу та складності виконуваних проектів.

 Вимагають суттєвої управлінської надбудови.

Більш тривалі стадії аналізу та проектування.

Більше формалізовані мунікації.
Легкі Менше непродуктивних витрат, пов'язаних із управлінням проектом, ризиками, змінами, конфігураціями.

Спрощені стадії аналізу та проектування, основний упор на розробку функціональності, поєднання ролей. Неформальні комунікації.

 Ефективність сильно залежить від індивідуальних здібностей, які вимагають більш кваліфікованої, універсальної та стабільної команди.

Обсяг та складність виконуваних проектів обмежені.

Ті, хто намагається слідувати описаним у книгах моделям, не аналізуючи їх застосування у конкретній ситуації, показання та протипоказання, уподібнюються послідовникам культу "Карго" - релігії літакопоклонників. У Меланезії вірять, що західні товари (карго, англ. вантаж) створені духами предків та призначені для меланезійського народу. Вважається, що білі люди нечесним шляхом одержали контроль над цими предметами. У найбільш відомих культах карго з кокосових пальм та соломи будуються точні копії злітно-посадкових смуг, аеропортів та радіовишок. Члени культу будують їх, вірячи в те, що ці споруди залучать транспортні літаки (які вважаються посланцями парфумів), заповнені вантажем (карго). Віруючі регулярно проводять стройові вчення ("муштру") і таке собі подібність військових маршів, використовуючи гілки замість гвинтівок і малюючи на тілі ордени і написи "USA". Все це для того, щоб знову з неба спустилися літаки і цих предметів побільшало.

Алістер Коуберн, один із авторів "Маніфесту гнучкої розробки ПЗ" проаналізував дуже різні програмні проекти, які виконувались за різними моделями від абсолютно полегшених та "гнучких" до важких (СММ-5) за останні 20 років [ , ]. Він не виявив кореляції між успіхом чи провалом проектів та моделями процесу розробки, які застосовувалися у проектах. Звідси він зробив висновок про те, що ефективність розробки програмного забезпечення не залежить від моделі процесу, а також про те, що:

  • Кожен проект має мати свою модель процесу розробки.
  • Кожна модель має свій час.

Це означає, що немає єдиного правильного процесу розробки ПЗ, у кожному новому проекті процес повинен визначатися щоразу заново, залежно від проекту, продукту та персоналу, у відповідність до "Законом 4-х П" (Малюнок 4). Цілком різні процеси повинні застосовуватися в проектах, у яких беруть участь 5 осіб, та у проектах, у яких беруть участь 500 осіб. Якщо продуктом проекту є критичне ПЗ, наприклад система управління атомною електростанцією, то процес розробки повинен сильно відрізнятися від розробки, наприклад, сайту "отдохни.ру". І, нарешті, по-різному слід організовувати процес розробки в команді вчорашніх студентів і в команді професіоналів.


Малюнок 4. "Закон 4-х П". Процес у проекті має визначатися залежно від проекту, продукту та персоналу

Команда, яка розпочинала проект, не залишається незмінною, вона проходить певні стадії формування та, як правило, кількісно зростає в міру розвитку проекту. Тому процес має постійно адаптуватися до цих змін. Головний принцип: не люди повинні будуватися під обрану модель процесу, а модель процесу має підлаштовуватися під конкретну команду, щоб забезпечити її найвищу ефективність.

Що треба робити для успіху програмного проекту

Стів Макконнелл у своїй книзі наводить тест програмного проекту на виживання. Цей чек-лист із 33-х пунктів, який я вважаю за необхідне процитувати з невеликими коригуваннями. Керівник програмного проекту повинен періодично використовувати його для внутрішнього аудиту своїх процесів.

Щоб програмний проект став успішним, необхідно:

  1. Чітко ставити цілі.
  2. Визначати спосіб досягнення мети.
  3. Контролювати та керувати реалізацією.
  4. Аналізувати загрози та протидіяти їм.
  5. Створювати команду.
  1. Ставимо цілі

    1.1. Концепція визначає ясні недвозначні цілі.
    1.2. Усі члени команди вважають концепцію реалістичною.
    1.3. Проект має обґрунтування економічної ефективності.
    1.4. Розроблено прототип інтерфейсу користувача.
    1.5. Розроблено специфікацію цільових функцій програмного продукту.
    1.6. З кінцевими користувачами продукту налагоджено двосторонній зв'язок

  2. Визначаємо спосіб досягнення цілей

    2.1. Є детальний письмовий план розробки товару.
    2.2. До списку завдань проекту включені "другорядні" завдання (управління конфігураціями, конвертація даних, інтеграція з іншими системами).
    2.3. Після кожної фази проекту оновлюється розклад та бюджет.
    2.4. Архітектура та проектні рішення документовані.
    2.5. Є план забезпечення якості, що визначає тестування та рецензування.
    2.6. Визначено план багатоетапного постачання товару.
    2.7. У плані враховано навчання, вихідні, відпустки, лікарняні.
    2.8. План проекту та розклад схвалено всіма учасниками команди.

  3. Контролюємо та керуємо реалізацією

    3.1. Проект має куратора. Це такий топ-менеджер компанії, що виконує, який особисто зацікавлений в успіху даного проекту.
    3.2. У проекту є менеджер, причому лише один!
    3.3. У плані проекту визначено "бінарні" контрольні точки.
    3.4. Усі заінтересовані сторони можуть отримати необхідну інформацію про хід проекту.
    3.5. Між керівництвом та розробниками встановлені довірчі відносини.
    3.6. Встановлено процедуру управління змінами у проекті.
    3.7. Визначено осіб, відповідальних за рішення про ухвалення змін у проекті.
    3.8. План, розклад та статусна інформація щодо проекту доступна кожному учаснику.
    3.9. Код системи відбувається автоматичне рецензування.
    3.10. Застосовується система керування дефектами.

  4. Аналізуємо погрози

    4.1. Є перелік ризиків проекту. Здійснюється його регулярний аналіз та оновлення.
    4.2. Керівник проекту відстежує виникнення нових ризиків.
    4.3. Для кожного підрядника визначено особу, відповідальну за роботу з нею.

  5. Працюємо над створенням команди

    5.1. Досвід команди достатній для виконання проекту.
    5.2. У команди достатня компетенція у прикладній галузі.
    5.3. У проекті є технічний лідер.
    5.4. Чисельність персоналу достатня.
    5.5. У команди є достатня згуртованість.
    5.6. Усі учасники віддані проекту.

Оцінка та інтерпретація тесту

Оцінка: сума балів, кожен пункт оцінюється від 0 до 3:

  • 0 - навіть не чули про це;
  • 1 - чули, але поки що не застосовуємо;
  • 2 – застосовується частково;
  • 3 - застосовується повною мірою.

Поправочні коефіцієнти:

  • для малих проектів (до 5 осіб) – 1.5;
  • для середніх (від 5 до 20 осіб) – 1.25.

Результат:

  • <40 - завершение проекта сомнительно.
  • 40-59 – середній результат. У ході проекту слід очікувати на серйозні проблеми.
  • 60-79 – гарний результат. Проект, найімовірніше, буде успішним.
  • 80-89 – відмінний результат. Імовірність успіху висока.
  • >90 - чудовий результат. 100% шансів на успіх.

Цей чек-лист перераховує, що треба робити для успіху програмного проекту, але не дає відповіді на питання, як це слід робити. Саме про це йтиметься в решті лекцій.