- •Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Ивановский государственный энергетический университет имени в.И. Ленина».
- •Иваново 2014
- •Оглавление
- •Предисловие
- •Введение
- •1.Предмет программной инженерии
- •1.1.Определение и свойства программного обеспечения
- •1.2.Проблемы разработки программного обеспечения
- •1.3.Процессы производства программного обеспечения
- •1.4.Понятие программного проекта
- •1.5. Стандартизация в области производства по
- •1.6.Определение программной инженерии и ее место в системе информационных технологий
- •2.Жизненный цикл программных продуктов
- •2.1.Понятие жизненного цикла
- •2.2.Процессы жизненного цикла программного обеспечения
- •2.3.Модели жизненного цикла
- •3.Виды деятельности в программной инженерии
- •3.1.Управление требованиями
- •3.1.1.Проблема
- •3.1.2.Цикл работы с требованиями
- •3.1.3.Виды и свойства требований
- •3.1.4.Варианты формализации требований
- •3.2.Проектирование программного обеспечения
- •3.2.1.Понятие
- •3.2.2.Принципы
- •3.2.3.Шаблоны
- •3.2.4.Моделирование по
- •3.2.5.Методологии
- •3.2.6.Оценка качества
- •3.3.Конструирование программного обеспечения
- •3.3.1.Определение
- •3.3.2.Связь с другими процессами
- •3.3.3.Принципы
- •3.3.4.Модели и методы
- •3.3.5.Языки конструирования
- •3.4.Конфигурационное управление
- •3.4.1.Проблемы управления активами программного проекта
- •3.4.2.Единицы конфигурационного управления
- •3.4.3.Управление версиями
- •3.4.4.Управление сборками
- •3.4.5.Понятие baseline
- •3.5.Тестирование программного обеспечения
- •3.5.1.Основные определения
- •3.5.2.Уровни тестирования (Test Levels)
- •3.5.3.Виды тестирования
- •3.5.4.Метрики
- •3.6.Сопровождение программного обеспечения
- •Эволюция программного обеспечения (Evolution of Software)
- •4.Методология объектно-ориентированного анализа и проектирования
- •4.1.Основные понятия
- •4.1.1.Объекты и классы
- •4.1.2.Принципы ооп
- •4.1.3.Разработка объектно-ориентированных программ
- •4.2.Язык uml
- •4.2.1.Что дает uml
- •4.2.2.Структура языка uml
- •4.2.3.Uml диаграммы
- •4.2.4.Программы поддержки языка uml
- •4.3.Вопросы для самоконтроля
- •5.Технологии разработки программного обеспечения
- •5.1.Тяжеловесные и облегченные технологии
- •5.2.Технология rup
- •5.3.Гибкие технологии
- •5.4.Технология msf
- •5.4.1. Управление рисками в msf for Agile Software Development1
- •5.4.2.Основные сведения о рисках
- •5.4.3.Планирование управления рисками
- •5.4.4.Процесс управления рисками
- •5.4.5.Управление рисками как составная часть жизненного цикла проекта
- •5.4.6.Учебный пример. Выделение рисков
- •5.5.Модель процессов msf for Agile Software Development2
- •5.5.1.Принципы модели процессов
- •5.5.2.Управление компромиссами
- •5.5.3.Схема процесса разработки
- •5.6.1. Подготовка проекта
- •5.6.2. Планирование проекта
- •5.6.3. Планирование спринта
- •5.6.4. Выполнение спринта
- •5.6.5. Отслеживание проекта
- •5.7.1. Каково назначение модели cmmi?
- •5.7.2. Как лучше использовать модель cmmi?
- •5.7.3. Элементы модели cmmi
- •Заключение Литература
- •153003, Г. Иваново, ул. Рабфаковская, 34.
5.3.Гибкие технологии
5.3.1.SCRUM
Метод предложен в 1986 в Японии.
Позволяет гибко разрабатывать проекты небольшими командами 7 человек ±2 в ситуации изменяющихся требований. При этом процесс разработки итеративен и представляет большую свободу команде.
Работа начинается с формирования требований ко всему продукту, из них выбирается самое актуальное и создается план следующей итерации, в течении итерации планы не меняются. Итерация заканчивается созданием работоспособной версии продукта, который можно предъявить заказчику. После этого результаты обсуждаются и требования к продукту корректируются. В SCRAM выделяют 3 вида ролей:
Владелец продукта – менеджер проекта который представляет интересы заказчика, в его обязанности входит разработка требований. И он совершенно не участвует в выполнении самой итерации.
Scrum master – обеспечивает продуктивную работу команды. Решает административные и хозяйственные задачи.
Scrum команда – группа состоящая из 5-9 самостоятельных и инициативных программистов.
Задачи команды:
Постановка для итерации реально достижимых задач.
Выполнение плана итерации во что бы то не стало в отведенные сроки.
В Scrum определены следующие практики:
Spring planning meeting (собрание по планированию продуктов) – проводятся в начале каждой итерации, итерацию в scrum называют sprint. Участвуют представители заказчика и Scrum master, создается список приоритетных задач и оценивается трудоемкость каждой из них.
Ежедневные совещания (15 минут) – каждый участник команды отвечает на 3 вопроса:
Что я сделал со времени предыдущей встречи.
Мои проблемы
Что я буду делать до следующей встречи.
Собрание для обзора результатов спринта, на них программа демонстрируется владельцу продукта, проводится анализ прошедшего спринта, который ведет scrum master, scrum команда ищет пути для повышения эффективности дальнейшей работы.
5.4.Технология msf
Стремясь достичь максимальной отдачи от IT-проектов, Майкрософт выпустил в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Все это представлено в виде двух связанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).
Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Информация по MSF доступна в Internet по адресу http://www.microsoft.com/msf/.
MOF призван обеспечить организации, создающие критически важные (mission-critical) IT‑решения на базе продуктов и технологий Майкрософт, техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала, процессов; технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленной Central Computer and Telecommunications Agency - Агентством правительства Великобритании. Информация по MOF доступна в Internet по адресуhttp://www.microsoft.com/mof/.
Технология разработки решений по проектированию и реализации информационных технологий - Microsoft Solution Framework (MSF) содержит в себе набор моделей и четко определенных этапов, которые можно рассматривать и как рекомендации, и как руководство по планированию, ведению и управлению проектами создания информационных систем. Эти модели - результат интеграции в единую систему наиболее успешных и многократно примененных практик, выявленных в процессе анализа опыта по разработке программных продуктов, накопленного фирмой Microsoft, ее заказчиками и партнерами.
Перед многими компаниями стоит задача так организовать управление проектами, чтобы программные продукты были неизменно высокого качества, и всегда появлялись в срок и в рамках бюджета. Методология создания программных решений Microsoft Solutions Framework (MSF) опирается на практический опыт корпорации Майкрософт и описывает управление людьми и рабочими процессами в процессе разработки решения под бизнес-требования заказчика.
Microsoft Solutions Framework представляет собой согласованный набор концепций, моделей и правил.
На сайте компании Майкрософт http://www.microsoft.com/rus/msdn/msf/default.mspx представлены переводы следующих документов :
Модель процессов MSF. В модели процессов приводится общее описание организации работ над проектом по разработке и внедрению ИТ-решений.Предлагаемая схема достаточно гибка и может применяться к самым разным проектам в области информационных технологий. В версии 3 концепция была расширена и теперь охватывает практически весь цикл создания решений — начиная с их обсуждения и заканчивая внедрением. Такой подход поможет разработчикам сосредоточиться на решении проблем заказчика, так как реальная отдача (business value) появляется только после того, когда решение внедрено и работает.
Модель проектной группыMSF. В модели проектной группы описывается подход Microsoft по организации труда исполнителей с целью обеспечить успешное выполнение проекта. В модели определяются роли исполнителей, функции, области ответственности и принципы управления, которые помогают каждому из участников проекта выполнять задачи, которые ставятся перед ними по мере выполнения проекта.
Дисциплина управления рисками MSF. Управление рисками — это одна из основных дисциплин в Microsoft Solution Framework. В методологии MSF с самого начала учитывается, что IT-проекты могут изменяться в процессе реализации, что вносит дополнительную неопределенность. В дисциплине управления рисками MSF предлагается упреждающий подход к управлению рисками, их постоянная оценка и учет при принятии решений.
Дисциплина управления проектами MSF. Управление проектами в MSF построено с учетом работы распределенных проектных групп. Таким образом, предлагаемые механизмы учета обладают большей гибкостью и лучше масштабируются при переходе от малых проектов к большим. В статье описываются принципы управления распределенными проектами и место, которое управление проектом занимает в концепции MSF.
Дисциплина управления подготовкой MSF. Управление подготовкой — еще одна ключевая концепция в MSF. В статье представлено описание принципов учета и управления знаниями, навыками и способностями, которые необходимы для успешного планирования, реализации и управленияИТ-проектами.
Одно из ключевых свойств MSF — возможность коллективного обсуждения в терминах вышеозначенных моделей различных высокоуровневых аспектов проекта, включая концепцию, архитектуру и распределение обязанностей. Другой ключевой аспект — связанность проектной группы и проекта: проект заканчивают те же люди, что и начинают (в противовес другому подходу, при котором над проектом работают несколько групп, каждая из которых, выполнив свой узкоспециализированный кусочек работы, передает проект другой группе, и так вплоть до его завершения). Таким образом, группа, работающая над проектом, обладает всеми навыками, необходимыми для принятий решений, ведущих к его завершению. Развитие же самого проекта рассматривается как последовательное прохождение вех (milestones), позволяющих проектной группе соизмерять степень соответствия первоначального замысла и актуального проекта.
Microsoft все время оценивает свои собственные методологии по ведению проектов, а также отзывы использующих MSF. Анализ этой информации приводит к расширению существующих моделей MSF и включению новых, что делает MSF динамической, постоянно развивающейся и улучшающейся системой.
