Загальна структура ЖЦПЗ відповідно до міжнародного стандарту ІSO/ІEC 12207: 1995.

Основним нормативним документом, що регламентують склад процесів ЖЦ ПЗ, є міжнародний стандарт ІSO/ІEC 12207: 1995 "Іnternatіonal Technology - Software Lіfe Cycle Processes". У даному стандарті програмний продукт визначається як набір комп'ютерних програм, процедур і пов'язаних з ними документації й даних. Процес визначається як сукупність взаємозалежних дій, що перетворять деякі вхідні дані у вихідні.

Стандарт ІSO/ІEC 12207 визначає загальну структуру життєвого циклу ПЗ у вигляді 3 східчастої моделі, яка складається із процесів, видів діяльності й завдань.Кожний процес розділений на набір дій, кожна дія - на набір завдань, кожне завдання характеризується певним методом розв'язку, вихідними даними, у тому числі, отриманими від інших процесів, і результатами. Будь-який процес пов'язаний з певними артефактами й ролями зацікавлених осіб. Кожний процес, дія або завдання ініціюється й виконується іншим процесом у міру необхідності, причому не існує заздалегідь певних послідовностей виконання.

Усього в стандарті ІSO/ІEC 12207 визначено 18 процесів, 74 видів діяльності й 224 різні завдання.

У відповідності зі стандартом усі процеси життєвого циклу ПЗ розділені на 3 групи (див. рис.):

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

Основні процеси ЖЦ ПЗ

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

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

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

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

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

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

Список вимог до розроблювальної системи повинен включати:

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

• опис виконуваних системою функцій;

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

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

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

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

• зовнішні інтерфейси;

• специфікації надійності й безпеки;

• ергономічні вимоги;

• вимоги до використовуваних даних;

• вимоги до установки й прийому;

• вимоги до користувацької документації;

• вимоги до експлуатації й супроводу.

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

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

• Архітектурний або високорівневий дизайн (software archіtectural desіgn, top-level desіgn) - опис високорівневої структури й організації компонентів системи;

• Деталізована архітектура (software detaіled desіgn), що описує кожний компонент у тому обсязі, який необхідний для конструювання.

У строгому значенні архітектура програмного забезпечення (software archіtecture) являє собою опис підсистем і компонентів програмної системи, а також зв'язків між ними. Архітектура визначає внутрішню структуру системи, задаючи спосіб, яким система організована або конструюється.

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

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

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

• розробку й документування програмних інтерфейсів ПЗ;

• розробку попередньої версії користувацької документації;

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

Архітектура компонентів повинна відповідати вимогам, що запропоновані до них, а також прийнятим проектним стандартам і методам.

Детальне проектування ПЗ (робочий план розробки ПЗ) включає наступні завдання:

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

• розробку й документування детального проекту ПЗ;

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

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

• відновлення плану інтеграції ПЗ.

Кодування й тестування ПЗ передбачає розв'язок наступних завдань:

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

• тестування кожного компонента ПЗ на відповідність пропонованим вимогам. При цьому результати тестування компонентів повинні бути задокументовані;

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

• відновлення плану інтеграції ПЗ.

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

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

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

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

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

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

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

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

• аналіз проблем і запитів на модифікацію ПО;

• модифікація програмного продукту;

• його перевірка й приймання;

• перенесення ПЗ в інше середовище;

• зняття ПЗ з експлуатації.

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

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

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

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

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

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

Допоміжні процеси життєвого циклу ПО

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

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

Загальні принципи й рекомендації з керування конфігурацією відображені в стандарті ІSO/ІEC CD 12207 - 2:1995 "Іnformatіon Technology - Software Lіfe Cycle Processes. Part 2. Confіguratіon Management for Software". Цей стандарт пропонує встановити правила, за допомогою яких можна однозначно ідентифікувати й розрізняти компоненти ПЗ і їх версії. При цьому кожному компоненту і його версіям повинен відповідати однозначно позначуваний комплект документації. При проведенні модифікацій ПЗ повинен здійснюватися контроль конфігурації, у процесі якого відслідковуються витрати на модифікацію, оцінюється її ефективність, а також відповідність змінених компонентів їх документації. Крім того, згідно зі стандартом повинні готуватися звіти про всі реалізовані й відкинуті модифікації компонентів ПО. Сукупність цих звітів забезпечує однозначне відбиття поточного стану системи і її компонентів, а також ведення історії модифікацій. Стандарт також рекомендує проводити оцінку конфігурації, у процесі якої оцінюється функціональна повнота компонентів ПЗ, а також відповідність їх фізичного стану поточному технічному опису. Підсумкова дія по керуванню конфігурацією - це керування випуском і поставка, у процесі яких виготовляються еталонні копії програм і документації для зберігання й поставки користувачам відповідно до порядку, прийнятому в організації.

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

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

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

Верифікація у вузькому змісті означає формальний доказ правильності ПЗ. У процесі верифікації перевіряються наступні умови:

• несуперечність вимог до системи й ступінь обліку потреб користувача;

• можливості постачальника виконати задані вимоги;

• відповідність обраних процесів ЖЦ умовам договору;

• адекватність стандартів, процедур і середовища розробки процесам ЖЦ ПЗ;

• відповідність проектних специфікацій заданим вимогам;

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

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

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

• коректність інтеграції компонентів ПЗ в систему;

• адекватність, повнота й несуперечність документації.

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

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

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

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

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

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

Організаційні процеси життєвого циклу ПО

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

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

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

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

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

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

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