6. Моделі жц пз. Спіральна модель. Зміст етапів створення пз.

Стандарт Iso/iec 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання і взаємозв'язку процесів, дій і завдань, що виконуються впродовж ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт Iso/iec 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.

До теперішнього часу найбільшого поширення набули наступні моделі ЖЦ:

- каскадна (водопад) модель (70-85 г.г.);

- спіральна модель (86-90 г.г.).

- інкрементальная модель

Спіральна модель процесу

У разі спірального процесу (автор Баррі Боем,1988) послідовність аналіз вимог - проектування - реалізація - тестування виконується більше одного разу.

Для цього може бути декілька причин:

- необхідність попередження рисок;

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

Версії продукту називають прототипами. Кожен виток спіралі відповідає створенню фрагмента або версії ПО.

Т.ч. заглиблюються і послідовно конкретизуються деталі проекту. В результаті вибирається обгрунтований варіант, який доводиться до реалізації.

Дополнительное преимущество: на каждом витке спирали можно собрать метрические характеристики проекта (трудоемкость затрат, затраты на проект, длительность, документированность).

Т.ч. уточнюється план-графік подальшої роботи.

Мінуси:

1. Потрібне майстерніше управління

2. Необхідність підтримки цілісності документації, яка має бути повністю сформована до кінця кожної версії.

3. Трудність у визначенні моменту переходу на наступний етап.

4. Перехід здійснюється відповідно до плану навіть якщо не всі роботи виконані.

5. Дуже велика кількість витків зажадає збільшення витрат, великих витрат.

Типовий проект:

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

7. Моделі жц пз. Інкрементальная модель. Зміст етапів створення пз.

Стандарт Iso/iec 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання і взаємозв'язку процесів, дій і завдань, що виконуються впродовж ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт Iso/iec 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.

До теперішнього часу найбільшого поширення набули наступні моделі ЖЦ:

- каскадна (водопад) модель (70-85 г.г.);

- спіральна модель (86-90 г.г.).

- інкрементальная модель

Інкрементальная модель

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

Наприклад, Кукумано і Селбі [21] підготували доповідь по процесу, використовуваному в деяких відділеннях корпорації Microsoft, де оновлення програмної коди і документації надаються щодня до конкретного часу для інтеграції і нічного тестування. Інші організації використовують для цього тижневі цикли. Для підтримки відповідного рівня інкрементальной розробки необхідно мати чітко встановлену архітектуру проекту і виключно синхронізовану систему документації (мал. 1.10). Для організації інкрементальной розробки зазвичай вибирається характерний часовий інтервал, наприклад тиждень. Потім протягом цього інтервалу відбувається оновлення початкового проекту (документації, набору тестів, програмної коди і так далі). Теоретично кроки розробки (increments) можуть виконуватися і паралельно, але такий процес дуже складно скоординувати. Інкрементальная розробка проходить краще всього, якщо наступна стадія п+1 починається по можливості після того, як оновлення всіх модулів на стадії п закінчене, і найгірше, якщо час, потрібний на оновлення модулів, значно перевищує вибраний інтервал. Для того, щоб переконатися в цьому, уявіть, що необхідно змінити модуль 789, який залежить від семи інших модулів: 890, 23, 489, 991, 7653, 2134 і 2314. Якщо зміна займає дев'ять тижнів, то модуль 789 має бути побудований виходячи з передбачуваного стану всіх семи модулів через дев'ять тижнів. Цю роботу дуже важко скоординувати, оскільки кожна з семи частин може бути змінена до дев'яти разів (щонеділі), причому кожна нова зміна може грунтуватися на дослідженні ефективності попередніх змін.

1 План управління програмним проектом

2 Проектна документація програмного забезпечення

3 Специфікація вимог до програмного забезпечення