Проектування інформаційних систем
СОДЕРЖАНИЕ: Поняття методології проектування інформаційних систем та життєвого циклу їх програмного забезпечення. Основні, допоміжні та організаційні процеси структури життєвого циклу. Планування та організації робіт по розробці і супроводу програмного забезпечення.Життєвий цикл по ІС
Одним з базових понять методології проектування ІС є поняття життєвого циклу її програмного забезпечення (ГЦ ПЗ). ЖЦ ПЗ - це безперервний процес, який починається з моменту ухвалення рішення про необхідність його створення і закінчується у момент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.
Структура ЖЦ ПО за стандартом ISO/IEC 12207 базується на трьох групах процесів:
-основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);
-допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);
-організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка і поліпшення самого ЖЦ, навчання).
Розробка включає всі роботи із створення ПЗ і його компонент відповідно до заданих вимог, включаючи оформлення проектної і експлуатаційної документації, підготовку матеріалів, необхідних для перевірки працездатності і відповідної якості програмних продуктів, матеріалів, необхідних для організації навчання персоналу і т.д. Розробка ПЗ включає, як правило, аналіз, проектування і реалізацію (програмування).
Експлуатація включає роботи по впровадженню компонентів ПЗ в експлуатацію, зокрема конфігурацію бази даних і робочих місць користувачів, забезпечення експлуатаційною документацією, проведення навчання персоналу і т.д., і безпосередньо експлуатацію, зокрема локалізацію проблем і усунення причин їх виникнення, модифікацію ПЗ в рамках встановленого регламенту, підготовку пропозицій по вдосконаленню, розвитку і модернізації системи.
Управління проектом повязане з питаннями планування і організації робіт, створення колективів розробників і контролю за термінами і якістю виконуваних робіт. Технічне і організаційне забезпечення проекту включає вибір методів і інструментальних засобів для реалізації проекту, визначення методів опису проміжних станів розробки, розробку методів і засобів випробувань ПЗ, навчання персоналу і т.п. Забезпечення якості проекту повязане з проблемами верифікації, перевірки і тестування ПЗ. Верифікація - це процес визначення того, чи відповідає поточний стан розробки, досягнутий на даному етапі, вимогам цього етапу. Перевірка дозволяє оцінити відповідність параметрів розробки з початковими вимогами. Перевірка частково співпадає з тестуванням, яке повязане з ідентифікацією відмінностей між дійсними і очікуваними результатами і оцінкою відповідності характеристик НА початкові вимоги. В процесі реалізації проекту важливе місце займають питання ідентифікації, опису і контролю конфігурації окремих компонентів і всієї системи в цілому.
Управління конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, перш за все процеси розробки і супроводу ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожний з яких може мати різновиди або версії, виникає проблема обліку їх звязків і функцій, створення уніфікованої структури і забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати і контролювати внесення змін до ПЗ на всіх стадіях ЖЦ. Загальні принципи і рекомендації конфігураційного обліку, планування і управління конфігураціями ПЗ відбиті в проекті стандарту ISO 12207-2.
Кожен процес характеризується певними завданнями і методами їх рішення, початковими даними, одержаними на попередньому етапі, і результатами. Результатами аналізу, зокрема, є функціональні моделі, інформаційні моделі і відповідні їм діаграми. ЖЦ ПЗ носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, вироблених на попередніх етапах.
Моделі життєвого циклу ПЗ
Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання і взаємозвязку процесів, дій і завдань, що виконуються впродовж ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси. До теперішнього часу найбільшого поширення набули наступні дві основні моделі ЖЦ:
- каскадна модель (70-85 г.г.);
- спіральна модель (86-90 г.г.).
У спочатку існуючих однорідних ІС кожне застосування було єдине ціле. Для розробки такого типу застосувань застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (Рис. 2.1). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Позитивні сторони застосування каскадного підходу полягають в наступному:
- на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;
- виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Рис. 2.1. Каскадна схема розробки ПЗ
Каскадний підхід добре зарекомендував себе при побудові ІС, для яких на самому початку розробки можна достатньо точно і повно формулювати всі вимоги, з тим щоб надати розробникам свободу реалізувати їх якнайкраще з технічної точки зору. У цю категорію потрапляють складні розрахункові системи, системи реального часу і інші подібні завдання. Проте, в процесі використання цього підходу виявився ряд його недоліків, викликаних перш за все тим, що реальний процес створення ПЗ ніколи повністю не укладався в таку жорстку схему. В процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень. В результаті реальний процес створення ПЗ приймав наступний вигляд (Рис. 2.2):
Рис. 2.2. Реальний процес розробки ПЗ по каскадній схемі
Основним недоліком каскадного підходу є істотне запізнювання з отриманням результатів. Узгодження результатів з користувачами проводиться тільки в крапках, що плануються після завершення кожного етапу робіт, вимоги до ІС заморожені у вигляді технічного завдання на весь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена. У разі неточного викладу вимог або їх зміни протягом тривалого періоду створення ПЗ, користувачі одержують систему, що не задовольняє їх потребам. Моделі (як функціональні, так і інформаційні) обєкту, що автоматизується, можуть застаріти одночасно з їх твердженням.
Для подолання перерахованих проблем була запропонована спіральна модель ЖЦ (Рис. 2.3), що робить упор на початкові етапи ЖЦ: аналіз і проектування. На цих етапах реалізовується технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Таким чином заглиблюються і послідовно конкретизуються деталі проекту і в результаті вибирається обґрунтований варіант, який доводиться до реалізації.
Розробка ітераціями відображає обєктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. При ітеративному способі розробки бракуючу роботу можна буде виконати на наступній ітерації. Головне ж завдання - щонайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення і доповнення вимог.
Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її вирішення необхідно ввести тимчасові обмеження на кожний з етапів життєвого циклу. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, одержаних в попередніх проектах, і особистого досвіду розробників.
Рис 2.3. Спіральна модель ЖЦ
Використана література
1. Горін С.В., Тандоєв А.Ю. Застосування CASE-засобу Erwin 2.0 для інформаційного моделювання в системах обробки даних. СУБД, 1995 №3.
2. Горчинськая О.Ю. Designer/2000 - нове покоління CASE-продуктів фірми ORACLE. СУБД, 1995 №3.
3. Зіндер Е.З. Бізнес-рєїнжінірінг і технології системного проектування. Навчальний посібник. М., Центр Інформаційних Технологій, 1996
4. Калянов Г.Н. CASE. Структурний системний аналіз (автоматизація і застосування). М., Лорі, 1996.
5. Марка Д.А., МакГоуен К. Методология структурного аналізу і проектування. М., МетаТехнология, 1993.