Життєвий цикл програмного забезпечення: поняття, стандарти, процеси. Життєвий цикл програмного забезпечення (ЖЦ ПЗ) Що входить у життєвий цикл програмного забезпечення

Життєвий цикл програмного забезпечення

Життєвий цикл програмного забезпечення- період часу, який починається з прийняття рішення про необхідність створення програмного продукту і закінчується у його повного вилучення з експлуатації. (Стандарт IEEE Std 610.12)

Необхідність визначення етапів життєвого циклу (ЖЦ) ПЗ обумовлена ​​прагненням розробників до підвищення якості ПЗ за рахунок оптимального управліннярозробкою та використання різноманітних механізмів контролю якості на кожному етапі, починаючи від постановки завдання та закінчуючи авторським супроводом ПЗ. Найбільш загальним уявленням життєвого циклу ПЗ є модель у вигляді базових етапів – процесів, до яких відносяться:

Системний аналіз та обґрунтування вимог до ПЗ;

Попереднє (ескізне) та детальне (технічне) проектування ПЗ;

Розробка програмних компонент, їх комплексування та налагодження ПЗ у цілому;

Випробування, дослідна експлуатація та тиражування ПЗ;

Регулярна експлуатація ПЗ, підтримка експлуатації та аналіз результатів;

Супровід ПЗ, його модифікація та вдосконалення, створення нових версій.

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

Стандарти життєвого циклу ПЗ

ГОСТ 34.601-90

ISO/IEC 12207:1995 (російський аналог - ГОСТ Р ІСО/МЕК 12207-99)

Графічне уявлення моделей ЖЦ дозволяє наочно виділити їх особливості та деякі властивості процесів.

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

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

Ризик перевищення термінів та вартості проекту;

Необхідність виконання ще однієї ітерації;

Ступінь повноти та точності розуміння вимог до системи;

Доцільність припинення проекту.

Стандартизація ЖЦ ПЗ проводиться за трьома напрямками. Перший напрямок організується та стимулюється Міжнародною організацією зі стандартизації (ISO – International Standard Organization) та Міжнародною комісією з електротехніки (IEC – International Electro-technical Commission). На цьому рівні здійснюється стандартизація найзагальніших технологічних процесів, що мають значення для міжнародної кооперації. Другий напрямок активно розвивається в США Інститутом інженерів електротехніки та радіоелектроніки (IEEE - Institute of Electrotechnical and Electronics Engineers) спільно з Американським національним інститутом стандартизації (American National Standards Institute-ANSI). Стандарти ISO/IEC та ANSI/IEEE в основному мають рекомендаційний характер. Третій напрямок стимулюється Міністерством оборони США (Department of Defense-DOD). Стандарти DOD мають обов'язковий характер для фірм, які працюють на замовлення Міністерства оборони США.

Для проектування програмного забезпечення складної системи, особливо системи реального часу, доцільно використовувати загальносистемну модель ЖЦ, засновану на об'єднанні всіх відомих робіт у рамках розглянутих базових процесів. Ця модель призначена для використання при плануванні, складанні робочих графіків, управлінні різними програмними проектами.

Сукупність етапів даної моделі ЖЦ доцільно ділити на дві частини, що істотно відрізняються особливостями процесів, техніко-економічними характеристиками та факторами, що впливають на них.

У першій частині ЖЦ проводиться системний аналіз, проектування, розробка, тестування та випробування ПЗ. Номенклатура робіт, їх трудомісткість, тривалість та інші показники цих етапах істотно залежить від об'єкта і середовища розробки. Вивчення подібних залежностей для різних класів ПЗ дозволяє прогнозувати склад та основні характеристики графіків робіт для нових версій ПЗ.

Друга частина ЖЦ, що відображає підтримку експлуатації та супроводу ПЗ, відносно слабо пов'язана з характеристиками об'єкта та середовища розробки. Номенклатура робіт цих етапах більш стабільна, які трудомісткість і тривалість можуть істотно змінюватися, і залежить від масовості застосування ПО. Для будь-якої моделі ЖЦ забезпечення високої якостіпрограмних комплексів можливе лише при використанні регламентованого технологічного процесукожному з цих етапів. Такий процес підтримується засобами автоматизації розробки, які доцільно вибирати з наявних чи створювати з урахуванням об'єкта розробки та адекватного йому переліку робіт.

Анотація.

Вступ.

1. Життєвий цикл ПЗ

Вступ.

Кроки процесу програмування по Райлі

Вступ.

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

1.1.2. Проектування рішення.

1.1.3. Кодування алгоритму.

1.1.4. Супровід програми.

1.1.5. Програмна документація

Висновок до п. 1.1

