Контрольная работа: Життєвий цикл інформаційної системи

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

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

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

життєвий цикл інформаційна система

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

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

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

— невелику команду програмістів (від 2 до 10 чоловік);

— короткий, але ретельно пророблений виробничий графік (від 2 до 6 мес.);

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

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

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

· фаза аналізу й планування вимог;

· фаза проектування;

· фаза побудови;

· фаза впровадження.

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

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

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

· загальна інформаційна модель системи;

· функціональні моделі системи в цілому й підсистем, реалізованих окремими командами розроблювачів;

· точно визначені за допомогою CASE-засобу інтерфейси між автономно розроблювальними підсистемами;

· побудовані прототипи екранів, звітів, діалогів.

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

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

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

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

· визначається необхідність розподілу даних;

· здійснюється аналіз використання даних;

· здійснюється фізичне проектування бази даних;

· визначаються вимоги до апаратних ресурсів;