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

Методології проектування програмного забезпечення як програмні продукти. Методологія DATARUN та інструментальне засіб SE Companion

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

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

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

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

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

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

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

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

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

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

Методологія DATARUN спирається на дві моделі або на два подання:  модель організації;  модель ІС.

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

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

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

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

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

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

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

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

Рис. 3.2. Це автоматизоване проектування системи

· BPM ( B usiness P rocess M odel) - модель бізнес-процесів.
PDS ( P rimary D ata S tructure) - структура первинних даних.
CDM ( C onceptual D ata M odel) - концептуальна модель даних.
SPM ( S ystem P rocess M odel) - модель процесів системи.
ISA ( I nformation S ystem A rchitecture) - архітектура інформаційної системи.
ADM ( A pplication D ata M odel) - модель даних додатки.
IPM ( I nterface P resentation M odel) - модель представлення інтерфейсу.
ISM ( I nterface S pecification M odel) - модель специфікації інтерфейсу.

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

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

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

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

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

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

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

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

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

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

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

Інструментальне засіб SE Companion [27] є середовищем, в якому реалізований електронний варіант методології DATARUN. Воно дозволяє:  створити гіпертекстове опис методології у вигляді ієрархії      опису стадій, етапів і операцій розробки;  створити гіпертекстове опис усіх методів та методик реалізації      процесів ЖЦ ПЗ;  виділити з гіпертекстового опису ієрархію процесів ЖЦ ПЗ для      планування та управління процесом створення ПЗ (ієрархію робіт);  змінювати гіпертекстові опису ЖЦ і методів так, як це      необхідно розробнику, іншими словами, проводити авторизацію      методології і відслідковувати ці зміни в ієрархії робіт, призначеної      для управління проектом;  прив'язати до процесів ЖЦ інструментальні засоби підтримки цих      процесів і забезпечити виклик інструментальних засобів з відповідних      екранів гіпертекстового довідника;  забезпечити перегляд гіпертекстових екранів опису використовуваних      методів з інструментальних засобів;  забезпечити підтримку процесу управління розробкою, зокрема,      за рахунок взаємодії із засобом планування робіт MS Project,      оцінювання трудомісткості проекту, відстеження виконання робіт, створення      графіків робіт, та ін

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

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

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

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

Мінімальна конфігурація апаратно-програмних засобів, необхідних SE Companion Authoring Tool:  процесор: i486/33;  оперативна пам'ять: 4 Mбайт для перегляду гіпертексту, 12 Mбайт      для авторизації;  дискова пам'ять: 20 Мбайт;  операційні середовища: Microsoft Windows 3.1, Microsoft Windows for      Workgroups 3.11, Microsoft Windows NT 3.5, Microsoft Windows 95. CASE-засоби. Загальна характеристика та класифікація

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

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

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

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

Інтегроване CASE-засіб (або комплекс засобів, що підтримують повний ЖЦ ПЗ) містить наступні компоненти;  сховище, що є основою CASE-засоби. Він повинен      забезпечувати зберігання версій проекту і його окремих компонентів,      синхронізацію надходження інформації від різних розробників при      групової розробки, контроль метаданих на повноту і несуперечність;        графічні засоби аналізу і проектування, що забезпечують      створення і редагування ієрархічно пов'язаних діаграм (DFD, ERD і      ін), що утворюють моделі ІС;  засоби розробки додатків, включаючи мови 4GL і генератори      кодів;  кошти конфігураційного управління;  засоби комунікації;  засоби тестування;  засоби управління проектом;  засоби реінжинірингу.

Вимоги до функцій окремих компонент у вигляді критеріїв оцінки CASE-засобів наведені в розділі 4.2.

Всі сучасні CASE-засоби можуть бути класифіковані в основному за типами та категоріями. Класифікація за типами відображає функціональну орієнтацію CASE-засобів на ті чи інші процеси ЖЦ. Класифікація за категоріями визначає ступінь інтегрованості по виконуваних функцій і включає окремі локальні засоби, вирішальні невеликі автономні завдання (tools), набір частково інтегрованих засобів, що охоплюють більшість етапів життєвого циклу ІС (toolkit) і повністю інтегровані засоби, що підтримують весь ЖЦ ІВ і пов'язані спільним репозиторієм. Крім цього, CASE-засоби можна класифікувати за такими ознаками:  застосовуваних методологій та моделями систем і БД;  ступеня інтегрованості з СУБД;  доступним платформ.

