Цикл розробки програмного забезпечення

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

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

Зміст

1 Передмова

2 Дії в процесі написання програмного забезпечення

2.1 Аналіз вимог до продукту

2.2 Специфікація

2.3 Архітектура

2.4 Проектування, реалізація і тестування

2.5 Розповсюдження та підтримка

3 Моделі

3.1 Водоспад

3.1.1 Гнучка модель розробки

3.2 Ітеративна та інкрементна модель - еволюційний підхід. 

3.2.1 Спіральна модель 
 
3.2.2 XP: Екстремальне програмування

3.3 Інші моделі

4 Формальні методи

5 Див також

6 Примітки

 7 Links 

Передмова

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

Дії у процесі написання програмного забезпечення

Дії у процесі написання, представлені в моделі водоспаду (дивись рисунок). Є й інші моделі, які по іншому описують цей процес.

Малюнок 2. Водоспадна модель.

Аналіз вимог до продукту

Найважливіше завдання при створенні програмного продукту - це вироблення вимог, або аналіз вимог до продукту. Замовник найчастіше представляє досить розмиту ідею про те, яким повинен бути кінцевий результат, і не має уявлення про те, як повинна працювати програма. Незакінчені, безглузді, а іноді суперечать один одному вимоги розпізнаються добрими інженерами на цій стадії. Часта демонстрація живого коду може зменшити ризик того, що початкові вимоги були не вірні. Один з методів знаходження проблем такого роду - це аналіз елементів програмного забезпечення.
Коли загальні вимоги отримані від клієнта, їх необхідно уточнити і відобразити в документі. Реалізована функціональність може відрізнятися від визначеної, в результаті високої вартості розробки та / або незрозумілих вимогах до продукту. Якщо розробка проводиться поза фірмою замовника, то даний документ може використовуватися для вирішення питань пов'язаних з функціональністю продукту.
Аналіз області роботи часто є першою сходинкою проектування нового фрагмента програмного забезпечення, незалежно від того, чи є він додаванням до вже існуючого додатка або новим додатком, підсистемою або зовсім новою системою. Зважаючи на те, що розробники (так само як і аналітик) не є на початку досить освіченими у галузі нового програмного забезпечення, перше завдання - це власне дослідження цієї самої галузі. Чим краще розробники знають область, в якій працюють, тим менше потім виникає роботи. Також її проводять для того, щоб пізніше не з'являлося плутанини в термінології, і розумінні того, що робить ця програма. Якщо аналітик використовує невірну термінологію, то знову ж таки можливі непорозуміння, в результаті того, що програма буде робити не те, що потрібно. Ця робота виключає випадки на зразок «Я знаю, що ви вірите в те, що зрозуміли, що я говорю, але я не впевнений, що ви розумієте, що те, що ви чули - це не те, що я маю на увазі.»

Специфікація

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

Архітектура

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

Проектування, реалізація і тестування

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

Розповсюдження та підтримка

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

Моделі

Водоспад

Моделлю водоспаду називається методологія, що розділяє процес розробки на наступні етапи (ступені):
1.Спеціфікація вимог

2.Проектування

3.Кодірованіе

4.Інтеграція

5.Тестірованіе та налагодження (валідація та верифікація)

6.Установка

7 . Підтримка

Гнучка модель розробки

Гнучка модель розробки створена організаціями, що займаються розробкою ітераційної. Для цього використовується більш гнучкий, централізований на людях підхід, ніж використовується в традиційних підходах. Гнучкі процеси використовують зворотний зв'язок замість планування як головного контролюючого механізму. Зворотній зв'язок ведеться за допомогою регулярних тестів, а також частих релізів розробки продукту. Цікаво, що дослідження показують потенціал для хорошого поліпшення продуктивності щодо стандартного «Водопадного» методу. Наприклад дослідження, опубліковане в серпні 2006 року, і базоване на опитуваннях більш ніж 700 компаній, свідчить про величезний прибуток при використанні цієї моделі. Дослідження було повторене в серпні 2007 року з базою в 1,700 компаній.

