, обстежених в США в 1994 році, невдалими виявилися більш ніж 30% проектів, загальна вартість яких перевищувала 80 мільярдів доларів. При цьому виявилися виконаними у строк лише 16% від загального числа проектів, а перевитрата коштів склав 189% від запланованого бюджету.
Водночас, замовники ІС стали висувати все більше вимог спрямованих на забезпечення можливості комплексного використання корпоративних даних в управлінні і плануванні своєї діяльності.
Таким чином, виникла нагальна необхідність формування нової методології побудови ІС.
В
Життєвий цикл ІС
Методологія проектування ІС описує процес створення і супроводу систем у вигляді життєвого циклу (ЖЦ), ІС, представляє його як деяку послідовність стадій і виконуваних на них процесів. Для кожного етапу визначаються склад і послідовність виконуваних робіт, одержувані результати, методи і кошти, необхідні для виконання робіт, ролі та відповідальність учасників і т.д. Таке формальне опис ЖЦ ІС дозволяє спланувати та організувати процес колективної розробки і забезпечити управління цим процесом.
Етапи по спільності цілей можуть об'єднуватися в стадії. Сукупність стадії та етапів, які проходить ІС в своєму розвитку від моменту прийняття рішення про створення системи до моменту припинення її функціонування, називається життєвим циклом ІС.
В
Модель ЖЦ
Модель життєвого циклу відображає різні стани системи, починаючи з моменту виникнення необхідності, в даній ІС закінчуючи моментом її повного виходу з вживання. Модель життєвого циклу - структура, яка містить процеси, дії і завдання, які здійснюються в ході розробки, функціонування та супроводу програмного продукту протягом усього життя системи, від визначення вимог до завершення її використання.
В даний час відомі і використовуються наступні моделі життєвого циклу:
* Каскадна модель (рис. 2.1) передбачає послідовне виконання всіх етапів проекту в строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі. p> * Поетапна модель з проміжним контролем (рис. 2.2). Розробка ІС ведеться итерациями з циклами зворотного зв'язку між етапами. Міжетапні коригування дозволяють враховувати реально існуюче взаємовплив результатів розробки на різних етапах; час життя кожного з етапів розтягується на весь період розробки (інша назва - итерационная модель). p> * Спіральна модель (рис. 2.3). На кожному витку спіралі виконується створення чергової версії продукту, уточнюються вимоги проекту, визначається його якість і плануються роботи наступного витка.
В В
Рис. 2.1 Каскадна модель ЖЦ ІС
В
Рис. 2.2. Поетапна модель з проміжним контролем
В В
Рис. 2.3. Спіральна модель ЖЦ ІС
На практиці найбільшого поширення набули дві основні моделі життєвого циклу:
* каскадна модель (характерна для періоду 1970-1985 рр..);
* спіральна модель (характерна для періоду після 1986 р.).
У ранніх проектах досить простих ІС кожен додаток являло собою єдиний, функціонально та інформаційно незалежний блок. Для розробки такого типу додатків ефективним виявився каскадний спосіб. Кожен етап завершувався після повного виконання та документального оформлення всіх передбачених робіт.
Можна виділити наступні позитивні сторони застосування каскадного підходу:
* на кожному етапі формується закінчений набір проектної документації, який відповідає критеріям повноти та узгодженості;
* виконуються в логічної послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Каскадний підхід добре зарекомендував себе при побудові відносно простих ІС, коли в самому початку розробки можна досить точно і повно сформулювати всі вимоги до системи. Основним недоліком цього підходу є те, що реальний процес створення системи ніколи повністю не вкладається в таку жорстку схему, постійно виникає потреба в поверненні до попередніх етапах і уточнення або перегляд раніше прийнятих рішень. У результаті реальний процес створення ІС виявляється відповідним поетапної моделі проміжним контролем.
Однак і ця схема не дозволяє оперативно враховувати виникаючі зміни і уточнення вимог до системи. Узгодження результатів розробки з користувачами проводиться тільки в точках, що плануються після завершення кожного етапу робіт, а загальні вимоги до ІС зафіксовані у вигляді технічного завдання на весь час її створення. Таким чином, користувачі часто отримують систему, не задовольняє їх реальним потребам.
Іншими словами каскадна модель передбачає розробку закінчених продуктів на кожному етапі: технічного завдання, технічного проекту, програмного продукту і користувача документації. Розроблена документація дозволяє не тільки визначити вимоги до продукту наступного етапу, а й визначити обов'язки сторін, обсяг робіт і т...
