Лекція 3. Організація технологічного процесу розробки ПЗ
Не дивлячись на природні відмінності в описах процесів, як правило, в усіх присутні розглянуті стадії. Вони можуть інакше називатися, можуть деталізуватися, але від них нікуди не піти.
Існують відомі процеси, що досить добре себе зарекомендували, напр. Microsoft Solutions
Framework (MSF), Rational Unified Process (RUP) та інші. Ці процеси (часто до них застосовують термін методологія) мають свої різновиди і можуть застосовуватися як для малих і середніх компаній й проектів, так і для великих. Однак, всі ці процеси базуються на одному (основному), або об’єднанні декількох моделей.
Розглянемо основні моделі процесу розробки Програмних Продуктів.
2. Життєвий цикл та моделі процесу розробки ПЗ
Отже, якийсь "каркас" процесу зазвичай виглядає так:
Специфікація. -> Розробка. -> Атестація. -> Модернізація.
Сам цей "каркас" можна приводити в життя по-різному. Існують загальні моделі процесу, які визначають, як організувати роботу по "каркасу" на практиці. Фактично, модель процесу - якесь абстрактне представлення процесу на верхньому рівні. Так, модель не розглядає детально вміст кожного з етапів. Модель розглядає склад етапів і способи їх запровадження
Розглянемо деякі сталі моделі процесу розробки програмного забезпечення.
2.1.Каскадна модель (Waterfall model)
Дуже часто класичний життєвий цикл називають каскадною або водопадом моделлю, підкреслюючи, що розробка розглядається як послідовність етапів, причому перехід на наступний, ієрархічно нижній етап відбувається тільки після повного завершення робіт на поточному етапі (мал.
1.1).
Мал. 1.1. Класична каскадна модель розробки ПЗ
Суть каскадної моделі полягає в наступному:
Вимоги до системи визначаються на початковому етапі і далі не міняються.
Процес створення ПЗ розбивається на наступні стандартні етапи: визначення вимог, проектування, кодування і тестування модулів, інтеграція і тестування продукту, експлуатація і супровід.
Всі етапи послідовні: кожен етап може початися лише тоді, коли закінчився попередній.
Зміст основних етапів.
Розробка починається на системному рівні і проходить через аналіз, проектування, кодування,
22
Лекція 3. Організація технологічного процесу розробки ПЗ
тестування і супровід. При цьому моделюються дії стандартного інженерного циклу.
Системний аналіз задає роль кожного елементу в комп'ютерній системі, взаємодія елементів один з одним. Оскільки ПЗ є лише частиною великої системи, то аналіз починається з визначення вимог до всіх системних елементів і призначення підмножини цих вимог програмному «елементу». Необхідність системного підходу явно виявляється, коли формується інтерфейс ПЗ з іншими елементами (апаратурою, людьми, базами даних). На цьому ж етапі починається рішення задачі планування проекту ПЗ. В ході планування проекту визначаються об'єм проектних робіт і їх ризик, необхідні трудовитрати, формуються робочі завдання і план-графік робіт.
Аналіз вимог відноситься до програмного елементу — програмного забезпечення. Уточнюються і деталізують його функції, характеристики і інтерфейс.
Всі визначення документуються в специфікації аналізу. Тут же завершується рішення задачі планування проекту.
Проектування полягає в створенні описів:
1.архітектура ПЗ;
2.модульної структури ПЗ;
3.алгоритмічної структури ПЗ;
4.структури даних;
5.вхідного і вихідного інтерфейсу (вхідних і вихідних форм даних).
Початкові дані для проектування містяться в специфікації аналізу, тобто в ході проектування виконується трансляція вимог до ПЗ в безліч проектних уявлень. При вирішенні завдань проектування основна увага приділяється якості майбутнього програмного продукту.
Кодування полягає в перекладі результатів проектування в текст на мові програмування.
Тестування — виконання програми для виявлення дефектів у функціях, логіці і формі реалізації програмного продукту.
Супровід — це внесення змін до експлуатованого ПЗ. Цілі змін:
•виправлення помилок;
•адаптація до змін зовнішньою для ПЗ середовища;
•удосконалення ПЗ по вимогах замовника.
Супровід ПЗ полягає в повторному застосуванні кожного з попередніх кроків (етапів) життєвого циклу до існуючої програми але не в розробці нової програми.
Як і будь-яка інженерна схема, класичний життєвий цикл має Переваги і недоліки.
Переваги класичної каскадної моделі в простоті і хорошій структурованості: дає план і часовий графік по всіх етапах проекту, упорядковує хід конструювання.
Недоліки класичної каскадної моделі пов'язані з прямолінійністю і відсутністю гнучкості
1)реальні проекти часто вимагають відхилення від стандартної послідовності кроків;
2)цикл заснований на точному формулюванні початкових вимог до ПО (реально на початку проекту вимоги замовника визначені лише частково);
3)результати проекту доступні замовникові тільки в кінці роботи.
Основна проблема цієї моделі полягає в тому, що незмінність вимог є міфом! Вимоги мінялися, міняються і мінятимуться завжди в ході розробки. Каскадна модель не враховує цей факт. У результаті, якщо нічого не робити, кінцевий продукт відрізнятиметься від поточних потреб замовника (користувачів). Більш того, швидше за все і документація в кінці не відображатиме реальної ситуації (наприклад, ТЗ, складене на початку не співпадатиме з тим, що вийде в кінці). Тому каскадна модель в чистому вигляді перспективна лише для дуже великих проектів, де хороша структурованість виходить на перший план, а також в тих випадках, коли вимоги добре усвідомлені і зафіксовані на самому початку.
23
Лекція 3. Організація технологічного процесу розробки ПЗ
2.2.Макетування (прототипіювання)
Достатньо часто замовник не може сформулювати докладні вимоги по введенню, обробці або виведенню даних для майбутнього програмного продукту. З іншого боку, розробник може сумніватися в приспосабливаемое™ продукту під операційну систему, формі діалогу з користувачем або в ефективності алгоритму, що реалізовується. У цих випадках доцільно використовувати макетування.
Основна мета макетування — зняти невизначеності у вимогах замовника.
Макетування (прототипіювання) — це процес створення моделі необхідного програмного продукту.
Модель може приймати одну з 3-х форм:
паперовий макет або макет на основі ПК (зображає або малює людино-машинний діалог); працюючий макет (виконує деяку частину необхідних функцій); існуюча програма (характеристики якої потім повинні бути покращувані).
Як показано на рис. 1.2, макетування грунтується на багатократному повторенні ітерацій, в яких беруть участь замовник і розробник.
Рис. 1.2. Процес макетування (прототипіювання)
Послідовність дій при макетуванні представлена на рис. 1.3. Макетування починається із збору і уточнення вимог до створюваного ПП.
Розробник і замовник зустрічаються і визначають всі цілі ПП, встановлюють, які вимоги відомі, а які належить довизначити.
Потім виконується швидке проектування. Тут увага зосереджується на таких характеристиках ПП, які повинні бути видимі користувачеві. Швидке проектування приводить до побудови макету. Макет оцінюється замовником і використовується для уточнення вимог до реального ПП.
Ітерації повторюються до тих пір, поки макет не виявить всі вимоги замовника і, тим самим, не дасть можливість розробникові зрозуміти, що повинне бути зроблене.
Переваги макетування:
1.забезпечує визначення повних вимог до ПО.
Недоліки макетування:
2.замовник може прийняти макет за продукт;
3.розробник може прийняти макет за продукт.
Пояснимо суть недоліків. Коли замовник бачить працюючу версію ПО, він перестає усвідомлювати, що деталі макету скріпляють «жувальною гумкою і дротом»; він забуває, що в гонитві за працюючим варіантом залишені невирішеними питання якості і зручності супроводу ПО. Коли замовникові говорять, що продукт повинен бути перебудований, він починає обурюватися і вимагати, щоб макет «в три прийоми» був перетворений на робочий продукт. Дуже часто це негативно позначається на управлінні розробкою ПО.
24
Лекція 3. Організація технологічного процесу розробки ПЗ
Рис. 1.3. Послідовність дій при макетуванні
З іншого боку, для швидкого отримання працюючого макету розробник часто йде на певні компроміси. Можуть використовуватися не самі відповідні мова програмування або операційна система. Для простої демонстрації можливостей може застосовуватися неефективні алгоритми. Через деякий час розробник забуває про причини, по яких ці засоби не підходять. В результаті далеко не ідеальний первинний варіант інтегрується в систему.
Очевидно, що подолання цих недоліків вимагає боротьби з зі спокусою прийняти бажане за
дійсне.
2.3.Інкрементна модель
Інкрементна модель є класичним прикладом інкрементної стратегії конструювання (мал. 1.4). Вона об'єднує елементи послідовної моделі водопаду з ітераційною філософією макетування.
Кожна лінійна послідовність тут виробляє інкремент, що поставляється, ПО. Наприклад, ПО для обробки слів в 1-му інкременті реалізує функції базової обробки файлів, функції редагування і документування; у 2-му інкременті — складніші можливості редагування і документування; у 3-му інкременті — перевірку орфографії і граматики; у 4-му інкременті — можливості компоновки сторінки.
Перший інкремент приводить до отримання базового продукту, що реалізовує базові вимоги (правда, багато допоміжних вимог залишаються нереалізованими).
План наступного інкремента передбачає модифікацію базового продукту, що забезпечує додаткові характеристики і функціональність.
За своєю природою інкрементний процес є ітеративним, але, на відміну від макетування, інкрементна модель забезпечує на кожному інкременті працюючий продукт.
25