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

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

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

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

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

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

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

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

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

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

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

11