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

Є такі визначення, що використовуються у виробництві:

1. Створення сукупності документів, розрахунків, креслень, необхідних для виготовлення виробу.

2. Планування, організація, задум

Проектування ПЗ – це розробка архітектури системи. Під архітектурою ПЗ розуміємо внутрішню будову системи, тобто, з яких компонентів вона складається і як вони взаємодіють між собою. Ще до поняття архітектури ПЗ включають розробку користувацького інтерфейсу. Проектування ПЗ полягає у створенні представлення про складові програмного забезпечення та зв’язки між ними, алгоритми роботи програми, структури даних, про модульну структуру ПЗ, вхідний і вихідний інтерфейси. Одним з найважливіших інструментів проектування архітектури ПЗ є «Патерн» - типовий конструктивний елемент, який задає взаємодію компонентів спроектованої системи. Патерн проектування – це зразок, готовий до використання, іншими словами, шаблон.

Реалізація

Зміст цього етапу – конструювання програмної системи за розробленими проектними документами та кодування проектних рішень вибраною мовою програмування. Етап складається з таких робіт:

1. Створення алгоритмів мовою програмування.

2. Кодування окремих модулів програми.

3. Створення цілісного коду програми на основі інтеграції компонентів.

4. Налагодження вихідного коду.

Основний результат цього етапу – вихідний код програми та файли конфігурації. Конфігурація системи – це склад функцій програмного та технічного забезпечення системи, їх можливі комбінації, в залежності від наявності обладнання, загальних системних засобів, зазначених у технічній документації системи.

Тестування та верифікація пз (Software testing )

Тестування ПЗ – це процес перевірки ГОТОВОЇ програми в статиці(перегляди інспекції налагодження вихідного коду) і динаміці способом прогону кінцевого набору тестових даних для різних шляхів виконання програми, та порівняння отриманих результатів із заздалегідь запланованими.

На цьому етапі передбачається участь користувачів і спеціальних фахівців (тестерів) у всіх перевірках системи.

Готова програма – це та, яку розробник вважає правильно працюючою. Тестування – це не процес від лагодження програми.

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

Методи тестування поділяються на дві групи :

• СТАТИЧНІ (коли тестування виконується шляхом перевірки коду без запуску самої програми);

• ДИНАМІЧНІ (коли тестування виконується шляхом запуску програми);

Різні рівні тестування

• Тестування окремих програмних модулів (модульне );

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

Верифікація / Verification

Верифікація вимог – це процес перевірки правильності специфікацій вимог на їх відповідність, несуперечність, повноту і здійсненність, а також на відповідність стандартам. Основний результат цього етапу – контроль відповідності програми вимогам.

Експлуатація і супровід Software operation and maintenance

Етап включає такі роботи :

• Виконання готової програмної системи;

• Оцінка її ефективності виконання;

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

• Внесення необхідних змін для підтримки актуальності програмної системи;

• Перевірка коректності внесених змін (зміни не повинні негативно впливати на функціонування системи).

Супровід – трудомісткий процес

• Він охоплює дії стосовно вже розробленого ПЗ які виконуються після поставки програмного продукту замовнику.

• Проблема супроводу реальних програм є в тому що вони настільки великі що через певний час розробник вже не пам‘ятає усіх деталей запису коду.

• Супровід може потребувати більше ніж половину бюджету закладений на весь життєвий цикл програми.

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

• Це щонайменше потребує достатньої кількості коментарів в програмі.

• Необхідна повна адекватна документація до розробленого ПЗ.

• ПЗ оптимально/»правильно» спроектовано.

• Модифікацією коди програми можуть займатись не розробники а зовсім інші люди.

Дві групи робіт зі супроводу програмних систем :

• Усунення дефектів

• Вдосконалення програми

• Перший вид робіт спричиняє недостатньо повне тестування системи;

• Другий вид робіт спричиняють зміни факторів використання програми.

Реінженірінг та рефакторінг

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

Завершальний етап ЖЦ

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

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

Висновок

Усі ці етапи так чи інакше присутні у процесі розробки, але розробники часто змінюють 9 адаптують) їх залежно від обставин.

Життєвий цикл є ітеративний (допускає багатократне повторення своїх етапів).

Формула чотири «П»

