Каскадна модель

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

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

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

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

На етапі тестування проводиться власне тестування, а також налагодження і оцінка якості ПЗ.

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

 

 

 

Експлуатація ПЗ - це використання ПЗ для вирішення практичних завдань на комп'ютері шляхом виконання її програм.

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

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

 

1.2.2. Неминучі повернення на попередні стадії в каскадній моделі

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

 

 

 

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

 

Схема еволюційної моделі ЖЦ

 

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

 

 
 

 


Особливості ітераційних моделей:

Ø процес розробки розбивається на послідовність кроків, які виконуються циклічно;

Ø модель нагадує декілька послідовних «каскадів»;

Ø різні види діяльності не прив'язані намертво до певних етапів розробки, а виконуються в міру необхідності, іноді повторюються, до тих пір, поки не буде отриманий потрібний результат;

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

 
 

 


Схема покрокової ітераційної моделі ЖЦ.

 

Особливості спіральної моделі:

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

Ø рішення про початок нової ітерації ухвалюється на основі результатів попередньої;

Ø дострокове припинення проекту у разі виявлення його недоцільності.

Достоїнства ітераційних моделей:

Ø повний облік вимог замовника, більша його участь в проекті;

Ø рівномірне навантаження на групу;

Ø раннє виявлення проблем і їх розв’язування у міру виникнення, зменшення ризиків на кожній ітерації.

 
 

 


Схема спіральної моделі ЖЦ

 

Недоліки ітераційних моделей: складність планування; погана документованість створюваного ПЗ.

Проблемою сучасної програмної інженерії є «важкі» процеси. Характеристики «важкого» процесу:

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

Протилежністю «важкого» процесу є «легковагий» процес - основа швидкої розробки ПЗ (agile software development). Швидка розробка орієнтується на ефективну комунікацію між розробниками, високу кваліфікацію розробників і інші чинники, які дозволяють скоротити витрати на «бюрократію». Принципи швидкої розробки:

  1. Діалог «лицем до лиця» - найефективніший спосіб обміну інформацією.
  2. Надмірна «тяжкість» технології (додаткові робочі продукти, плани, діаграми, документи) коштує дорого.
  3. Численніші команди вимагають «важчих» технологій.
  4. Велика «тяжкість» процесу підходить для проектів з більшою критичністю.
  5. Зростання зворотного зв'язку і комунікації скорочує потребу у проміжних продуктах.
  6. Дисципліна, уміння і розуміння протистоять процесу, формальності і документуванню.
  7. Втрата ефективності в некритичних видах діяльності цілком допустима.

Під критичністю розуміються масштаби наслідків відмови розроблюваного ПЗ. Рівні критичності:

Ø втрата зручності;

Ø втрата важливих даних і/або робочого часу;

Ø втрата невідшкодовних засобів, дорогого устаткування;

Ø втрата людського життя.

Основні напрями розвитку сучасної програмної інженерії:

  1. Управління вимогами
  2. Управління конфігурацією і змінами
  3. Управління якістю ПЗ
  4. Ітераційна розробка ПЗ
  5. Використання компонентної архітектури (об'єктно-орієнтований підхід)
  6. Візуальне моделювання ПЗ

 

Література до лекції 1

 

1. Мацяшек Л. Анализ и проектирование информационных систем с помощью UML 2.0. М.: ООО «И.Д. Вильямс», 2008. – 816 с.

2. Киммел П. UML. Основы визуального анализа и проектирования / Пол Киммел. – М.: НТ Пресс, 2008. – 272 с.

3. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. – СПб.: Символ-Плюс, 1999

4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2005

5. Коберн А. Быстрая разработка программного обеспечения.: Пер. с англ. – М.: ЛОРИ, 2002

6. Соммервилл И. Инженерия программного обеспечения. 6-е издание.: Пер. с англ.: – М.: Вильямс, 2002

7. Жоголев Е. А. Технология программирования – М.: Научный мир, 2004

8. Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007