Т.С.П.П / Махинации с ТСПП / ТСПП / Іспит / опорные конспекты / Лекція 6 y оп

Лекція 6:

Тема: Програмні засоби підтримки життєвого циклу ПЗ. Методологія DATARUN.

План:

1. Методології проектування ПЗ як програмних продуктів.

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

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

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

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

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

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

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

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

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

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

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

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

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

• модель ІС.

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

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

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

Мал. 1. Модель ІС

Підхід DATARUN переслідує дві цілі:

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

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

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

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

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

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

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

BPM (Business Process Model) - модель бизнес-процессов. PDS (Primary Data Structure) - структура первинних даних. CDM (Conceptual Data Model) - концептуальна модель даних. SPM (System Process Model) - модель процесів системи. ISA (Information System Architecture) - архітектура інформаційної системи. ADM (Application Data Model) - модель даних застосування. IPM (Interface Presentation Model) - модель представлення інтерфейсу. ISM (Interface Specification Model) - модель специфікації інтерфейсу.

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

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

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

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

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

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

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

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

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

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

Контрольні питання:

1. Дати визначення методології DATARUN.

2. Стадії методології DATARUN

3. На які дві моделі спирається методологія DATARUN.

4. Які цілі переслідує підхід DATARUN.

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

Література:

1. Левин В.И .История информационных технологий. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру », БИНОМ. Лаборатория знаний ». Серия: Основы информационных технологий », 2007 - 336 стр.

2. Галатенко В.А., Основы информационной безопасности. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру » Серия: Основы информационных технологий »,2008 - 208 стр.

3. Терехов А.Н. Технология программирования, БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2007

4. Скопин И.Н. Интернет-университет информационных технологий - ИНТУИТ.ру, 2004

5. Котляров В.П. Основы тестирования программного обеспечения. Интернет-университет информационных технологий - ИНТУИТ.ру, 2006

4