Загрузил B Kc

4 лабораторная

реклама
4 лабораторная
1. Методология MSF. Модели и дисциплины MSF
Методология Microsoft Solutions Framework (разработана компанией Microsoft) описывает
подходы и принципы управления людьми и рабочими процессами для организации
процесса разработки программного обеспечения.
Модель процесса MSF. Модель процесса MSF служит основой методологии MSF. Он
обеспечивает основу для управления проектами и состоит из пяти этапов:
а. Предвидение: на этом этапе основное внимание уделяется пониманию видения, целей
и масштаба проекта. Он включает в себя определение заинтересованных сторон,
определение бизнес-требований и проведение начального планирования.
б. Планирование: на этом этапе создаются подробные планы проекта, включая график
разработки, распределение ресурсов, оценку рисков и стратегии обеспечения качества.
Команда проекта определяет технический подход и создает план проекта для руководства
реализацией.
в. Разработка: Этап разработки включает в себя выполнение плана проекта и разработку
решения. Он включает в себя такие действия, как проектирование архитектуры решения,
кодирование, тестирование и документирование программного обеспечения.
д. Стабилизация: на этом этапе основное внимание уделяется решению проблем,
стабилизации решения и подготовке к развертыванию. Он включает в себя такие действия,
как тестирование производительности, приемочное тестирование пользователями и
устранение выявленных дефектов.
е. Развертывание. Заключительный этап включает доставку решения конечным
пользователям и ввод его в эксплуатацию. Этот этап включает в себя такие действия, как
обучение пользователей, развертывание системы и передача знаний.
Дисциплины MSF: На каждом этапе модели процессов MSF соблюдаются определенные
дисциплины для обеспечения эффективного управления проектами. Методология MSF
включает в себя следующие дисциплины:
а. Управление рисками: эта дисциплина фокусируется на выявлении, оценке и управлении
рисками на протяжении всего проекта. Он включает в себя выявление потенциальных
рисков, анализ их воздействия и вероятности, а также разработку стратегий смягчения
последствий.
б. Командная модель. Дисциплина командной модели делает упор на командную работу,
сотрудничество и эффективное общение внутри команды проекта. Он устанавливает
руководящие принципы для групповых ролей и обязанностей, каналов связи и процессов
принятия решений.
в. Управление проектами. Дисциплина «Управление проектами» предоставляет
рекомендации по планированию проектов, составлению графиков и управлению
ресурсами. Он охватывает такие действия, как определение целей проекта, создание
структур разбивки работ, мониторинг хода выполнения и контроль содержания,
расписания и бюджета проекта.
д. Управление готовностью. Эта дисциплина направлена на обеспечение готовности
решения к развертыванию и принятию конечными пользователями. Сюда входят такие
действия, как обучение пользователей, управление изменениями и подготовка
механизмов поддержки решения.
е. Управление решениями. Дисциплина управления решениями фокусируется на
управлении решением на протяжении всего его жизненного цикла. Он включает в себя
такие действия, как разработка решения, архитектура, документация и управление
конфигурацией.
ф. Архитектура жизненного цикла. Дисциплина «Архитектура жизненного цикла»
фокусируется на определении и поддержке общей архитектуры решения. Это гарантирует,
что решение соответствует целям, стандартам и технологическим платформам
организации.
2. Модель процесса MSF. Итеративная разработка
Модель процесса MSF (Microsoft Solutions Framework) представляет собой структуру
управления проектами, разработанную Microsoft для проектов разработки программного
обеспечения. Он обеспечивает структурированный и итеративный подход к управлению
проектами, обеспечивая гибкость и адаптируемость на протяжении всего жизненного
цикла проекта. Одной из ключевых характеристик модели процесса MSF является
поддержка итеративной разработки. Давайте рассмотрим, как модель процесса MSF
включает итеративную разработку.
В модели процесса MSF разработка программного решения делится на несколько
итераций, каждая из которых направлена на предоставление определенного набора
функций. Эти итерации ограничены по времени и обычно имеют фиксированную
продолжительность, например от двух до четырех недель. Итеративный подход позволяет
постепенно улучшать и развивать программное решение, основываясь на отзывах и
обучении на каждой итерации.
Вот ключевые аспекты итеративной разработки в рамках модели процесса MSF:
1) Инкрементная поставка: Модель процесса MSF способствует поэтапной поставке
функциональности. Вместо того, чтобы пытаться предоставить все решение сразу,
проектная группа сосредотачивается на предоставлении небольших, управляемых
приращений функциональности в каждой итерации. Это позволяет заинтересованным
сторонам видеть развивающееся решение и взаимодействовать с ним на ранней
стадии, а также предоставляет возможности для сбора отзывов и внесения изменений.
2) Обратная связь и обучение. Итеративная разработка в модели процесса MSF
способствует постоянной обратной связи и обучению. В конце каждой итерации
заинтересованные стороны имеют возможность просмотреть реализованную
функциональность и оставить отзыв. Эта обратная связь используется для уточнения и
определения приоритетов будущих итераций, обеспечивая соответствие проекта
ожиданиям и требованиям заинтересованных сторон.
3) Адаптивность и гибкость. Модель процесса MSF признает, что проекты разработки
программного обеспечения часто сталкиваются с изменяющимися требованиями,
технологическими достижениями и растущими потребностями бизнеса. Итеративный
подход обеспечивает гибкость и приспособляемость к этим изменениям. Команда
проекта может включать новые требования, решать проблемы и вносить коррективы в
последующие итерации на основе уроков, извлеченных из предыдущих итераций.
4) Снижение рисков. Разбивая процесс разработки на итерации, модель процесса MSF
помогает снизить риски. Это позволяет на раннем этапе выявить и решить
потенциальные проблемы и риски. Любые риски или проблемы, обнаруженные во
время итерации, могут быть устранены в последующих итерациях, что сводит к
минимуму влияние на общий график проекта и результаты.
5) Непрерывное совершенствование. Итеративное развитие модели процесса MSF
способствует постоянному совершенствованию на протяжении всего жизненного
цикла проекта. Команда проекта может проанализировать результаты и проблемы
каждой итерации, определить области для улучшения и применить эти уроки к
последующим итерациям. Этот итеративный процесс обучения и совершенствования
помогает повысить качество, эффективность и результативность усилий по разработке
программного обеспечения.
3. Структура модели жизненного цикла MSF. Вехи и фазы.
Модель жизненного цикла MSF (Microsoft Solutions Framework) состоит из ряда фаз и вех,
определяющих продвижение проекта разработки программного обеспечения. Структура
модели жизненного цикла MSF помогает организовать деятельность проекта и управлять
ею, а также обеспечивает получение ключевых результатов и решений на
соответствующих этапах. Давайте рассмотрим структуру модели жизненного цикла MSF,
включая его фазы и вехи.
Фаза представления:
Веха: концепция утверждена
Цель: На этом этапе команда проекта тесно сотрудничает с заинтересованными
сторонами, чтобы определить видение, цели и объем проекта. Оценивается
осуществимость проекта, определяются требования высокого уровня и риски. Веха
«Утверждено видение» отмечает официальное утверждение видения проекта и решение
перейти к следующему этапу.
Этап планирования:
Веха: утвержден план проекта
Цель: Этап планирования фокусируется на разработке подробного плана проекта. Команда
проекта определяет график проекта, требования к ресурсам, бюджет и цели в области
качества. Риски анализируются и снижаются, а также создается подробная структура
разбивки работ. Веха Project Plan Approved означает утверждение плана проекта и
готовность приступить к разработке.
Этап разработки:
Вехи: базовый уровень завершен, промежуточный обзор
Цель: Этап разработки включает фактическую разработку программного решения. Он
включает в себя такие действия, как сбор требований, проектирование, кодирование,
тестирование и документирование. Веха «Базовое завершение» представляет собой
завершение базового плана решения, которое можно протестировать и подтвердить.
Промежуточная веха — это контрольная точка для оценки прогресса, проверки решения и
внесения необходимых корректировок.
Стабилизирующая фаза:
Вехи: завершение кода, завершение приложения
Цель: этап стабилизации направлен на стабилизацию решения и подготовку его к
развертыванию. Он включает в себя такие действия, как всестороннее тестирование,
исправление ошибок, настройка производительности и приемочное тестирование
пользователями. Веха Code Complete означает завершение кодирования и готовность к
тестированию. Веха Application Complete отмечает завершение всех действий по
разработке и стабилизации.
Этап развертывания:
Вехи: готовность к выпуску, выпуск утвержден
Цель. Этап развертывания включает в себя развертывание и доставку программного
решения конечным пользователям. Сюда входят такие действия, как обучение
пользователей, документация, планирование поддержки и подготовка к развертыванию.
Веха «Готовность к выпуску» указывает, что решение готово к развертыванию. Веха Release
Approved означает окончательное утверждение развертывания решения в целевой среде.
4. Методология RUP
Методология Rational Unified Process (разработана компанией Rational Software)
описывает, как эффективно применять коммерчески обоснованные и практически
опробованные подходы к разработке программных продуктов.
5. Модель процесса разработки RUP. Фазы и итерации
RUP разделен на четыре фазы, каждая из которых состоит из нескольких итераций. Фазы и
итерации в модели процесса разработки RUP следующие:
Начальная фаза:
Итерация 1. Во время этой итерации проектная группа разрабатывает экономическое
обоснование, определяет объем системы, определяет ключевых заинтересованных лиц и
выполняет начальное технико-экономическое обоснование.
Итерация 2. Целью этой итерации является дальнейшее уточнение требований,
определение архитектуры и высокоуровневого дизайна, а также создание
предварительного плана проекта.
Этап проработки:
Итерация 3. Эта итерация включает в себя сбор и анализ подробных требований, создание
подробной системной архитектуры, разработку комплексного плана проекта, а также
выявление и снижение областей высокого риска.
Итерация 4. Основное внимание в этой итерации уделяется проверке архитектуры путем
создания прототипа, разработки более детального проекта и уточнения плана проекта.
Этап строительства:
Итерация 5: Эта итерация включает в себя разработку программных компонентов,
интеграцию компонентов и проведение модульного тестирования для обеспечения
функциональности и качества системы.
Итерация 6. Основное внимание в этой итерации уделяется дальнейшей разработке и
интеграции программных компонентов, проведению системного тестирования и
уточнению системной документации.
Переходная фаза:
Итерация 7. Во время этой итерации система подготавливается к развертыванию, включая
окончательную подготовку пользовательской документации, проведение приемочного
тестирования пользователями и подготовку к выпуску системы.
Итерация 8. Основное внимание в этой итерации уделяется развертыванию системы в
производственной среде, обучению конечных пользователей и устранению любых
оставшихся проблем или дефектов.
6. Дисциплины RUP.
Дисциплины
Дисциплина RUP соответствует понятию технологического процесса и представляет собой
последовательность действий, приводящую к получению значимого результата. В рамках
RUP определены шесть основных дисциплин (технологических процессов) и три
вспомогательных (поддерживающих).
Бизнес-моделирование:
Цель: Дисциплина «Бизнес-моделирование» фокусируется на понимании бизнесконтекста и требований к программному решению. Он включает в себя такие действия, как
определение бизнес-процессов, определение вариантов использования, анализ
требований и создание бизнес-моделей. Цель состоит в том, чтобы привести программное
решение в соответствие с потребностями бизнеса и убедиться, что оно приносит пользу
организации.
Требования:
Цель: дисциплина «Требования» занимается выявлением, документированием и
управлением требованиями к программному решению. Он включает в себя такие
действия, как сбор потребностей пользователей, определение функциональных и
нефункциональных требований, создание моделей вариантов использования и проверка
требований. Цель состоит в том, чтобы установить четкое понимание того, что должно
делать программное обеспечение, и управлять изменениями требований на протяжении
всего проекта.
Анализ и дизайн:
Цель: Дисциплина «Анализ и проектирование» направлена на преобразование
требований в детальный проект программного обеспечения. Он включает в себя такие
действия, как создание архитектурных моделей, определение системных компонентов,
определение интерфейсов и проектирование классов и объектов. Цель состоит в том,
чтобы разработать надежную и гибкую программную архитектуру, отвечающую
требованиям и поддерживающую будущие усовершенствования и обслуживание.
Выполнение:
Цель: Дисциплина «Реализация» связана с фактическим кодированием и модульным
тестированием программного решения. Он включает в себя такие действия, как написание
кода, создание программных компонентов, проведение модульных тестов и интеграция
компонентов в работающую систему. Цель состоит в том, чтобы создать
высококачественный код, реализующий дизайн и отвечающий требованиям.
Тестирование:
Цель: Дисциплина «Тестирование» фокусируется на проверке и проверке программного
решения. Он включает в себя такие действия, как создание планов тестирования,
проведение функциональных и нефункциональных тестов, выявление и исправление
дефектов, а также проведение системных интеграционных тестов. Цель состоит в том,
чтобы гарантировать, что программное обеспечение соответствует заданным
требованиям, правильно функционирует и работает так, как ожидалось.
Развертывание:
Назначение: Дисциплина «Развертывание» занимается упаковкой, установкой и выпуском
программного решения. Он включает в себя такие действия, как подготовка пакетов
развертывания, настройка программного обеспечения для конкретных сред, проведение
приемочных испытаний пользователями и развертывание решения для конечных
пользователей. Цель состоит в том, чтобы успешно доставить программное обеспечение в
целевую среду и обеспечить его правильную установку и работу.
Конфигурация и управление изменениями:
Цель: Дисциплина «Управление конфигурацией и изменениями» фокусируется на
управлении конфигурацией программного обеспечения и контроле над изменениями на
протяжении всего проекта. Он включает в себя такие действия, как контроль версий,
управление конфигурацией, отслеживание изменений и управление выпусками. Цель
состоит в том, чтобы обеспечить эффективное управление программным обеспечением,
контроль над изменениями и надлежащее обслуживание артефактов проекта.
Управление проектом:
Назначение: Дисциплина «Управление проектами» занимается планированием,
мониторингом и контролем проекта разработки программного обеспечения. Он включает
в себя такие действия, как планирование проекта, управление рисками, распределение
ресурсов, отслеживание прогресса и общение с заинтересованными сторонами. Цель
состоит в том, чтобы обеспечить выполнение проекта вовремя, в рамках бюджета и в
соответствии с установленными стандартами качества.
7.
Скачать