Читайте также:
|
Класична методологія проектування ІС передбачала в різній термінології і під різноманітними назвами послідовну в загальному організацію робіт. її основною характеристикою є розбиття розроб-» лення на етапи, причому перехід від одного етапу до іншого відбувається лише після того, як буде цілком завершена робота на поточному. Кожний етап завершується випуском повного комплекту документації, достатньої для того, щоб розроблення могло бути продовженим іншою командою розробників.
Крім того, найрозумніше організовані методики та стандарти уникали жорстко однозначного «прив'язування» робіт до конкретних стадій. Разом з тим, при можливості неодноразового включення деякої роботи в загальну схему постійно виділялися наступні проектні стадії:
>> «запуск» (proposal for the development, agreement, mobilization): організація підстави для діяльності і запуск робіт: наказ та (або) договір на розробку інформаційної системи, завдання на виконання робіт;
>> «обстеження» (feasibility stady, scope analysis, strategy stady and planning, requirement definition): передпроектне обстеження, загальний аналіз ситуації на підприємстві (фірмі), Розроблення загального обґрунтування доцільності створення ІС;
>> «концепція, ТЗ» (strategy planning, analysis, requirement specification, function description): дослідження вимог підприємства і користувачів, формування рекомендацій з розроблення ІС, Розроблення технічного завдання (ТЗ) на проектування ІС загалом та часткових ТЗ (ЧТЗ) для підсистем;
>> «ескізний проект» (detailed analysis, high level design): Розроблення архітектури майбутньої ІС в межах ескізного проекту;
>> дослідний варіант ІС (pilot-project, test development): Розроблення спрощеного варіанта, пілотного проекту майбутньої ІС;
>> дослідне використання пілот-проекту ІС, Розроблення виправлень та доповнень до ТЗ (test, corrected requirement specification);
>> «777» (detailed analysis and design, test development): Розроблення технічного проекту ІС;
>> «РП» (development, test, system implementation): Розроблення робочої документації проекту;
>> «введення в дію» (deployment, put into operation): іншими словами — «впровадження» ІС.
7. Етапи життєвого циклу ПЗ. Суть кожного з етапів.
Період часу, який починається з моменту прийняття рішення про необхідність створення програмного продукту і закінчується в момент його повного вилучення з експлуатації
Цей цикл - процес побудови і розвитку ПЗ.
Стадія - частина процесу створення ПЗ, обмежена певними тимчасовими рамками і закінчується випуском конкретного продукту (моделей, програмних компонентів, документації), що визначається заданими для даної стадії вимогами.
Етапи проекту відповідно до каскадної моделлю:
1. Формування вимог;
2. Проектування;
3. Реалізація;
4. Тестування;
5. Впровадження;
6. Експлуатація та супровід.
У Водоспадної моделі перехід від однієї фази проекту до іншого передбачає повну коректність результату (виходу) попередньої фази. Однак неточність вимозі або некоректна його інтерпретація в результаті призводить до того, що доводиться "відкочуватися" до ранньої фази проекту і необхідна переробка не просто вибиває проектну команду з графіка, але призводить часто до якісного зростання витрат і, не виключено, до припинення проекту в тій формі, в якій він спочатку замислювався. На думку сучасних фахівців, основне оману авторів Водоспадної моделі полягає в припущеннях, що проект проходить через весь процес один раз, спроектована архітектура хороша і проста у використанні, проект здійснення розумний, а помилки в реалізації легко усуваються в міру тестування. Ця модель виходить з того, що всі помилки будуть зосереджені в реалізації, а тому їх усунення відбувається рівномірно під час тестування компонентів і системи. Таким чином, Водопадна модель для великих проектів мало реалістична і може бути ефективно використана тільки для створення невеликих систем.
Дата добавления: 2015-09-09; просмотров: 129 | Поможем написать вашу работу | Нарушение авторских прав |