Шкірні захворювання 

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


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

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

Методології розробки ПЗ

  • Rational Unified Process (RUP).
  • Microsoft Solutions Framework (MSF). Включає чотири фази: аналіз, проектування, розробка, стабілізація, передбачає використання об'єктно-орієнтованого моделювання.
  • Екстремальне програмування ( Extreme Programming, XP). В основі методології командна робота, ефективна комунікація між замовником та виконавцем протягом усього проекту з розробки ІВ. Розробка ведеться з використанням послідовно допрацьованих прототипів.

Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 передбачає такі стадії та етапи створення автоматизованої системи:

  1. Формування вимог до АС
    1. Обстеження об'єкта та обґрунтування необхідності створення АС
    2. Формування вимог користувача до АС
    3. Оформлення звіту про виконання робіт та заявки на розробку АС
  2. Розробка концепції АС
    1. Вивчення об'єкту
    2. Проведення необхідних науково-дослідних робіт
    3. Розробка варіантів концепції АС та вибір варіанта концепції АС, який відповідає вимогам користувачів
    4. Оформлення звіту про виконану роботу
  3. Технічне завдання
    1. Розробка та затвердження технічного завдання на створення АС
  4. Ескізний проект
    1. Розробка попередніх проектних рішень щодо системи та її частин
  5. Технічний проект
    1. Розробка проектних рішень щодо системи та її частин
    2. Розробка документації на АС та її частини
    3. Розробка та оформлення документації на постачання комплектуючих виробів
    4. Розробка завдань на проектування у суміжних частинах проекту
  6. Робоча документація
    1. Розробка робочої документації на АС та її частини
    2. Розробка та адаптація програм
  7. Введення в дію
    1. Підготовка об'єкта автоматизації
    2. Підготовка персоналу
    3. Комплектація АС виробами, що постачаються (програмними та технічними засобами, програмно-технічними комплексами, інформаційними виробами)
    4. Будівельно-монтажні роботи
    5. Пуско-налагоджувальні роботи
    6. Проведення попередніх випробувань
    7. Проведення дослідної експлуатації
    8. Проведення приймальних випробувань
  8. Супровід АС.
    1. Виконання робіт відповідно до гарантійних зобов'язань
    2. Післягарантійне обслуговування

Ескізний, технічний проекти та робоча документація - це послідовна побудова дедалі точніших проектних рішень. Допускається виключати стадію «Ескізний проект» та окремі етапи робіт на всіх стадіях, об'єднувати стадії «Технічний проект» та «Робоча документація» у «Техноробочий проект», паралельно виконувати різні етапи та роботи, включати додаткові.

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

Стандарт ISO/IEC 12207/ та його застосування

Стандарт ISO/IEC 12207:1995 "Information Technology - Software Life Cycle Processes" є основним нормативним документом, що регламентує склад процесів життєвого циклу ПЗ. Він визначає структуру життєвого циклу, що містить процеси, дії та завдання, які мають бути виконані під час створення ПЗ.

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

