Організація процесу проектування

В даній лекції проведемо визначення базових понять технології проект­тування програмного забезпечення (ПЗ). Розглянемо основні підходи процесу проектування.

1. Визначення технології конструювання ПЗ.

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

Розрізняють методи, засоби та процедури (ТКПЗ).

Методи забезпечують вирішення наступних задач:

• планування та оцінка проекту;

• аналіз системних та програмних вимог;

• проектування алгоритмів, структур даних і програмних структур;

• кодування;

• тестування;

• супроводження.

Засоби (утілити) (ТКПЗ) забезпечують автоматизовану або автоматичну підтримку методів. В цілях спільного застосування утиліти можуть об’єднува­тися в системи автоматизованого конструювання ПЗ. Такі системи прийнято називати CASE-стстеми. Абревіатура CASE розшифровується як Computer Aided Software Engineering (програмна інженерія з комп’ютерною підтримкою).

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

• порядок застосування методів та утиліт;

• формування звітів, форм за відповідними вимогами;

• контроль, який допомагає забезпечити якість і координувати зміни;

• формування «віх», за якими керівник оцінює прогрес.

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

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

2. Класичний життєвий цикл

Найстарішою парадигмою процесу розробки ПЗ є класичний життєвий цикл (автор Уїнстон Ройс, 1970).

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

Охарактеризуємо зміст основних етапів.

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

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

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

Проектування складається з створення:

• архітектури ПЗ;

• модульної структури ПЗ;

• алгоритмічної структури ПЗ;

• структури даних;

• вхідного та вихідного інтерфейсу (вхідних і вихідних форм даних).

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

Кодування є процес перекладу результатів проектування на мову прог­ра­мування.

Тестування – виконання програми для виявлення дефектів в функціях, логіці і формі реалізації програмного продукту.

Супроводження – це внесення змін в працююче ПЗ. Мета змін:

• виправлення помилок;

• адаптація до зміни зовнішнього для ПЗ середовища;

• вдосконалення ПЗ за вимогою замовника.

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

Як і довільна інженерна схема, класичний життєвий цикл має переваги і недоліки.

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

Недоліки класичного життєвого циклу:

1. Реальні проекти часто вимагають відхилення від стандартної послідовності кроків.

2. Цикл базується на точному формулювання вихідних вимог до ПЗ (реально на початку проекту вимоги замовника визначені лише частково).

3. Результати проекту досяжні замовнику лише по закінченню роботи.

4. Макетування

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

Основна мета макетування – зняти невизначеності в вимогах замовника.

Макетування – це процес створення моделі необхідного програмного продукту.

Модель може приймати одну з трьох форм:

1. Паперовий макет або макет на основі ПК (створює або малює людино-машинний діалог).

2. Працюючий макет (виконує деяку частину заданих функцій).

3. Існуюча програма (характеристики якої в подальшому будуть покращені).

Як показано на рис.2.2, макетування базується на багаторазовому повто­рення ітерацій, в яких приймає участь замовник і розробник.

П ослідовність дій при макетуванні зображена на рис. 2.3.

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

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

Швидке проектування приводить до створення макету.

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

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

Преваги макетування: забезпечує визначення повних вимог до ПЗ.

Недоліки макетування:

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

• розробник може сприйняти макет за продукт.

Пояснимо суть недоліків. Коли замовник бачить працюючу версію ПЗ, він перестає розуміти, деталі макету скріплені «жвачкою і дротом»; він забуває, що в гонитві за працюючим варіантом залишені питання якості і зручності суп­роводу ПЗ. Коли замовник говорить, що продукт повинен бути перебудова­ний, він починає вимагати, щоб макет «швидко» був перероблений в робочий про­дукт. Дуже часто це негативно впливає на управління розробкою ПЗ.

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

5. Стратегії конструювання ПЗ

Існує три стратегії конструювання ПЗ:

• однократний прохід (водоспадна стратегія) – лінійна послідовність етапів конструювання;

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

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

Характеристики стратегій конструювання ПЗ в відповідності до вимог стандарту IIIE/EIA 12207 наведено в табл. 2.1.

