Процеси і технології створення програмного забезпечення

і його процеси. Поняття про моделі життєвого циклу.
1.2 Базові методології створення ПЗ.
1.3 Процеси створення програмних продуктів невеликої складності.

життєвого циклу.

- це система інженерних принципів для створення економічного ПО з заданими характеристиками якості.
Будь-яка технологія розробки ПЗ базується на деякій методології або сукупності методологій.
Під методологією розуміється система принципів і способів організації процесу розробки програмних засобів. Мета методології розробки ПЗ - впровадження методів розробки ПП, які забезпечують досягнення заданих характеристик якості.В даний час широку популярність набули два базових принципа розробки ПП: модульний і об'єктно-орієнтований.
Розробка модульних ПП ґрунтується на використанні структурних методів проектування, метою яких є розбиття за деякими правилам проектованого програмного засобу на структурні компоненти. До структурних методів проектування відносяться такі класичні методи,як структурне програмування, проектування «зверху-вниз» і «знизу-вверх», метод розширення ядра, а також ряд сучасних
методів і методологій розробки ПЗ.
Об'єктно-орієнтована розробка базується на застосуванні об'єктно-проектних методів, до яких відносяться методології об'єктно-орієнтованого аналізу, проектування і програмування.

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

реалізуються під управлінням основних сторін, які беруть участь в життєвому циклі програмних засобів. Основними сторонами є замовник, постачальник, розробники, користувачі і персонал супроводу програмних продуктів. До основних процесів відноситься п'ять процесів:
замовлення;
поставка;
розробка;
експлуатація;
супровід.

виконуються розробником. Даний процес містить тринадцять робіт:
1) підготовка процесу розробки;
2) аналіз вимог до системи;
3) проектування системної архітектури;
4) аналіз вимог до програмних засобів;
5) проектування програмної архітектури;
6) технічне проектування програмних засобів;
7) програмування і тестування програмних засобів;
8) збірка програмних засобів;
9) кваліфікаційні випробування програмних засобів;
10) збірка системи;
11) кваліфікаційні випробування системи;
12) введення в дію програмних засобів;
13) приймання програмних засобів.

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

розроблялися за принципом «кодування - усунення помилок»
       На сучасности етапі широко використовуються три базові методології розробки ПО:
- каскадна;
- інкрементна;
- еволюційна.
Існують тісні взаємозв'язки між моделлю ЖЦ, обраної при реалізації процесу розробки ПС, використовуваними методологіями і технологіями розробки ПС і рівнем якості розробленого програмного продукту.

Дана методологія базується на повному визначенні всіх вимог до програмного засобу або системи на початку процесу розробки. Кожен етап розробки починається лише після завершення попереднього етапу. Повернення до вже виконаних етапів не передбачається. проміжні продукти розробки в якості версії програмного засобу не розглядаються.
Використання даної методології найбільш ефективно в наступних випадках:
1) при розробці проектів з чіткими, незмінними протягом ЖЦ вимогами і зрозумілою реалізацією;
2) при розробці проектів невисокої складності;.
3) при виконанні великих проектів в якості складової частини моделей ЖЦ, що реалізують інші методології розробки.

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

Дана методологія базується на частковому визначенні вимог щодо розроблюваного програмного засобу або системи на початку процесу розробки. Вимоги поступово уточнюються в послідовних циклах розробки. Результат кожного циклу розробки зазвичай являє собою чергову версію програмного засобу або системи.
Слід зазначити, що в загальному випадку для еволюційної методології характерним є істотно менша кількість циклів розробки при більшій тривалості циклу в порівнянні з інкрементною методологією. При цьому результат кожного циклу розробки (чергова версія програмного засобу значно відрізняється від результату попереднього циклу.
Використання даної методології найбільш ефективно в наступних випадках:
1) при розробці проектів, для яких вимоги занадто складні, невідомі заздалегідь, непостійні або вимагають уточнення;
2) при розробці складних проектів, в тому числі:
- великих довгострокових проектів;
- проектів зі створення нових, які не мають аналогів ПЗ або систем;
- проектів зі середнім і високим ступенем ризиків;
- проектів, для яких потрібна перевірка концепції, демонстрація технічної здійсненності або проміжних продуктів;
3) при розробці проектів, що використовують нові технології.

1.2 Базові методології створення ПЗ.

ПЗ:
КП1. Що є причиною потреби в ПЗ?
Альтернативи рішень КП1
КП2. Спосіб задоволення ІТ-потреби?
Альтернативи рішень КП2

Покупка ПЗ

Виробництво
ПЗ

Замовлення
ПЗ

Комбінований
спосіб

:
КП3. Як позиціонується програмний продукт, вимоги до якого розробляються, в ієрархії вкладених систем?
Альтернативи рішень КП3
КП4. До якої категорії належить ПЗ за обсягом трикутника параметрів розробки: «час-ресурси-якість»?
Альтернативи рішень КП4

Невелике ПЗ

ПЗ середнього
обсягу

Велике ПЗ

Надвелике ПЗ

:
КП5. Які можливості залучення до процесів створення ПЗ розробників? Альтернативи рішень КП5
КП6. Жорсткість вимог до якості і надійності?
Альтернативи рішень КП6
КП7. Яким є рівень невизначеності щодо необхідних властивостей ПЗ? Альтернативи рішень КП7

