Original: http://www.umsl.edu/~hugheyd/is6840/waterfall.html
Традиційний каскадний підхід
Каскадний підхід до аналізу систем і дизайну став першим встановленим сучасним підходом до побудови системи. Цей метод був спочатку визначений Уїнстоном У. Ройсом в 1970 році (“Методологія каскадного розвитку”, 2006). Він швидко отримав підтримку з боку менеджерів, тому що все логічно випливає з самого початку проекту і до кінця (Йоханссон, 2008). Джерела відрізняються, коли мова йде про конкретні кроки в процесі побудови каскаду (Йоханссон, 2008), і я буду детально розкривати деякі з цих відмінностей у наступному параграфі. Проте, основна базова логіка і кроки представлені в кожній інтерпретації.
Рисунок 1. Каскадний метод
(“Методологія каскадного розвитку”, 2006)
Оригінальний каскадний метод, розроблений Ройсом, показаний на рисунку 1. Етапи включають визначення вимоги, проектування, впровадження, перевірку і технічне обслуговування. Інші моделі зміни фази вимоги на фазу ідеї (Йоханссон, 2008), або зламати вимоги поетапного в планування і аналізу (Хоффер, Джордж, Валасіч, 2008). Крім того, деякі моделі додатково розбити на стадію проектування з в логічні і фізичні підфази дизайну (Хоффер, і ін, 2008). Як згадувалося раніше, однак, основні принципи, що лежать в основі залишаються тими ж.
Каскадний метод робить припущення, що всі вимоги можуть бути зібрані на фронті під час фази вимог (Кі, 2006). Зв’язок із користувачем перевантаженням в цю фазу, як керівник проекту робить його або її сили, щоб отримати детальне розуміння вимог користувача. Після того, як цей етап буде завершено, процес проходить “під гору” (Хоффер та ін., 2008).
Етап дизайну найкраще описуються розбиваючи його на підфази логічного дизайну і фізичного дизайну. У логічної стадії проектування, аналітики системи використовує інформацію, зібрану в фазі вимоги для розробки системи незалежно від будь-яких апаратних засобів або програмного забезпечення системи (Хоффер та ін., 2008) Після того, як логічний дизайн високого рівня є повним, системний аналітик потім починає його трансформації у фізичній конструкції в залежності від специфікацій конкретних апаратних і програмних технологій ( “Життєвий цикл розробки програмного забезпечення”, н.д.)
Етап впровадження, коли все фактичного коду пишеться (“Фази SDLC”, н.д.). Ця фаза відноситься до програмістам в методі водоспаду, як вони приймають вимоги до проекту та специфікацій, а також код додатків.
Етап перевірки був спочатку закликав на Ройса, щоб гарантувати, що проект відповідає очікуванням клієнтів. Однак в реальних аналізу і проектування, цей етап часто ігнорується. Проект розкочується до клієнта, і починається фаза технічного обслуговування.
На етапі технічного обслуговування клієнт використовує розроблений додаток. Оскільки проблеми виявляються через неправильне визначення вимог або інших помилок в процесі проектування, або через зміни у вимогах користувачів, внесені зміни в систему під час цієї фази. (“Фази SDLC”, н.д.).
Каскадний метод має певні переваги, серед яких:
• Помилки проектування були захоплені перед тим будь-яке програмне забезпечення написано економить час на стадії реалізації.
• Відмінна технічна документація є частиною результатів, і це простіше для нових програмістів, щоб отримати до швидкості під час підтримуючої фази.
• Підхід дуже структурований і його легше виміряти прогрес шляхом посилання на чітко визначених етапах.
• Загальна вартість проекту може бути точно оцінена після того, як були визначені вимоги (за допомогою функціональних і призначених для користувача специфікацій інтерфейсів).
• Тестування простіше, так як це може бути зроблено шляхом посилання на сценарії, визначені в функціональної специфікації (“Методологія каскадного розвитку”, 2006).
На жаль, каскадний метод має досить багато недоліків, наприклад:
• Клієнти часто буде важко викласти свої вимоги на абстрактному рівні функціональної специфікації і буде тільки в повній мірі оцінити те, що необхідно, коли додаток буде доставлено. Потім він стає дуже важко (і дорого), щоб реорганізувати додаток.
• Модель не для задоволення можливості вимог змінюються під час циклу розробки.
• Проект часто може зайняти значно більше часу, щоб поставити, ніж коли розроблені з итеративной методології, такі як метод швидкої розробки. (“Методологія каскадного розвитку”, 2006).
Через ці та подібні проблеми системні аналітики стали шукати альтернативні методи проектування систем. У наступних розділах я розповім про деякі розроблені методи. Я зосереджуся на методології, класифікованій як гнучка. У цій статті я зосереджуся на екстремальному програмуванні, скрамінгу і розробці через тестування.
Copyright 2009 Douglas Hughey.
