ня В»). Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ. Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси. p> До теперішнього часу найбільшого поширення набули наступні дві основні моделі ЖЦ:
В· каскадна модель (70-85 р.р.);
В· спіральна модель (86-90 р.р.).
У спочатку існували однорідних ІС кожен додаток являло собою єдине ціле. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основний характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (рис.1). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників. p> Позитивні сторони застосування каскадного підходу полягають в наступному:
В· на кожному етапі формується закінчений набір проектної документації, який відповідає критеріям повноти та узгодженості;
В· виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
В
Рис.1 В«Каскадна модель життєвого циклу В»
Каскадний підхід добре зарекомендував себе при побудові ІС, для яких на самому початку розробки можна досить точно і повно сформулювати всі вимоги, з тим, щоб надати розробникам свободу реалізувати їх якнайкраще з технічної точки зору. У цю категорію потрапляють складні розрахункові системи, системи реального часу і інші подібні завдання. Проте в процесі використання цього підходу виявився ряд його недоліків, викликаних перш за все тим, що реальний процес створення ПО ніколи повністю не вкладався в таку жорстку схему. У процесі створення ПЗ постійно виникала потреба у поверненні до попередніх етапах і уточнення або перегляд раніше прийнятих рішень. У результаті реальний процес створення ПО брав такий вигляд (рис. 2):
В
Рис.2 В«Модель життєвого циклу з проміжним контролем В»
Основним недоліком каскадного підходу є суттєве запізнення з отриманням результатів. Узгодження результатів з користувачами проводиться тільки в точках, планованих після завершення кожного етапу робіт, вимоги до ІС "Заморожені" у вигляді технічного завдання на весь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена. У разі неточного викладу вимог або їх зміни протягом тривалого періоду створення ПЗ, користувачі отримують систему, не задовольняє їх потреб. Моделі (як функціональні, так і інформаційні) автоматизується об'єкта можуть застаріти одночасно з їх затвердженням. p> Для подолання перелічених проблем була запропонована спіральна модель ЖЦ (рис. 3), що робить упор на початкові етапи ЖЦ: аналіз і проектування. На цих етапах реалізація технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Таким чином, поглиблюються і послідовно конкретизуються деталі проекту, і в результаті вибирається обгрунтований варіант, який доводиться до реалізації. p> Розробка итерациями відображає об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. При ітеративному способі розробки відсутню роботу можна буде виконати на наступній ітерації. Головна ж задача - якнайшвидше показати користувачам системи працездатний продукт, тим самим, активізуючи процес уточнення і доповнення вимог.
Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її вирішення необхідно ввести тимчасові обмеження на кожен з етапів життєвого циклу. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, отриманих у попередніх проектах, і особистого досвіду розробників.
В
Рис. 3 В«Спіральна модель життєвого циклу В»
При проектуванні програмного забезпечення за основу була взята спіральна модель життєвого циклу (рис. 3), так як при проектуванні даної ІС на ранніх стадіях можна показати попередню версію програмного забезпечення користувачеві, для того щоб обговорити н...
