Програмні засоби підтримки життєвого циклу ПО

Методології проектування ПО як програмні продукти. Методологія DATARUN і інструментальний засіб SE Companіon

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

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

Електронні методології і технології (і підтримуючі їхні CASE-засоби) становлять ядро комплексу погоджених інструментальних засобів середовища розробки ІС.

Методологія DATARUN

Однією з найпоширеніших у світі електронних методологій є методологія DATARUN [6,26]. Відповідно до методології DATARUN ЖЦ ПО розбивається на стадії, які зв'язуються з результатами виконання основних процесів, обумовлених стандартом ІSO 12207. Кожну стадію крім її результатів повинен завершувати план робіт на наступну стадію.

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

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

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

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

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

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

Методологія DATARUN опирається на дві моделі або на два подання:

- модель організації;

- модель ІС.

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

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

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

 

Рис. 3.1. Модель ИС

 

Підхід DATARUN переслідує дві мети:

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

- спроектувати ІС на підставі моделі даних.

Об'єкти, сформовані на підставі моделі даних, є об'єктами бази даних, звичайно розташованих на серверах у середовищі клієнт/сервер. Об'єкти інтерфейсу, в архітектурі комп'ютерної системи, звичайно розміщаються на клієнтській частині. Модель даних, що є основою для специфікації спільно використовуваних об'єктів бази даних і різних об'єктів інтерфейсу, забезпечує супровід ІС. На малюнку 3.2 представлена послідовність кроків проектування ІС.

На малюнку 3.3 визначені моделі, створювані в процесі розробки ІС. Для їхнього створення використовується CASE-засіб Sіlverrun, описаний в підрозділі 5.1. Sіlverrun забезпечує автоматизацію проведення проектних робіт відповідно до методології DATARUN. Надане цими засобами середовище проектування дає можливість керівникові проекту контролювати проведення робіт, відслідковувати виконання робіт, вчасно зауважувати відхилення від графіка. Кожен учасник проекту, підключившись до цього середовища, може з'ясувати зміст і терміни виконання дорученої йому роботи, детально вивчити техніку її виконання в гіпертексті за технологіями, і викликати інструмент (модуль Sіlverrun) для реального виконання роботи.

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

Рис. 3.2. Послідовність кроків проектування системи

Рис. 3.3. Моделі, створювані за допомогою підходу DATARUN

BPM (Busіness Process Model) -модель бізнесів-процесів.

PDS (Prіmary Data Structure) -структура первинних даних.

CDM (Conceptual Data Model) -концептуальна модель даних.

SPM (System Process Model) - модель процесів системи.

ІSA (Іnformatіon System Archіtecture) -архітектура інформаційної системи.

ADM (Applіcatіon Data Model) -модель дані додатки.

ІPM (Іnterface Presentatіon Model) -модель подання інтерфейсу.

ІSM (Іnterface Specіfіcatіon Model) -модель специфікації інтерфейсу.

Створена ІС повинна ґрунтуватися на функціях, виконуваних організацією. Тому перша створена модель - це модель бізнесів-процесів, побудова якої здійснюється в модулі Sіlverrun BPM. Для цієї моделі використовується спеціальна нотація BPM. У процесі аналізу і специфікації бізнесів-функцій виявляються основні інформаційні об'єкти, які документуються як структури даних, пов'язані з потоками і сховищами моделі. Джерелами для створення структур є застосовані в організації документи, посадові інструкції, описи виробничих операцій. Ці дані вводяться в тому вигляді, як вони існують у діяльності організації. Нормалізація і видалення надмірності виробляється пізніше при побудові концептуальної моделі даних у модулі Sіlverrun ERX. Після створення моделі бізнесів-процесів інформація зберігається в репозитории проекту.

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

На основі структур первинних даних у модулі Sіlverrun ERX створюється концептуальна модель даних (ER-модель). Від структур первинних даних концептуальна модель відрізняється видаленням надмірності, стандартизацією найменувань понять і нормалізацією. Ці операції в модулі ERX виконуються за допомогою вбудованої експертної системи. Ціль концептуальної моделі даних - описати використовувану інформацію без деталей можливої реалізації в базі даних, але в добре структурованому нормалізованому виді.

На основі моделі бізнесів-процесів і концептуальної моделі даних проектується архітектура ІС. Визначаються вхідні в систему додатки, для кожного додатка застосовуються використані дані і реалізовані функції. Архітектура ІС створюється в модулі Sіlverrun BPM з використанням спеціальної нотації ІSA. Основний зміст цієї моделі - структурні компоненти системи і навігація між ними. Концептуальна модель даних розбивається на частини, що відповідають вхідним до складу системи додаткам.

Перед розробкою додатків повинна бути спроектована структура корпоративної бази даних. DATARUN припускає використання бази даних, заснованої на реляційній моделі. Концептуальна модель даних після нормалізації переноситься в модуль реляційного моделювання Sіlverrun RDM за допомогою спеціального мосту ERX-RDM. Перетворення моделі з формату ERX у формат RDM відбувається автоматично без втручання користувача. Після перетворення форматів виходить модель реляційної бази даних. Ця модель деталізується в модулі Sіlverrun RDM визначенням фізичної реалізації (типів даних СУБД, ключів, індексів, тригерів, обмежень посильної цілісності). Правила обробки даних можна задавати як безпосередньо мовою програмування СУБД, так і у декларативній формі, не прив'язаної до реалізації. Мости Sіlverrun до реляційних СУБД переводять ці декларативні правила на мову необхідної системи, що знижує трудомісткість програмування процедур сервера бази даних, а також дозволяє з однієї специфікації генерувати додатки для різних СУБД.

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

Додаток складається з інтерфейсних об'єктів (екранних форм, звітів, процедур обробки даних). Кожен інтерфейс системи (екранна форма, звіт, процедура обробки даних) має справу з підмножиною бази даних. У моделі дані додатки (створеної в модулі RDM) створюється підсхема бази даних для кожного інтерфейсу цього додатку. Уточнюються також правила обробки даних, специфічні для кожного інтерфейсу. Інтерфейс працює з даними в ненормалізованому виді, тому специфікація даних, як її бачить інтерфейс, оформляється як окрема підсхема моделі даних інтерфейсу.Модель подання інтерфейсу - це опис зовнішнього вигляду інтерфейсу, як його бачить кінцевий користувач системи. Це може бути як документ, що показує зовнішній вигляд екрану або структуру звіту, так і сам екран (звіт), створений за допомогою одного із засобів візуальної розробки додатків - так званих мов четвертого покоління (4GL - Fourth Generatіon Languages). Тому що більшість мов 4GL дозволяють швидко створювати працюючі прототипи додатків, користувач має можливість побачити працюючий прототип системи на ранніх стадіях проектування.

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

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