Ітеративна та інкрементна модель - еволюційний підхід.

Малюнок 2. Ітеративна та інкрементна модель.

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

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

Еволюційна модель має на увазі не лише складання працюючої (з точки зору результатів
тестування) версії системи, але і її розгортання в реальних умовах з аналізом відгуків користувачів для визначення змісту і планування наступної ітерації. "Чиста" інкрементна модель не передбачає розгортання проміжних збірок (релізів) системи і всі ітерації проводяться за наперед визначеним планом нарощування функціональності, а користувачі (замовник) отримує тільки результат фінальної ітерації як повну версію системи. З іншого боку, Скотт Амблер [Ambler, 2004], наприклад, визначає еволюційну модель як поєднання ітеративного та інкрементального підходів. У свою чергу, Мартін Фаулер [Фаулер, 2004, с.47] пише: "ітеративну розробку називають по- різному: інкрементна, спіральна, еволюційна і поступова. Різні люди вкладають у
ці терміни різний зміст, але ці відмінності не мають широкого визнання і не так важливі, як
протистояння ітеративного методу і методу водоспаду. "

Брукс пише [Брукс, 1995, с.246-247], що, в ідеалі, оскільки на кожному кроці ми маємо
працюючу систему:


• можна дуже рано почати тестування користувачами;


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

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

Спіральна модель 

Спіральна модель (представлена на рисунку 3) була вперше сформульована Баррі Боемом
(Barry Boehm) у 1988 році [Boehm, 1988]. Відмінною особливістю цієї моделі є спеціальна увага на ризиках, що впливає на організацію життєвого циклу. 

Боем формулює "top-10" найбільш поширених (за пріоритетами) ризиків (використовується з
дозволу автора):

1. Дефіцит фахівців.
2. Нереалістичні терміни і бюджет.
3. Реалізація невідповідної функціональності.
4. Розробка неправильного користувальницького інтерфейсу.
5. "Золота сервіровка", перфекціонізм, непотрібна оптимізація і відточування деталей.
6. Безперервний потік змін.
7. Брак інформації про зовнішні компоненти, що визначають оточення системи залученої до інтеграції.
8. Недоліки в роботах, виконуваних зовнішніми (по відношенню до проекту) ресурсами.
9. Недостатня продуктивність одержуваної системи.
10. "Розрив" в кваліфікації фахівців різних галузей знань.

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

Малюнок 3. Оригінальна спіральна модель життєвого циклу розробки по Боему  (Використовується з дозволу автора) [Boehm, 1988]

Сам Баррі Боем так характеризує спіральну модель розробки (використовується з дозволу
автора):

"Головне досягнення спіральної моделі полягає в тому, що вона пропонує спектр можливостей

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

Спіральна модель володіє рядом переваг:

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

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

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

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

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

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

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

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

Описуючи створену спіральну модель, Боем звертає увагу на те, що маючи явні переваги в порівнянні з іншими поглядами на життєвий цикл, необхідно уточнити, деталізувати кроки, тобто цикли спіральної моделі для забезпечення цілісного контексту для всіх осіб, залучених до проекту (Боем це формулює так: "Need for further elaboration of spiral model steps. In general, the spiral model process steps need further elaboration to ensure that all software development participants are operating in a consistent context. "). Організація ролей (Відповідальності членів проектної команди), деталізація етапів життєвого циклу і процесів, визначення активів (артефактів), важливих на різних етапах проекту, практики аналізу та попередження ризиків - все це питання вже конкретного процесного фреймворку або, як прийнято говорити, методології розробки. 

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

У 2000 році [Boehm, 2000], представляючи аналіз використання спіральної моделі і, зокрема,
побудованого на його основі підходу MBASE - Model-Based (System) Architecting and Software
Engineering (MBASE), Боем формулює 6 ключових характеристик або практик, що забезпечують
успішне застосування спіральної моделі:

1. Паралельне, а не послідовне визначення артефактів (активів) проекту
2. Згода в тому, що на кожному циклі приділяється увага::
• цілям та обмеженням, важливим для замовника
• альтернатив організації процесу і технологічних рішень, які закладаються в продукт
• ідентифікації та вирішення ризиків
• оцінки з боку зацікавлених осіб (у першу чергу замовника)
• досягнення згоди в тому, що можна і необхідно рухатись далі
3. Використання міркувань, пов'язаних з ризиками, для визначення рівня зусиль, необхідного для кожної роботи на всіх циклах спіралі.
4. Використання міркувань, пов'язаних з ризиками, для визначення рівня деталізації кожного артефакту, що створюється на всіх циклах спіралі.
5. Управління життєвим циклом в контексті зобов'язань усіх зацікавлених осіб на основі трьох контрольних точок:
• Life Cycle Objectives (LCO)
• Life Cycle Architecture (LCA)
• Initial Operational Capability (IOC)
6. Приділення спеціальної уваги до проектних робіт і артефактів створюваної системи (Включаючи безпосередньо програмне забезпечення яке розробляється, її оточення, а також експлуатаційні характеристики) та життєвого циклу (розроблення та використання). 

Еволюціонування спіральної моделі пов'язано з питаннями деталізації робіт. Особливо варто виділити акцент на більш важливих питаннях - вимог, дизайну та коду, тобто надання більшої важливості питанням ітерацій, в тому числі, збільшення їх кількості при скороченні тривалості кожної ітерації. У результаті, можна визначити загальний набір контрольних точок в сьогоднішній спіральної моделі:
• Concept of Operations (COO) - концепція <використання> системи;
• Life Cycle Objectives (LCO) - цілі і зміст життєвого циклу;
• Life Cycle Architecture (LCA) - архітектура життєвого циклу; тут же можливо говорити про  готовності концептуальної архітектури цільової програмної системи;
• Initial Operational Capability (IOC) - перша версія створюваного продукту, придатна для дослідної експлуатації;
• Final Operational Capability (FOC) - готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації. 

Таким чином, ми приходимо до можливого сучасному погляду (див., наприклад, подання  спіральної моделі в [Фатрелл, Шефер і Шафер, 2003, с.159]) на ітеративний і  інкрементальинй- еволюційний життєвий цикл у формі спіральної моделі, зображеної на рисунку 4.

Малюнок 4. Оновлена спіральна модель c контрольними точками проекту.

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

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

• Rational Unified Process (RUP)
• Enterprise Unified Process (EUP)
• Microsoft Solutions Framework (MSF) попередньої версії 3 та її якісного оновлення - Версії 4 в обох виставах: MSF for Agile і MSF for CMMI (анонсована  спочатку як "MSF Formal")
• Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), SCRUM ,...).

XP: Екстремальне програмування

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

Інші моделі

ISO / IEC 15504 - один з американських стандартів Six sigma - методологія для управління варіативністю процесу, що використовує дані і статистичний аналіз, щоб виміряти і збільшити продуктивність компанії. Test Driven Development - розробка через тестування - техніка програмування, при якій модульні тести для програми або її фрагмента пишуться до самої програми і, по суті, управляють її розробкою. Є однією з основних практик екстремального програмування.

Формальні методи

Формальні методи - математичні представлення проблеми створення програмного забезпечення, а також обладнання на рівнях вимог, специфікації, а також дизайну. Як приклад можна навести B-Method, Мережі Петрі, RAISE. Доступні різні формальні нотації специфікацій, такі як Z notation. Частіше за все для створення та валідації додатків і їх дизайну використовується теорія кінцевих автоматів.
Формальні методи використовуються при розробці авіаційного софту, а також там, де безпека софта найбільш критична. Існують так само стандарти на критерії безпеки.

Links:
http://sorlik.blogspot.com
http://ru.wikipedia.org/wiki/Цикл_разработки_программного_обеспечения