1.2. Визначення ЖЦПО за Леманом.

Вступ.

1.2.1 Визначення системи.

1.2.2. Реалізація.

1.2.3. Обслуговування.

Висновок п. 1.2.

1.3. Фази та роботи ЖЦПО з Боему

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

1.3.2. Економічне обґрунтування каскадної моделі.

1.3.3. Удосконалення каскадної моделі.

1.3.4. Визначення фаз життєвого циклу.

1.3.5. Основні роботи над проектом.

Література.

Вступ

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

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

1 Життєвий цикл ПЗ

ВСТУП

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

Існує кілька підходів щодо фаз і робіт життєвого циклу програмного забезпечення (ЖЦПО), кроків процесу програмування, каскадна і спіральна моделі. Але вони містять загальні основні компоненти: постановка завдання, проектування рішення, реалізація, обслуговування.

Найбільш відомою і повною, мабуть, є структура ЖЦПО Боему, що включає вісім фаз. Вона і буде представлена ​​надалі докладніше.

Одним з можливих варіантів може послужити опис верхнього рівня по Леман, що включає три основні фази і представляє опис ЖЦПО в загальному випадку.

І, для різноманітності – наведемо кроки процесу програмування, представлені Д.Райлі у книзі «Використання мови Модула-2». Це уявлення, на мою думку, є дуже простим і звичним, з нього і почнемо.

1.1 Кроки процесу програмування по Райлі

Вступ

Процес програмування включає чотири кроки (рис. 1):

постановка завдання, тобто. отримання адекватного ставлення до тому, яку завдання має виконати програма;

проектування вирішення вже поставленого завдання (загалом, таке рішення є менш формальним, ніж остаточна програма);

кодування програми, тобто переведення спроектованого рішення у програму, яка може бути виконана на машині;

супровід програми, тобто. процес усунення в програмі неполадок і додавання нових можливостей.

Мал. 1.Чотири кроки програмування.

Програмування починається з того моменту, коли користувач, тобто. той, хто потребує програми для вирішення завдання, викладає проблему системного аналітика.Користувач та системний аналітик спільно визначають постановку задачі. Остання потім передається алгоритмісту, що відповідає за проектування рішення. Рішення (або алгоритм) є послідовністю операцій, виконання яких призводить до вирішення задачі. Оскільки алгоритм часто не пристосований до виконання машиною, його слід перевести в машинну програму. Ця операція виконується кодувальником. За наступні зміни у програмі відповідає відповідальний програміст. І системний аналітик, і алгоритміст, і кодувальник, і програміст, що супроводжує – всі вони є програмістами.

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

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

Одним із найважливіших кроків програмування є постановка задачі. Вона виконує функції контракту між користувачем та програмістом (програмістами). Як і юридично погано складений контракт, погана постановка завдання марна. При хорошій постановці завдання як користувач, і програміст ясно і недвозначно представляють завдання, яку потрібно виконати, тобто. у разі враховуються інтереси як користувача, і програміста. Користувач може планувати використання ще нествореного програмного забезпечення, спираючись на знання того, що може. Хороша постановка завдання є основою формування її розв'язання.

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

Характеристики Гарної Постановки Завдання:

Точність, тобто. виняток будь-якої неоднозначності. Не повинно бути питань щодо того, яким буде виведення програми при кожному конкретному введенні.

Повнота, тобто. розгляд всіх варіантів для заданого введення, включаючи помилкове або непередбачене введення, та визначення відповідного виведення.

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

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

Стандартна форма постановки задачі.

Розглянемо таку постановку задачі: «Ввести три числа та вивести числа у порядку».

Така постановка не задовольняє наведеним вище вимогам: вона не є точною, ні повною, ні зрозумілою. Справді, чи числа вводяться по одному на рядку або всі числа на одному рядку? Чи означає вираз «у порядку» впорядкування від більшого до меншого, від меншого до більшого або той самий порядок, в якому вони були введені.

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

найменування задачі (схематичне визначення);

загальний опис (короткий виклад задачі);

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

приклад ( гарний прикладможе передати сутність завдання, і навіть проілюструвати різні випадки).

приклад. Постановка завдання у стандартній формі.

НАЗВА

Сортування трьох цілих чисел.

ОПИС

Введення та виведення трьох цілих чисел, відсортованих від меншого числа до більшого.

Вводяться три цілих числа по одному числу на рядку. При цьому цілим числом є одна або кілька послідовних десяткових цифр, яким може передувати знак плюс + або знак мінус -.

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

1) Якщо введено менше трьох чисел, програма чекає на додаткове введення.

2) Рядки введення, крім перших трьох, ігноруються.

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

