Розробка ПЗ неможлива без розуміння так званого життєвого циклу програм. Пересічному користувачеві це, можливо, і не потрібно знати, але основні стандарти бажано засвоїти (далі буде сказано, навіщо це потрібно).
Під життєвим циклом будь-якого прийнято розуміти час його існування, починаючи зі стадії розробки та до моменту повної відмови від використання у вибраній сфері застосування аж до повного вилучення додатку з ужитку.
Говорячи простою мовою, інформаційні системи у вигляді програм, баз даних або навіть «операційок» є затребуваними лише у разі актуальності даних та можливостей, що ними надаються.
Вважається, що визначення життєвого циклу жодною мірою не застосовується до тестових додатків, наприклад, до бета-версій, які є найнестійкішими в роботі. Сам же життєвий цикл ПЗ залежить від безлічі факторів, серед яких одну з головних ролей відіграє середовище, в якому програма використовуватиметься. Однак можна виділити і Загальні умови, що застосовуються щодо поняття життєвого циклу.
Розробка програмного забезпечення складається з усіх вищезгаданих стадій і не може обійтися хоча б без однієї з них. Але для контролю таких процесів встановлено спеціальні стандарти.
Серед систем, що визначають умови і вимоги до таких процесів, сьогодні можна назвати лише три основні:
Для другого міжнародного стандарту є російський аналог. Це ГОСТ Р ІСО/МЕК 12207-2010, що відповідає за системну та програмну інженерію. Але життєвий цикл програмного забезпечення, Який описується в обох правилах, є ідентичним по суті. Пояснюється це досить просто.
Вони, до речі, для більшості відомих програм мультимедіа є засобами збереження основних параметрів конфігурації. Використання ПЗ такого типу, звичайно, є досить обмеженим, але розуміння загальних принципів роботи з тими самими медіаплеєрами не зашкодить. І ось чому.
По суті, у них життєвий цикл програмного забезпечення закладено лише на рівні терміну оновлення версії самого програвача або встановлення кодеків та декодерів. А звукові та відео транскодери є невід'ємними атрибутами будь-якої аудіо чи відеосистеми.
Спочатку віртуальна студія-секвенсор FL Studio мала назву Fruity Loops. Життєвий цикл ПЗ у його первинній модифікації минув, але додаток дещо трансформувався і набув нинішнього вигляду.
Якщо говорити про етапи життєвого циклу, спочатку на стадії постановки завдання задавали кілька обов'язкових умов:
На стадії розробки були використані засоби мов програмування «Сі». Але платформа виглядала досить примітивно і не давала кінцевого користувача необхідної якості звучання.
У зв'язку з цим, на стадії тестування та налагодження розробникам довелося піти шляхом німецької корпорації Steinberg і застосувати в вимогах до основного звукового драйвера підтримку режиму Full Duplex. Якість саунду стала вищою і дозволило змінювати темп, висоту тону та накладати додаткові FX-ефекти в режимі реального часу.
Завершенням життєвого циклу цього ПЗ прийнято вважати вихід першим офіційної версії FL Studio, яка, на відміну від своїх прабатьків, мала вже інтерфейс повноцінного секвенсора з можливістю редагування параметрів на віртуальному 64-канальному мікшерному пульті з необмеженим додаванням аудіо-доріжок та MIDI-треків.
Цим не обмежилося. На стадії управління проектом було введено підтримку підключення плагінів формату 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-го кадру, коли інформація закладається у свідомість користувача незалежно від нього самого).
Звичайно, такі технології у світі є забороненими, проте багато хто з нас навіть не здогадується про те, що вони все одно можуть використовуватись і впливати на підсвідомість у певний спосіб. Чого тільки варте «зомбування» каналами новин або інтернет-сайтами, не кажучи вже про застосування більш потужних засобів, на кшталт впливу інфразвуком (таке було застосовано в одній оперній постановці), внаслідок чого людина може відчувати страх або неадекватні емоції.
Повертаючись до програмного забезпечення, варто додати, що деякі програми при запуску застосовують звуковий сигнал, який привертає увагу користувача. І, як показують дослідження, такі програми виявляються більш життєздатними, порівняно з іншими програмами. Природно, збільшується і життєвий цикл, без різниці, яка функція на нього покладена спочатку. І цим, на жаль, користуються багато розробників, що викликає сумніви щодо законності таких методів.
Але не нам судити про це. Можливо, найближчим часом буде розроблено кошти, що визначають такі загрози. Поки що це лише теорія, але, як вважають деякі аналітики та експерти, до практичного застосуваннязалишилось зовсім небагато. Якщо вже створюють копії нейронних мереж людського мозку, то що казати?
Здрастуйте, шановні хабрівчани! Думаю, буде комусь цікаво згадати які моделі розробки, впровадження та використання програмного забезпечення існували раніше, які моделі в основному використовуються зараз, навіщо і що це власне таке. У цьому й полягатиме моя невелика тема.
Власне, що таке життєвий цикл програмного забезпечення- ряд подій, що відбуваються із системою в процесі її створення та подальшого використання. Іншими словами, це час від початкового моменту створення будь-якого програмного продукту, до кінця його розробки та впровадження. Життєвий цикл програмного забезпечення можна подати у вигляді моделей.
Модель життєвого циклу програмного забезпечення- структура, що містить процеси дії та завдання, що здійснюються в ході розробки, використання та супроводу програмного продукту.
Ці моделі можна розділити на 3 основні групи:
Переваги:
Модель належить до другої групи.
Переваги:
Дуже дякую за увагу!
Поняття життєвого циклу програмного забезпечення (ЖЦ ПЗ) є одним із базових у програмній інженерії. Життєвий цикл визначають як період часу, який починається з моменту прийняття рішення про необхідність створення ПЗ та закінчується в момент його повного вилучення з експлуатації.
Відповідно до стандарту ISO/IEC 12207, всі процеси ЖЦ розділені на три групи (рис. 2.1).
Під моделлю життєвого циклу ПЗ розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій та завдань протягом ЖЦ. Вона залежить від специфіки, масштабу та складності проекту та специфіки умов, у яких система створюється та функціонує. До складу життєвого цикло ПЗ зазвичай включаються такі стадії:
1. Формування вимог до ПЗ.
2. Проектування.
3. Реалізація.
4. Тестування.
5. Введення у дію.
6. Експлуатація та супровід.
7. Зняття з експлуатації.
В даний час найбільшого поширення набули такі основні моделі ЖЦ ПЗ:
a) каскадна та
b) спіральна (еволюційна).
Перша застосовувалася для програм невеликого обсягу, що є єдиним цілим. Важливою особливістю каскадного підходує те, що перехід на наступну стадію здійснюється тільки після того, як буде повністю завершено роботу на поточній, і повернень на пройдені стадії не передбачається. Її схема наведена на рис. 2.2.
Переваги застосування каскадної моделі полягають у наступному:
На кожній стадії формується закінчений набір проектної документації;
Стадії робіт, що виконуються, дозволяють планувати термін їх завершення та відповідні витрати.
Така модель застосовується для систем, яких вже на початку розробки можна точно сформулювати всі вимоги. До них належать, наприклад, системи, у яких вирішуються, переважно, завдання обчислювального типу. Реальні процеси зазвичай мають ітераційний характер: результати чергової стадії часто викликають зміни у проектних рішеннях, вироблених більш ранніх стадіях. Таким чином, найпоширенішою є модель із проміжним контролем, яка наведена на рис. 2.3.
Основним недоліком каскадного підходу є суттєве запізнення з отриманням результатів і, як наслідок, досить високий ризик створення системи, що не задовольняє потребам користувачів, що змінилися.
Ці проблеми усуваються в спіральної моделі життєвого циклу (Рис. 2.4). Її принциповою особливістю є те, що прикладне ПЗ створюється не відразу, як у разі каскадного підходу, а частинами з використанням методу прототипування . Під прототипом розуміється діючий програмний компонент, що реалізує окремі функції та зовнішній інтерфейс ПЗ, що розробляється. Створення прототипів здійснюється у кілька ітерацій – витків спіралі.
Каскадну (еволюційну) модель можна як діаграми, яка наведена малюнку 2.5.
Одним із результатів застосування спіральної моделі ЖЦ є спосіб, що набув широкого поширення, так званої швидкої розробки додатків , або RAD (Rapid Application Development). Життєвий цикл ПЗ відповідно до цього способу включає чотири стадії:
1) аналіз та планування вимог;
2) проектування;
3) реалізація;
4) Використання.
Аналіз життєвого циклу програм дозволяє уточнити зміст та виділити такі процеси проектування складних систем.
1) Стратегія;
2) Аналіз;
3) Проектування;
4) Реалізація;
5) Тестування;
6) Використання;
7) Експлуатація та технічна підтримка.
Стратегія
Визначення стратегії передбачає обстеження системи. Основне завдання обстеження – оцінка реального обсягу проекту, його цілей та завдань, а також отримання визначень сутностей та функцій на високому рівні. На цьому етапі залучаються висококваліфіковані бізнес-аналітики, які мають постійний доступ до керівництва фірми. Крім того, передбачається тісна взаємодія з основними користувачами системи та бізнес-експертами. Основне завдання такої взаємодії - отримати якомога повнішу інформацію про систему, однозначно зрозуміти вимоги замовника та передати отриману інформацію у формалізованому вигляді системним аналітикам. Як правило, інформація про систему може бути отримана на підставі низки розмов (або семінарів) з керівництвом, експертами та користувачами.
Підсумком етапу визначення стратегії стає документ, у якому чітко сформульовано таке:
Що саме належить замовнику, якщо він погодиться фінансувати проект;
Коли він зможе отримати готовий продукт (графік виконання робіт);
Скільки це йому обійдеться (графік фінансування етапів робіт для великих проектів).
У документі мають бути відображені не лише витрати, а й вигода, наприклад, термін окупності проекту, очікуваний економічний ефект (якщо його вдається оцінити).
Розглянутий етап життєвого циклу може бути представлений у моделі лише один раз, особливо якщо модель має циклічну структуру. Це не означає, що у циклічних моделях стратегічне плануванняпроводиться раз і назавжди. У таких моделях етапи визначення стратегії та аналізу як би об'єднуються, а їх поділ існує лише на першому витку, коли керівництво підприємства приймає принципове рішення про старт проекту. У цілому нині стратегічний етап присвячений розробці документа рівня керівництва підприємства.
Етап аналізу передбачає докладне дослідження бізнес-процесів (функцій, визначених на попередньому етапі) та інформації, необхідної для їх виконання (сутностей, їх атрибутів та зв'язків (стосунків)). Цей етап дає інформаційну модель, а наступний його етап проектування - модель даних.
Вся інформація про систему, зібрана на етапі визначення стратегії, формалізується та уточнюється на етапі аналізу. Особлива увага приділяється повноті отриманої інформації, її аналізу на несуперечність, а також пошуку інформації, що не використовується або дублюється. Як правило, замовник спочатку формує вимоги не до системи загалом, а до окремих її компонентів. І в цьому конкретному випадку циклічні моделі життєвого циклу ПЗ мають перевагу, оскільки з часом з великою ймовірністю буде потрібний повторний аналіз, так як у замовника часто апетит приходить під час їжі. На цьому етапі визначаються необхідні компоненти плану тестування.
Аналітики збирають та фіксують інформацію у двох взаємопов'язаних формах:
a) функції - інформація про події та процеси, що відбуваються у бізнесі;
b) сутність - інформація про предмети, які мають значення для організації та про які щось відомо.
При цьому будуються діаграми компонентів, потоків даних та життєвих циклів, що описують динаміку системи. Вони будуть розглянуті пізніше.
Проектування
На етапі проектування формується модель даних. Проектувальники обробляють дані аналізу. Кінцевим продуктом етапу проектування є схема бази даних (якщо існує в проекті) або схема сховища даних (ER-модель) і набір специфікацій модулів системи (модель функцій).
У невеликому проекті (наприклад, у курсовому) одні й самі люди можуть виступати у ролі і аналітиків, і проектувальників, і розробників. Перераховані вище схеми та моделі допомагають знайти, наприклад, не описані взагалі, нечітко описані, суперечливо описані компоненти системи та інші недоліки, що сприяє запобіганню потенційним помилкам.
Усі специфікації мають бути дуже точними. План тестування системи також доопрацьовується цьому етапі розробки. У багатьох проектах результати етапу проектування оформлюються як єдиного документа - так званої технічної специфікації. При цьому широке застосування отримала мова UML, яка дозволяє отримати одночасно документи аналізу, що відрізняються меншою деталізацією (їх споживачі - менеджери виробництва), так і документи проектування (їх споживачі - менеджери груп розробки та тестування). Ця мова буде розглянута пізніше. Програмне забезпечення, побудоване із застосуванням UML, дозволяє простіше здійснити генерацію коду – як мінімум ієрархію класів, а також деякі частини коду самих методів (процедур та функцій).
Завданнями проектування є:
Розгляд результатів аналізу та перевірка їх повноти;
Семінари із замовником;
Визначення критичних ділянок проекту та оцінка його обмежень;
визначення архітектури системи;
ухвалення рішення про використання продуктів сторонніх розробників, а також про способи інтеграції та механізми обміну інформацією з цими продуктами;
Проектування сховищ даних: модель бази даних;
Проектування процесів та коду: остаточний вибір засобів розробки, визначення інтерфейсів програм, відображення функцій системи на її модулі та визначення специфікацій модулів;
визначення вимог до процесу тестування;
Визначення вимог щодо безпеки системи.
Реалізація
При реалізації проекту особливо важливо координувати групу розробників. Усі розробники повинні підкорятися жорстким правилам контролю вихідних текстів. Вони, отримавши технічний проект, починають писати код модулів. Основне завдання розробників у тому, щоб усвідомити специфікацію: проектувальник написав, що треба зробити, а розробник визначає, як і зробити.
На етапі розробки здійснюється тісна взаємодія проектувальників, розробників та груп тестувальників. У разі інтенсивної розробки тестувальник буквально нерозлучений із розробником, фактично стаючи членом групи розробки.
Найчастіше на етапі розробки змінюються інтерфейси користувача. Це пов'язано з періодичною демонстрацією модулів замовнику. Він також може суттєво змінювати запити до даних.
Етап розробки пов'язаний з етапом тестування, і обидва процеси йдуть паралельно. Синхронізує дії тестерів та розробників система bug tracking.
Помилки мають бути класифіковані згідно з пріоритетами. Для кожного класу помилок має бути визначено чітку структуру дій: «що робити», «як терміново», «хто є відповідальним за результат». Кожна проблема повинна відстежуватися проектувальником/розробником/тестувальником, який відповідає за її усунення. Те саме стосується ситуацій, коли порушуються заплановані терміни розробки та передачі модулів на тестування.
Крім того, повинні бути організовані сховища готових модулів проекту та бібліотек, що використовуються при складанні модулів. Це сховище постійно оновлюється. Контролювати процес оновлення має одна людина. Одне сховище створюється для модулів, що пройшли функціональне тестування, друге - для модулів, що пройшли тестування зв'язків. Перше – це чернетки, друге – те, з чого вже можна збирати дистрибутив системи та демонструвати його замовнику для проведення контрольних випробувань або для здачі будь-яких етапів робіт.
Тестування
Групи тестування можуть залучатись до співпраці вже на ранніх стадіях розробки проекту. Зазвичай комплексне тестування виділяють на окремий етап розробки. Залежно від складності проекту, тестування та виправлення помилок може займати третину, половину загального часу роботи над проектом і навіть більше.
Чим складніший проект, тим більше буде потреба в автоматизації системи зберігання помилок - bug tracking, яка забезпечує такі функції:
Зберігання повідомлення про помилку (до якого компонента системи відноситься помилка, хто її знайшов, як її відтворити, хто відповідає за її виправлення, коли вона має бути виправлена);
Система сповіщення про появу нових помилок, про зміну статусу відомих у системі помилок (повідомлення по електронній пошті);
Звіти про актуальні помилки щодо компонентів системи;
Інформація про помилку та її історія;
Правила доступу до помилок тих чи інших категорій;
Інтерфейс обмеженого доступу до системи bug tracking для користувача.
Подібні системи беруть на себе безліч організаційних проблем, зокрема, питання автоматичного повідомлення про помилки.
Власне тести систем прийнято поділяти на кілька категорій:
a) автономні тестимодулів; вони використовуються вже на етапі розробки компонентів системи та дозволяють відстежувати помилки окремих компонентів;
b) тести зв'язківкомпонентів системи; ці тести також використовуються і на етапі розробки; вони дозволяють відстежувати правильність взаємодії та обміну інформацією компонентів системи;
c) системний тест; він є основним критерієм приймання системи; як правило, це група тестів, що включає і автономні тести, тести зв'язків і моделі; такий тест повинен відтворювати роботу всіх компонентів та функцій системи; його основна мета - внутрішнє приймання системи та оцінка її якості;
d) прийомоздавальний тест; основне його призначення – здати систему замовнику;
e) тести продуктивності та навантаження; ця група тестів входить до системного, саме вона є основною для оцінки надійності системи.
До кожної групи обов'язково входять тести моделювання відмов. Вони перевіряють реакцію компонента, групи компонентів, а також системи загалом на такі відмови:
окремого компонента інформаційної системи;
Групи компонентів;
Основні модулі системи;
операційної системи;
Жорсткий збій (відмова живлення, жорстких дисків).
Ці тести дозволяють оцінити якість підсистеми відновлення коректного стану інформаційної системи та є основним джерелом інформації для розробки стратегій запобігання негативним наслідкам збоїв при промисловій експлуатації.
Ще одним важливим аспектом програми тестування інформаційних систем є наявність генераторів тестових даних. Вони використовуються для проведення тестів функціональності, надійності та продуктивності системи. Завдання оцінки характеристик залежності продуктивності інформаційної системи зростання обсягів оброблюваної інформації без генераторів даних вирішити неможливо.
Впровадження
Досвідчена експлуатація перекриває процес тестування. Система рідко запроваджується повністю. Як правило, це процес поступовий чи ітераційний (у разі циклічного життєвого циклу).
Введення в експлуатацію відбувається як мінімум три стадії:
2) накопичення інформації;
3) вихід проектну потужність (тобто власне перехід до етапу експлуатації).
інформації може викликати досить вузький спектр помилок: в основному, неузгодженість даних під час завантаження та власні помилки завантажувачів. Для їх виявлення та усунення застосовують методи контролю якості даних. Такі помилки мають бути виправлені якнайшвидше.В період накопичення інформаціїв інформаційної системивиявляється найбільша кількість помилок, пов'язаних з розрахованим на багато користувачів доступом. Друга категорія виправлень пов'язана з тим, що користувач не влаштовує інтерфейс. При цьому циклічні моделі та моделі із зворотним зв'язком етапів дозволяють знизити витрати. Розглянутий етап є найбільш серйозним тестом - тестом схвалення користувачем (customer aceptance tests).
Вихід системи на проектну потужністьу хорошому варіанті - це доведення дрібних помилок та рідкісні серйозні помилки.
Експлуатація та технічна підтримка
На цьому етапі останнім документом для розробників є акт технічного приймання. Документ визначає необхідний персонал та необхідне обладнання для підтримки працездатності системи, а також умови порушення експлуатації продукту та відповідальність сторін. Крім цього, зазвичай у вигляді окремого документа оформляються умови технічної підтримки.
Життєвий цикл програмного забезпечення
Одним із базових понять методології проектування ПЗ є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ). ЖЦ ПЗ - це безперервний процес, який починається з моменту ухвалення рішення про необхідність його створення та закінчується в момент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт 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 ст.) Відповідає технології проектування «згори - вниз». Передбачає використання програмного прототипу, що дозволяє програмне розширення. Проект системи циклічно повторює шлях від деталізації вимог до деталізації програмного коду.
p align="justify"> При проектуванні архітектури системи спочатку визначається склад функціональних підсистем і вирішуються загальносистемні питання (організація інтегрованої бази даних, технологія збору, передачі та накопичення інформації). Потім формулюються окремі завдання та розробляється технологія їх вирішення.
При програмуванні спочатку розробляються головні програмні модулі, та був - модулі, виконують окремі функції. Спочатку забезпечується взаємодія модулів між собою та з базою даних, а потім - реалізація алгоритмів.
Переваги:
1. скорочення кількості ітерацій і, отже, кількість помилок і невідповідностей, які необхідно виправляти;
2. скорочення термінів проектування;
3. спрощення створення проектної документації.
Недолік:високі вимоги до якості загальносистемного репозиторію (загальної бази проектних даних).
Спіральна модель лежить в основі технології швидкої розробки додатківабо RAD-технології (rapid application development), яка передбачає активну участь кінцевих користувачів майбутньої системи у процесі її створення. Основні стадії інформаційного інжинірингу такі:
· Аналіз та планування інформаційної стратегії.Користувачі разом із фахівцями-розробниками беруть участь у ідентифікації проблемної галузі.
· Проектування.Користувачі під керівництвом розробників беруть участь у технічному проектуванні.
· Конструювання.Розробники проектують робочу версію програмного забезпечення з використанням мов 4-го покоління;
· Використання.Розробники навчають користувачів роботі серед нової ПЗ.
Слід почати з визначення,Життєвий цикл програмного забезпечення(Software Life Cycle Model) - це період часу, який починається з моменту прийняття рішення про створення програмного продукту і закінчується в момент повного вилучення з експлуатації. Цей цикл - процес побудови та розвитку ПЗ.
Життєвий цикл можна у вигляді моделей. В даний час найбільш поширеними є:каскадна, інкрементна (поетапна модель із проміжним контролем ) та спіральнамоделі життєвого циклу
Каскадна модель(Англ. waterfall model) - модель процесу розробки програмного забезпечення, життєвий цикл якої виглядає як потік, що послідовно проходить фази аналізу вимог, проектування. реалізації, тестування, інтеграції та підтримки.
p align="justify"> Процес розробки реалізується за допомогою впорядкованої послідовності незалежних кроків. Модель передбачає, що кожен наступний крок починається після завершення виконання попереднього кроку. На всіх кроках моделі виконуються допоміжні та організаційні процеси та роботи, що включають управління проектом, оцінку та управління якістю, верифікацію та атестацію, менеджмент конфігурації, розробку документації. У результаті завершення кроків формуються проміжні продукти, які можуть змінюватися наступних кроках.
Життєвий цикл традиційно поділяють такі основніетапи:
Переваги моделі:
Недоліки моделі:
Реалізувати Каскадну модель життєвого циклу важко через складність розробки ПС без повернень до попередніх кроків і зміни їх результатів для усунення проблем, що виникають.
Обмеження сфери застосування каскадної моделі визначається її недоліками. Її використання найефективніше у таких випадках:
(Поетапна модель з проміжним контролем)
Інкрементна модель(Англ. increment- Збільшення, збільшення) передбачає розробку програмного забезпечення з лінійною послідовністю стадій, але в кілька інкрементів (версій), тобто. із запланованим поліпшенням продукту за весь час доки Життєвий цикл розробки ПЗ не підійде до закінчення.
Розробка програмного забезпечення ведеться ітераціями із циклами зворотного зв'язку між етапами. Міжетапні коригування дозволяють враховувати реальний взаємовплив результатів розробки на різних етапах, час життя кожного з етапів розтягується на весь період розробки.
На початку роботи над проектом визначаються всі основні вимоги до системи, поділяються на більш менш важливі. Після чого виконується розробка системи за принципом прирощень, щоб розробник міг використовувати дані, отримані під час розробки ПЗ. Кожен інкремент повинен додавати системі певну функціональність. При цьому випуск починають із компонентів із найвищим пріоритетом. Коли частини системи визначені, беруть першу частину і починають її деталізувати, використовуючи при цьому найбільш підходящий процес. У той самий час можна уточнювати вимоги та інших частин, які у поточної сукупності вимог цієї роботи були заморожені. Якщо є потреба, можна повернутися пізніше до цієї частини. Якщо частина готова, вона поставляється клієнту, який може використовувати їх у роботі. Це дозволить клієнту уточнити вимоги для таких компонентів. Потім займаються розробкою наступної частини системи. Ключові етапи цього процесу - проста реалізація підмножини вимог до програми та вдосконалення моделі в серії послідовних релізів доти, доки не буде реалізовано ПЗ у всій повноті.
Життєвий цикл даної моделі характерний розробки складних і комплексних систем, котрим є чітке бачення (як із боку замовника, і з боку розробника) те, що собою має бути кінцевий результат. Розробка версіями ведеться з різних причин:
Перевагиі недолікицієї моделі (стратегії) такі самі, як і в каскадної (класичної моделі життєвого циклу). Але на відміну від класичної стратегії, замовник може раніше побачити результати. Вже за результатами розробки та впровадження першої версії він може трохи змінити вимоги до розробки, відмовитися від неї або запропонувати розробку більш досконалого продукту з укладанням нового договору.
Переваги:
Недоліки моделі:
Схема не дозволяє оперативно враховувати зміни та уточнення вимог до ПЗ. Узгодження результатів розробки з користувачами проводиться тільки в точках, що плануються після завершення кожного етапу робіт, а Загальні вимогидо ПЗ зафіксовані у вигляді технічного завдання на весь час її створення. Таким чином, користувачі часто отримую ПП, що не задовольняє їх реальним потребам.
Спіральна модель:Життєвий цикл - на кожному витку спіралі виконується створення чергової версії продукту, уточнюються вимоги проекту, визначається його якість та плануються роботи наступного витка. Особлива увага приділяється початковим етапам розробки - аналізу та проектування, де реалізованість тих чи інших технічних рішень перевіряється та обґрунтовується за допомогою створення прототипів.
Дана модель являє собою процес розробки програмного забезпечення, що поєднує в собі як проектування, так і постадійне прототипування з метою поєднання переваг висхідної та низхідної концепції, яка наголошує на початкових етапах життєвого циклу: аналіз і проектування.Відмінною особливістю цієї моделі є особлива увага до ризиків, що впливають на організацію життєвого циклу.
На етапах аналізу та проектування реалізованість технічних рішень та ступінь задоволення потреб замовника перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню працездатного фрагмента чи версії системи. Це дозволяє уточнити вимоги, цілі та характеристики проекту, визначити якість розробки, спланувати роботи наступного витка спіралі. Таким чином поглиблюються та послідовно конкретизуються деталі проекту та в результаті вибирається обґрунтований варіант, який задовольняє дійсним вимогам замовника та доводиться до реалізації.
Життєвий цикл на кожному витку спіралі можуть застосовуватися різні моделі процесу розробки ПЗ. Зрештою на виході виходить готовий продукт. Модель поєднує в собі можливості моделі прототипування таводоспадні моделі. Розробка ітераціями відбиває об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. Головна задача— якнайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення та доповнення вимог.
Переваги моделі:
Недоліки моделі:
Основна проблема спірального циклу – визначення моменту переходу на наступний етап. Для її вирішення запроваджуються тимчасові обмеження на кожен із етапівжиттєвого циклу і перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена.Плануванняпроводиться на основі статистичних даних, отриманих у попередніх проектах та особистого досвідурозробників.
Застосування спіральної моделі доцільно у таких випадках:
