- •Водопадная и эволюционная модели разработки по
- •Scrum – методология
- •Встречи:
- •3.) Выявление требований к программному обеспечению. Способы представления требований
- •4.Архитектурные стили: компонентный, многослойный, многоуровневый, клиент-сервер.
- •6. Шаблоны проектирования Адаптер, Наблюдатель. Диаграмма классов. Сценарии применения
- •7. Шаблоны проектирования Фасад, Мост. Диаграмма классов. Сценарии применения
- •8. Тестирование программного обеспечения. Метод черного и белого ящика
- •Тестирование методом черного ящика
- •Тестирование методом белого ящика
- •9. Тестирование программного обеспечения. Юнит тестирование. Заглушки. Виды заглушек
- •10. Тестирование программного обеспечения. Виды тестирования. Последовательность фаз тестирования.
- •11. Диаграмма вариантов использования
- •12. Диаграмма классов
- •13. Диаграмма деятельности
- •1 4. Диаграмма развертывания(размещения)
- •15. Диаграмма компонентов
- •16. Диаграмма dfd
Водопадная и эволюционная модели разработки по
ВОДОПАДНАЯ МОДЕЛЬ жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
Формирование требований; Проектирование; Реализация; Тестирование; Внедрение; Эксплуатация и сопровождение.
Преимущества:
Полная и согласованная документация на каждом этапе;
Легко определить сроки и затраты на проект.
Недостатки водопадного подхода
Накопление различных ошибок, допущенных на ранних стадиях проекта => Неоправданное увеличение времени реализации, превышение бюджета и риск полного срыва проекта.
Все ключевые решения принимаются тогда, когда у аналитиков и разработчиков нет полного понимания системы. Очень сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему, поэтому постоянно возникает необходимость возврата к предыдущим этапам с целью уточнения и пересмотра ранее принятых решений.
Конечный продукт может оказаться невостребованным из-за неточного изложения требований или их изменения за длительное время создания ПО.
ЭВОЛЮЦИОННЫЕ МОДЕЛИ: ИТЕРАЦИОННАЯ МОДЕЛЬ
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются инкрементально (эволюционно).
ЭВОЛЮЦИОННЫЕ МОДЕЛИ: СПИРАЛЬНАЯ МОДЕЛЬ
Спиральная модель, предложенная Барри Боэмом в 1988 году, представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
«Разрыв» в квалификации специалистов разных областей знаний.
Название " спиральная " эта модель получила из-за изображения хода работ в "полярных координатах", в которых угол соответствует выполняемому этапу в рамках общей структуры итераций, а удаление от начала координат — затраченным ресурсам.