Лекція 4. Життєвий цикл пз
Одним з базових понять методології проектування є поняття життєвого циклу програмного забезпечення (ЖЦ ПО). ЖЦ ПО – це безперервний процес, який починається з моменту ухвалення рішення про необхідність його створення і закінчується у момент його повного вилучення з експлуатації.
Стандарти життєвого циклу
Для того, щоб отримати уявлення про можливу структуру життєвого циклу ПО, звернемося спочатку до відповідних стандартів, що описують технологічні процеси. Міжнародними організаціями, такими як
IEEE —, Institute of Electrical and Electronic Engineers, Інститут інженерів по електротехніці і електроніці;
ISO — International Standards Organization, Міжнародна організація по стандартизації;
EIA — Electronic Industry Association, Асоціація електронної промисловості;
IEC — International Electrotechnical Commission, Міжнародна комісія з електротехніки.
ANSI — American National Standards Institute, Американський національний інститут стандартів;
SEI — Software Engineering Institute, Інститут програмної інженерії;
Група стандартів ISO
ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes (є аналог ГОСТ Р-1999 ). Визначає загальну структуру життєвого циклу ПО у вигляді 3-х ступінчастій моделі, що складається з процесів, видів діяльності і завдань. Стандарт описує елементи, що вводяться, в термінах їх цілей і результатів, тим самим задаючи неявно можливі взаємодії між ними, але не визначаючи чітку структуру взаємодій, можливу організацію елементів в рамках проекту і метрики, по яких можна було б відстежувати хід робіт і їх результативність.
Найкрупнішими елементами є процеси життєвого циклу ПО (lifecycle processes), все виділено 18 процесів, які об'єднані в 4 групи процесів.
Основні процеси |
Підтримуючі процеси |
Організаційні процеси |
Адаптація |
Придбання ПО; Передача ПО (у використання); Розробка ПО; Експлуатація ПО; Підтримка ПО |
Документування; Управління конфігураціями; Забезпечення якості; Верификация;
Валідация; Сумісні експертизи; Аудит; Дозвіл проблем |
Управління проектом; Управління інфраструктурою; Удосконалення процесів; Управління персоналом |
Адаптація описуваних стандартом процесів під потреби конкретного проекту |
Процеси будуються з окремих видів діяльності (activities). Стандартом визначено 74 види діяльності, пов'язаної з розробкою і підтримкою ПО. Тут ми згадаємо тільки деякі з них.
Придбання ПО включає такі діяльності, як ініціація придбання, підготовка запиту пропозицій, підготовка контракту, аналіз постачальників, отримання ПО і завершення придбання.
Розробка ПО включає розгортання процесу розробки, аналіз системних вимог, проектування системи в цілому (програмно-апаратною), аналіз вимог до ПО, проектування архітектури ПО, детальне проектування, кодування і налагоджувальне тестування, інтеграція ПО, кваліфікаційне тестування ПО, системна інтеграція, кваліфікаційне тестування системи, розгортання (установка, інсталяція) ПО, підтримка процесу отримання ПО.
Підтримка ПО включає розгортання процесу підтримки, аналіз виникаючих проблем і необхідних змін, внесення змін, експертизу і передачу зміненого ПО, перенесення ПО з однієї платформи на іншу, вилучення ПО з експлуатації.
Управління проектом включає запуск проекту і визначення його рамок, планування, виконання проекту і нагляд за його виконанням, експертизу і оцінку проекту, згортання проекту.
Структура ЖЦ ПО за стандартом ISO/IEC 12207 базується на трьох групах процесів:
основні процеси ЖЦ ПО (придбання, постачання, розробка, експлуатація, супровід);
допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, вирішення проблем);
організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка і поліпшення самого ЖЦ, навчання).
Моделі життєвого циклу ПО
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
До теперішнього часу найбільшого поширення набули наступні основні моделі ЖЦ:
каскадна модель;
ітеративна модель;
спіральна модель.
Каскадна модель
У спочатку існуючих однорідних ІС кожне застосування було єдиним цілим. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (рис. 4.1). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Позитивні сторони застосування каскадного підходу полягають в наступному:
на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;
виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Рис. 4.1 – Каскадна схема розробки ПО
Каскадний підхід добре зарекомендував себе при побудові ІС, для яких на самому початку розробки можна достатньо точно і повно сформулювати всі вимоги, з тим щоб надати розробникам свободу реалізувати їх якнайкраще з технічної точки зору. У цю категорію потрапляють складні розрахункові системи, системи реального часу і інші подібні завдання. Проте, в процесі використання цього підходу виявилися ряд його недоліків, викликаних перш за все тим, що реальний процес створення ПО ніколи повністю не укладався в таку жорстку схему. В процесі створення ПО постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень. В результаті реальний процес створення ПО приймав наступний вигляд (рис.. 4.2):
Рис. 4.2 – Реальний процес розробки ПО по каскадній схемі
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям..
Ітеративна модель
Ітеративні або инкрементальные моделі припускають розбиття що розробляється ПО на набір частин, які розробляються послідовно, один за одним так, щоб на самому початку — на першій ітерації — можна було розробити частину, не залежну від інших, пройшовши повний цикл робіт на ній, потім оцінити результати і на наступній ітерації або переробити першу частину, або розробити наступну частину, яка може залежати від першої, або якось сумістити доопрацювання першої частини з додаванням нових функцій. В результаті можна аналізувати результати роботи і реакцію на них всіх зацікавлених осіб, включаючи користувачів, на кожній ітерації окремо, і вносити зміни, що коректують, на наступних ітераціях.
Ітеративний процес припускає, що різні види діяльності не прив'язані намертво до певних етапів розробки, а виконуються в міру необхідності, іноді повторюються, до тих пір, поки не буде отриманий потрібний результат.
Разом з гнучкістю і можливістю швидко реагувати на зміни ітеративні моделі привносять додаткові складнощі в управління проектом і відстежування його ходу. При використанні ітеративного підходу адекватно оцінити поточний стан проекту і спланувати довгостроковий розвиток подій, а також передбачити терміни і ресурси, необхідні для забезпечення певної якості результату, значно складніше, ніж для каскадних проектів.
Спіральна модель
Назва спіральною ця модель отримала із-за зображення ходу робіт в «полярних координатах», в яких кут відповідає виконуваним діям, а видалення від початку координат — витраченим ресурсам. Кожен виток спіралі відповідає створенню фрагмента або версії ПО, на нім уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі.
Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. Главная же задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основна проблема спірального циклу – визначення моменту переходу на наступний етап. Для її вирішення необхідно ввести тимчасові обмеження на кожен з етапів життєвого циклу. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, отриманих в попередніх проектах, і особистого досвіду розробників.
Рис. 4.3 – Спіральна модель ЖЦ