ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 08.11.2023
Просмотров: 40
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования.
Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий.
Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использоватьV-модель?
• Когда требуется тщательное тестирование
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
«Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки.
Терминология часто используется для описания поэтапной сборки ПО.
Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад».
Цикл разделен на более мелкие легко создаваемые модули.
Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования.
Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов».
Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы.
Пример проектов: читалка DefView, сеть электронных библиотек Vivaldi.
Пример одного инкремента.
Сеть электронных библиотек Vivaldi пришла на смену DefView.
DefView подключалась к одному серверу документов, а теперь может подключаться ко многим.
На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат.
Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.
«RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель — разновидность инкрементной модели.
В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов.
Временные рамки одного цикла жестко ограничены.
Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
• Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
• Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
• Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
• Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
• Тестирование: тестируются новые компоненты и интерфейсы.
Когда используется RAD-модель?
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов.
Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки.
RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
«Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет.
Это одно из преимуществ гибкой модели.
К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку.
Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.
Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка.
Соответственно, в процессе реализации требования изменяются.
Гибкая разработка лучше всего подходит для психотипа руководителей - творческие люди, которым свойственно генерировать, выдавать и опробовать новые идеи еженедельно или даже ежедневно.
Внутренние стартапы компании разрабатываются по Agile.
Примером клиентских проектов является Электронная Система Медицинских Осмотров, созданная для проведения массовых медосмотров в считанные минуты.
Когда использовать Agile?
• Когда потребности пользователей постоянно меняются в динамическом бизнесе.
• Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
• В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
«Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований.
Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований.
Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, идет стремление к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
Примером итерационной разработки может служить распознавание голоса.
Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге.
С каждой новой итерацией качество распознавания улучшалось.
Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
• Требования к конечной системе заранее четко определены и понятны.
• Проект большой или очень большой.
• Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
«Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков.
Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты.
Даже столь любимая всеми Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования.
Методологии частично пересекаются в средствах и отчасти похожи друг на друга.
Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.