- •Вопросы к дифзачету по дисциплине «Управление проектами в области it»
- •1. Понятие проекта в сфере разработки по.
- •2. «Железный треугольник».
- •3. Отличия разработки по от других отраслей.
- •4. Проект и организационная структура компании. Различия между функциональной и проектной структурой.
- •5. Матричная организация компании. «Слабая», «сбалансированная» и «жесткая» матрицы.
- •6. Модель зрелости процессов создания по (cmm – Capability Maturity Model).
- •7. Жизненный цикл проекта. Стадии жизненного цикла проекта.
- •8. Модель «Code & Fix».(Проб и ошибок).
- •9. Модель водопада. Стадии, преимущества, недостатки.
- •11. Итеративная модель. Стадии, преимущества, недостатки.
- •12. Основные отличия итеративного подхода от модели водопада.
- •13. Методология rup
- •1. Начальная стадия (Inception)
- •2. Уточнение (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •14. Спиральная модель.
- •15. Технология Microsoft Solutions Framework.
- •16. Понятие «экстремального программирования» (Extreme Programming - xp). Основные особенности хр.
- •17. Практики xp.
- •18. Планирование и оценка проекта. Основные этапы/действия.
- •19. Метод Дельфи оценки проекта.
- •20. Экспертный метод оценки проекта. Отличия от метода Дельфи.
- •21. Модель оценки стоимости проекта сосомо. Уровни сосомо.
13. Методология rup
RUP (Rational Unified Process) – методология разработки ПО, созданная компанией Rational Software
Основные принципы:
1 — ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков
2 — концентрация на выполнении требований заказчиков к исполняемой программе
3 — ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки
4 — компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта
5 — постоянное обеспечение качества на всех этапах разработки проекта (продукта)
6 — работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.
Полный жизненный цикл разработки ПО состоит из 4 этапов:
1. Начальная стадия (Inception)
В фазе начальной стадии:
-
Формируются видение и границы проекта.
-
Создается экономическое обоснование (business case).
-
Определяются основные требования, ограничения и ключевая функциональность продукта.
-
Создается базовая версия модели прецедентов.
-
Оцениваются риски.
При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.
2. Уточнение (Elaboration)
В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
-
Документирование требований (включая детальное описание для большинства прецедентов).
-
Спроектированную, реализованную и оттестированную исполняемую архитектуру.
-
Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
-
Сниженные основные риски.
Успешное выполнение фазы уточнения означает достижение этапа жизненного цикла архитектуры (англ. Lifecycle Architecture Milestone).
3. Построение (Construction)
В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).
4. Внедрение (Transition)
В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.
14. Спиральная модель.
Спиральная модель - Материал из Википедии
Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Каждый виток разбит на 4 сектора:
-
определение целей,
-
оценка и разрешение рисков,
-
разработка и тестирование,
-
планирование следующей итерации.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт.
Преимущества:
-
Быстрое получение результата
-
Повышение конкурентоспособности
-
Изменяющиеся требования — не проблема
Недостатки:
-
Отсутствие регламентации стадий.
Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:
-
Дефицит специалистов.
-
Нереалистичные сроки и бюджет.
-
Реализация несоответствующей функциональности.
-
Разработка неправильного пользовательского интерфейса.
-
«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
-
Непрекращающийся поток изменений.
-
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
-
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
-
Недостаточная производительность получаемой системы.
-
Разрыв между квалификацией специалистов и требованиями проекта.