Процеси життєвого циклу ПЗ

  • Основні:
    • Придбання (дії та завдання замовника, що набуває ПЗ)
    • Постачання (дії та завдання постачальника, який забезпечує замовника програмним продуктом або послугою)
    • Розробка (дії та завдання, що виконуються розробником: створення ПЗ, оформлення проектної та експлуатаційної документації, підготовка тестових та навчальних матеріалів тощо)
    • Експлуатація (дії та завдання оператора - організації, яка експлуатує систему)
    • Супровід (дії та завдання, що їх супроводжує організація, тобто служба супроводу). Супровід - внесення змін до ПЗ з метою виправлення помилок, підвищення продуктивності або адаптації до умов роботи або вимог, що змінилися.
  • Допоміжні
    • Документування (формалізоване опис інформації, створеної протягом ЖЦ ПЗ)
    • Управління конфігурацією (застосування адміністративних і технічних процедур протягом ЖЦ ПЗ визначення стану компонентів ПЗ, управління його модифікаціями).
    • Забезпечення якості (забезпечення гарантій того, що ІВ та процеси її ЖЦ відповідають заданим вимогам та затвердженим планам)
    • Верифікація (визначення того, що програмні продукти, які є результатами певної дії, повністю задовольняють вимоги або умови, зумовлені попередніми діями)
    • Атестація (визначення повноти відповідності заданих вимог та створеної системи їхньому конкретному функціональному призначенню)
    • Спільна оцінка (оцінка стану робіт за проектом: контроль планування та управління ресурсами, персоналом, апаратурою, інструментальними засобами)
    • Аудит (визначення відповідності вимогам, планам та умовам договору)
    • Вирішення проблем (аналіз та вирішення проблем, незалежно від їх походження або джерела, які виявлені в ході розробки, експлуатації, супроводу або інших процесів)
  • Організаційні
    • Управління (дії та завдання, які можуть виконуватися будь-якою стороною, яка керує своїми процесами)
    • Створення інфраструктури (вибір та супровід технології, стандартів та інструментальних засобів, вибір та встановлення апаратних та програмних засобів, що використовуються для розробки, експлуатації або супроводу ПЗ)
    • Удосконалення (оцінка, вимірювання, контроль та удосконалення процесів ЖЦ)
    • Навчання (початкове навчання та подальше постійне підвищення кваліфікації персоналу)

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

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

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

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

Стадії життєвого циклу ПЗ, взаємозв'язок між процесами та стадіями

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

Стандарт ДЕРЖСТАНДАРТ ІСО/МЕК 12207-99 не пропонує конкретну модель життєвого циклу. Його положення є спільними для будь-яких моделей життєвого циклу, методів та технологій створення ІВ. Він описує структуру процесів життєвого циклу, не конкретизуючи, як реалізувати чи виконати дії та завдання, включені до цих процесів.

Модель ЖЦ ПО включає:

  1. Стадії;
  2. Результати виконання робіт на кожній стадії;
  3. Ключові події - точки завершення робіт та прийняття рішень.

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

На кожній стадії можуть виконуватися кілька процесів, визначених у стандарті ГОСТ Р ИСО/МЭК 12207-99, і навпаки, той самий процес може виконуватися різних стадіях. Співвідношення між процесами та стадіями також визначається використовуваною моделлю життєвого циклу.

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

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

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

  • Задачна модель;
  • каскадна модель (або системна) (70-85 р.р.);
  • спіральна модель (зараз).

Задачна модель

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

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

Загальний висновок: досить велику ефективну інформаційну систему у такий спосіб створити неможливо.

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

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

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

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

Етапи проекту відповідно до каскадної моделі:

  1. формування вимог;
  2. Проектування;
  3. Реалізація;
  4. Тестування;
  5. Впровадження;
  6. Експлуатація та супровід.

Мал. 1. Каскадна схема розробки

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

Мал. 2. Реальний процес розробки ПЗ за каскадною схемою

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

Спіральна модель

Для подолання перерахованих проблем було запропоновано спіральна модельжиттєвого циклу (рис. 3), яка була розроблена в середині 1980-х Баррі Боемом. Вона ґрунтується на початкових етапах життєвого циклу: аналіз та проектування. На цих етапах реалізованість технічних рішень перевіряється шляхом створення прототипів.

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

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

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

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

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

Рис 3. Спіральна модель ЖЦ ІВ

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

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

Життєвий цикл програмного забезпечення методології RAD складається з чотирьох фаз:

  • фаза визначення вимог та аналізу;
  • фаза проектування;
  • фаза реалізації;
  • фаза застосування.

На кожній ітерації оцінюються:

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

Переваги ітераційного підходу:

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

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

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

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

  • 1. Формування вимог до ПЗ.
  • 2. Проектування.
  • 3. Реалізація.
  • 4. Тестування.
  • 5. Введення у дію.
  • 6. Експлуатація та супровід.
  • 7. Зняття з експлуатації.

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

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

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

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

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

моделі "ТО-ВЕ" ("як має бути"), що відображає уявлення про нові технології роботи організації.

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

Перехід від моделі "AS-IS" до моделі "ТО-ВЕ" може виконуватись двома способами:

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

