- •Другие причины возможных неудач (по данным 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)
  
