Життєвий цикл інформаційної системи
Контрольная работа - Компьютеры, программирование
Другие контрольные работы по предмету Компьютеры, программирование
о етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (Рис.1).
Рис. 1.1. Каскадна схема життєвого циклу ПЗ
Кожний етап завершується випуском повного комплекту документації, достатнього для того, щоб розробка могла бути продовжена іншою командою розроблювачів.
Позитивні сторони застосування каскадного підходу полягають у наступному:
- на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти й погодженості;
- виконувані в логічній послідовності етапи робіт дозволяють планувати строки завершення всіх робіт і відповідні витрати.
Каскадний підхід добре зарекомендував себе при побудові ІС, для яких на самому початку розробки можливо досить точно й повно сформулювати всі вимоги, для того щоб розроблювачі реалізували їх якнайкраще з технічної точки зору. У цю категорію попадають складні розрахункові системи, системи реального часу й інші подібні задачі.
Однак, у процесі використання цього підходу виявився ряд його недоліків, викликаних насамперед тим, що реальний процес створення ПЗ ніколи повністю не укладався в таку тверду схему. У процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень. У результаті реальний процес створення ПЗ приймав наступний вид (Рис.2).
Рис2. Реальний процес розробки ПЗ за каскадною схемою
Основним недоліком каскадного підходу є істотне запізнювання з одержанням результатів. Узгодження результатів з користувачами здійснюється тільки в точках, планованих після завершення кожного етапу робіт, вимоги до ІС "заморожені" у вигляді технічного завдання на весь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена.
У випадку неточного викладу вимог або їхньої зміни протягом тривалого періоду створення ПЗ, користувачі одержують систему, що не задовольняє їхнім потребам. Моделі (як функціональні, так і інформаційні) автоматизованого обєкту можуть застаріти одночасно з їхнім затвердженням.
Для подолання перерахованих проблем була запропонована спіральна модель ЖЦ (Рис.3), що робить упор на початкові етапи ЖЦ: аналіз і проектування. На цих етапах реалізованість технічних рішень перевіряється шляхом створення прототипів. Кожний виток спирали відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі й характеристики проекту, визначається його якість і плануються роботи наступного витка спирали. У такий спосіб заглиблюються й послідовно конкретизуються деталі проекту й у результаті вибирається обґрунтований варіант, що доводиться до реалізації.
Рис.3. Спіральна модель ЖЦ
життєвий цикл інформаційна система
Розробка ітераціями відбиває обєктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. При ітеративному способі розробки відсутню роботу можна буде виконати на наступній ітерації. Головна ж задача - якнайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення й доповнення вимог.
Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її рішення необхідно ввести часові обмеження на кожний з етапів життєвого циклу. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, отриманих у попередніх проектах, і особистого досвіду розроблювачів.
Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є, що одержала в останній час широке поширення, є методологія швидкої розробки додатків RAD (Rapid Application Development). Під цим терміном звичайно розуміється процес розробки ПЗ, що містить 3 елементи:
- невелику команду програмістів (від 2 до 10 чоловік);
- короткий, але ретельно пророблений виробничий графік (від 2 до 6 мес.);
- повторюваний цикл, при якому розроблювачі, у міру того, як додаток починає набувати форму, запитують і реалізують у продукті вимоги, отримані через взаємодію із замовником.
Команда розроблювачів повинна представляти із себе групу професіоналів, що мають досвід в аналізі, проектуванні, генерації коду й тестуванні ПЗ з використанням CASE-засобів. Члени колективу повинні також уміти трансформувати в робочі прототипи пропозиції кінцевих користувачів.
Життєвий цикл ПЗ за методологією RAD складається із чотирьох фаз:
- фаза аналізу й планування вимог;
- фаза проектування;
- фаза побудови;
- фаза впровадження.
На фазі аналізу й планування вимог користувачі системи визначають функції, які вона повинна виконувати, виділяють найбільш пріоритетні з них, що вимагають пророблення в першу чергу, описують інформаційні потреби. Визначення вимог виконується в основному силами користувачів під керівництвом фахівців-розроблювачів. Обмежується масштаб проекту, визначаються часові рамки для кожної з наступних фаз. Крім того, визначається сама можливість реалізації даного проекту у встановлених рамках фінансування, на даних апаратних засобах і т.п. Результатом даної фази повинні бути список і пріоритетність функцій майбутньої ІС, попередні функціональні та інформаційні мо?/p>