Таблиця 1.1. Характеристики стратегій конструювання

Стратегії конструювання	На початку процесу визначені всі вимоги?	Множина циклів конструювання?	Проміжне ПЗ поширюється?
Одноразовий прохід	Так	Ні	Так
Інкрементальна (заплановане покращення продукту)	Так	Так	Може бути
Еволюційна	Ні	Так	Так

4. Інкрементна модель

Інкрементна модель є класичним прикладом інкрементної стратегії кон­струювання (рис. 2.4). Вона об’єднує елементи послідовної водоспадної моделі з ітераційною філософією макетування.

Кожна лінійна послідовність тут виробляє користувацький інкремент ПЗ. Наприклад, ПЗ для обробки слів в 1-му інкремент реалізує функції базової обробки файлів, функції редагування і документування; в 2-му інкремент – більш складні можливості; в 3-му інкремент – перевірку орфографії і грамати­ки; в 4-му – можливості компоновки сторінок.

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

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

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

Зауважимо, що сучасна реалізація інкрементного підходу – екстрема­ль­не програмування ХР (Кент Бек, 1999). Воно орієнтоване на дуже мале збіль­шення функціональності.

Швидка розробка додатків

Модель швидкої розробки додатків (Rapid Application Development) – інший приклад застосування інкрементної стратегії конструювання (рис. 1.5).

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

• бізнес-моделювання. Моделюється інформаційний потік між біз­нес-функціями. Ведеться пошук відповіді на наступні питання: Яка інформація керує бізнес процесом? Яка генерується інформація? Хто її генерує? Де ін фор­мація застосовується? Хто її опрацьовує?

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

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

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

Застосування RAD можливо в тому випадку, коли кожна головна функ­ція може бути завершена за 3 місяці. Кожна головна функція адресується окре­мій групі розробників, а в наступному інтегрується в цілу систему.

Застосування RAD має свої недоліки та обмеження.

1. Для великих проектів в RAD необхідні значні людські ресурси ( необ­хідно створити достатню кількість груп).

2. RAD можливо застосувати до таких додатків, які можуть декомпозу­ва­тися на окремі модулі і в яких продуктивність не є критичною величиною.

3. RAD не застосовують в умовах високих технічних ризиків (тобто при використанні нової технології).

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

Спіральна модель – класичний приклад застосування еволюційної стра­тегії конструювання.

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

Як показано на рис. 1.6. модель визначає чотири дії, що зображаються чотирма календарними спіралями.

1. Планування – визначення цілей, варіантів та обмежень.

2. Аналіз ризику – аналіз варіантів та розпізнавання/вибір ризику.

3. Конструювання – розробка продукту наступного рівня.

4. Оцінювання – оцінка замовником біжучих результатів конструюван­ня.

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

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

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

Переваги спіральної моделі:

1. найбільш реально (в вигляді еволюції) відображає розробку програм­ного забезпечення;

2. дозволяє явно враховувати ризик на кожному витку еволюції розробки;

3. включає крок системного підходу в ітераційну структуру розробки;

4. використовує моделювання для зменшення ризику і покращення ПЗ.

Недоліки спіральної моделі:

1. новизна (відсутня достатня статистика ефективності моделі);

2. підвищені вимоги до замовника;

3. трудність контролю і управління часом розробки.

Компонентно-орієнтована модель

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

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

Переваги компонентно-орієнтованої моделі:

1. зменшує на 30% час розробки програмного продукту;

2. зменшує вартість програмної розробки до 70%;

3. збільшує в півтора рази продуктивність роботи.

В ажковагові та полегшені процеси.

Традиційно для впорядкування і прискорення програмних розробок пропонувались строго впорядковані важковагові (heavyweight) процеси. В цих процесах прогнозується весь об’єм робіт, тому вони називаються прогнозую­чи­ми (predictive) процесами. Порядок, який має виконувати при цьому людина-розробник, надміру суворий – «крок вправо, крок вліво - розстріл». Іншими сло­вами, недоліки в розрахунок не приймаються, а об’єм необхідної документації може забрати багато часу і праці.

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

