пользователей: 21219
предметов: 10452
вопросов: 177398
Конспект-online
зарегистрируйся или войди через vk.com чтобы оставить конспект.
РЕГИСТРАЦИЯ ЭКСКУРСИЯ


07. Каскадний процес розробки. Переваги та недоліки


Основна ідея полягає в тому, що процес розробки ділиться на чітко певні фази, що виконуються строго послідовно.
Класична каскадна модель включає наступні області:
  • Розробка вимог: збір бізнес-вимог замовника і їх перетворення в функціональні вимоги до програмного продукту.
  •  Аналіз та дизайн: розробка моделі предметної області, проектування схеми бази даних, об'єктної моделі, користувальницького інтерфейсу.
  •  Реалізація: створення продукту по специфікаціям, розробленим на попередньому етапі.
  •  Тестування: включає перевірку відповідності функціональності програмного продукту потребам користувачів, а також пошук дефектів в реалізації.
  •  Розгортання: навчання користувачів, інсталяція системи, переклад в промислову експлуатацію.

У каскадній моделі кожна з процесних областей являє собою окрему фазу проекту.
Переваги:

  • Справляється зі складнощами і добре працює для тих проектів, які досить зрозумілі, але все ж важко розв'язні;
  •  Доступна для розуміння;
  •  Проста і зручна в застосуванні, так як процес розробки виконується поетапно;
  • Представляє собою шаблон, в який можна помістити методи для виконання аналізу, проектування, кодування, тестування і забезпечення;
  • При правильному використанні моделі дефекти можна виявити на більш ранніх етапах, коли їх усунення ще не вимагає відносно великих витрат;

Недоліки:

  •  Процес вкрай неефективний при постійних змінах тренованій. Кожна зміна змушує повертатися до фази визначення вимог і повторювати весь процес з початку.
  •  Складно управляти ризиками деяких типів (таких, як ризики, пов'язані з використанням нових технологій або ризики некоректного визначення вимог). Подібні ризики можуть проявити себе тільки на етапі реалізації, коли число можливих шляхів виправлення ситуації набагато менше, ніж на початку проекту.
  •  Вельми обмежені можливості оцінки і коректування важливих атрибутів проекту - швидкості розробки, якості продукту, обгрунтованості прийнятих архітектурних рішень.
  •  виникає необхідність в жорсткому управлінні і контролі, оскільки в моделі не передбачена можливість модифікації вимог;
  •  всі вимоги повинні бути відомі на початку життєвого циклу
  •  весь програмний продукт розробляється за один раз. Немає можливості розбити систему на частини.

 

 

Модель водопада
Основная идея заключается в том, что процесс разработки делится на четко определенные фазы, выполняемые строго последовательно.
Классическая водопадная модель включает следующие области:
§    Разработка требований: сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту.
§    Анализ и дизайн: разработка модели предметной области, проектирование схемы базы данных, объектной модели, пользовательского интерфейса.
§    Реализация: создание продукта по спецификациям, разработанным на предыдущем этапе.
§    Тестирование: включает проверку соответствия функциональности программного продукта потребностям пользователей, а также поиск дефектов в реализации.
§    Развертывание: обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.
В модели водопада каждая из процессных областей представляет собой отдельную фазу проекта.
Преимущества:
·     справляется со сложностями и хорошо срабатывает для тех проектов, которые достаточно понятны, но все же трудно разрешимы;
·     весьма доступна для понимания;
·    проста и удобна в применении, так как процесс разработки выполняется поэтапно;
·     представляет собой шаблон, в который можно поместить методы для выпол­нения анализа, проектирования, кодирования, тестирования и обеспечения;
·    при правильном использовании модели дефекты можно обнаружить на более ран­них этапах, когда их устранение еще не требует относительно больших затрат;
Недостатки:
§    Процесс крайне неэффективен при постоянных изменениях тренований. Каждое изменение заставляет возвращаться к фазе определения требований и повторять весь процесс с начала.
§    Сложно управлять рисками некоторых типов (таких, как риски, связанные с использованием новых технологий или риски некорректного определения требований). Подобные риски могут проявить себя только на этапе реализации, когда число возможных путей исправления ситуации намного меньше, чем в начале проекта.
§    Весьма ограничены возможности оценки и корректировки важных атрибутов проекта – скорости разработки, качества продукта, обоснованности принятых архитектурных решений.
§    возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;
§    все требования должны быть известны в начале жизненного цикла
§    весь программный продукт разрабатывается за один раз. Нет возможности раз­бить систему на части.

 

 

 

 


хиты: 413
рейтинг:0
Точные науки
информатика
для добавления комментариев необходимо авторизироваться.
  Copyright © 2013-2016. All Rights Reserved. помощь