
- •Другие причины возможных неудач (по данным Standish Group и Rational Software)
- •Одна из причин - экстремальные условия выполнения проектов:
- •Причины, порождающие экстремальные проекты
- •Причины участия в экстремальных проектах
- •2. Жизненный цикл по (software lifecycle):
- •3. Процессы жизненного цикла в различных стандартах
- •4. Жизненный цикл, гост исо мэк 12207
- •5. Жизненный цикл, гост 34, Oracle, rup.
- •6. Каскадная модель жизненного цикла эис, реальная модель
- •7. Спиральная модель жизненного цикла эис, ее сопоставление с каскадной моделью
- •8. Подход rad
- •Пример - технология Microsoft Microsoft Solutions Framework (msf)
- •9. Модель и архитектура эис
- •10. Языки моделирования
- •11. Диаграммы uml
- •12. Диаграммы uml. Диаграммы вариантов использования
- •1 3. Диаграмма обзора взаимодействия (uml 2.0)
- •14. Технологии создания по
- •15. Технология rup
- •Общее представление rup
- •16. Стадии жц по технологии rup
- •17. Средства моделирование бизнес процессов
- •18. Методология sadt
- •19. Методология idef0
- •20. Методология idef3
- •21. Методология aris
- •22. Dfd, основные элементы
- •23. Моделирование erd
- •25. Связи обобщения, включения, расширения rup
- •26. Объектно-ориентированный подход в проектировании эис
- •27. Основные принципы ооп
- •28. Основные понятия ооп
7. Спиральная модель жизненного цикла эис, ее сопоставление с каскадной моделью
Основные особенности спиральной модели
И
дентификация и анализ риска на каждой итерации
Назначение приоритетов пользовательским требованиям
Разработка последовательности прототипов, начиная с требований наивысшего приоритета
Использование каскадной модели для реализации окончательного прототипа
Оценка результатов по завершении каждой итерации и планирование следующей итерации
Завершение проекта при нецелесообразности его продолжения
Виды прототипов
Прототип пользовательского интерфейса
Функциональный прототип
Исследовательский прототип
Достоинства:
ускорение разработки (раннее получение результата за счет прототипирования)
постоянное участие заказчика в процессе разработки
разбиение большого объема работы на небольшие части
снижение риска (повышение вероятности предсказуемого поведения системы)
Проблемы:
сложность планирования (определения количества и длительности итераций, оценки затрат и рисков)
сложность применения модели с точки зрения менеджеров и заказчиков
напряженный режим работы для разработчиков
8. Подход rad
Подход RAD (Rapid Application Development) – IBM, James Martin, середина 80-х годов
Небольшие группы разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО (максимальная управляемость коллектива);
Короткий, но тщательно проработанный производственный график (до 3 месяцев);
Повторяющийся цикл реализации требований, полученных в результате взаимодействия с заказчиком.
Основные принципы подхода RAD
разработка приложений итерациями
необязательность полного завершения работ на каждой из стадий ЖЦ ПО
обязательность вовлечения пользователей в процесс разработки
использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей
тестирование и развитие проекта одновременно с разработкой
немногочисленная, хорошо управляемая команда профессионалов
грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ
Пример - технология Microsoft Microsoft Solutions Framework (msf)
Основные особенности подхода Microsoft
начальная разработка концепции (vision statement), выбор возможностей и определение их приоритетов на основе запросов пользователей
пошаговое наращивание функциональных возможностей продукта
много небольших команд разработчиков (3 - 8 человек), параллельно работающих над продуктом
частая синхронизация изменений
полная сборка очередного релиза к концу дня с помощью средств управления конфигурацией («daily build»)
немедленная фиксация дефектов в каждом релизе и их устранение
непрерывное тестирование в процессе разработки
всестороннее внутреннее и внешнее тестирование (бета-тестирование)
3 или 4 контрольные точки стабилизации продукта в течение цикла разработки
Результат - создание "good enough" продукта для массового рынка с последующим совершенствованием и поставкой новых версий (upgrades)