Рухомі процеси вимагають меншого об’єму документації і орієнтовані на людину. В них явно вказано на необхідність використання природних якос­тей людської натури.

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

Таким чином, в сучасній інфраструктурі програмної інженерії існує два сімейства процесів розробки:

• сімейство прогнозуючих (важковагових) процесів;

• сімейство адаптивних (рухомих, полегшених) процесів.

У кожного сімейства є свої переваги, недоліки та область застосування:

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

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

ХР-процес

Екстремальне програмування (eXtreme Programming, XP) – полегшений (рухомий ) процес (або методологія), головний автор якого – Кент Бек (1999). ХР-процес орієнтований на групи малого та середнього розміру, що розробля­ють програмне забезпечення в умовах невизначеності або в умовах швидкої зміни вимог. ХР-групу створюють до 10 співробітників, які розміщуються в одному приміщенні.

Основна ідея ХР – ліквідувати високу вартість змін, характерну для додатків з використання об’єктів, паттернів і реляційних баз даних. Тому ХР-процес повинен бути високо динамічним. ХР-група має справу зі змінами вимог на всьому протязі ітераційного циклу розробки, при чому складається із дуже коротких ітерацій. Чотирма базовими діями в ХР-процесі є: кодування, тестува­ння, вислуховування замовника і проектування. Динамізм забезпечується за до­помогою чотирьох характеристик: неперервного зв’язку з замовником (в межах групи), простоти (завжди вибирається мінімальне рішенні), швидкості зворот­ного зв’язку (за допомогою модульного та функціонального тестування), сміли­вості в проведенні профілактики можливих проблем.

Більшість принципів, застосованих в ХР процесі досягають екстремаль­них значень, що проілюстровано в таблиці 1.2.

Таблиця 1.2.

Практика здорового глузду	ХР-екстремум	ХР-реалізація
Перевірка коду	Код перевіряється весь час	Парне програмування
Тестування	Тестування виконується весь час, навіть з допомогою замовника	Тестування модуля, функціональне тестування
Проектування	Проектування є частиною щоденної роботи кожного розробника	Реорганізація
Простота	Для системи вибирається найпростіше системне рішення, що підтримує її біжучу функціональність	Сама проста річ, що могла би працювати
Архітектура	Кожен постійно працює над уточненням архітектури	Метафора
Тестування інтеграції	Інтегруються і тестуються кілька раз в день	Неперервна інтеграція
Короткі ітерації	Ітерації є допустимо ко­роткими, що тривають сек.., хв.., год., а не неділі.	Гра планування

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

Базис ХР створюється такими методами.

1. Гра планування (Planning game) – швидке визначення області дії нас­тупної реалізації шляхом об’єднання ділових пріоритетів і технічних оцінок. Замовник формує область дії, пріоритетність і терміни з точки зору бізнесу, а розробник оцінює і відслідковує прогрес.

2. Швидка зміна версій (Small releases) – швидкий запуск в виробництво простої системи. Нові версії реалізуються в дуже короткому циклі (до двох неділь).

3. Метафора (Metaphor) – вся розробка проводиться на основі простої, загальнодоступної версії про принцип роботи всієї системи.

4. Просте проектування (Simple desing) – проектування виконується на стільки просто, наскільки це можливо в даний час.

5. Тестування (Testing) – неперервне написання тестів для модулів, які повинні виконуватись ідеально; замовники пишуть тести для демонстрації закінченості функцій. «Тестуй, а потім кодуй» значить, що вхідним критерієм для написання коду є «відмовивний» тестовий варіант.

6. Реорганізація (Refactoring) – система реструктурується, але її поведін­ка не змінюється; мета – ліквідувати дублювання, покращити взаємодію, спрос­тити систему або добавити в неї гнучкість.

7. Парне програмування (Pair programming) – весь код пишеться двома програмістами, що працюють на одному комп’ютері.

