Особливості процесів керування при створенні сімейств програмних систем
Розглянуто особливості процесів керування в інженерії сімейств програмних систем (СПС), зокрема, нові функції процесу керування конфігурацією, який інтегрований з базовим процесом розроблення (БПР) готових ресурсів та БПР ПС і узгоджує їх виконання. Запропоновано формалізацію СПС і БПР СПС із залуче...
Saved in:
| Date: | 2009 |
|---|---|
| Main Authors: | , , , |
| Format: | Article |
| Language: | Ukrainian |
| Published: |
Інститут програмних систем НАН України
2009
|
| Subjects: | |
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/4596 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Особливості процесів керування при створенні сімейств програмних систем. / К.М. Лавріщева, Г.І. Коваль, О.О. Слабоспицька, А.Л. Колєснік // Пробл. програмув. — 2009. — № 3. — С. 40-49. — Бібліогр.: 11 назв. — укр. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859967499103109120 |
|---|---|
| author | Лавріщева, К.М. Коваль, Г.І. Слабоспицька, О.О. Колєснік, А.Л. |
| author_facet | Лавріщева, К.М. Коваль, Г.І. Слабоспицька, О.О. Колєснік, А.Л. |
| citation_txt | Особливості процесів керування при створенні сімейств програмних систем. / К.М. Лавріщева, Г.І. Коваль, О.О. Слабоспицька, А.Л. Колєснік // Пробл. програмув. — 2009. — № 3. — С. 40-49. — Бібліогр.: 11 назв. — укр. |
| collection | DSpace DC |
| description | Розглянуто особливості процесів керування в інженерії сімейств програмних систем (СПС), зокрема, нові функції процесу керування конфігурацією, який інтегрований з базовим процесом розроблення (БПР) готових ресурсів та БПР ПС і узгоджує їх виконання. Запропоновано формалізацію СПС і БПР СПС із залученням формалізму сімейства процесів та надано методологічне ядро математичного апарата його підтримки.
Рассмотрены особенности процессов управления в инженерии семейств программных систем (СПС), в частности новые функции процесса управления конфигурацией, который интегрирован с базовым процессом разработки (БПР) готовых ресурсов и БПР ПС и согла-совывает их выполнение. Предложена формализация СПС и БПР СПС с привлечением формализма семейства процессов и определено методологическое ядро математического аппарата его поддержки
Specialities of management processes in software systems families (SSF) engineering are considered, in particular new functions of software configuration management process, integrated with the core assets base development process (BDP) and SS BDP, and coordinated their implementation. The formalization of SSF and SSF BDP based on formalism of processes family is offered, and a methodological kernel of mathematical theory of his support is given
|
| first_indexed | 2025-12-07T16:21:29Z |
| format | Article |
| fulltext |
Моделі та процеси життєвого циклу програмного забезпечення
40
УДК 681.3.06
К.М. Лавріщева, Г.І. Коваль, О.O. Слабоспицька, А.Л. Колєснік
ОСОБЛИВОСТІ ПРОЦЕСІВ КЕРУВАННЯ ПРИ СТВОРЕННІ
СІМЕЙСТВ ПРОГРАМНИХ СИСТЕМ
Розглянуто особливості процесів керування в інженерії сімейств програмних систем (СПС), зокрема,
нові функції процесу керування конфігурацією, який інтегрований з базовим процесом розроблення
(БПР) готових ресурсів та БПР ПС і узгоджує їх виконання. Запропоновано формалізацію СПС і БПР
СПС із залученням формалізму сімейства процесів та надано методологічне ядро математичного апара-
та його підтримки.
Вступ
На сучасному етапі розвитку індус-
трії програмного забезпечення дієвим за-
собом забезпечення конкурентоспромож-
ності організацій-розробників програмних
систем (ПС), що спеціалізуються на авто-
матизації різних проблемних областей
(ПрО), є побудова ПС у новій парадигмі
генерувального програмування (ГП) [1, 2].
Головним цільовим об’єктом розроблення
у цій парадигмі є не унікальна ПС, а сі-
мейство ПС (СПС) у певній ПрО, кожний
член якого не створюється “з нуля”, а ге-
нерується на основі загальної моделі сі-
мейства шляхом її конкретизації відповід-
но до специфікації ПС. Нова ПС для ПрО
утворюється множиною активів, які є ре-
зультатом постійного накопичення та уза-
гальнення напрацювань у ПрО. Вони збе-
рігаються та опрацьовуються в інтегрова-
ному середовищі розроблення (IDE, від
Integrated Development Environment) СПС і
складають готові інформаційні ресурси
(ГОР), які вибираються, адаптуються та
несуперечливо поєднуються у композиції в
ході розроблення ПС.
На відміну від організацій, які роз-
робляють одиничні ПС, організація-
розробник СПС та окремих ПС на їх осно-
ві оперує трьома видами об’єктів – ГОР,
СПС, ПС, – які мають власні, відмінні від
інших, моделі життєвого циклу (ЖЦ) та
методології розроблення. Процеси їх ЖЦ
виконуються паралельно і потребують уз-
годженого керування.
Організація-розробник може ство-
рювати одночасно декілька СПС, заснова-
них на спільній множині ГОР, мати одно-
часно декілька замовників різних ПС на
базі відповідних СПС, а також накопичу-
вати нові ГОР не лише для замовлених ПС,
але й з урахуванням еволюції ПрО, техно-
логій та потреб ринку програмної продук-
ції у ній. У такій організації задачі керу-
вання на рівні окремих проектів і на рівні
організації у цілому значно складніші, ніж
у тій, що розробляє одиничні ПС, оскільки
виконання проектів потребує не лише ефе-
ктивного розподілу ресурсів за проектами,
але й координації дій зі створення, викори-
стання та еволюції ГОР – активів ПрО.
Побудова інформаційно-техноло-
гічного середовища синхронізованого ви-
конання проектів СПС, яке доповнює IDE
СПС, є актуальною проблемою інженерії
якості СПС [2]. Її вирішення потребує
розв’язання, перш за все, задач ідентифі-
кації множини, структури і взаємозв’язку
артефактів проектів, які набуватимуть ста-
тусу ГОР в репозитарії IDE, а також ви-
значення процесів керування, від ефектив-
ного виконання яких залежить успіх прое-
кту СПС.
У роботі розглядаються особливості
процесів, виконуваних у проектах СПС,
зокрема, процесів організаційного та тех-
нічного керування, серед яких виділено
процес керування конфігурацією, на який
покладено нові функції. Запропоновано
формалізацію процесу розроблення СПС,
надано методологічне ядро математичного
апарата його підтримки та визначено пер-
шочергові задачі створення такого матема-
тичного апарата.
© К.М. Лавріщева, Г.І. Коваль, О.О. Слабоспицька, А.Л. Колєснік , 2009
ISSN 1727-4907. Проблеми програмування. 2009. № 3
Моделі та процеси життєвого циклу програмного забезпечення
41
Аспекти методологічної підтрим-
ки проектів СПС
Методологічна підтримка проекту
СПС полягає у визначенні моделей і окре-
мих процесів ЖЦ ГОР, ПС та СПС, ролей
агентів цих процесів і їх взаємодії, взаємо-
зв’язку процесів ЖЦ при виконанні проек-
ту, складу і структури відповідних інфор-
маційних об’єктів репозитарія IDE з метою
накопичення і використання досвіду вико-
нання проектів та вдосконалення процесів
розроблення СПС.
Основними видами об’єктів, які
мають власні моделі ЖЦ при їх розроб-
ленні у парадигмі ГП, є такі:
– готові ресурси повторного ви-
користання, які є активами, напрацьова-
ними або придбаними «в інтересах» одно-
го СПС або множини створюваних СПС
(моделі ЖЦ МЖЦГОР),
– сімейство ПС як множина взає-
мопов’язаних ГОР (модель ЖЦ МЖЦСПС),
– програмна система, яка розроб-
ляється на базі СПС (модель ЖЦ МЖЦПС).
Розрізняються дві категорії ГОР –
програмні (модулі, компоненти, аспекти
тощо) і не програмні (моделі, текстові до-
кументи тощо).
Спільним для ГОР будь-якої кате-
горії є наявність:
– постійної невід’ємної складової
(ядра ГОР), прийнятного для всіх ПС у сі-
мействі,
– змінюваних складових (розши-
рень ядра),
– точок варіантності, в яких ядро
ГОР може доповнюватися розширеннями і
в результаті утворювати варіант ГОР, при-
йнятний для конкретної ПС,
– мікропроцесу, який визначає об-
меження щодо варіантів ГОР, умови та
механізми розширень ядра, взаємозалеж-
ність та взаємозв’язки з іншими ГОР, а та-
кож детальний опис дій з адаптації ГОР.
Моделі ЖЦ відбивають взаємо-
зв’язок основних стадій ЖЦ об’єктів [3].
Структура моделей МЖЦГОР визна-
чається категорією ГОР та складом дій мі-
кропроцесу (наприклад, мікропроцес для
програмного ГОР включатиме крок тесту-
вання, а для не програмного – крок колегі-
альної перевірки).
Структура МЖЦСПС визначається
типом генеративної моделі СПС [4]. Ці ти-
пи (конфігураційний або трансформацій-
ний) відрізняються підходом до відобра-
ження між абстракціями, притаманними
ПрО (простором проблеми) і абстракціями
інформаційно-програмного змісту, прида-
тними для побудови реалізацій специфіка-
цій ПС (простором рішень).
Структура МЖЦПС визначається
класом базової моделі ЖЦ, на якій вона
засновується (каскадна, ітераційна тощо)
[3], а також прийнятою стратегією побудо-
ви і функціонування СПС [5].
Стратегія може бути проактивною
(заснованою на попередньому виробництві
множини ГОР і наступному розробленні
ПС з їх використанням), реактивною (за-
снованою на попередньому розробленні
множини ПС з наступним аналізом і вибо-
ром компонентів ПС для виробництва
ГОР) або змішаною. Фактично стратегія
визначає порядок взаємодії двох базових
процесів розроблення (БПР), які впрова-
джує організація-розробник СПС і які ма-
ють відмінні моделі. Це:
– базовий процес колективного
розроблення готових ресурсів (БПР ГОР)
(модель МБПРГОР),
– базовий процес розроблення
окремих програмних систем (БПР ПС) з
ГОР (модель МБПРПС).
Кожний з цих процесів є складеним,
тобто таким, що включає низку процесів
ЖЦ (представлених профілями процесів
[3]) відповідно до виду об’єктів, їх моде-
лей ЖЦ та стратегії виробництва об’єктів
даного виду.
Процеси виконуються паралельно,
взаємодіють через дані (робочі продукти
цих процесів у репозитарії IDE), якими во-
ни можуть опосередковано обмінюватися в
узгоджений спосіб (рис. 1).
Відмітна особливість МБПРГОР –
наявність у структурі моделі дій щодо тра-
сування несуперечливості варіантів різних
ГОР (наприклад, концептуальна модель
ПрО � архітектура � компоненти).
Відмітна особливість МБПРПС – на-
явність точок аналізу варіантів і прийняття
рішень щодо вибору оптимального варіан-
та ГОР.
Моделі та процеси життєвого циклу програмного забезпечення
42
Проект ПС1
Об’єкт розробки: ПС
Модель ЖЦ – МЖЦПС
ГОРi
Програма повторного
використання ГОР
організації
Потенційний ГОРk
Базовий процес
розроблення ПС1
Модель процесу – МБПРПС
Проект СПС1
Команда проекту СПС:
артефакти СПС
(вимоги, архітектура,
компоненти…)
Репозитарій:
Команда програми ГОР
Модель команди – МКПГОР
Команда проекту ПС1
Модель команди – МКППСКоординаційна рада
менеджерів
Базовий процес
розроблення ГОР
Модель процесу – МБПРГОР
Модель ЖЦ – МЖЦГОР
ГОР1 . . . ГОРi
ГОРn
Об’єкт розробки: ГОР
Репозитарій:
Робочі
продукти
БПР
база знань
проектів та
процесів
(МЖЦ, МБПР…)
Рис. 1. Взаємозв’язок проектів при розробленні ПС як членів СПС
Розроблення ГОР виконується в ра-
мках програми (або проекту) повторного
використання ГОР організації (далі про-
грами ГОР) відповідною окремою коман-
дою (модель команди МКПГОР). Програма
охоплює множину мікро-проектів з розро-
блення (придбання) окремих ГОР та забез-
печення несуперечливості їх інтерфейсів.
Розроблення кожної ПС на базі від-
повідної СПС виконується в рамках проек-
ту ПС також окремою командою проекту
(модель команди МКППС).
Розроблення кожного СПС здійс-
нюється, в загальному випадку (якщо ор-
ганізація розробляє декілька СПС на базі
спільної множини ГОР [6]), в рамках
окремого проекту СПС командою, яка
включає менеджерів СПС, окремих проек-
тів ПС та програми ГОР) (рис. 1). Згаданий
менеджмент утворює координаційну раду
з розроблення СПС.
Очевидно, що керування програ-
мою ГОР, проектами СПС та ПС усклад-
нюється.
Основні напрями керування у
контексті СПС
Задачі керування в організаціях-
розробниках СПС, зокрема, керування
проектами, ризиками, конфігурацією, ви-
рішенням проблем тощо, за змістом відрі-
зняються від визначених для відповідних
процесів ЖЦ в ISO/IEC 12207, є складні-
шими з огляду на різнотипність, множин-
ність, взаємопов’язаність основних об’єк-
тів (ГОР, СПС та ПС) і проектів з їх розро-
блення та потребують узгодження дій.
У роботі [5] запропоновано виділя-
ти два рівні керування у проектах СПС –
організаційне керування та технічне керу-
вання, і визначено 20 напрямів діяльності,
розподілених за цими рівнями. Вони схе-
матично показані на рис. 2 в еліптичних
контурах і стисло схарактеризовані далі.
Організаційне керування включає
такі напрями діяльності:
– організація діяльності зі ство-
рення СПС як нового бізнесу (формування
бізнес-плану, економічне моделювання та
обґрунтування витрат та створення СПС);
– керування взаємодією із замов-
никами та інвесторами;
– вироблення договірної стратегії
щодо придбання ГОР та користування по-
слугами інших організацій;
– фінансове забезпечення;
– запуск та інституціалізація біз-
несу (впровадження змін у діяльність ор-
ганізації з метою створення СПС та ПС);
Моделі та процеси життефого циклу програмного забезпечення
43
Рис. 2. Дворівневе керування проектами у контексті СПС
– опис операційної діяльності ор-
ганізації (зміст проектів, базових процесів,
принципів організації роботи тощо);
– маркетингові дослідження (ана-
ліз попиту, ринків збуту тощо);
– організаційне планування;
– організаційне керування ризи-
ками;
– структуризація організації згід-
но з цілями розроблення ПС на базі СПС;
– технологічне передбачення під-
тримка технологічної еволюції СПС);
– підготовка кадрів.
До цих напрямів діяльності слід
долучити ведення бази знань за проектами
організації як засіб накопичення та пере-
дачі досвіду їх виконання, а також прийн-
яття обґрунтованих рішень щодо розподілу
ресурсів, доцільності розширення сфери
СПС тощо.
Процеси організаційного керування
взаємодіють з процесами технічного керу-
вання.
Головне завдання технічного керу-
вання – вироблення рішень щодо ефектив-
них методів виробництва і формування ви-
робничого плану щодо об’єктів відповід-
них БПР у проектах ГОР, СПС та ПС.
Моделі та процеси життєвого циклу програмного забезпечення
44
До технічного керування долуча-
ється менеджмент програми ГОР та проек-
тів кожної ПС, а також менеджмент проек-
ту СПС, який відповідає за ефективність
рішень для досягнення стратегічних цілей
побудови СПС та дотримання виробничих
обмежень щодо СПС, за раціональність
розподілу ресурсів між програмою ГОР та
проектами ПС. Менеджмент програми
ГОР опікується якістю ГОР, їх корисністю
для СПС та ефективністю колективної ро-
боти команди програми ГОР, а менедж-
мент проектів окремих ПС – якістю та
ефективністю роботи команд цих проектів.
Сфера технічного керування охоп-
лює такі напрями діяльності (рис. 2):
– визначення сфери застосування
СПС, а саме: меж охоплення ПрО множи-
ною ПС, контексту застосування ПС, най-
суттєвіших вимог до ПС, обмежень та по-
ведінкових аспектів, що вирізняють мно-
жину ПС з поміж інших систем у ПрО, го-
ловних спільних рис для всіх ПС та від-
мінностей, а також критеріїв приймання
кінцевих розроблених ПС як членів СПС;
– технічне керування ризиками,
яке є безперервним процесом, виконува-
ним на рівні окремих проектів (ГОР, ПС,
СПС). Оскільки у сімействах ПС ризики
можуть стосуватися більш ніж одного про-
дукту, бути взаємопов’язаними, а їх нас-
лідки – більш глобальними, плани керу-
вання ризиками створення об’єктів у СПС
мають координуватися. Це, в свою чергу,
потребує тіснішої взаємодії команд проек-
тів у питаннях виявлення і спостереження
ризиків;
– технічне планування проекту в
парадигмі ГП є ітеративним і безперерв-
ним процесом, який координується з пла-
нуванням вимірювань, оцінювань, гаран-
тування якості, керування ризиками тощо.
Планування виконання програми ГОР по-
в'язується, крім того, з робочим плануван-
ням стосовно кожного ГОР, а планування
проекту СПС – з загальним плануванням
виробництва ПС з ГОР. План виробництва
спирається на операційне визначення про-
цесу виробництва ПС (у моделі МБПРПС)
як членів СПС і додає до нього технічні
деталі стосовно ресурсів процесу та плано-
вих показників для контролю виконання
плану і вдосконалення виробничого про-
цесу. При конкретизації виробничого пла-
ну кроки процесу уточнюються до рівня
супутніх мікропроцесів відповідних ГОР;
– підтримка виконання базового
процесу спрямована на визначення, до-
тримання і вдосконалення БПР відповідно
до моделі процесу МБПРПС (наприклад,
[7]). Забезпечує формулювання операцій-
ного визначення процесу, складеного з дій,
пов’язаних алгоритмом їх виконання, та
формування профілю базового процесу.
Специфікою БПР є те, що в нього після
кожної дії стосовно вибору ГОР для вико-
ристання у ПС інкорпорується супутній
мікропроцес, що за кроками визначає,
яким чином налаштувати ГОР у точці варі-
антності для застосування в процесі розро-
блення даної ПС;
– аналіз можливостей придбання
ГОР стосується як програмних, так і не
програмних ГОР, які можуть бути розроб-
лені в рамках БПР ГОР організації-
розробника СПС, закуплені на ринку як
комерційні COTS продукти (безпосередньо
або через отримання ліцензійних прав на
використання («open source» компоненти
або Web-сервіси)), замовлені через від-
криття проектів на розроблення спеціалі-
зованих ГОР для СПС або виявлені (видо-
буті) в раніше створених ПС організацією-
розробником;
– вимірювання та контроль прое-
кту. Вимірювання виконується на рівні
кожного проекту, а оцінювання – як на рі-
вні окремих проектів, так і на рівні проек-
ту СПС. Результати, отримані на рівні про-
ектів ГОР і ПС, використовуються для
контролю досягнення вимірних цілей за
цими проектами щодо якості (наприклад,
зменшення рівня дефектів в артефактах до
певного рівня), ефективності роботи ко-
манд проектів (наприклад, зростання про-
дуктивності праці до певного рівня), а на
рівні СПС – для приймання узгоджених
рішень з керування окремими проектами в
світлі стратегічних цілей побудови СПС.
Досягнення цілей проектів ГОР, ПС та
СПС є взаємопов’язаними подіями, а від-
повідні метрики, спроектовані для контро-
лю досягнення цілей, комплексними (на-
приклад, корисність ГОР для ПС, кількість
Моделі та процеси життєвого циклу програмного забезпечення
45
дефектів у ГОР, виявлених при застосу-
ванні ГОР у різних ПС, кількість часу на
пошук, адаптацію та інтеграцію ГОР у різ-
них ПС [8]);
– інструментальне забезпечення.
Інструменти IDE мають підтримувати па-
ралельне створення, супроводження і ви-
користання множини версій артефактів
СПС та координацію одночасної роботи
команд програми ГОР і проектів ПС, які
спільно використовують ГОР;
– керування конфігурацією СПС,
яке займає центральне місце серед множи-
ни задач технічного керування у проектах
СПС і тому далі розглядається детальніше.
Керування конфігурацією та
варіабельність СПС
Наразі два аспекти керування кон-
фігурацією (КК) – керування версіями од-
нієї ПС у часі (історичний аспект) і керу-
вання версіями паралельно створюваних
частин ПС, періодично об’єднуваних в од-
ну версію (аспект кооперативної розробки)
– отримали належну методичну та інстру-
ментальну підтримку (наприклад, Clear-
Case, CVS) [9]. Третій аспект КК – керу-
вання одночасно існуючими варіантами
окремих робочих продуктів (РП) ПС, які
відбивають їх логічну варіантність (напри-
клад, варіанти коду для різних платформ) –
розглядається, як правило, лише з позицій
пошуку «обхідних шляхів» для застосу-
вання існуючих інструментів КК (напри-
клад, ведення версій кількох копій ПС для
різних платформ, використання умовної
компіляції коду тощо).
Проте саме аспект конфігурування
множини варіантів є актуальним в інжене-
рії сімейств систем, оскільки варіанти ко-
жного ГОР відповідають контекстам його
використання у різних ПС і мають знахо-
дитися під контролем конфігурації одноча-
сно. Та й сама ПС, що є членом СПС, роз-
глядається як його варіант.
Властивість СПС, обумовлена її
здатністю до розширювання, змінювання,
налаштовування або конфігурування з ме-
тою використання у визначеному контекс-
ті, називається варіабельністю СПС.
Забезпечення варіабельності СПС і
конфігурування ПС як членів СПС визна-
чаються у [9] як дві ключові концепції ін-
женерії сімейств ПС.
Метою забезпечення варіабельності
СПС є врахування нових вимог до ПС у
сімействі через його поповнення новими
варіантами ГОР. Варіабельність забезпечу-
ється наявністю механізмів ідентифікації
та специфікації загальних і відмітних рис
на всіх рівнях подання СПС – характерис-
тик ПрО (її ділової логіки), архітектури
СПС і реалізації, а також механізмів кон-
фігурування та трасування ГОР на різних
рівнях через локалізацію несуперечливих
варіантів ГОР на цих рівнях.
Задачами забезпечення варіабель-
ності СПС є:
– моделювання конфігурабельних
вимог до СПС під час аналізу ПрО. Варі-
ант конфігурації вимог має відповідати
вимогам замовника (користувача) до конк-
ретної ПС як члена сімейства. Вимоги мо-
жуть пред’являтися до функцій ПС (функ-
ціональні вимоги) та показників якості ПС
(не функціональні вимоги), елементів архі-
тектури ПС (зокрема, до апаратно-
програмної платформи, технічного ото-
чення, стандартів архітектури), програм-
них компонентів ПС (зокрема, до мови,
парадигми програмування) та не програм-
них компонентів ПС (зокрема, до складу
комплекту поставки ПС замовнику);
– реалізація механізмів розши-
рення ядра ГОР у точках варіантності. То-
чки варіантності на одному рівні абстрак-
ції реалізують варіабельність на більш ви-
сокому рівні абстракції. Прикладами меха-
нізмів реалізації варіабельності є патерни
проектування, агрегація, успадкування,
параметризація, макроси, умовна компіля-
ція, динамічно приєднувані бібліотеки то-
що [9]. Реалізація варіабельності здійсню-
ється на рівні архітектури та компонентів
СПС. Архітектура СПС визначає всі мож-
ливі комбінації реалізацій програмних
компонентів (з урахуванням обмежень,
встановлених вимогами до ПС, зокрема, до
його архітектури). Архітектура ПС є варіа-
нтом архітектури СПС, позбавленим точок
варіантності.
Моделі та процеси життєвого циклу програмного забезпечення
46
Задачами конфігурування ПС з ГОР
СПС є:
– ототожнювання вимог до ПС з
вимогами до СПС у моделі вимог до СПС
на будь-якому рівні встановлення вимог
(вимог до функцій, архітектури або ком-
понентів);
– підтримка операцій: поповнен-
ня моделі вимог, трасування вимог до ва-
ріантів існуючих ГОР всіх рівнів, поро-
дження нових варіантів архітектури та
компонентів у точках варіантності для ре-
алізації раніше не встановлених вимог до
ПС у ПрО. Ці операції мають виконувати-
ся з урахуванням обмежень ПрО;
– підтримка прийняття ефектив-
них рішень щодо розроблення нових варі-
антів ГОР через надання інформації для
проведення аналізу «витрат / переваг» з
урахуванням досвіду, накопиченого у базі
знань проектів СПС.
Керування варіабельністю СПС по-
лягає у плануванні розширення ГОР нови-
ми варіантами та контролі повноти та не-
суперечливості варіантів ГОР для потреб
СПС, а керування конфігуруванням ПС – у
наданні засобів обґрунтованого вибору уз-
годжених варіантів ГОР при побудові ПС.
Для розв’язання поставлених задач
середовище IDE має бути доповнене не
лише інформаційними структурами щодо
варіантів ГОР, функціями введення (вилу-
чення) варіантів, зіставлення між собою
варіантів одного ГОР («по горизонталі») та
варіантів ГОР різних рівнів («по вертика-
лі»), але й моделями та методами, призна-
ченими для підтримки прийняття ефектив-
них рішень розробниками СПС і ПС щодо
вибору окремих варіантів і їх композицій з
урахуванням вимог до показників якості
ПС, вартості тощо на кожному кроці побу-
дови ПС у парадигмі ГП.
Адекватне керування конфігураці-
єю СПС потребує узгодженої інтеграції до
БПР ГОР і БПР ПС відповідного процесу.
На відміну від процесу керування конфігу-
рацією одиничних ПС, який має чітко ви-
значений профіль, включаючи норматив-
но-методичну та інструментальну підтри-
мку, процес КК для СПС потребує форма-
лізації та забезпечення всіх складових
профіля [2].
Першим кроком такої формалізації
може бути розроблення формальної моделі
цього процесу (MC).
Уніфікована формалізація процесу
створення СПС
Враховуючи окреслені особливості
процесів організаційного й технічного ке-
рування при реалізації БПР ГОР та БПР
ПС, з метою їх уніфікованої формалізації
(й подальшого створення на її підставі
адекватного математичного апарату під-
тримки) пропонується наступне
Означення 1. Сімейство ПС – це
трійка
SPSt = 〈GORt, PRGt, PRCt〉, (1)
(∀ GR ∈ GORt PRGt(GR) = TRUE) ∧
∧ (∀ GR ∉ GORt PRGt(GR) = FALSE) ,
де t – довільний момент перебігу
БПР ГОР і БПР ПС;
GORt – множина ГОР станом на
момент t;
PRGt – деякий предикат приналеж-
ності до GORt, актуальний на момент t;
PRCt – специфічний предикат, акту-
альний на момент t, що визначає припус-
тимі операції композування ГОР при ство-
ренні окремих членів СПС у ході БПР ПС.
Згідно виразу (1), означення 1 сфо-
рмульоване в термінах ГОР – кінцевих
продуктів БПР ГОР. Зіставлення цього
означення з організаційною структурою
БПР ГОР і БПР ПС (див. рис. 1) та діями
процесів керування у цих БПР (див. рис. 2)
дозволяє конструктивізувати його для ПС
– кінцевих продуктів БПР ПС – за допомо-
гою
Означення 2. Сімейство ПС – це
пара
SPSt = 〈PSt, PRPt(PRGt, PRCt)〉, (2)
де PSt – множина ПС, отриманих у ході
БПР ПС, станом на момент t;
PRPt(PRGt, PRCt) – предикат прина-
лежності до PSt, актуальний на момент t,
породжений предикатами PRGt і PRCt з
означення 1.
Сформульовані означення 1 і 2 на-
дають можливостей залучення до формалі-
зації БПР ГОР і БПР ПС формалізму сі-
Моделі та процеси життєвого циклу програмного забезпечення
47
мейства процесів, розвинутого Л. Остер-
вейлом [10, 11]. Обидва БПР можуть бути
подані як сімейства взаємопов’язаних (че-
рез інформаційні об’єкти з репозитарію
IDE, див. рис. 1) уніфікованих процесів
виконання проектів розроблення відповід-
но ГОР та ПС.
Операції довільного процесу реалі-
зуються агентами з ролями, окресленими
на рис. 1 (AG), у спільному інформаційно-
му середовищі всіх процесів (EE). Врахо-
вуючи наявність у процесах керування за-
дач організаційного й технічного рівня,
доцільно, як і в роботі [11], виділити в EE
концептуальну модель ПрО БПР ГОР і
БПР ПС (O) та ретроспективу результатів
процесів створення ГОР і ПС (R). Однак,
на відміну від [11], пропонується виокре-
мити в ЕЕ також і репозитарій тих варіан-
тів ГОР, названих незалежними, жоден з
яких не може бути отриманий за допомо-
гою решти варіантів ГОР, потребуючи без-
посереднього розроблення (REPt). Роль
концептів O тоді відіграватимуть типи
ГОР і ПС, а також типи артефактів ПрО та
робочих продуктів обох БПР, які є цільо-
вими об'єктами ділових процесів організа-
ції-розробника. Варіанти ГОР, окремі ПС
та зазначені артефакти і робочі продукти
являтимуть собою екземпляри відповідних
концептів. Довільний процес виконання
проекту ГОР і ПС для створюваного СПС
SPSt (1), (2) формуватиме спеціальну стру-
ктуру знань, названу слідом процесу, яка є
формальним поданням всіх його результа-
тів. Графи, гілками яких є такі сліди, на-
звані протоколами процесу розроблення
СПС у цілому PRF(SPSt), утворюватимуть
ретроспективу R.
Остаточне подання СПС з викорис-
танням формалізму сімейства процесів,
конструктивне для розроблення методів
підтримки операцій процесів розроблення
ГОР і ПС, встановлює
Означення 3. Сімейство ПС – це
пара
SPSt = 〈EEt, CMt(PRGt, PRCt)〉, (3)
EEt = Ot ∪ Rt, ∪ REPt,
де EEt – спільне середовище перебігу
БПР ГОР і БПР ПС станом на момент t;
Ot – концептуальна модель предме-
тної області БПР ГОР і БПР ПС;
Rt – спільна ретроспектива резуль-
татів БПР ГОР і БПР ПС;
REPt – репозитарій незалежних
ГОР;
CMt(PRGt, PRCt) – модель коорди-
нації [10, 11] операцій процесів з розроб-
лення ГОР та ПС – граф, вершинами якого
є ці операції.
Зазначимо, що потреби забезпечен-
ня й постійного підвищення якості членів
СПС обумовлюють виокремлення двох
класів операцій БПР ГОР і БПР ПС. Пер-
ший складають операції розроблення, які
формують всі робочі продукти відповідних
проектів та їх кінцеві продукти разом із
структурами знань, що є їх формальними
поданнями, постійно поповнюючи репози-
тарій REPt та протокол PRF(SPSt) у складі
ретроспективи Rt. Другий клас утворений
операціями узгодженої актуалізації компо-
нентів середовища EEt з (3), предикатів
PRGt, PRCt, PRPt з (1), (2), моделі коорди-
нації CMt (3) та параметрів операцій про-
цесів за результатами розроблення ГОР і
ПС з метою вдосконалення БПР ГОР і БПР
ПС. Тому граф CMt(PRGt, PRCt) може бути
розбитий на два порівнево пов’язані під-
графи, структура першого з яких збігається
зі структурою PRF(SPSt). У свою чергу,
цей підграф також розбивається на два
підграфи, що подають склад та взаємо-
зв’язки операцій процесів виконання прое-
ктів відповідно ГОР (CMGt) та ПС (CMPt).
Запропонована структура CMt(PRGt,
PRCt) є підставою формального визначен-
ня БПР ГОР і БПР ПС (див. рис. 1) за до-
помогою
Означення 4. Моделі БПР ГОР і
БПР ПС – це трійки
MGt = 〈AGGt, EEt, CMGt〉;
MPt = 〈AGPt, EEt, CMPt〉; (4)
AGGt ∪ AGPt = AG; AGGt ∩ AGPt ⊇ ∅,
де AGGt, AGPt і AG – множини ролей аген-
тів відповідно БПР ГОР, БПР ПС і процесу
розроблення СПС.
Формалізація (4), запропонована
для БПР ГОР та БПР ПС, породжує пер-
шочергові задачі створення математичного
апарату їх адекватної підтримки, а саме:
Моделі та процеси життєвого циклу програмного забезпечення
48
– формування множин ролей аге-
нтів AGGt та AGPt ;
– встановлення складу категорій
концептів моделі Ot та формальних засобів
їх опису;
– визначення складу та взаємо-
зв’язків операцій процесів виконання про-
ектів ГОР та ПС;
– визначення формальних подань
для слідів процесів та протоколів розроб-
лення PRF(SPSt);
– визначення типів незалежних
ГОР у репозитарії REPt та формальних за-
собів їх опису;
– формування моделей координа-
ції БПР ГОР (CMGt), БПР ПС (CMPt) з (4)
та CMt з (3);
– розроблення методів виконання
визначених операцій процесів виконання
проектів ГОР та ПС.
Висновки
Звертання до інженерії СПС надає
організаціям-розробникам низку переваг,
зокрема, зниження вартості та ризику про-
ектів окремих ПС – членів СПС, постійне
підвищення кваліфікації співробітників та
вдосконалення процесу розроблення і його
продуктів (через повторне використання
набутого досвіду стосовно ПрО у вигляді
ГОР і вдалих рішень у СПС), стимулюван-
ня еволюції СПС (через задоволення по-
треб у ПС з новими властивостями).
Однак реалізація наведених переваг
потребує створення адекватного матема-
тичного апарату підтримки процесу розро-
блення СПС. З цією метою висвітлено його
внутрішню структуру верхнього рівня, по-
дану трійкою: базові процеси розроблення
ГОР і ПС та процес керування конфігура-
цією, що “узгоджує” їх для досягнення
згаданих переваг. Тому поряд із традицій-
ними функціями з керування версіями ПС
згідно ISO/IEC 12207, на нього поклада-
ються також і нові функції:
− формування єдиного інформа-
ційного середовища ефективної комуніка-
ції агентів процесів розроблення ГОР і ПС;
− підтримка інформаційного обмі-
ну між операціями цих процесів;
− створення умов підвищення ефе-
ктивності індивідуальної й колективної
діяльності цих агентів у сформованому се-
редовищі;
− накопичення й ефективне вико-
ристання досвіду процесів розроблення
ГОР і ПС для їх постійного вдосконалення.
Їх підтримка обумовлює виокремлення у
керуванні конфігурацією нового процесу
керування варіантами ГОР, СПС і ПС та
його інтеграцію до процесів керування
проектами ГОР і ПС.
Сформульовано специфічні задачі
цих процесів з керування версіями й варіа-
нтами ГОР, СПС і ПС.
Для їх розв’язання базові процеси
розроблення ГОР і ПС та процес керуван-
ня конфігурацією подано як сімейства уні-
фікованих процесів виконання проектів
ГОР і ПС, здійснюваних у спільному інфо-
рмаційному середовищі згідно єдиної мо-
делі координації їх операцій агентами із
відповідними ролями. У середовищі виді-
лено три компоненти верхнього рівня:
концептуальну модель ПрО цих БПР, рет-
роспективу їх результатів та репозитарій
незалежно створюваних ГОР.
На підставі запропонованої форма-
лізації процесу розроблення СПС надано
методологічне ядро формованого матема-
тичного апарату його підтримки у складі
базових означень СПС, конструктивних
для створення методів підтримки його
операцій, та першочергових задач конкре-
тизації цих означень.
Запропонована формалізація СПС
та базового процесу розроблення СПС на-
дає можливостей інтеграції до нього про-
цесу експертного оцінювання [11]. В ре-
зультаті переваги останнього – підвищен-
ня формалізованої обґрунтованості рішень
та створення умов підвищення ефективно-
сті діяльності агентів – поширюються на
розроблення СПС.
1. Лавріщева К.М. Генерувальне програму-
вання програмних систем і їх сімейств //
Проблеми програмування. – 2009.– № 1. –
С. 3 – 16.
2. Лавріщева К.М, .Коваль Г.І., Коротун Т.М.
Підходи інженерії якості сімейств про-
грамних систем // Проблеми програму-
вання. – 2008. – № 2-3. – С. 219 – 228.
3. Основы инженерии качества программных
систем / Ф.И. Андон, Г.И. Коваль, Т.М.
Моделі та процеси життєвого циклу програмного забезпечення
49
Коротун, Е.М. Лаврищева, В.Ю. Суслов //
2-е издание. – Киев.: Академпериодика,
2007. – 672 с.
4. Czarnecki K., Helsen S. Classification of
Model Transformation Approaches –
http://www.swen. uwaterloo. Ca /~ kczarnec /
gsdoverview. pdf
5. Framework for Software Product Line Prac-
tice, version 5 – http: // www. sei. cmu. Edu /
productlines / index.html
6. Czarnecki K., Helsen S., Eisenecker U. Staged
configuration through specialization and
multi-level configuration of feature models //
Software Process Improvement and Practice.
– 2005.– N 10. – P. 143 – 169. –
http://swen.uwaterloo.ca/~kczar
nec/spip05b.pdf
7. Software Process Engineering Metamodel
Specification (SPEM), version 1.1 // OMG,
January 2005 – http: // www. omg. Org / docs
/formal/ 05-01-06.pdf
8. Zubrow D., Chastek G. Measures for Software
Product Lines (CMU/SEI-2003-TN-031) –
http://www.sei.cmu.edu/pub/documents/03.re
ports/pdf/03tn031.pdf
9. Variant Configuration of Software Systems
(PESOA-Report N. 06/2004) – http: // www.
pesoa. de / pages / Publications / Fachberichte
022004 / PESOA_TR_6-2004 % 20 Variant
% 20 Configuration % 20 of % 2 0Software %
20 Systems. pdf
10. Osterweil L.J. et al. Representing Process
Variation with a Process Family // Q. Wang,
D. Pfahl, D.M. Raffo (Eds.): Software Process
Dynamics and Agility, International Conf. on
Software Process, ICSP 2007, Minneapolis,
MN, USA, May 19– 20, 2007, Proceedings. –
P. 109 – 120. – http: // laser. cs. umass. Edu /
techreports/07-13.pdf
11. Лаврищева Е.М., Слабоспицкая О.А. Под-
ход к экспертному оцениванию в про-
граммной инженерии // Кибернетика и
системный анализ. – 2009. – № 4. –
С. 151 – 168.
Отримано 05.05.2009
Про авторів:
Лавріщева Катерина Михайлівна,
доктор фізико-математичних наук,
професор, завідуюча відділом,
Коваль Галина Іванівна,
кандидат фізико-математичних наук,
старший науковий співробітник відділу,
Слабоспицька Ольга Олександрівна,
кандидат фізико-математичних наук,
старший науковий співробітник відділу,
Колєснік Андрій Леонідович,
аспірант ІПС НАН України,
Місце роботи авторів:
Інститут програмних систем НАН України
03187, Київ-187,
Проспект Академіка Глушкова, 40.
Тел.: (044) 526 3470; (044) 526 4579.
e-mail: lem@isofts.kiev.ua
g.koval@ekotex.ua
ols07@mail.ru
a-kolesnik@hotmail.com
|
| id | nasplib_isofts_kiev_ua-123456789-4596 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Ukrainian |
| last_indexed | 2025-12-07T16:21:29Z |
| publishDate | 2009 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Лавріщева, К.М. Коваль, Г.І. Слабоспицька, О.О. Колєснік, А.Л. 2009-12-08T11:43:31Z 2009-12-08T11:43:31Z 2009 Особливості процесів керування при створенні сімейств програмних систем. / К.М. Лавріщева, Г.І. Коваль, О.О. Слабоспицька, А.Л. Колєснік // Пробл. програмув. — 2009. — № 3. — С. 40-49. — Бібліогр.: 11 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/4596 681.3.06 Розглянуто особливості процесів керування в інженерії сімейств програмних систем (СПС), зокрема, нові функції процесу керування конфігурацією, який інтегрований з базовим процесом розроблення (БПР) готових ресурсів та БПР ПС і узгоджує їх виконання. Запропоновано формалізацію СПС і БПР СПС із залученням формалізму сімейства процесів та надано методологічне ядро математичного апарата його підтримки. Рассмотрены особенности процессов управления в инженерии семейств программных систем (СПС), в частности новые функции процесса управления конфигурацией, который интегрирован с базовым процессом разработки (БПР) готовых ресурсов и БПР ПС и согла-совывает их выполнение. Предложена формализация СПС и БПР СПС с привлечением формализма семейства процессов и определено методологическое ядро математического аппарата его поддержки Specialities of management processes in software systems families (SSF) engineering are considered, in particular new functions of software configuration management process, integrated with the core assets base development process (BDP) and SS BDP, and coordinated their implementation. The formalization of SSF and SSF BDP based on formalism of processes family is offered, and a methodological kernel of mathematical theory of his support is given uk Інститут програмних систем НАН України Моделі та процеси життєвого циклу програмного забезпечення Особливості процесів керування при створенні сімейств програмних систем Особенности процессов управления при создании семейств программных систем Specialities of management processes in case of software systems families creation Article published earlier |
| spellingShingle | Особливості процесів керування при створенні сімейств програмних систем Лавріщева, К.М. Коваль, Г.І. Слабоспицька, О.О. Колєснік, А.Л. Моделі та процеси життєвого циклу програмного забезпечення |
| title | Особливості процесів керування при створенні сімейств програмних систем |
| title_alt | Особенности процессов управления при создании семейств программных систем Specialities of management processes in case of software systems families creation |
| title_full | Особливості процесів керування при створенні сімейств програмних систем |
| title_fullStr | Особливості процесів керування при створенні сімейств програмних систем |
| title_full_unstemmed | Особливості процесів керування при створенні сімейств програмних систем |
| title_short | Особливості процесів керування при створенні сімейств програмних систем |
| title_sort | особливості процесів керування при створенні сімейств програмних систем |
| topic | Моделі та процеси життєвого циклу програмного забезпечення |
| topic_facet | Моделі та процеси життєвого циклу програмного забезпечення |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/4596 |
| work_keys_str_mv | AT lavríŝevakm osoblivostíprocesívkeruvannâpristvorennísímeistvprogramnihsistem AT kovalʹgí osoblivostíprocesívkeruvannâpristvorennísímeistvprogramnihsistem AT slabospicʹkaoo osoblivostíprocesívkeruvannâpristvorennísímeistvprogramnihsistem AT kolêsníkal osoblivostíprocesívkeruvannâpristvorennísímeistvprogramnihsistem AT lavríŝevakm osobennostiprocessovupravleniâprisozdaniisemeistvprogrammnyhsistem AT kovalʹgí osobennostiprocessovupravleniâprisozdaniisemeistvprogrammnyhsistem AT slabospicʹkaoo osobennostiprocessovupravleniâprisozdaniisemeistvprogrammnyhsistem AT kolêsníkal osobennostiprocessovupravleniâprisozdaniisemeistvprogrammnyhsistem AT lavríŝevakm specialitiesofmanagementprocessesincaseofsoftwaresystemsfamiliescreation AT kovalʹgí specialitiesofmanagementprocessesincaseofsoftwaresystemsfamiliescreation AT slabospicʹkaoo specialitiesofmanagementprocessesincaseofsoftwaresystemsfamiliescreation AT kolêsníkal specialitiesofmanagementprocessesincaseofsoftwaresystemsfamiliescreation |