Життєвий цикл пз

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

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

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

Головні ресурси програмної iнженерiї, що визначають ефективнiсть розроблень, - це час та вартiсть.

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

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

Характерні роботи процесу розроблення:

• Визначення вимог. Збiр та аналiз вимог замовника виконавцем та подання їх у нотацiї, яка є зрозумiлою як замовнику, так i виконавцю.

• Проектування. Перетворення вимог до розроблення у послiдовнiсть проектних рiшень щодо способiв реалiзацiї вимог: формування загальної архiтектури програмної системи та принципiв її прив'язки до конкретного середовища функцiонування; визначення детального складу модулiв кожної з архiтектурних компонент.

• Реалiзацiя. Перетворення проектних рiшень у програмну систему, що реалiзує означенi рiшення.

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

• Експлуатацiя та супроводження готової системи.

Інженерiя вимог

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

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

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

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

• побудову двох видів моделей:

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

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

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

1) удосконалюванням існуючих технологій на основі оцінки їхньої ефективності;

2) радикальною зміною технологій і перепроектуванням бізнес-процесів.

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

Є кiлька класiв нефункцiональних вимог, суттєвих для бiльшостi ІС, якi виражають обмеження, актуальнi для багатьох проблемних галузей:

• вимоги конфiденцiйностi;

• вiдмовостiйкiсть;

• кiлькiсть клiєнтiв, що одночасно мають доступ до системи;

• вимоги безпеки;

• час очікування вiдповiдi на звернення до системи;

• виконавськi якостi системи (обмеження щодо ресурсiв пам'ятi, швидкiсть реакцiї на звернення до системи тощо).

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

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