8. Модель «Code & Fix».
- 1-й шаг – написание программного кода
- 2-й шаг – поиск и устранение ошибок в коде
- Принятие решения о переходе либо не переходе к стадии концепции
Преимущества такой модели:
- может применяться для маленьких программ (менее 10 000 строк кода)
Минусы:
- после нескольких исправлений ошибки могут быть не исправлены;
- результат очень часто не соответствует требованиям пользователя;
- ошибки сложно исправлять из-за отсутствия тестовых (контрольных) задач/примеров.
9. Модель водопада. Стадии, преимущества, недостатки.
Процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Стадия анализа и определения требований
На основе «Определения» заказчиков создаются «Пользовательские требования»
На основе «заданных определений» к ПО разрабатываются требования к ПО
Результатом является Системная спецификация (требования к системе) – пользовательские и функциональные требования к ПО
Стадия проектирования ПО
Определяются требования со стороны используемых аппаратных и программных систем
Система делится на модули – создается архитектура системы
Определяются требования и спецификации модулей и требования к их взаимодействию
Разрабатывается детализированная спецификация – содержит структуру и архитектуру модулей.
Результат: документация по архитектуре системы, детализированные спецификации на модули - документы, подробно описывающие для программистов способ и план реализации указанных требований + тестовые примеры.
Реализация и тестирование компонентов
Разрабатываются модули по отдельности
Выполняется тестирование модулей (Test Frame). Тесты включают функциональные тесты
Стадия интеграции и системного тестирования
Объединение модулей (интеграция)
Тестирование объединенных модулей – «интегрированное тестирование»
Проверка соответствия требованиям пользователей и системным требованиям
В случае успешного прохождения всех тестирований и проверок – продукт предоставляется заказчику
Внедрение и поддержка
Функционирование и поддержка
Установка у заказчика, «разрешение» на использование
Исправление не выявленных ранее ошибок и недочетов (может оказаться очень дорогим)
«Улучшение поведения» системы – например запуск, графический интерфейс пользователя и т. п.
Расширение системы – внедрение новых функций (если необходимо)
Преимущества
Программа и цикл ее разработки хорошо структурирована и задокументирована
После каждой стадии поддерживаются управленческие решения
Благодаря четко определенным требованиям достаточно просто передавать разработку субподрядчикам
Недостатки
Требования и спецификации фиксируются раз и навсегда – результат может не соответствовать потребностям заказчикам
Возможны сложности при разработке интерактивных продуктов из-за того же – фиксации требований и функций на ранних стадиях
Точка зрения заказчика фактически приравнивается к точке зрения разработчика – проблема в том, что заказчик может четко сказать, что он хочет, только получив результат
10. V-образная модель.
Используется для определения единой процедуры разработки программных продуктов, аппаратного обеспечения и человеко-машинных интерфейсов. V-Model (VEE) представляет собой скорее набор стандартов в области проектов, касающихся разработки новых продуктов.
Идея модели:
Разработка привязана к организации тестовых примеров
Чем дольше ошибки присутствуют в системе, тем дороже их устранение
За стадиями конструирования должны следовать стадии тестирования
В целом процесс аналогичен модели водопада
Особенности:
Показывает связи между каждой фазой ЖЦ
Каждая фаза может быть реализована на основе детальной документации по предыдущей фазе
Фактически расширение водопадной модели
Преимущества:
Считается хорошо проверенной (в Германии) и подходящей для большинства проектов
Тестирование может начинаться с анализа требований и определения критериев – что собственно, нужно тестировать
Недостатки:
Ошибки, найденные позже стадии абстрактной модели, гораздо дороже в обнаружении и устранении