8. Колективне володіння кодом (Collective ownership) любий розробник може покращити код сите мив любий час.

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

10. 40-годинна робоча неділя (40-hour week) – як правило, працюють не більше 40 годин в неділю.

11. Локальний замовник (On-site customer) – в групі весь час повинен бути представник замовника, реально готовий відповідати на всі запитання розробника.

12. Стандарти кодування (Coding standards) – повинні виконуватись пра­вила, що забезпечують однакове представлення програмного коду у всіх части­нах програмної системи.

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

«Метафора» забезпечує глобальне бачення проекту. Цей розділ проекту­вання можна було б розглядати, як високорівнева архітектура, але ХР підкрес­лює процес проектування при мінімальній проектній документації. Точніше ка­жучи, ХР передбачає неперервне перепроектування при якому не має необхід­но­сті деталізувати проектну документацію, для інженерів надійним джерелом інформації є програмний код. Проектна документація зберігається в тому випа­дку коли замовник тимчасово втрачає здатність придумувати нові історії. Вико­ристання реорганізації приводить до реалізації найпростішого рішення, що за­до­вольняє біжучу необхідність. Зміни в вимогах заставляють відмовитись від всіх «загальних рішень».

Парне програмування – один з найбільше суперечливих методів ХР, він впливає на ресурси, що важливо для менеджерів, які вирішують, чи буде даний проект використовувати ХР. На перший погляд може здатись, що парне програ­мування подвоює ресурси, але дослідження показали: парне програмування під­вищує якість і зменшує час циклу. Для узгодженої групи затрати збільшуються на 15%, а час циклу скорочується на 40-50%.

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

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

Основним засобом управління ХР є метрика, а серед метрик – «велика візуальна діаграма». Як правило, використовують 3-4 метрики, при чому такі, які видимі всій групі. Базовою в ХР метрикою є «швидкість проекту» - кіль­кість версій заданого розміру, які можуть бути реалізовані в ітерації.

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

Розглянемо структуру «ідеального» ХР-процесу. Основним структурним елементом процесу є ХР-реалізація, в яку багатократно вкладається базовий елемент – ХР-ітерація. В склад ХР-реалізації і ХР-ітерації входять три фази – дослідження, блокування, регулювання. Дослідження (exploration) – це пошук нових вимог (версій, задач), кі повинна виконувати система. Блокування (com­mitent) – вибір для реалізації конкретної підмножини із всіх можливих вимог (іншими словами , планування). Регулювання (steering) – проведення розробки, реалізація плану в життя.

ХР рекомендує: перша реалізація повинна мати тривалість 2-6 місяців, тривалість останніх реалізацій – біля двох місяців, кожна ітерація триває приб­лизно дві неділі, а чисельність групи розробників не перевищує 10 чоловік. ХР-п роцес для проекту з семи реалізацій, може виконуватись за 15 місяців, рис. 1.8.

Процес ініціалізується початковою дослідницькою фазою.

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

Передбачається, що тривалість першої реалізації складає 3 місяці, трива­лість 2-7 реалізації – 2 місяці. Друга – сьома реалізації створюють період супро­водження, який характеризує природу ХР-проекту. Кожна ітерація триває 2 ти­ж­ні, за виключенням тих, які відносяться до пізнішої стадії реалізації – «запуск в виробництво» (в цей період темп ітерацій прискорюється).

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

Моделі якості процесів конструювання

В сучасних умовах дуже важливо гарантувати високу якість процесу конструювання ПЗ. Таку гарантію дає сертифікат якості процесу, що підтверд­жує його відповідність прийнятим міжнародним стандартам. Кожен такий стандарт фіксує свою модель забезпечення якості . Найбільш авторитетні мо­делі стандартів ISO 9001:2000, ISO/ІЕС 15504 і модель зрілості процесу конст­руювання ПЗ (Capability Maturity Model – CMM) Інституту програмної інжене­рії при американському університеті Карнегі-Меллон.