з електротехніки). Цей стандарт визначає структуру ЖЦ, що містить процеси, дії та завдання, які мають бути виконані під час створення ПС.

У цьому стандарті ПС (або програмний продукт) визначається як набір комп'ютерних програм, процедур та, можливо, пов'язаної з ними документацією та даних. Процес визначається як сукупність взаємопов'язаних дій, що перетворюють деякі вхідні дані на вихідні (Г. Майєрс називає це трансляцією даних). Кожен процес характеризується певними завданнями та методами їх вирішення. У свою чергу, кожен процес поділено на набір дій, а кожна дія – на набір завдань. Кожен процес, дія чи завдання ініціюється і виконується іншим процесом у міру необхідності, причому не існує заздалегідь визначених послідовностей виконання (звісно, ​​при збереженні зв'язків за вхідними даними).

Слід зазначити, що у Радянському Союзі, та був у Росії створення програмного забезпечення ( ПЗ ) спочатку, у роки минулого століття, регламентувалося стандартами ГОСТ ЕСПД ( Єдиної системипрограмної документації – серії ГОСТ 19.ХХХ), орієнтовані на клас щодо простих програм невеликого обсягу, створюваних окремими програмістами. В даний час ці стандарти застаріли концептуально і формою, їх терміни дії закінчилися і використання недоцільно.

Процеси створення автоматизованих систем(АС), до складу яких входить і ПЗ, регламентовані стандартами ГОСТ 34.601-90 " Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Стадії створення", ГОСТ 34.602-89 "Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи" та ГОСТ 34.603-92 "Інформаційна технологія. Види випробувань автоматизованих систем". Однак багато положень цих стандартів застаріли, а інші відображені недостатньо, щоб їх можна було застосовувати для серйозних проектів створення ПС. Тому у вітчизняних розробках доцільно використати сучасні міжнародні стандарти.

Відповідно до стандартом ISO/ IEC 12207 всі процеси ЖЦ ПЗ розділені на три групи (рис.5.1).

Мал. 5.1.

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

5.2. Основні процеси ЖЦ ПС

Процес придбання складається з дій та завдань замовника, що набуває ПС. Цей процес охоплює такі дії:

1. ініціювання придбання;
2. підготовку заявних пропозицій;
3. підготовку та коригування договору;
4. нагляд над діяльністю постачальника;
5. приймання та завершення робіт.

Ініціювання придбання включає такі завдання:

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

Заявні пропозиції повинні містити:

1. вимоги до системи;
2. список програмних продуктів;
3. умови придбання та угоди;
4. технічні обмеження (наприклад, серед функціонування системи).

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

Підготовка та коригування договору включає наступні завдання:

1. визначення замовником процедури вибору постачальника, що включає критерії оцінки пропозицій потенційних постачальників;
2. вибір конкретного постачальника з урахуванням аналізу пропозицій;
3. підготовку та висновок договори з постачальником;
4. внесення змін (при необхідності) до договору у процесі його виконання.

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

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

1. ініціювання постачання;
2. підготовку відповіді на заявні пропозиції;
3. підготовку договору;
4. планування робіт за договором;
5. виконання та контроль договірних робіт та їх оцінку;
6. постачання та завершення робіт.

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

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

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

Процес розробки включає такі дії:

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

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

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

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

Аналіз вимог до програмного забезпечення передбачає визначення наступних характеристик для кожного компонента ПЗ:

1. функціональних можливостей, включаючи характеристики продуктивності та середовища функціонування компонента;
2. зовнішніх інтерфейсів;
3. специфікацій надійності та безпеки;
4. ергономічні вимоги;
5. вимог до використовуваних даних;
6. вимог до встановлення та приймання;
7. вимог до документації користувача;
8. вимог до експлуатації та супроводу.

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

Проектування архітектури ПЗ включає наступні завдання для кожного компонента ПЗ:

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

Детальне проектування ПЗ включає такі завдання:

1. опис компонентів ПЗ та інтерфейсів між ними на нижчому рівні, достатньому для подальшого кодування та тестування;
2. розробку та документування детального проекту бази даних;
3. оновлення (при необхідності) документації користувача;
4. розробку та документування вимог до тестів та плану тестування компонентів ПЗ;

Кодування та тестування ПЗ включає такі завдання:

1. кодування та документування кожного компонента ПЗ та бази даних, а також підготовку сукупності тестових процедур та даних для їх тестування;
2. тестування кожного компонента ПЗ і БД на відповідність вимогам, що пред'являються до них, з подальшим документуванням результатів тестування;
3. оновлення документації (за потреби);
4. оновлення плану інтеграції ПЗ.

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

Кваліфікаційне тестування ПЗ проводиться розробником у присутності замовника (

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

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

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

Життєвий цикл програмного забезпечення

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

Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Міжнародна організаціязі стандартизації, IEC – International Electrotechnical Commission – Міжнародна комісія з електротехніки). Він визначає структуру ЖЦ, що містить процеси, дії та завдання, які мають бути виконані під час створення ПЗ. У цьому стандарті ПЗ (програмний продукт)визначається як набір комп'ютерних програм, процедур та, можливо, пов'язаної з ним документації та даних. Процесвизначається як сукупність взаємозалежних процесів, що перетворюють деякі вхідні дані у вихідні. Кожен процес характеризується певними завданнями та методами їх вирішення, вихідними даними, отриманими з інших процесів, та результатами.

Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:

· Основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);

· Допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, вирішення проблем);

· організаційні процеси(Управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого ЖЦ, навчання).

Моделі життєвого циклу ПЗ

Модель життєвого циклу- структура, що визначає послідовність виконання та взаємозв'язку стадій та етапів, що виконуються протягом ЖЦ. Модель ЖЦ залежить від специфіки ПЗ та специфіки умов, у яких остання створюється та функціонує. Основні моделі ЖЦ такі.

1. Каскадна модель(до 70-х років XX ст) визначає послідовний перехід на наступний етап після завершення попереднього.

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

Гідність: хороші показники за термінами розробки та надійності при вирішенні окремих завдань

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

2. Ітераційна модель(70-80-ті роки XX ст.) відповідає технології проектування "знизу - вгору". Допускає ітераційні повернення на попередні етапи після виконання чергового етапу;

Модель передбачає узагальнення одержаних проектних рішень окремих завдань у загальносистемні рішення. У цьому виникає потреба у перегляді раніше сформульованих вимог.

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

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

3. Спіральна модель(80-90-ті роки XX ст.) відповідає технології проектування «зверху – вниз». Передбачає використання програмного прототипу, що припускає програмне розширення. Проект системи циклічно повторює шлях від деталізації вимог до деталізації програмного коду.

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

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

Переваги:

1. скорочення кількості ітерацій і, отже, кількість помилок і невідповідностей, які необхідно виправляти;

2. скорочення термінів проектування;

3. спрощення створення проектної документації.

Недолік:високі вимоги до якості загальносистемного репозиторію ( загальної базипроектних даних).

Спіральна модель лежить в основі технології швидкої розробки додатківабо RAD-технології (rapid application development), що передбачає активну участь кінцевих користувачів майбутньої системи у процесі її створення. Основні стадії інформаційного інжинірингу такі:

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

· Проектування.Користувачі під керівництвом розробників беруть участь у технічному проектуванні.

· Конструювання.Розробники проектують робочу версію програмного забезпечення з використанням мов 4-го покоління;

· Використання.Розробники навчають користувачів роботі серед нової ПЗ.

Мал. 5.2.

Такими аспектами є:

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

p align="justify"> Організаційні процеси виконуються на корпоративному рівні або на рівні всієї організації в цілому, створюючи базу для реалізації та постійного вдосконалення процесів ЖЦ ПЗ.

5.6. Моделі та стадії ЖЦ ПЗ

Під моделлю ЖЦ ПО розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій та завдань протягом ЖЦ ПО . Модель ЖЦ залежить від специфіки, масштабу та складності проекту та специфіки умов, у яких система створюється та функціонує.

Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ та методи розробки ПЗ. Його положення є спільними для будь-яких моделей ЖЦ, методів та технологій розробки ПЗ. Стандарт описує структуру процесів ЖЦ ПЗ, але не конкретизує, як реалізувати або виконати дії та завдання, включені до цих процесів.

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

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

1. формування вимог до ПЗ;
2. проектування (розробка системного проекту);
3. реалізація (може бути розбита на підетапи: детальне проектування, кодування);
4. тестування (може бути розбите на автономне та комплексне тестування та інтеграцію);
5. введення у дію (впровадження);
6. експлуатація та супровід;
7. зняття з експлуатації.

Деякі фахівці додатково вводять початкову стадію – аналіз здійсненностісистеми. Тут мають на увазі програмно-апаратна система, на яку створюється, купується чи модифікується ПЗ .

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

Стадія формування вимог до ПЗ включає такі етапи.

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

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

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

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

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

Стадія проектування включає такі етапи.

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

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

2. Розробка детального (технічного) проекту. На цьому етапі здійснюється власне проектування ПЗ, що включає проектування архітектури системи та детальне проектування. Таким чином, дається відповідь на запитання: "Як побудувати систему, щоб вона задовольняла вимоги?"

Результатом детального проектування є розробка верифікованої специфікації ПЗ, що включає:

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

Завершенням стадії детального проектування є наскрізний