2.1. Стратегії розробки програмних засобів та систем
2.1.1. Базові стратегії розробки програмних засобів та систем
На початковому етапі розвитку обчислювальної техніки програмне забезпечення розроблялося за принципом "кодування - усунення помилок". Модель такого процесу розробки ПС ілюструє рисунок2.1 [19].
Робити, доки не буде зроблено
Малюнок 2.1 – Модель «Робити, доки зроблено»
Очевидно, що недоліками такої моделі є:
- неструктурованість процесу розробки програмних засобів;
- орієнтація на індивідуальні знання та вміння програміста;
- складність управління та планування проекту;
- велика тривалість та вартість розробки;
- низька якість програмних продуктів;
- високий рівень ризиків проекту.
В даний час найбільш широко використовуються три базові стратегії розробки програмного забезпечення, призначені для усунення або скорочення вищезгаданих недоліків:
Деякі характеристики каскадної, інкрементної та еволюційної стратегій розробки ПС та вимоги, що висуваються до них, наведені в стандарті ГОСТ Р ИСО/МЭК ТО – Інформаційна технологія
– Посібник із застосування ISO/IEC 12207 (Процеси життєвого циклу програмних засобів) [6].
Вибір тієї чи іншої стратегії визначається характеристиками:
- вимог до продукту;
Кожна зі стратегій розробки має як переваги, і недоліки, зумовлені правильністю вибору даної стратегії стосовно конкретному проекту.
Слід підкреслити, що ті самі властивості стратегії можуть проявляти себе як переваги при виборі стратегії до відповідного їй проекту і як її недоліки, якщо стратегія обрана неправильно.
Три базові стратегії можуть бути реалізованірізними моделями
2.1.2. Каскадна стратегія розробки програмних засобів та систем
Каскадна стратегія є одноразовий прохід етапів розробки.
Ця стратегія заснована на повному визначенні всіх вимог до програмного засобу, що розробляється на початку процесу розробки. Повернення до вже виконаних етапів розробки не передбачається. Проміжні результати як версія програмного засобу не
стратегію, є каскадна та моделі.
Основними перевагами каскадної стратегії, що виявляються при
розроблення відповідного їй проекту, є:
проходу етапів розробки; 3) простота планування, контролю та управління проектом;
4) можливість досягнення високих вимог до якості проекту у разі відсутності жорстких обмежень витрат та графіка робіт;
5) доступність розуміння замовниками.
До недоліків каскадної стратегії, що виявляються при її виборі до невідповідного проекту, слід зарахувати:
1) складність чіткого формулювання вимог на початку життєвого циклу ПС та неможливість їх динамічної зміни протягом ЖЦ ПС;
2) послідовність лінійної структури процесу розробки; на практиці розроблювані ПС (або система) зазвичай занадто великі, щоб усі роботи щодо їх створення виконати одноразово; в результаті повернення до
збільшення витрат та порушення графіка робіт;
3) проблемність фінансування проекту, пов'язана зі складністю одноразового розподілу великих коштів;
4) непридатність проміжного продукту для використання;
5) недостатня участь користувача в розробці системи або ПС-тільки на самому початку (при розробці вимог) і в кінці (під час приймальнихвипробувань), що призводить до неможливості попередньої оцінки користувачем якості ПС або системи.
Області застосування каскадної стратегії обмежені недоліками цієї стратегії. Її використання найефективніше у таких випадках:
1) при розробці проектів з чіткими, незмінними протягом ЖЦ вимогами, зрозумілими реалізацією та технічними методиками;
2) при розробці проекту, орієнтованого на побудову системи або продукту такого ж типу, як розроблялися раніше;
3) при розробці проекту, пов'язаного зі створенням та випуском нової версії вже існуючого продукту чи системи;
4) розробки проекту, пов'язаного з перенесенням вже існуючого продукту на нову платформу;
5) під час виконання великих проектів, яких задіяно кілька великих команд розробників (наприклад, див. малюнок 2.5).
2.1.3. Інкрементна стратегія розробки програмних засобів та систем
Інкрементна стратегія є багаторазовим проходом етапів розробки із запланованим поліпшенням результату.
Ця стратегія заснована на повному визначенні всіх вимог до ПС, що розробляється на початку процесу розробки. Однак повний набір