Побудовані моделі мають самостійне практичне значення. Наприклад, модель "AS-IS" дозволяє виявляти вузькі місця в існуючих технологіях та пропонувати рекомендації щодо вирішення проблем незалежно від того, передбачається на даному етапі подальша розробка ЕІС чи ні. Крім того, модель полегшує навчання співробітників конкретним напрямкам діяльності організації за рахунок використання наочних діаграм (відомо, що "одна картинка коштує тисячі слів").

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

  • * Розробка системного проекту. На цьому етапі дається відповідь на питання: "Що має робити майбутня система?", а саме: визначаються архітектура системи, її функції, зовнішні умови функціонування, інтерфейси та розподіл функцій між користувачами та системою, вимоги до програмних та інформаційних компонентів, склад виконавців та терміни опрацювання. Основу системного проекту складають моделі проектованої ЕІС, які будуються на основі моделі "ТО-ВЕ". Документальним результатом етапу є технічне завдання;
  • * Розробка технічного проекту. На цьому етапі на основі системного проекту здійснюється власне проектування системи, що включає проектування архітектури системи та детальне проектування. Таким чином, дається відповідь на запитання: "Як побудувати систему, щоб вона задовольняла вимоги до неї?". Моделі проектованої ЕІС при цьому уточнюються та деталізуються до необхідного рівня.

На кожній стадії можуть виконуватися кілька процесів, визначених у стандарті ISO/IEC 12207, і, навпаки, той самий процес може виконуватися на різних стадіях.

На цей час найбільшого поширення набули такі дві основні моделі ЖЦ ПО: каскадна модель (1970-1985 рр.) і спіральна модель (1986-1990 рр.).

У однорідних ЕІС 70-х та 80-х рр. прикладне ПЗ являло собою єдине ціле. Для розробки такого типу застосовувався каскадний підхід (інша назва - водоспад (waterfall)) (рис. 1.3). Принциповою особливістю каскадного підходу є таке: перехід на наступну стадію здійснюється тільки після того, як буде повністю завершено роботу на поточній стадії, і повернення на пройдені стадії не передбачається. Кожна стадія закінчується отриманням деяких результатів, які є вихідними даними для наступної стадії. Вимоги до ПЗ, визначені на стадії формування вимог, суворо документуються у вигляді технічного завдання і фіксуються на весь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб технологія могла бути продовжена іншою командою розробників. Критерієм якості розробки за такого підходу є точність виконання специфікацій технічного завдання.

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

Переваги застосування каскадного способу полягають у наступному:

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

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

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

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

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

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

  • 1. Користувачі не в змозі одразу викласти всі свої вимоги і не можуть передбачати, як вони зміняться під час розробки.
  • 2. За час розробки можуть відбутися зміни у довкіллі, які вплинуть на вимоги до системи.

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

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

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

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

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

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

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

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

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

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

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

До складу ЖЦ ПЗ зазвичай включаються такі етапи:

1) формування вимог, які пред'являються ПЗ;

2) проектування структури ПЗ;

3) реалізація;

4) тестування;

5) введення в дію;

6) експлуатація та супровід;

7) зняття з експлуатації.

На кожному етапі можуть виконуватися кілька процесів, визначених у стандарті 1SO/IEC 12207, і, навпаки, той самий процес може виконуватися на різних етапах.

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

На сьогодні найбільшого поширення набули наступні три основні моделі ЖЦ.

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

2)Поетапна модельз проміжним контролем (1980-1985 рр.) - Ітераційна модель розробки ПЗ з циклами зворотного зв'язкуміж етапами

3)Спіральна модель(1986-1990 рр.) робить упор на початкові етапи ЖЦ(Аналіз вимог, проектування специфікацій, попереднє та детальне проектування).

Основні характеристики каскадного способу:

Розбиття всієї розробки на етапи;

Перехід з одного етапу на наступний відбувається тільки після завершення роботи на поточному етапі (рис. 4.1);

Можливість планувати терміни завершення всіх робіт та відповідні витрати;

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

Вихідними для кожного етапу є документи та рішення, отримані на попередньому етапі.

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

Мал. 4.1. Каскадна модель розробки програмного забезпечення

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

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


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

Тому реально каскадна модель створення програмного забезпечення має вигляд, показаний на рис. 4.2.

