Development of a spiral model of life cycle of the program systems
Two new sorts of a spiral model of life cycle of the program system for different modes of development are offered: operational development of the characteristics of the system up to the characteristics incorporated in the requirements of the customer, and creation of the new version of the system a...
Gespeichert in:
| Datum: | 2015 |
|---|---|
| Hauptverfasser: | , |
| Format: | Artikel |
| Sprache: | Ukrainian |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2015
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/25 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-25 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/ee/1c0efd1df45fc4c91d1d18ef6b7062ee.pdf |
| spelling |
pp_isofts_kiev_ua-article-252018-10-09T12:00:42Z Development of a spiral model of life cycle of the program systems Развитие спиральной модели жизненного цикла программных систем Розвиток спіральної моделі життєвого циклу програмних систем Alekseev, V.A. Tereshchenko, V.S. UDC 681.3.06 УДК 681.3.06 УДК 681.3.06 Two new sorts of a spiral model of life cycle of the program system for different modes of development are offered: operational development of the characteristics of the system up to the characteristics incorporated in the requirements of the customer, and creation of the new version of the system after its experimental maintenance according to the new requirements of the customer. The generalized spiral model is offered, in which the features of the characteristics of first two models are integrated. Предлагаются два новых вида спиральной модели жизненного цикла программной системы для разных режимов разработки: доводки характеристик системы до характеристик, заложенных в требованиях заказчика, и создания новой версии системы после ее опытной эксплуатации в соответствии с новыми требованиями заказчика. Предлагается обобщенная спиральная модель, в которую интегрированы особенности характеристик первых двух моделей. Пропонуються два нових види спіральної моделі життєвого циклу програмної системи для різних режимів розробки: доводки характеристик системи до характеристик, закладених у вимогах замовника, та створення нової версії системи після її дослідної експлуатації відповідно до нових вимог замовника. Надається узагальнена спіральна модель, в яку інтегровані характеристики перших двох моделей. PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2015-07-01 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/25 PROBLEMS IN PROGRAMMING; No 4 (2003) ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2003) ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2003) 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/25/29 Copyright (c) 2015 ПРОБЛЕМИ ПРОГРАМУВАННЯ |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2018-10-09T12:00:42Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 681.3.06 |
| spellingShingle |
UDC 681.3.06 Alekseev, V.A. Tereshchenko, V.S. Development of a spiral model of life cycle of the program systems |
| topic_facet |
UDC 681.3.06 УДК 681.3.06 УДК 681.3.06 |
| format |
Article |
| author |
Alekseev, V.A. Tereshchenko, V.S. |
| author_facet |
Alekseev, V.A. Tereshchenko, V.S. |
| author_sort |
Alekseev, V.A. |
| title |
Development of a spiral model of life cycle of the program systems |
| title_short |
Development of a spiral model of life cycle of the program systems |
| title_full |
Development of a spiral model of life cycle of the program systems |
| title_fullStr |
Development of a spiral model of life cycle of the program systems |
| title_full_unstemmed |
Development of a spiral model of life cycle of the program systems |
| title_sort |
development of a spiral model of life cycle of the program systems |
| title_alt |
Развитие спиральной модели жизненного цикла программных систем Розвиток спіральної моделі життєвого циклу програмних систем |
| description |
Two new sorts of a spiral model of life cycle of the program system for different modes of development are offered: operational development of the characteristics of the system up to the characteristics incorporated in the requirements of the customer, and creation of the new version of the system after its experimental maintenance according to the new requirements of the customer. The generalized spiral model is offered, in which the features of the characteristics of first two models are integrated. |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2015 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/25 |
| work_keys_str_mv |
AT alekseevva developmentofaspiralmodeloflifecycleoftheprogramsystems AT tereshchenkovs developmentofaspiralmodeloflifecycleoftheprogramsystems AT alekseevva razvitiespiralʹnojmodeližiznennogociklaprogrammnyhsistem AT tereshchenkovs razvitiespiralʹnojmodeližiznennogociklaprogrammnyhsistem AT alekseevva rozvitokspíralʹnoímodelížittêvogocikluprogramnihsistem AT tereshchenkovs rozvitokspíralʹnoímodelížittêvogocikluprogramnihsistem |
| first_indexed |
2025-07-17T09:33:47Z |
| last_indexed |
2025-07-17T09:33:47Z |
| _version_ |
1850409708190433280 |
| fulltext |
Методы и средства программной инженерии
© В.А. Алексєєв, В.С. Терещенко, 2003
34 ISSN 1727-4907. Проблемы программирования. 2003. № 4
УДК 681.3.06
В.А. Алексєєв, В.С. Терещенко
РОЗВИТОК СПІРАЛЬНОЇ МОДЕЛІ ЖИТТЄВОГО ЦИКЛУ
ПРОГРАМНИХ СИСТЕМ
Пропонуються два нових види спіральної моделі життєвого циклу програмної
системи для різних режимів розробки: доводки характеристик системи до характери-
стик, закладених у вимогах замовника, та створення нової версії системи після її
дослідної експлуатації відповідно до нових вимог замовника. Надається узагальнена
спіральна модель, в яку інтегровані характеристики перших двох моделей.
Вступ
Життєвий цикл програмного за-
безпечення (програмного продукту,
програмної системи) визначається як
термін часу, який починається від мо-
мента прийняття рішення про ство-
рення програмного забезпечення й за-
кінчується у момент його повного ви-
лучення з експлуатації, скоріше за все,
з метою встановлення та інсталяції но-
вого продукту. Саме – нового, а не
нової версії того ж продукту, що вилу-
чається. Життєвий цикл поділяється на
етапи, упродовж кожного з яких ство-
рюється нова версія програмного про-
дукту. Під моделлю життєвого циклу
програмного забезпечення сприйма-
ється структура, що визначає послідо-
вність виконання і взаємозв’язок про-
цесів, дій і задач упродовж життєвого
циклу. Головним нормативним докуме-
нтом, що регламентує склад процесів
життєвого циклу, є міжнародний стан-
дарт ISO/IEC 12207: 1995 “Information
Technology – Software Life Cycle Pro-
cessing” та відповідний йому Держав-
ний стандарт України ДСТУ 3918-99
“Інформаційні технології. Процеси жит-
тєвого циклу програмного забезпечен-
ня“ [1]. В усіх роботах, в яких так чи
інакше висвітлюється життєвий цикл
програмних систем, наприклад [2, 3], є
посилання на ці стандарти. Крім того, в
них наводяться приклади каскадної
моделі життєвого циклу та для порів-
няння на її тлі – спіральної моделі, що
має більш придатні властивості для мо-
делювання процесів життєвого циклу.
Але, якщо для каскадної моделі життє-
вий цикл включає стадію експлуатації
та супроводу, то для спіральної моделі
(її графічного зображення) життєвий
цикл закінчується стадією тестування.
Інакше кажучи, така спіральна модель
відображає не життєвий цикл програм-
ної системи, а життєвий цикл її розро-
бки. Цей погляд на спіральну модель
дещо розбігається з міжнародним та
державним стандартами. Саме цій роз-
біжності і присвячена дана стаття.
1. Спіральна модель життєвого циклу
програмної системи
Спіральна модель життєвого ци-
клу розробки (саме розробки [2, с. 20])
програмної системи є подальшим роз-
витком водоспадної або каскадної мо-
делі, в якій кожний завій спіралі відпо-
відає одній з версій розробленої сис-
теми [2]. Точніше було б сказати: кож-
ний завій спіралі відповідає одному з
етапів життєвого циклу, під час якого
розробляється версія програмної сис-
теми. Ця модель позбавляє замовника і
розробника від необхідності повного і
точного формулювання вимог до сис-
теми на початковій стадії, оскільки во-
ни уточнюються на кожному завії спі-
ралі (ітерації або етапі розробки версії
системи). Таким чином, постійно по-
глиблюються та конкретизуються дета-
лі проекту і, в результаті, вибирається
обґрунтований варіант, який доводить-
ся до реалізації [3]. Спіральна модель
(у всякому разі її графічне зображен-
ня), тобто кожний з її завіїв – етапів
розробки, складається з чотирьох ста-
дій: аналізу вимог, проектування, реа-
лізації та тестування. Під стадією роз-
робки розуміється частина етапу про-
цесу розробки програмної системи, що
Методы и средства программной инженерии
35
обмежена у часі і завершується ство-
ренням конкретного продукту, визна-
ченого у вимогах. Проходження всіх
стадій повторюється на кожному етапі
розробки, кожному завії спіралі, окрім
останнього, який завершується виво-
дом системи з експлуатації. Відміною
такої моделі від попередньої (каскад-
ної) є можливість багаторазового повер-
нення до стадії формулювання вимог
до розробки з будь-якої стадії робіт,
якщо виявиться необхідність внесення
змін. Це позитивна властивість моделі,
бо на кожній стадії життєвого циклу
може виникнути потреба змін, а вне-
сення змін на будь-якій стадії
обов’язково починається з внесення
змін до попередньо зафіксованих ви-
мог. Це може бути пов’язане з вияв-
ленням у процесі розробки недостат-
ньої обґрунтованості сформульованих
вимог або неузгодженості окремих по-
зицій такого формулювання, відсутнос-
ті потрібних інформаційних або техніч-
них ресурсів, зниження обсягів фінан-
сового забезпечення тощо. Такі зміни
носять локальний поточний характер і
не приводять до принципових змін ви-
мог, зафіксованих у документах. Але і
в цьому випадку рішення про внесення
змін повинно бути виваженим, ретель-
но обґрунтованим і не виходити за ра-
мки розроблюваної версії, тому що ве-
лика кількість змін і, таким чином, час-
те повернення до попередніх стадій
можуть внести додаткові труднощі в
організацію робіт, пов’язаних з розро-
бкою. Більш суттєві пропозиції щодо
змін, які пов’язані з розширенням фу-
нкціональних можливостей програмної
системи, накопичуються у замовника,
узгоджуються з розробником і вно-
сяться у список для подальшого вклю-
чення у нові вимоги до розробки сис-
теми з метою створення її нової, більш
досконалої, версії.
Найбільш суттєві зміни у вимо-
гах (по суті – створення нових вимог)
замовника можуть виникнути тільки
після дослідної, а, можливо, й під час
промислової експлуатації програмної
системи. Наведена модель (графічне її
зображення) не враховує цієї стадії
етапу життєвого циклу, хоча в згада-
них роботах перед тим на цьому наго-
лошувалось. Тому пропонуємо для ре-
жиму розробки нової версії програмної
системи з метою її вдосконалення та
розвитку у зв’язку з появою нових ви-
мог замовника для досягнення більш
високих характеристик, аніж ті, що бу-
ли закладені у початкових, викори-
стовувати не чотирьохстадійну, а п’яти-
стадійну спіральну модель життєвого
циклу розробки, тепер вже і супроводу
(дослідної або промислової експлуатації)
програмної системи. Шосту стадію –
вивід системи з експлуатації, про яку
ведеться мова в роботах, застосовувати
у моделі не будемо, тому що на ній за-
кінчується спіраль, розвиток процесу
(його динаміка) завершується і предмет
дослідження (життєвий цикл) зникає.
Це, на наш погляд, не стадія, а, скорі-
ше, кінцева фаза одного (останнього) з
етапів розвитку подій. І без уваги він
не залишиться, але про нього трохи пі-
зніше. Графічно п’ятистадійна модель
зображується не у вигляді чотирьох
квадрантів на тлі Декартових (прямо-
кутних) координат, а у вигляді п’яти
секторів полярної сітки координат
(рис. 1). Весь простір полярної коорди-
натної сітки на площині п’ятьма про-
менями (ОА, ОВ, ОС, OD та ОЕ) розби-
тий на сектори, кожний з яких разом з
променем відповідає певній стадії ета-
пу життєвого циклу розробки. Промені
проградуйовані відповідно до шкали
одиниць вимірювання процесів, що
відбуваються упродовж кожної з цих
стадій. Чотири з них такі ж, як і у по-
передній моделі: аналіз вимог, проек-
тування, реалізація та тестування, а
п’ята – дослідна (а може, й промисло-
ва) експлуатація разом з авторським
супроводженням розробником. Розгля-
немо більш детально призначення кож-
ної стадії.
На першій стадії (стадія А) кож-
ного етапу по результатах збирання
вимог (вивчення директивних, договір-
них та нормативних галузевих докумен-
тів замовника, опитування його упов-
новажених на це фахівців тощо), ана-
лізу вимог замовника (виявлення функ-
Методы и средства программной инженерии
36
ціональних і нефункціональних вимог,
визначення їх пріоритетності тощо)
будується модель проблеми для нової
версії програмної системи. На першо-
му етапі у функціональній точці старту
S починається процес розробки першої
версії програмної системи. Умовними
одиницями вимірювання вимог (шкали
цієї стадії) можуть бути інтегровані по-
казники, що враховують кількісні і які-
сні показники вимог, їх складність,
взаємопов’язаність, або, навпаки, їх
локалізованість і незалежність, трудо-
місткість та ресурсоємність при реалі-
зації тощо.
На другій стадії (стадія В) кожно-
го етапу під час проектування версії
програмної системи відбувається про-
цес трансформації побудованої моделі
проблеми у структуровану множину
проектних рішень щодо побудови сис-
теми відповідно до вимог замовника –
побудова архітектури самої системи, її
бази даних, інших компонентів і моду-
лів. Одиницями вимірювання шкали
цього процесу також можуть бути інте-
гровані показники, що враховують
кількість компонентів, їх архітектурний
склад тощо.
На третій стадії (стадія С) кож-
ного етапу відбувається реалізація про-
ектних рішень, тобто створення нової
версії програмної системи шляхом
трансформації проекту в код реалізації
відповідно до вибраної технології
(структурного, об’єктно-орієнтованого,
імперативного методу) за допомогою
сучасних новітніх програмних інстру-
ментальних CASE-засобів проектуван-
ня і генерації розподілених баз даних
(як, наприклад, S-Designer) або інших
програмних засобів такого класу, що
підтримують візуальне об’єктно-орієн-
товане моделювання (наприклад, UML),
програмних засобів розробки функціо-
нальних модулів (наприклад, Java, Pow-
erBuilder). І тут в шкалі цієї стадії оди-
ницями вимірювання процесу можуть
бути інтегровані показники, що врахо-
вують якісні показники застосованого
програмного інструментарію, обсяг
програмних компонент тощо.
На четвертій стадії (стадія D)
кожного етапу під час тестування (се-
мантичної перевірки програми) відбу-
вається верифікація – перевірка пра-
вильності трансформації проекту в код,
а також валідація – перевірка відповід-
ності функцій працюючої версії про-
грамної системи вимогам замовника до
системи. Якщо будуть виявлені відмо-
ви, дефекти або помилки у системі, то
виконуються цикли доведення, які
здійснюються згідно другої, теж спі-
Рис. 1. Спіральна модель життєвого циклу програмної системи
(режим розробки)
Методы и средства программной инженерии
37
ральної, моделі життєвого циклу дове-
дення (налагоджування) програмних
засобів, зображеної на рис. 2: проекту-
вання, а може, й перепроектування
програмного компонента, залежно від
виявленого дефекту, реалізація і знову
тестування. Після відпрацювання цієї
моделі (моделі доведення) у повному
обсязі (можливо, за кілька циклів дове-
дення) розробка знову повертається до
першої моделі – моделі розробки про-
грамних засобів. Але опису моделі до-
ведення та циклам доведення програм-
ної системи буде приділена увага трохи
пізніше. Одиницями вимірювання ре-
зультатів тестування в шкалі цієї стадії
можуть бути інтегровані показники,
що враховують кількість виявлених
дефектів, їх складність, час на їх ви-
правлення, питому вагу серед інших
дефектів, кількість компонент з дефек-
тами тощо.
На п’ятій стадії (стадія Е) кожно-
го етапу життєвого циклу (вже не роз-
робки, а супроводження) програмної
системи під час її дослідної (а може, й
під час промислової) експлуатації від-
бувається перевірка адекватності і
працеспроможності не самого продук-
ту (це вже було виявлено під час тес-
тування), а тих вимог, ідей, що були
закладені у розробку при її проекту-
ванні. Саме під час цієї стадії етапу
життєвого циклу програмної системи і
визріває потреба у замовника на вдос-
коналення самої системи, на її розви-
ток, розширення та поглиблення влас-
тивостей, характеристик у зв’язку з
накопиченням досвіду її експлуатації,
виникненням нових задач, нових тех-
нічних (а може, й фінансових) можли-
востей тощо. Інакше кажучи, настає
новий етап ітерації розробки системи,
розробки її нової версії, нового завію
спіралі моделі життєвого циклу не
тільки розробки, але й супроводу під
час експлуатації – дослідної або про-
мислової. Після реалізації такої версії,
тестування та дослідної експлуатації
знову може виникнути потреба в удо-
сконаленні системи, її розвитку та
створенні нової версії – нового завію
спіралі на моделі життєвого циклу. І
так весь час, тому що загальновизна-
ним законом програмної інженерії є
закон еволюції, котрий формулюється
так: кожна діюча програмна система з
часом потребує змін або перестає ви-
користовуватись [2, с. 19].
Під час дослідної, а в окремих
випадках і промислової експлуатації
системи обов’язково відбувається су-
проводження її розробником. Метою
такої дії є:
Рис. 2. Спіральна модель життєвого циклу програмної системи
(режим доведення)
Методы и средства программной инженерии
38
• усунення дефектів у програм-
них засобах, які не були виявлені під
час тестування і можуть бути виявлені
під час цієї стадії життєвого циклу (ко-
ригуюче супроводження);
• адаптація системи до умов
експлуатації замовником, консульту-
вання, а можливо, і навчання фахівців
замовника кваліфікованій експлуатації
системи (адаптивне супроводження);
• збирання й накопичення саме
розробником ідей з вдосконалення си-
стеми, підвищення її програмно-
технічних характеристик та якості для
включення їх у списки змін вимог до
наступної версії системи (вдосконалю-
вальне супроводження).
Замовник, як вже було сказано,
теж збирає ідеї з функціонального вдо-
сконалення системи, розширення її
функціональних можливостей, розв’я-
зання нею нових задач тощо з тією ж
метою – для включення їх у списки
змін вимог до наступної версії системи.
Таких версій на рис. 1 зображено три,
але, зрозуміло, що їх кількість може
обмежуватись, скоріше за все фінансо-
вими можливостями замовника, а ви-
значатися буде залежністю від кількос-
ті, масштабності, а головне – зміню-
ваності (у часі) функціональних задач,
що стоять перед замовником.
2. Спіральна модель життєвого циклу
для налагоджувального режиму
розробки
На четвертій стадії (стадія D)
кожного етапу неодмінною складовою
процесу розробки є режим доведення
(налагоджування) програмної системи.
Потреба в ньому виникає у тому разі,
коли під час тестування системи вияв-
ляється, що її характеристики не від-
повідають замовленим. Є розбіжності
між характеристиками, зафіксованими
у вимогах на створення системи, і ха-
рактеристиками, отриманими під час
тестування реалізованої програмної
системи. Це може статися за різних
обставин, але ясно одне – систему
(програмний продукт) треба доводити,
тобто вилучати помилки, усувати де-
фекти, вносити зміни в окремі програ-
ми, а може, й перепроектувати якісь
фрагменти системи. Після цього знову
необхідно реалізувати систему і ще раз
тестувати. Можливо, і на цей раз бу-
дуть виявлені розбіжності в характери-
стиках, але значно менші. Знов повто-
рення вказаного циклу доведення. Во-
чевидь – новий завій спіралі, але не
тої спіралі, що розходиться, як це здій-
снюється у моделі розробки (рис. 1), а
тої, що зходиться, як це здійснюється у
моделі доведення (наладки) версії про-
грамного продукту (дещо нагадує спі-
раль Архімеда з однією гілкою) і пока-
зано на рис. 2.
Ця спіральна модель зображена
на тлі прямокутних (Декартових) коор-
динат, координатні вісі яких поділяють
простір площини на чотири квадранти,
кожний з яких разом зі своєю напів-
віссю (оа, ob, oc, od) відповідає певній
стадії режиму доведення програмної
системи. Суттєвою відміною цієї моде-
лі є те, що вона притаманна іншому
режиму розробки програм, навіть не
розробки, а доведення їх до кондицій-
них умов, досягнення рівня адекватно-
сті програм висунутим до них вимогам,
тобто отримання необхідної якості
програмного продукту. Ця модель має
малі цикли (на відміну від великого
життєвого циклу) доводки програмних
засобів. Про це вже згадувалось вище.
Причиною проведення цих циклів до-
водки є не вимоги замовника, закладе-
ні у технічному завданні, а дефекти
програмних засобів, що виникли під
час розробки за вини самого розроб-
ника чи то через неадекватно сприйня-
ті розробником вимоги замовника, чи
то через невдало вибрану технологію
проектування, кодування й реалізації.
Саме це й впливає на характеристики
системи, вносить розбіжності між ни-
ми і характеристиками, зазначеними у
вимогах. Ці розбіжності відкладаються
на ординаті “Аналіз вимог і розбіжності
характеристик”. На першому циклі –
аналіз вимог, а на інших – розбіжнос-
ті характеристик. Треба зауважити, що
за своєю функціональною навантаже-
ністю напіввісь оа (стадія а) моделі до-
ведення співпадає з функціональною
Методы и средства программной инженерии
39
навантаженістю променя ОА (стадія А)
моделі розробки. Те ж саме можна
сказати про відповідності інших стадій:
оb ↔ OB (стадія B), oc ↔ OC (стадія C),
od ↔ OD (стадія D). Ця схожість не
випадкова. Вона говорить, що процеси,
які відбуваються під час функціону-
вання цих моделей, за природою схожі.
Вони тільки мають різну направленість.
Процес у першій моделі (моделі розроб-
ки) направлений на збільшення мож-
ливостей системи завдяки розробці но-
вих версій, а процес у другій моделі
направлений на зменшення дефектів в
системі внаслідок запровадження цик-
лів доведення програмного забезпе-
чення. На рис. 2 таких циклів зобра-
жено три, але в житті, залежно від ва-
ги, кількості і складнощів дефектів, а
також від акуратності і досвідченості
аналітиків-проектувальників та про-
грамістів, таких циклів може бути від
одного до кількох. Роль ординати (на-
піввісь оа) цієї стадії нагадує роль еле-
мента порівняння в моделях систем ав-
томатичного регулювання, який гене-
рує керуючий сигнал, ґрунтуючись на
відхиленнях порівнюваних параметрів.
Продовжуючи порівняння моделі довод-
ки з моделями систем автоматичного
регулювання, можна сказати, що роль
зворотного зв’язку тут виконує стадія
тестування. Проте з кожним таким ци-
клом доводки на стадії тестування де-
фектів виявляється все менше і менше
і, зрозуміло, й величини розбіжностей
весь час зменшуються, тому на одному
з чергових тестувань їх може не ви-
явитись зовсім, що й видно на моделі
(рис. 2) – розбіжність рівняється нулю
і спіраль зайшла у центр координат (в
усякому разі так повинно бути в ідеа-
лізованому уявленні).
3. Узагальнена спіральна модель
життєвого циклу програмної системи
Після усунення дефектів, що бу-
ли виявлені на стадії тестування про-
грамної системи, тобто після відпрацю-
вання моделі доводки, можна поверта-
тись до попередньої моделі, до моделі
життєвого циклу розробки і продовжу-
вати по всіх стадіях цей етап розробки
нової версії програмної системи відпо-
відно до наведеної моделі аж до стадії
переходу до дослідної експлуатації та
супроводження системи. І так до тих
пір, поки розроблена програмна систе-
ма не задовольнить замовника по всіх
параметрах та характеристиках, коли
він (замовник) прийме систему в про-
мислову експлуатацію, як це показано
на рис. 3.
Рис. 3. Узагальнена модель життєвого циклу розробки і доведення
програмної системи
Методы и средства программной инженерии
40
На цьому рисунку зображена
узагальнена (об’єднуюча всі процеси)
модель життєвого циклу розробки і до-
ведення програмної системи. Процес
режиму розробки системи (модель
розробки) включає три версії та по два
цикли режиму доведення системи (мо-
дель доведення) кожної версії. Зрозу-
міло, що це зображення умовне, тому
що може буде достатньо і однієї версії,
а можливо, й трьох буде замало. Це за-
лежить, як вже згадувалось, від досвід-
ченості фахівців замовника при фор-
мулюванні та висуванні вимог до про-
грамної системи, від досвідченості та
кваліфікації фахівців розробника при
проектуванні та реалізації системи та
багатьох інших об’єктивних і суб’єк-
тивних причин. І не в останню чергу
залежить і часто визначається типом
створюваної програмної системи. Так,
наприклад, автоматизовані системи
управління організацією (підприємст-
вом) весь час потребують змін через
появу нових або необхідності вдоско-
налення вже існуючих функціональних
задач, через розширення виробництва,
зміну партнерів, зміни в потребах рин-
ку, котирування продукції, зміни нор-
мативних актів тощо. Тому для такого
типу систем потреба у нових версіях
буде завжди, доки існуватиме органі-
зація (рис. 4, а). Процес розробки ав-
томатизованих інформаційних систем
у меншій мірі, але теж прихильний до
багатоітераційності внаслідок вклю-
чення до системи нових задач, розши-
рення її меж (масштабів). Особливо це
стосується територіально розподілених
інформаційних систем, що охоплюють
великі галузі народного господарства,
органи державного управління, мініс-
терства, відомства (рис. 4, б). Для про-
цесу розробки програмних систем,
призначених для наукових, інженерно-
технічних розрахунків або навіть моде-
люючих програмних систем, така бага-
тоітераційність менш характерна. Це
пояснюється тим, що сама задача та її
межі ясні замовнику з самого початку і
вимоги свої він формулює чітко і кон-
кретно. Якщо ж і з’явиться необхід-
ність у доробці системи, то це стосува-
тиметься скоріш за все невеликих змін
у алгоритмі розрахункової частини
програмного забезпечення, що не
вплине ні на архітектуру системи, ні на
інформаційні потоки, ні на технічне та
організаційне забезпечення. Але тип
системи вплине на зовнішній вигляд
самої моделі. Так, для моделюючих си-
стем, ймовірно, спіральна модель ма-
тиме незначну кількість завіїв, до того
ж вони більш щільно розмістяться
один до одного, якщо враховувати кі-
лькість та складність вимог (у вигляді
інтегрованого показника) на стадії А та
відкладати його на шкалі променя ОА
(рис. 4, в).
Кількість завіїв на спіралях мо-
делей свідчить лише про тенденцію, що
характерна для моделі того чи іншого
типу автоматизованих програмних сис-
тем, а не про дійсну їх кількість. Це
пояснюється: по-перше, браком місця
для графічного зображення великої
кількості завіїв спіральної моделі на
рис.4, а по-друге, дійсна кількість завіїв
визначається для кожної системи (на-
віть не типу системи, а самої системи)
Рис. 4. Спіральні моделі життєвого циклу різних типів автоматизованих систем:
а) автоматизована система управління; б) автоматизована інформаційна система;
в) моделююча автоматизована система та система для наукових розрахунків
Методы и средства программной инженерии
41
залежно від того, як про це було згада-
но вище, від чіткості визначення та
формулювання вимог замовником,
складності системи, кваліфікації і
досвіду фахівців розробника та ще ба-
гатьох інших чинників.
Висновки
Треба зазначити, що зображена
на рис.3 узагальнена модель, як і попе-
редні моделі (рис. 1 та рис. 2), наведені у
цій статті, представлені в ідеалізовано-
му вигляді. В них кутова відстань (роз-
міри кута) між променями або напів-
осями не відповідає когнітивній відста-
ні між стадіями (кількості інтелектуа-
льних зусиль, які необхідно затратити
розробникові програмного забезпечен-
ня для того, щоб перевести систему,
що розробляється, з однієї стадії жит-
тєвого циклу в іншу) [2, с. 264]. Точки
перерізу гілки спіралі з променями та
напівосями не враховують величини
інтегрованих показників, що повинні
бути адекватними кількісним (розміри,
об’єм, обсяг) чи якісним характеристи-
кам тих процесів, що моделюються на
цих стадіях життєвого циклу. Якби це
зробити, то наведені моделі графічно
виглядали б дещо інакше, що скоріше
за все утруднювало б зорове сприйнят-
тя і розуміння складнощів всієї мно-
жини процесів, що протікають під час
розробки програмної системи. Тим не
менш зовнішній вигляд моделей спону-
кає до таких висновків:
• Нові вимоги до програмної
системи виникають на стадії дослідної
(промислової) експлуатації і, відповід-
но, супроводження програмної систе-
ми, причому замовник під час експлуа-
тації напрацьовує вимоги до розши-
рення можливостей (підвищення функ-
ціональних показників) системи, а роз-
робник під час супроводження напра-
цьовує пропозиції на вдосконалення
(покращення програмно-технічних ха-
рактеристик) системи.
• На стадії тестування розроб-
ник визначає відхилення результуючих
характеристик створеної системи (вер-
сії системи) від заданих у вимогах тех-
нічного завдання і переходить у режим
налагоджування системи – доведення
її характеристик до потрібних.
• Виведення системи з експлуа-
тації не є стадією її життєвого циклу,
як це стверджується в [3, с. 35], а є
лише заключною фазою останнього
етапу життєвого циклу, інакше на кож-
ному етапі (завії спіралі) необхідно бу-
ло б вилучати систему з експлуатації, а
не замінювати її новою версією.
Хоча по цих моделях, вірніше, по
їх графічному зображенню, наведено-
му у статті, не можна судити про ког-
нітивну відстань між стадіями або про
інженерію якості (процес надання про-
дуктам програмного забезпечення вла-
стивостей якості, оцінки показників та
кількісного вимірювання їх із зістав-
ленням з зазначеними вимогами) ство-
рюваної системи, проте вона дає мож-
ливість показати читачеві, що таке
(ідеалізоване) графічне зображення до-
сліджуваних спіральних моделей жит-
тєвого циклу розробки й доведення
програмного продукту дозволяє точні-
ше сприймати багатоаспектні процеси
побудови програмних систем. Спіраль-
ні моделі у такому вигляді є своєрідни-
ми атрибутами зручності, що надають
можливість фахівцям з програмної ін-
женерії, зокрема розробникам саме
територіально розподілених інформа-
ційних корпоративних інтегрованих
систем, значно скоротити час на проек-
тування, реалізацію, тестування, дове-
дення та здачу в дослідну експлуатацію
створеного програмного продукту за-
вдяки більш ефективній організації
процесів на всіх стадіях життєвого ци-
клу цих систем.
1. ДСТУ 3918-99 (ISO/IEC 12207: 1995) Інфор-
маційні технології. Процеси життєвого цик-
лу програмного забезпечення. – К.: Держ-
стандарт України, 2002. – 49 с.
2. Бабенко Л.П., Лавріщева К.М. Основи про-
грамної інженерії: Навч. посіб. – К.: Знан-
ня, КОО, 2001. – 209 с. – (Вища освіта ХХІ
століття).
3. Вендров А.М. Проектирование программно-
го обеспечения экономических информаци-
онных систем: Учебник. – М.: Финансы и
статистика, 2000. – 352 с.
Методы и средства программной инженерии
42
Отримано 31.07.03
Про авторів
Алексєєв Віктор Анатолійович,
кандидат технічних наук, завідувач від-
ділом
Терещенко Валерій Савелійович,
кандидат технічних наук, старший нау-
ковий співробітник
Місце роботи авторів
Інститут програмних систем НАН України,
просп. Академіка Глушкова, 40,
Київ-187, 03680, Україна
Тел. (044) 266 4228, 266 6321
E-mail: terek@isofts.kiev.ua
|