10. Инкрементная модель жизненного цикла Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью[4].
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения[3].
По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»[4].
Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»[3].
11. . Модель быстрой разработки приложений (rad).
RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.
Назначение
RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементногопрототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях – обследование организации, выработка требований к системе.
Фазы разработки
Планирование - совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке. Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение.
Пользовательское проектирование - на протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции. Для перевода пользовательских прототипов в рабочие модели RAD-группа обычно использует технику объединенной разработки приложений (JAD) и CASE-инструменты. Пользовательское проектирование оказывается длительным интерактивным процессом, который позволяет пользователям понять, изменить и в конечном счете выбрать рабочую модель, отвечающую их требованиям.
Конструирование - этап, в котором основная задача заключается в разработке программ и приложений. Аналогична стадии "реализация" в SDLC. В RAD, однако, пользователи продолжают принимать участие и по-прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов. В их задачи входит программирование и разработка приложений, написание кода, интеграция модулей и системное тестирование.
Переключение - включает в себя операции по конверсии данных, тестирование, переход на новую систему и тренировку пользователей. По своим задачам напоминает финальную стадию SDLC. Сравнивая с традиционными методами разработки ПО, весь процесс оказывается сжатым по времени. Как результат, новая система оказывается быстрее построенной, доставленной до заказчика и установленной на рабочих местах.
Преимущества
Технология быстрой разработки приложений (RAD) позволяет обеспечить:
быстроту продвижения программного продукта на рынок;
интерфейс, устраивающий пользователя; легкую адаптируемость проекта к изменяющимся требованиям; простоту развития функциональности системы.
12.
Спиральная модель
Спиральная
модель представляет собой процесс
разработки программного обеспечения,
сочетающий в себе как проектирование,
так и постадийное прототипирование с
целью сочетания преимуществ восходящей
и нисходящей концепции.
Преимущества:
Быстрое получение результата
Повышение конкурентоспособности
Изменяющиеся требования — не проблема
Недостатки:
Отсутствие регламентации стадий
13. XP-процессы
Экстремальное программирование — является наиболее известной из гибких методологий. Она строится на 12 принципах, которые можно объединить в 4 группы:
Короткий цикл обратной связи
Разработка через тестирование
Игра в планирование
Заказчик всегда рядом
Парное программирование
Непрерывный, а не пакетный процесс
Непрерывная интеграция
Рефакторинг
Частые небольшие релизы
Понимание, разделяемое всеми
Простота
Метафора системы
Коллективное владение кодом или выбранными шаблонами проектирования
Стандарт кодирования
Социальная защищенность программиста
40-часовая рабочая неделя
XP, несомненно, очень популярно и позволяет разрабатывать проекты достаточно успешно, но только в идеальном варианте. В реальности все гораздо сложнее: заказчик, как правило, бывает доступен весьма ограниченное время, и он не может посвящать работе в проекте столько же времени, сколько программист или менеджер. Это значит, что получение отклика и уточнение требований будут проходить со значительной задержкой. Рефакторинг — это не панацея. Изменение существующего кода может потребовать значительно больше времени, чем разработка нового. Программист может тратить много времени на улучшение того, что уже есть, а не на создание нового функционала. Совместное владение кодом — еще один спорный момент. За каждый класс должен отвечать только один разработчик: при совместном владении возможны неожиданные правки, и класс станет работать не так, как было запланировано создателем класса. Совместное владение кодом, и парное программирование подразумевают затраты на изучение кода другого разработчика, но о них обычно нигде не упоминается: считается, что для этого достаточно всем программистам находиться в одной комнате и время от времени обмениваться репликами. Эта позиция не имеет каких-либо строгих обоснований, и совершенно нет уверенности, что такого обмена информацией будет достаточно. Даже если в организации приняты стандарты кодирования и они строго выполняются, изучение чужого кода может занимать большое количество времени.
14. Диаграммы переходов состояний
Диаграмма состояний является графом специального вида, который представляет некоторый автомат. Вершинами графа являются возможные состояния автомата, изображаемые соответствующими графическими символами, а дуги обозначают его переходы из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга для более детального представления отдельных элементов модели.
15. Диаграммы «сущность-связь».