вається Перехід до проектування, в ході которого створюються документи, что детально опісують для програмістів способ и план реализации зазначену вимог.
После того як проектування Повністю Виконання, програмістамі віконується реалізація отриманий проекту. На наступній Стадії процесса відбувається інтеграція ОКРЕМЕ компонентів, что розробляються різнімі командами програмістів. После того як реалізація и інтеграція завершені, проводитися тестування и відладка продукту; на Цій Стадії усуваються всі Недоліки, что з'явилися на попередніх стадіях розробки. После цього програмний продукт впроваджується и забезпечується его підтримка - внесення новой функціональності та Усунення помилок. Схема каскадної моделі ЖЦ подана на малюнку 1.1.1
Малюнок 1.1.1 - Схема каскадної моделі ЖЦ
Тім самим, каскадні модель має на увазі, что Перехід від однієї фази розробки до Іншої відбувається только після повного и успішного Завершення попередньої фази, І що переходів назад або вперед або перекриття фаз - НЕ відбувається. Коженая етап завершується випуском готового комплекту документації.
каскадного модель віділяє Такі основні етапи життєвого циклу програм:
§ Аналіз проблеми, постановка задачі и Специфікація вимог до майбутньої програми. Як правило, цею етап винен передбачаті взаємодію между Виконавцю та замовником. Результатом винне буті технічне замовлення, сформульоване в письмовий виде.
§ Проектування. Повинен буті Вибраний метод вирішенню задачі та спроектованій відповідній алгоритм.
§ кодування, Пожалуйста Полягає в написанні тексту програми відповідно до розроблення алгоритму.
§ Відлагодження, Пожалуйста Полягає у Виявлення та віправленні помилок.
§ Тестування, что предполагает перевірку правільності програми на тестових прикладах - спеціально підібраніх наборів вхідних даних. Для ціх наборів даних повінні буті відомімі правильні ВІДПОВІДІ. Если ВІДПОВІДІ програми на всех тестових прикладах співпадають з очікуванімі, программа вважається правильною.
§ Тестування винне буті якомога більш ПОВНЕ, І слушно підбір тестових примеров часто є очень непростим завданням. Повінні буті перевірені всі тіпі вхідніх даних и всі Можливі варіанти виконан програми. Повинен буті проведень тест в нормальних условиях (дані, характерні для реальних умів фунціонування), тест в екстремальних условиях (перевірка Функціонування програми в крайніх випадка, коли вхідні дані перебувають На межі Припустиме діапазону) i тест за виняткова обставинні (колі вхідні дані Виходять за рамки Припустиме діапазону) .Впровадження и експлуатація.
§ Модіфікація програми у випадка необхідності. Необходимость модіфікації програми может буті пов'язана, например, зі зміною умів ее Функціонування або з якихось Посилення вимог до неї.
§ Зняття з ЕКСПЛУАТАЦІЇ.
До Перевага каскадної моделі належати:
на шкірному етапі формується закінчений набір проектної документації, что відповідає крітеріям повнотіла и узгодженості;
віконувані в логічній послідовності етапи робіт дозволяють плануваті Терміни Завершення всех робіт и відповідні витрати.
каскадного ПІДХІД добро зарекомендував себе при створенні ПЗС, для якіх на самому качана розробки можна достаточно точно и повно сформулюваті всі вимоги, з тім щоб надаті розробник свободу реалізуваті їх якнайкраще з технічної точки зору. У Цю категорію потрапляють складні розрахункові системи, системи реального годині и Інші подібні Завдання.
Недолікамі каскадної моделі є ті, что Перехід від однієї фази проекту до наступної предлагает повну коректність результату попередньої фази. Одна неточність якої небудь вимоги чі некоректно его інтерпрітація в результате приводити до того, что необходимо буде провести відкат до фази в проекті яка булу Ранее. Такі Дії приводять до Збільшення витрат на проект и не виключення, до завершення проекту в форме, в Якій ВІН спочатку планувався.
Обгрунтування Вибори:
каскадного модель життєвого циклу Було звертаючись, тому что для даного проекту вона є найбільш підходящою. Проект є Невеликий з достаточно кількістю годині на его Розробка і з достаточно кількістю розробніків, щоб потихенько, вдумліво и без зайвих проблем відпрацюваті КОЖЕН з етапів моделі, Які Йдут одні за одним послідовно. Як позначають вже вищє, проект доволі простий и не потребує Додатковий прототіпів для власної реализации, при вікорістанні ітераційної моделі, например, перший же прототип БУВ бі готовою реалізацією, тому розбіття такого проекту на мінімум две ітерації Було б Зайве.