Класифікація за типами в основному збігається з компонентним складом CASE-засобів і включає наступні основні типи:  засоби аналізу (Upper CASE), призначені для побудови та      аналізу моделей предметної області (Design/IDEF (Meta Software), BPwin      (Logic Works));  засоби аналізу і проектування (Middle CASE), що підтримують      найбільш поширені методології проектування і що використовується для      створення проектних специфікацій (Vantage Team Builder (Cayenne),      Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas),      CASE.Аналітік (МакроПроджект)). Виходом таких засобів є специфікації      компонентів і інтерфейсів системи, архітектури системи, алгоритмів і      структур даних;  засоби проектування баз даних, що забезпечують моделювання      даних і генерацію схем баз даних (як правило, на мові SQL) для      найбільш поширених СУБД. До них відносяться ERwin (Logic Works),      S-Designor (SDP) і DataBase Designer (ORACLE). Засоби проектування баз      даних є також у складі CASE-засобів Vantage Team Builder,      Designer/2000, Silverrun і PRO-IV;  засоби розробки додатків. До них відносяться засоби 4GL      (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000      (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) тощо)      і генератори кодів, що входять до складу Vantage Team Builder, PRO-IV і      частково - у Silverrun;  кошти реінжинірингу, що забезпечують аналіз програмних кодів і      схем баз даних і формування на їх основі різних моделей і проектних      специфікацій. Засоби аналізу схем БД і формування ERD входять до складу      Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin і      S-Designor. В області аналізу програмних кодів найбільшого поширення      отримують об'єктно-орієнтовані CASE-засоби, що забезпечують      реінжиніринг програм на мові С + + (Rational Rose (Rational Software),      Object Team (Cayenne)).

Допоміжні типи включають:  засоби планування і управління проектом (SE Companion,      Microsoft Project та ін);  кошти конфігураційного управління (PVCS (Intersolv));  засоби тестування (Quality Works (Segue Software));  засоби комунікації (SoDA (Rational Software)).

На сьогоднішній день Російський ринок програмного забезпечення в своєму розпорядженні наступними найбільш розвиненими CASE-засобами:  Vantage Team Builder (Westmount I-CASE);  Designer/2000;  Silverrun;  ERwin + BPwin;  S-Designor;  CASE.Аналітік.

Опис перерахованих CASE-засобів наведено в розділі 5. Крім того, на ринку постійно з'являються як нові для вітчизняних користувачів системи (наприклад, CASE/4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так і нові версії і модифікації перерахованих систем. Література  Вендров А.М. Один з підходів до вибору засобів проектування баз      даних і додатків. "СУБД", 1995, № 3.  Зіндера Е.З. Бізнес-реінжиніринг і технології системного      проектування. Навчальний посібник. М., Центр Інформаційних Технологій, 1996        Калянов Г.М. CASE. Структурний системний аналіз (автоматизація та      застосування). М., "Лорі", 1996.  Марка Д.А., МакГоуен К. Методологія структурного аналізу і      проектування. М., "МетаТехнологія", 1993.  Міжнародні стандарти, що підтримують життєвий цикл програмних      коштів. М., МП "Економіка", 1996  Створення інформаційної системи підприємства. "Computer      Direct ", 1996, N2  Шлеер С., Меллор С. Об'єктно-орієнтований аналіз: моделювання      світу в станах. Київ, "Діалектика", 1993.  Barker R. CASE * Method. Entity-Relationship Modelling. Copyright      Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.  Barker R. CASE * Method. Function and Process Modelling. Copyright      Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.  Boehm B.W. A Spiral Model of Software Development and Enhancement.      ACM SIGSOFT Software Engineering Notes, Aug. 1986  Chris Gane, Trish Sarson. Structured System Analysis.      Prentice-Hall, 1979.