1. Моделі життєвого циклу розробки ІС Під моделлю ЖЦ розуміється структура, що визначає послідовність...

Моделі життєвого циклу розробки ІС

Наше деловое партнерство www.banwar.org

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

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

До теперішнього часу найбільшого поширення набули наступні основні моделі ЖЦ:

• Задачного модель;
• каскадна модель (або системна) (70-85 р г.);
• спіральна модель (теперішній час).

задачного модель

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

• Крайня терміновість (треба щоб хоч якось завдання вирішувалися; потім доведеться все зробити заново);
• Експеримент і адаптація замовника (не ясні алгоритми, рішення намацуються методом проб і помилок).

Загальний висновок: досить велику ефективну ІС таким способом створити неможливо.

каскадна модель

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

Позитивні сторони застосування каскадного підходу полягають в наступному [2]:

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

Мал. 1. Каскадна схема розробки

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

Мал. 1.2. Реальний процес розробки ПО по каскадної схемою

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

спіральна модель

Для подолання перелічених проблем була запропонована спіральна модель ЖЦ [1] (рис. 3), що робить упор на початкові етапи ЖЦ: аналіз і проектування. На цих етапах реалізація технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Таким чином, поглиблюються і послідовно конкретизуються деталі проекту і в результаті вибирається обгрунтований варіант, який доводиться до реалізації.

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

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

Рис 3. Спіральна модель ЖЦ ІС

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є що отримала останнім часом широкого поширення методологія швидкої розробки додатків RAD (Rapid Application Development). Під цим терміном зазвичай розуміється процес розробки ПЗ, що містить 3 елементи:

• невелику команду програмістів (від 2 до 10 осіб);
• короткий, але ретельно пророблений виробничий графік (від 2 до 6 міс.);
• повторюваний цикл, при якому розробники, у міру того, як додаток починає набувати форму, запитують і реалізують у продукті вимоги, отримані через взаємодію з замовником.

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

• фаза визначення вимог і аналізу;
• фаза проектування;
• фаза реалізації;
• фаза впровадження.

Послідовність етапів створення ІС на фазі визначення вимог і аналізу:

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

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

Результатами проектування архітектури є:

• модель процесів (діаграми архітектури системи (SAD) і миниспецификации на структурованому мовою);
• модель даних (ERD і підсхеми ERD);

модель користувальницького інтерфейсу (класифікація процесів на інтерактивні та Неінтерактивні функції, діаграма послідовності форм (FSD - Form Sequence Diagram), що показує, які форми з'являються в додатку і в якому порядку. На FSD фіксується набір і структура викликів екранних форм. Діаграми FSD утворюють ієрархію, на вершині якої знаходиться головна форма програми, що реалізує підсистему. на другому рівні знаходяться форми, що реалізують процеси нижнього рівня функціональної структури, зафіксованої на діаграмах SAD.

література

1. CASE-технології. Сучасні методи і засоби проектування інформаційних систем А.М. Вендров, "Argussoft Co" .

2. Марка Д.А., Мак Гоуен К. Методологія структурного аналізу і проектування. М., "МетаТехнологія", 1993.

3. Міжнародні стандарти, що підтримують життєвий цикл програмних засобів. М., МП "Економіка", 1996

Останнє оновлення 09.04.