Мал. 4.2. Модель із проміжним контролем

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

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

Мал. 4.3. Спіральна модель життєвого циклу

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

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

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

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

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

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

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

Іншими недоліками спіральної моделі є:

Трудомісткість внесення змін;

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

Складність перенесення інші платформи.

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

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

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

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

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

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

Стандарти ЖЦ ПС можуть використовуватись як директивні, керівні чи рекомендаційні документи.

Найбільш повно ЖЦ, технологія розробки та забезпечення якості ПС відображені у стандартах ISO (International Standards Organisation – Міжнародна організація зі стандартизації). Стандарт ISO 12207:1995 – «Процеси життєвого циклу програмних засобів» - найбільш повно відбиває архітектуру, роботи, організацію та управління ЖЦ ПС.

Використані реально у фірмах моделі ЖЦ ПС останнім часом змінюються щодо наведених у стандартах у зв'язку з впровадженням та розвитком об'єктно-орієнтованого аналізу та методів швидкої розробки ПП, CASE-систем та мов четвертого покоління. У нових моделях скорочуються роботи з безпосереднього створення програмних компонентів та деталізуються роботи з системного аналізу та проектування ПС та БД.

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

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

На основі однієї і тієї ж сукупності базових стандартів можуть формуватися різні профілі для різних проектів.

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

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



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

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

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

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

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

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

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

Розробка ПЗ включає в себе, як правило:

· Аналіз;

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

· Реалізація (програмування).

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

На цю фазу припадають, як правило, 50% вартості ПІ та 32% трудовитрат.

Експлуатаціяпочинається тоді, коли виріб передається користувачеві, перебуває у дії та використовується.

Включає в себе:

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

Забезпечення експлуатаційної документації;

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

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

Фазу супроводутакож називають фазою розробки, що триває.

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

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

Процес супроводу, продовжаться власне паралельно експлуатації ПІ.

Структура трудовитрат на різні види діяльності з супроводу така, що зміна функціональних можливостей ПІ йде близько 78% часу, але в виявлення помилок - 17%.

Управління конфігурацієює одним із допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, насамперед процеси розробки та супроводу ПЗ. p align="justify"> При створенні проектів складних ІС, що складаються з багатьох компонентів, кожен з яких може мати різновиди або версії, виникає проблема обліку їх зв'язків і функцій, створення уніфікованої структури та забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати та контролювати внесення змін до ПЗ на всіх стадіях ЖЦ. Загальні принципи та рекомендації конфігураційного обліку, планування та управління конфігураціями ПЗ відображені у проекті стандарту ISO 12207-2.

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

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

Кожен процес характеризується:

певними завданнями та методами їх вирішення,

вихідними даними, отриманими на попередньому етапі,

результатами.

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

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

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

На цей час найбільшого поширення набули такі дві основні моделі ЖЦ:

· Каскадна модель (70-85 р.р.);

· Спіральна модель (86-90 р.р.).

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

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

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

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


Мал. 1. Каскадна схема розробки ПЗ

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

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

· Неадекватне управління ризиками: ризики пов'язані з проектом, виявляються на пізніх стадіях виконання проекту

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


Мал. 2 Реальний процес розробки програмного забезпечення за каскадною схемою

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

Таким чином, у процесі створення ПЗ постійно виникала потреба у поверненні до попередніх етапів та уточненні чи перегляді раніше прийнятих рішень. В результаті реальний процес створення ПЗ набував наступного вигляду (рис. 2):

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

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

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

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

Мал. 3. Спіральна модель ЖЦ

При створенні програмного забезпечення може бути використана «Модель перевикористання та реверсивної інженерії».

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

У разі невдачі реалізованої версії можливий відкат за проектом (Reengineering).

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

Що це таке у формальному розумінні?

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

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

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

Початкові вимоги

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

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

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

Серед систем, що визначають умови і вимоги до таких процесів, сьогодні можна назвати лише три основні:

  • ГОСТ 34.601-90;
  • ISO/IEC 12207:2008;
  • Oracle CDM.

