1. Поняття життєвого циклу розробки програмного забезпечення.

Життє́вий цикл програ́много забезпе́чення — сукупність окремих етапів робіт, що проводяться у заданому порядку протягом періоду часу, який починається з вирішення питання про розроблення програмного забезпечення і закінчується припиненням використання програмного забезпечення[1].

Процес створення програмного продукту можна коротко представити у вигляді переліку наступних етапів:

• Розробка в середньому 0,5 - 2 роки:

  • проектування;

  • реалізація;

• Супровід у середньому 1- 10 років

2. Етапи розробки

Етап	Результат	Трудомісткість (у середньому)
1. Проектування
1.1 Аналіз вимог	Зовнішня специфікація (ТЗ)	10%
1.2 Загальне проектування	Внутрішні (проектні) специфікації	10%
1.3 Детальне проектування		20%
2. Реалізація
2.1 Кодування	Вихідні тексти програм	10%
2.2 Автономне тестування	Журнали помилок	20%
2.3 Комплексне тестування		30%

Специфікація означає строгий, докладний опис проекту, технічне завдання (ТЗ)

3. Базові моделі розробки програмних продуктів.

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

На сьогодні найбільшого розповсюдження набули наступні моделі:

• Каскадна (водоспадна)

• V - модель

• RAD – модель

• Інкрементна

• Модель прототипування програмного продукту

• Спіральна модель.

Вибір моделі ґрунтується на наступних чинниках:

• Структура підприємства

• Об’єм проекту

• Складність проекту

• Наявність факторів ризику

4. Вимоги до методології та технології розробки пп

Методології, технології й інструментальні засоби проектування ( CASE-Засобу) становлять основу проекту будь-якого програмного продукту. Методологія реалізується через конкретні технології й підтримуючі їхні стандарти, методики й інструментальні засоби, які забезпечують виконання процесів ЖЦ.

Технологія проектування визначається як сукупність трьох складових:

• покрокової процедури, що визначає послідовність технологічних операцій проектування;

• критеріїв і правил, використовуваних для оцінки результатів виконання технологічних операцій;

• нотацій (графічних і текстових засобів), використовуваних для опису проектованої системи.

Рис. Подання технологічної операції проектування

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

Технологія проектування, розробки й супроводження програм повинна задовольняти наступним загальним вимогам:

• технологія повинна підтримувати повний ЖЦ ПЗ;

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

• технологія повинна забезпечувати можливість виконання великих проектів у вигляді підсистем (тобто можливість декомпозиції проекту на складові частини, розроблювальні групами виконавців обмеженої чисельності з наступною інтеграцією складових частин). Досвід розробки великих програмних продуктів показує, що для підвищення ефективності робіт необхідно розбити проект на окремі слабко зв'язані за даними й функціям підсистеми. Реалізація підсистем повинна виконуватися окремими групами фахівців. При цьому необхідно забезпечити координацію ведення загального проекту й виключити дублювання результатів робіт кожної проектної групи, що може виникнути в силу наявності загальних даних і функцій;

• технологія повинна забезпечувати можливість ведення робіт із проектування окремих підсистем невеликими групами ( 3-7 чоловік). Це обумовлено принципами керованості колективу й підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;

• технологія повинна забезпечувати мінімальний час одержання працездатної ИС. Мова йде не про строки готовності всієї програми, а про строки реалізації окремих підсистем. Реалізація програмного продукту в цілому в короткий термін може зажадати залучення великої кількості розроблювачів, при цьому ефект може виявитися нижче, ніж при реалізації в більше короткий термін окремих підсистем меншим числом розроблювачів. Практика показує, що навіть при наявності повністю завершеного проекту, впровадження йде послідовно по окремих підсистемах;

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

• технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації (систем керування базами даних (СУБД), операційних систем, мов і систем програмування);

• технологія повинна бути підтримана комплексом погоджених CASE-Засобів, що забезпечують автоматизацію процесів, виконуваних на всіх стадіях ЖЦ. Загальний підхід до оцінки й вибору CASE-Засобів описаний у розділі 4, приклади комплексів CASE-Засобів.

Реальне застосування будь-якої технології проектування, розробки й супроводи в конкретній організації й конкретному проекті неможливо без виробітку ряду стандартів (правил, угод), які повинні дотримуватися всіма учасниками проекту. До таких стандартів ставляться наступні:

• стандарт проектування;

• стандарт оформлення проектної документації;

• стандарт користувальницького інтерфейсу.

Стандарт проектування повинен установлювати:

• набір необхідних моделей (діаграм) на кожній стадії проектування й ступінь їхньої деталізації;

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

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

• механізм забезпечення спільної роботи над проектом, у тому числі: правила інтеграції підсистем проекту, правила підтримки проекту в однаковому для всіх розроблювачів стані (регламент обміну проектною інформацією, механізм фіксації загальних об'єктів і т.д.), правила перевірки проектних рішень на несуперечність і т.д.

Стандарт оформлення проектної документації повинен установлювати:

• комплектність, состав і структуру документації на кожній стадії проектування;

• вимоги до її оформлення (включаючи вимоги до змісту розділів, підрозділів, пунктів, таблиць і т.д.),

• правила підготовки, розгляду, узгодження й твердження документації із вказівкою граничних строків для кожної стадії;

• вимоги до настроювання видавничої системи, використовуваної як убудований засіб підготовки документації;

• вимоги до настроювання CASE-Засобів для забезпечення підготовки документації відповідно до встановлених вимог.

Стандарт інтерфейсу користувача повинен установлювати:

• правила оформлення екранів (шрифти й колірна палітра), состав і розташування вікон і елементів керування;

• правила використання клавіатури й миші;

• правила оформлення текстів допомоги;

• перелік стандартних повідомлень;

• правила обробки реакції користувача.

Лекція №3, 4

Тема: Моделі розробки програмного забезпечення. Базові процеси, переваги та недоліки. Каскадна, V – модель, модель прототипування програмного продукту. Інкриментна модель, ХР – модель, спіральна модель.

Мета: Ознайомлення з моделями розробки програмного забезпечення. Визначення переваг та недоліків.

Перелік питань, що розглядаються на лекції:

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

2. V – модель.

3. Модель прототипування програмного продукту.

4. Спіральна модель.

5. Модель RAD.

6. Модель екстремального програмування (XP).

7. Модель MSF (Microsoft Solutions Framework).