Фактично система розробки програмних продуктів складається із чотирьох «П»: персонал, процес, проект продукт.

Продукт є більш ширшим поняттям, адже крім самої програми включає ще і так звані артефакти, наприклад результати тестів, документацію, засоби просування та реклами програми і т.д. Артефакт - це будь який штучно створений об‘єкт, артефакт ПЗ – це інформація, що використовується чи з‘являється в процесі розробки ПЗ.

Чи якісний вироблений продукт – створене ПЗ ?

• Основною характеристикою правильності роботи великих програм є їх якість.

• Поняття якісна програма означає, що програма успішно виконує усі поставлені на неї задачі і не створює проблем під час роботи усім зацікавленим особам.

• Згідно вимог стандарту ISO 9126 якість ПЗ поділяється на такі складові: внутрішня якість ( якість коду), зовнішня якість ( якість роботи програми) і якість при використанні (відгуки користувачів).

Якість задається такими властивостями:

• Функціональність;

• Надійність (найскладніше дослідити, бо немає ніяких критерій щодо цього. Стандартні теорії надійності що застосовуються для матеріальних системи не можуть бути використані для ПЗ);

• Зручність використання;

• Продуктивність;

• Зручність супроводу;

Переносимість / мобільність (здатність працювати на різних платформах).

Роль стандартів ПІ

Для укладання контракту, розробник повинен бути впевнений, що розробник не завалить проект. У світовій практиці промислового виробництва використовують практику стандартів на виробництво продуктів та послуг та сертифікацію виробників на відповідність цих стандартів. Замовник запитує у розробника: «Якими стандартами Ви володієте і чи є у Вас сертифікати на відповідність цим стандартам?». Процес стандартизації та сертифікації є основою промислового виробництва ПЗ. Міжнародні стандарти розробляються спеціальними міжнародними організаціями. Право сертифікації отримують організації, що пройшли ліцензування в міжнародних організаціях. Міжнародні стандарти враховують досвід відомих ІТ компаній, та грунтуються на корпоративних стандартах.

Історія впровадження стандартів

Перший стандарт 1985- 1988рр.

Розробка програмних засобів для систем військового призначення ( DOD-STD-2167A). Вперше формалізовано життєвий цикл розробки ПЗ,що вироблялося на замовлення міністерства оборони США. Регламентовано 8 етапів ЖЦ для складних програмних систем. Сформульовано 250 обов‘язкових вимог до процесів та об‘єктів проектування.

Стандарт 1995 року

«Процеси життєвого циклу для програмного забезпечення»

Зміст кожного процесу задавався описом загальних його функцій та переліком дій для забезпечення цих функцій. Для кожного процесу в стандарті представлена вхідна та вихідна інформація. Описаний процес адаптація (всі програмні засоби є унікальні). В стандарті представлено 4 варіанти адаптації процесів життєвого циклу до конкретних особливостей конкретних проектів. Розробка перших стандартів ЖЦ ПЗ та їх практичне застосування зіштовхнулись з такими проблемами :

1. Впровадження стандартів вимагає залучення додаткових коштів, це не завжди окуповувалися.

2. Незрозуміло чи всі процеси потрібно виконувати і якою мірою.

3. Різні типи ПЗ зумовлюють різні вимоги.

4. Динаміка розвитку ІТ галузі спричиняє швидке старіння стандартів.

5. Термінологічна неоднозначність корпоративних стандартів.

6. У більшості випадків застосування стандартів вимагалося лише замовниками, розробники на практиці не відчували користі від застосування стандартів.

Стандарт ISO/IEC 12207 “Information Technology – Software Life Cycle Processes” (1995, 2008)

Автори організація ISO (International Organization of Standardization), IEC (International Electrotechnical Commission).

Основні результати стандарту ISO :

1. Введення єдиної термінології для розробників, замовників, користувачів і загалом усіх зацікавлених в галузі ПІ.

2. Поділ понять ЖЦ ПЗ, модуль ЖЦ ПЗ.

ЖЦ ПЗ це повна сукупність усіх процесів, а модель ЖЦ це конкретний варіант організації ЖЦ обґрунтовано обраний для конкретного випадку.

3. Опис структури ЖЦ та класифікація процесів.

4. Виділення окрему процесу адаптації для побудови конкретних моделей ЖЦ.