альтернатив рішень для ключових
питань розробки ПЗ;
- формування контексту розробки ПЗ
- Мета розробки, призначення програми;
- Вхідні і вихідні дані;
- Функції обробки інформації;
- Вимоги до якості;
- Інші вимоги

Аналіз передумов розробки ПЗ

Проектування ПЗ

Постановка задачі

Реалізація ПЗ

Верифікація і тестування ПЗ

Розробка документації

Дослідна експлуатація

Застосування ПЗ

Артефакти

Складові підпроцеси

Документ
«Постановка
задачі»

Декомпозиція функцій і задачі розробки ПП
Виявлення компонент і програмних модулів
Візуалізація структури і функціональних
зв’язків ПП;
- Розробка інтерфейсів;

Документ
«Ескізний
проект»
«Технічний
проект»

Визначення порядку розробки модулів і мов
програмування;
Вибір способу організації і зберігання даних;
Вибір середовища для створення програм;
Кодування і відладка модулів;
- Формування баз даних (файлів даних).

Програми
модулів
Налаштовані
бази даних
Преамбула

Тестування модулів;
Збирання програмного продукту;
- Перевірка функціональності програми;
- Комплексне тестування програмного продукту

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

Розробка програми випробувань;
Дослідна експлуатація і збір статистики;
- Оцінка якості програмного продукту
Розробка пропозицій щодо удосконалення
програмного продукту;
Усунення помилок і доводка ПП;

Статистика
тестування

Тексти кодів
Опис програми
Інструкції
користувачів
Рекламні релізи

Статистичні дані
випробування ПП
Перелік змін

Акти здачі –
приймання ПП

Здача-приймання ПП
Навчання користувачів
Супровід ПП

Етапи розробки і основні процеси

Н І Ф У Н К Ц І Ї

Головний функціонал ПП

ОФ1

ОФ2

ОФn

ДФ1

ДФ2

ДФm

О С Н О В Н І

Д О П О М І Ж Н І

БФ1

БФ2

БФk

Б А З О В І Ф У Н К Ц І Ї О Б Р О Б К И І Н Ф О Р М А Ц І Ї

2

Програмний блок 1

Програмний блок 2

Рядок програмного кода 1

Рядок програмного кода 2

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

Виокремлена сукупність взаємозв’язаних
програмних модулів, яка реалізує певну
функціональність інформаційної системи

Відносно автономний , конструктивний елемент програмного компонента, який спеціалізується на певній ролі (ролях) в процесах компонента

Сукупність рядків програмного кода , які виконують певні види дій (операції) процесах обробки даних

Сукупність синтаксичних і семантичних одиниць мови програмування, якими кодуються комп’ютерні інструкції з обробки
даних

* Артефакт - будь який результат , отриманий при виконанні процесів розробки ПЗ і який має споживчу цінність для процесів розробки і застосування програмних продуктів

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

в термінах зрозумілих і користувачеві і розробнику програмного забезпечення і повинні висловлювати однозначний сенс. Неправильне тлумачення пропозиції призводить до створення програмного продукту, який правильно вирішує невірно сформульоване завдання.
Документ «Постановка завдання» може містити розділи:
1. Тема до програми.
2. Умова задачі. Формулюється умова завдання, короткий опис програми, що розробляється і її призначення.
3. Початок / закінчення роботи. Вказується місяць і рік початку / закінчення розробки програмного продукту.
4. Підстава для розробки. Підставою для розробки програмного забезпечення може бути замовлення користувача, завдання адміністрації навчального закладу, контракт навчального закладу з іншою організацією та ін.
5. Користувач (замовник). Вказуються замовники програмного продукту, і пояснюється, чому він їм необхідний.
6. Мета і призначення програми.
7. Основні вимоги. Перераховуються вимоги користувача до розробляється програмного продукту. Тут же з точки зору користувача слід перерахувати функції програмного продукту.
8. Вхідна інформація. Описуються всі вхідні дані програмного забезпечення з точки зору їх змісту і призначення - звіти, файли, записи, поля даних, таблиці. Їх можливі джерела, носії і засоби відображення інформації і т.д.
9. Вихідна інформація. Описуються вихідні дані так само, як в пункті 9. Споживачі вихідних Даних.
10. Зв'язок з іншими програмами
11. Вимоги до апаратного та програмного забезпечення. Конфігурація апаратури і програмного забезпечення, в яких розробляється система може працювати і інші програмні продукти, від яких вона залежить.
12. Зовнішні обмеження.
13. Ефективність. Цілі продуктивності, такі, як тимчасові характеристики, пропускна здатність, використання ресурсів, а також необхідні засоби вимірювання продуктивності і засоби настройки.
14. Безпека даних від несанкціонованого доступу.
15. Ергономічні характеристики. Ергономічними характеристиками вироби є такі властивості, які забезпечують надійність, комфорт і продуктивність роботи користувачів і операторів. Ергономіка (грец.) - праця + закон - галузь знання, що вивчає трудові процеси з метою створення найкращих умов праці.
16. Мобільність. Описуються вимоги і цілі забезпечення перенесення програмного продукту з одних робочих умов в інші.
17. Окупність капіталовкладень. Визначається прибуток, яку дасть створення програмного продукту в поняттях, відповідних цільовим призначенням організації.
18. Інші угоди сторін.
19. Термінологія. Чітко визначається вся термінологія, яка може виявитися специфічної для даної розробки