Модель стандарту ISO 9001:2000 орієнтована на процеси розробки в лю­бих областях людської діяльності. Стандарт ISO/ІЕС 15504 спеціалізується на процесах програмної розробки і відрізняється більш високим рівнем деталізації. Достатньо сказати, що об’єм цього стандарту перевищує 500 сторінок. Значна частина ідей ISO/ІЕС 15504 взята з моделі СММ.

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

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

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

Важливо відмітити, що модель СММ фіксує критерії для побудови сис­теми постійного покращення процесів. В ній зафіксовано п’ять рівнів зрілості (рис. 1.9) і передбачає плавний, поетапний підхід до удосконалення процесів – можливо поетапно підтверджувати покращення процесів після кожного рівня зрілості.

К ожний рівень СММ характеризується областю ключових процесів, при чому вважається, що кожний наступний рівень включає в себе всі характерис­тики попередніх рівнів. Область ключових процесів створює процеси, які при сумісному виконанні приводять до досягнення певного набору цілей. Наприк­лад ОКП 5-го рівня створює процеси:

• попередження дефектів;

• управління зміною технологій;

• управління змінами процесу.

Якщо всі цілі ОКП досягнуто, компанії присвоюють сертифікат даного рівня зрілості.

Контрольні питання

1. Дайте визначення технології конструювання програмного забезпечення.

2. Які етапи класичного життєвого циклу ви знаєте?

3. Охарактеризуйте зміст етапів класичного життєвого циклу.

4. Поясніть переваги та недоліки класичного життєвого циклу.

5. Чим відрізняється класичний життєвий цикл від макетування?

6. Які існують форми макетування?

7. Чим відрізняються одна від другої стратегії конструювання ПЗ?

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

9. Поясніть переваги та недоліки інкрементної моделі.

10. Чим відрізняється модель швидкої розробки додатків від інкрементної моделі?

11. Поясніть переваги та недоліки моделі швидкої розробки додатків.

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

13. В чому основна особливість спіральної моделі?

14. Чим відрізняється компонентно-орієнтована модель від спіральної моделі та класичного життєвого циклу?

15. Вкажіть переваги та недоліки компонентно-орієнтованої моделі.

16. Чим відрізняються важковагові процеси від полегшених?

17. Чим відрізняються важковагові процеси від прогнозуючих процесів?

18. Чим відрізняються рухомі процеси від полегшених процесів?

19. Перерахуйте переваги та недоліки важковагових процесів.

20. Перерахуйте переваги та недоліки полегшених процесів.

21. Приведіть приклади важковагових процесів.

22. Приведіть приклади полегшених процесів.

23. Перерахуйте характеристики ХР-процесу.

24. Перерахуйте методи ХР-процесу.

25. В чому полягає основна особливість ХР-процесу?

26. Охарактеризуйте зміст гри планування в ХР-процесі.

27. Охарактеризуйте значення метафори в ХР-процесі.

28. Які особливості проектування в ХР-процесі?

29. Що таке реорганізація?

30. Які особливості програмування в ХР-процесі?

31. Що таке колективне володіння?

32. Які особливості тестування в ХР-процесі?

33. Чим відрізняється ХР-реалізація від ХР-ітерації?

34. Чим ХР-реалізація подібна на ХР-ітерацію?

35. Яка тривалість ХР-реалізаці?

36. Яка тривалість ХР-ітерації?

37. Яка максимальна чисельність групи ХР-розробників?

38. Які моделі якості процесів конструювання ви знаєте?

39. Охарактеризуйте модель СММ.

40. Охарактеризуйте рівень зрілості довільної фірми.

Література:

1. Иан Соммервиль. Инженерия программного обеспечения. Москва▪Санк-Петербург▪Киев. 2002.

2. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориен­тированного проектирования. Санк-Петербург, 2001.

3. Гради Буч. Объектно-ориентированный анализ и проектирование. Санк-Петербург, 1998.

4. Г.С. Иванова, Т.Н. Ничушкына, Е.К. Пугачев. Объектно-ориентирован­ное программирование. Москва, 2003.

5. С.А. Орлов. Технологии разработки программного обеспечения. СПб.: Питер, 2004.