Для другого міжнародного стандарту є російський аналог. Це ГОСТ Р ІСО/МЕК 12207-2010, що відповідає за системну та програмну інженерію. Але життєвий цикл програмного забезпечення, що описується в обох правилах, є ідентичним. Пояснюється це досить просто.

Види ПЗ та апдейти

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

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

Приклад на основі програми FL Studio

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

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

  • створення барабанного модуля за типом ритм-машин на зразок Yamaha RX, але із застосуванням one-shot-семплів або секвенцій у форматі WAV, записаних у студіях наживо;
  • інтеграція до операційних систем Windows;
  • можливість експорту проекту у форматах WAV, MP3 та OGG;
  • сумісність проектів із додатковим додатком Fruity Tracks.

На стадії розробки були використані засоби мов програмування «Сі». Але платформа виглядала досить примітивно і не давала кінцевого користувача необхідної якості звучання.

У зв'язку з цим, на стадії тестування та налагодження розробникам довелося піти шляхом німецької корпорації Steinberg і застосувати в вимогах до основного звукового драйвера підтримку режиму Full Duplex. Якість саунду стала вищою і дозволило змінювати темп, висоту тону та накладати додаткові FX-ефекти в режимі реального часу.

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

Цим не обмежилося. На стадії управління проектом було введено підтримку підключення плагінів формату VST (спочатку другої, а потім і третьої версії), свого часу розробленого компанією Steinberg. Грубо кажучи, будь-який віртуальний синтезатор, який підтримує VST-host, міг підключатися до програми.

Не дивно, що невдовзі будь-який композитор міг використовувати аналоги залізних моделей, наприклад, повні комплекти звуків колись популярного Korg M1. Дальше більше. Застосування модулів типу Addictive Drums або універсального плагіна Kontakt дозволило відтворювати живі звуки реальних інструментів, записаних з усіма відтінками артикуляції в професійних студіях.

При цьому розробники постаралися досягти і максимальної якості, створивши підтримку для драйверів ASIO4ALL, які виявилися на голову вищими за режим Full Duplex. Відповідно підвищився і бітрейт. На сьогоднішній день якість звукового файлу, що експортується, може становити 320 кбіт/с при частоті дискретизації 192 кГц. А це професійний звук.

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

Перспективи розвитку

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

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

Навіть у випадку з Windows такі тенденції можна помітити неозброєним поглядом. Навряд чи сьогодні знайдеться хоч один користувач, який використовує системи як модифікацій 3.1, 95, 98 або Millennium. Їхній життєвий цикл закінчився після виходу версії XP. Але серверні версії на основі технологій NT все ще актуальні. Навіть Windows 2000 на сьогоднішній день є не тільки дуже актуальною, але й за деякими параметрами установки або безпеки, що навіть перевершує нові розробки. Те саме стосується системи NT 4.0, а також спеціалізованої модифікації Windows Server 2012.

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

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

Деякі додаткові питання

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

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

Але в комп'ютерних технологіях сьогодні надається перевага розвитку автоматизованих систем управління (АСУ), які застосовуються на виробництві. Навіть операційні системи у порівнянні зі спеціалізованими програмами програють.

Ті ж середовища на основі Visual Basic залишаються набагато популярнішими за Windows-системи. А про прикладне ПЗ під UNIX-системи не йдеться взагалі. Що говорити, якщо практично всі комунікаційні мережі тих самих Сполучених Штатів працюють виключно на них. До речі, системи на зразок Linux та Android теж спочатку створювалися саме на цій платформі. Тому, швидше за все, у UNIX перспектив набагато більше, ніж у інших продуктів, разом узятих.

Замість підсумку

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

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

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

Нехай вони не завжди розуміють суть програмування, зате чітко здатні визначити моделі життєвого циклу програмного забезпечення та тривалість їх застосування, виходячи зі світових тенденцій у цій галузі. Ефективний менеджмент найчастіше дає відчутніші результати. Так хоча б PR-технології, реклама і т. д. Може якесь додаток користувачеві і не потрібно, зате за умови його активного афішування користувач встановить його. Це вже, так би мовити, підсвідомий рівень (теж ефект 25-го кадру, коли інформація закладається у свідомість користувача незалежно від нього самого).

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

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

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