льний аналіз ситуації на п / п, розробка загального обгрунтування доцільності створення ІС;
концепція, ТЗ - дослідження вимог підприємства і користувачів, вироблення рекомендацій з розробки ІС, розробка ТЗ на проектування ІС в цілому і приватних ТЗ по підсистемах;
ескізний проект - розробка архітектури майбутньої ІС в рамках ескізного проекту;
досвідчений варіант ІС - розробка спрощеного варіанту, пілотного проекту майбутньої ІС
дослідне використання пілот-проекту ІС, розробка виправлень і доповнень до ТЗ
технич-е проектування - розробка технічного проекту ІС;
робоче проектування - розробка робочої документації проекту;
введення в дію - «впровадження» ІВ.
Це «Водоспадна» або «каскадна» модель.
Позитивні фактори застосування схеми:
на кожній стадії формувався закінчений, відповідає критеріям повноти та узгодженості набір проектної, користувача документації, що охоплює всі передбачені стандартами види забезпечення ІС: організаційне, методичне, інформаційне, програмне, апаратне та ін;
виконувані в логічній послідовності етапи робіт дозволяли планувати терміни завершення всіх робіт і відповідні витрати.
Недоліки:
1. Запізнення - суттєве запізнення з отриманням результатів, що мало кілька аспектів:
узгодження результатів з користувачем вироблялося після завершення кожного етапу робіт; => розробники робили не ту ІС, яку хотіли замовник і користувачі, а ту, яку представили собі проектувальники-аналітики, потім - програмісти;
моделі об'єкта, що автоматизується для великого проекту ІС застарівали незабаром після їх затвердження, а іноді й одночасно з ним;
спроби довести до впровадження проект, що виконується в такій манері, змушували або спотворювати вимоги до ІС, або перевищувати терміни і кошторис розробки.
2. Марність. Провідні аналітики оцінювали проектування ІС як дуже часто веде до примітивної автоматизації (по суті - механізації) існуючих виробничих дій працівників.
3. Жорсткість. Користувачеві природніше і простіше представляти моделі предметної області в ієрархічному вигляді, а не у вигляді мережевих структур, що пояснюється його постійними контактами з ієрархічними залежностями реального світу. Жорсткість ієрархічних структур обмежує їх користь, і чим далі, тим менше ці обмеження допустимі.
4 Закритість. Використання фірмових архітектур використовуваних комп'ютерів, операційних систем і СУБД отримали оцінку як недоліки закритих систем: закриті ІС було важко або дуже дорого розвивати, дуже дорого або практично неможливо стикувати з др з-ми.
5. Типові оргструктури. Практично не застосовувалися оргмеропріятія для побудови ІС (/ АСУ), що міняють оргструктури підвищення ефективності роботи підприємства. Для кожного підприємства, його відділення або відділу існували типові оргштатної структури, розкладу тастановища. Щоб провести зміну, потрібно було рішення відповідного міністерства => оргструктура залишалася незмінною, а ІС повторювала ті функції, які раніше виконувалися вручну.
Всі класичні методи залишилися в арсеналі розробників і в даний час. Тепер вони поєднуються з новими методами, що дозволяють досягти більшої гнучкості процесу розробки, і самої ІС, причому за менший час. Відносно класичних методів зміни в першу чергу стосуються якості їх комп'ютерної підтримки.
