Основные методологии разработки программного обеспечения

Управление проектами

Рассматривает группы процессов и области знания по управлению проектами:

Группы процессов:

• Группа процессов инициирования
• Группа процессов планирования
• Группа процессов исполнения
• Группа процессов мониторинга и управления
• Группа завершающих процессов

Области знаний:

• Управление интеграцией проекта
• Управление содержанием проекта
• Управление сроками проекта
• Управление стоимостью проекта
• Управление качеством проекта
• Управление человеческими ресурсами проекта
• Управление коммуникациями проекта
• Управление рисками проекта
• Управление поставками проекта

MSF

MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers. Начинать изучение MSF лучше с моделей, а затем перейти к дисциплинам.

MSF содержит модели и дисциплины:

• Модели:
  • модель проектной группы
  • модель процессов
• Дисциплины:
  • дисциплина управление проектами
  • дисциплина управление рисками
  • дисциплина управление подготовкой

Модель проектной группы

Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.

Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков пирамидальной, иерархической структуры традиционных проектных групп. В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться.

Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы. MSF включает в себя ряд основных принципов, которые имеют отношение к успешной работе команды:

• Распределение ответственности при фиксации отчетности
• Наделяйте членов команды полномочиями
• Концентрируйтесь на бизнес-приоритетах
• Единое видение проекта
• Проявляйте гибкость — будьте готовы к переменам
• Поощряйте свободное общение

Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций:

• Команда соратников
• Сфокусированность на нуждах заказчика
• Нацеленность на конечный результат
• Установка на отсутствие дефектов
• Стремление к самосовершенствованию
• Заинтересованные команды работают эффективно

MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из её ролевых кластеров ассоциирован с одной из упомянутых шести целей и работает над её достижением.

В проектную группу входят такие ролевые кластеры:

• управление программой (program manager) — разработку архитектуры решения, административные службы;
• разработку (developer) — разработку приложений и инфраструктуры, технологические консультации;
• тестирование (QAE) — планирование, разработку тестов и отчетность по тестам;
• управление выпуском (release manager) — инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;
• удовлетворение заказчика (user experience) — обучение, эргономику, графический дизайн, техническую поддержку;
• управление продуктом (product manager) — бизнес-приоритеты, маркетинг, представительство интересов заказчика.

Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести — один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц. Минимальный коллектив по MSF может состоять всего из трех человек. В малых проектных группах объединение ролей является необходимым, при этом должны соблюдаться два принципа:

1. Роль команды разработчиков не может быть объединена ни с какой другой ролью.
2. Избежание сочетания ролей, имеющих предопределенные конфликты интересов.

Одна из характерных особенностей MSF — отсутствие должности менеджера проекта! Ответственность за управление проектом распределена между лидерами ролевых кластеров внутри команды. Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams).

Модель процессов

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral).

Процесс MSF ориентирован на «вехи» (milestones) — ключевые точки проекта, характеризующие достижение существенного результата. Модель процессов включает такие основные фазы:

• Выработка концепции (Envisioning)
• Планирование (Planning)
• Разработка (Developing)
• Стабилизация (Stabilizing)
• Внедрение (Deploying)

В рамках MSF программный код, документация, дизайн и планы создаются итеративными методами. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности (стратегия версионирования). Решение не представляет бизнес-ценности, пока оно не внедрено, именно по этой причине модель процессов MSF содержит весь жизненный цикл создания решения, включая его внедрение.

Управление рисками

Управление рисками (risk management) — это одна из ключевых дисциплин MSF. MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина отстаивает превентивный подход к работе с рисками, непрерывное оценивание рисков и использование информации о них в рамках процесса принятия решений. Девиз MSF — мы не боремся с рисками, мы ими управляем.

Управление проектом

Проект — ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги. Хорошо известна взаимозависимость между ресурсами проекта, его календарным графиком и реализуемыми возможностями. Эти три переменные образуют так называемый «треугольник компромиссов».

Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом является WBS (Иерархическая структура работ). В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры.

Управление подготовкой

Управление подготовкой посвящено управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина описывает фундаментальные принципы MSF и дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий.

Agile

Гибкая методология разработки (Agile software development) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп. Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов (итераций), которые обычно длятся две-три недели.

Принципы

Agile определяется Agile Manifesto, разработанным и принятым в феврале 2001 года. Манифест содержит 4 основные идеи и 12 принципов.

Основные идеи:

• Личности и их взаимодействия важнее, чем процессы и инструменты;
• Работающее программное обеспечение важнее, чем полная документация;
• Сотрудничество с заказчиком важнее, чем контрактные обязательства;
• Реакция на изменения важнее, чем следование плану.

Принципы:

• удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
• приветствие изменений требований даже в конце разработки;
• частая поставка рабочего программного обеспечения;
• тесное, ежедневное общение заказчика с разработчиками;
• проектом занимаются мотивированные личности, обеспеченные нужными условиями;
• рекомендуемый метод передачи информации — личный разговор;
• работающее ПО — лучший измеритель прогресса;
• спонсоры, разработчики и пользователи должны поддерживать постоянный темп;
• постоянное внимание улучшению технического мастерства и удобному дизайну;
• простота — искусство не делать лишней работы;
• лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
• постоянная адаптация к изменяющимся обстоятельствам.

Критика

Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием плана развития продукта. Гибкий подход подразумевает возможность заказчика неожиданно выставлять новые требования, что иногда приводит к катастрофическим «авралам» с массовым рефакторингом. Кроме того, считается, что работа в agile мотивирует разработчиков решать задачи простейшим способом, что может приводить к снижению качества продукта и накоплению скрытых дефектов.

RUP

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

Принципы RUP

В основе RUP лежат следующие принципы:

• Ранняя идентификация и непрерывное устранение основных рисков.
• Концентрация на выполнении требований заказчиков (анализ и построение модели прецедентов).
• Ожидание изменений в требованиях и реализации в процессе разработки.
• Компонентная архитектура, реализуемая и тестируемая на ранних стадиях.
• Постоянное обеспечение качества на всех этапах разработки.
• Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Жизненный цикл

RUP использует итеративную модель разработки. В конце каждой итерации (от 2 до 6 недель) команда должна достичь запланированных целей и получить промежуточную функциональную версию продукта. Это позволяет быстро реагировать на меняющиеся требования и эффективно контролировать качество.

Процессный подход

При процессном подходе управление рассматривается как процесс — серия взаимосвязанных непрерывных действий (управленческих функций). Наиболее признанными считаются четыре первичных функции: ПЛАНИРОВАНИЕ, ОРГАНИЗАЦИЯ, МОТИВАЦИЯ И КОНТРОЛЬ. Они объединены связующими процессами коммуникации и принятия решения.

Функция планирования

Функция планирования предполагает решение о том, какими должны быть цели организации и что надо делать для их достижения. Она отвечает на три основных вопроса:

1. Где мы находимся в настоящее время? Оценка сильных и слабых сторон организации и прогноз внешней среды.
2. Куда мы хотим двигаться? Определение целей организации на основе анализа возможностей и угроз.
3. Как мы собираемся сделать это? Решение того, что конкретно надо делать для достижения поставленных целей.

Планирование не представляет собой одноразового события, оно должно осуществляться непрерывно из-за постоянной неопределенности будущего.

Функция организации

Организовать — значит создать некую структуру, чтобы предприятие могло выполнить свои планы. Руководитель подбирает людей для конкретной работы, делегируя задания и полномочия. Делегирование — это средство, с помощью которого руководство осуществляет выполнение работы с помощью других лиц.

Мотивация

Задача функции мотивации заключается в том, чтобы члены организации выполняли работу в соответствии с порученными им обязанностями. Исследования в области поведенческих наук показали, что мотивация является результатом сложной совокупности потребностей. Руководитель должен определить эти потребности и обеспечить условия для их удовлетворения через хорошую работу.

Контроль

Контроль — это процесс обеспечения того, что организация действительно достигает своих целей. Он включает три аспекта:

1. Установление стандартов — точное определение целей на основе планов.
2. Измерение — сравнение достигнутого с ожидаемыми результатами.
3. Корректировка — действия для устранения отклонений от первоначального плана.

Связующие процессы

Принятие решений — это выбор того, как и что планировать, организовать, мотивировать и контролировать. Наличие точной информации является основным требованием для принятия эффективного решения.

Коммуникация

Коммуникация — это процесс обмена информацией между двумя и более людьми. В процессе обмена информацией можно выделить четыре базовых элемента:

1. Отправитель — лицо, генерирующее идеи или собирающее информацию.
2. Сообщение — собственно информация, закодированная с помощью символов.
3. Канал — средства передачи информации.
4. Получатель — лицо, которому предназначается информация.

Этапы коммуникации включают: зарождение идеи, кодирование и выбор канала, передачу и декодирование.

ООП

Объектно-ориентированное программирование (ООП) ориентировано на разработку крупных программных комплексов. Объектно-ориентированное проектирование состоит в описании структуры и поведения системы: из каких частей она состоит и в чём состоит ответственность каждой из частей. Выделение частей производится таким образом, чтобы каждая имела минимальный набор выполняемых функций и взаимодействовала с другими частями как можно меньше.

Одна из известных проблем больших систем — проблема хрупкости базового класса, когда внесение изменений в код базовых классов иерархии может непредсказуемым образом отразиться на классах-потомках.

Родственные методологии

Прототип- и класс-ориентированное программирование — разные подходы к созданию программы, которые могут комбинироваться.

Компонентное программирование

Компонентно-ориентированное программирование — это «надстройка» над ООП, направленная на построение крупных развивающихся систем. Изменения вносятся путём создания новых компонентов. При создании новых компонентов запрещено использование наследования реализации — новый компонент может наследовать лишь интерфейсы базового. Таким образом обходится проблема хрупкости базового класса.

Прототипное программирование

Прототипное программирование отказалось от базовых понятий класса и наследования. Язык предоставляет механизм создания объекта и механизм клонирования объектов. Каждый объект может стать прототипом для создания нового объекта. Среда исполнения обеспечивает механизм делегирования — если объект не содержит нужного метода, вызов передаётся прототипу.

Класс-ориентированное программирование

Класс-ориентированное программирование сфокусировано на данных, причем данные и поведение неразрывно связаны между собой и представляют собой класс. Класс определяет структуру и функциональность, одинаковую для всех экземпляров. Экземпляр является носителем данных и обладает состоянием, меняющимся в соответствии с поведением, заданным классом.

IDEF0

IDEF0 — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность.

Стандарт IDEF0 представляет организацию как набор модулей. Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов.

EPC

Событийная цепочка процессов (EPC-диаграмма, event-driven process chain) — тип блок-схемы, используемой для бизнес-моделирования. EPC может быть использована для настройки системы планирования ресурсов предприятия (ERP) и для улучшений бизнес-процессов.

Организации используют EPC-диаграммы для планирования потоков работ бизнес-процессов. EPC-метод был разработан Августом-Вильгельмом Шеером в рамках работ над созданием ARIS в начале 1990-х годов.

Элементы событийных цепочек процессов

• События — пассивные элементы, фиксирующие состояние параметров на определенный момент времени (изображаются в виде шестиугольника).
• Функции — активные элементы, определенное действие, выполняемое в течение некоторого промежутка времени.
• Организационная единица — должность или подразделение, которому может быть поручено выполнение функции.
• Информация, материал или объект ресурса — объекты реального мира, выступающие входными или выходными данными (изображаются в виде прямоугольника).
• Логический соединитель — элемент управления, определяющий ветвление потока работ (конъюнкция, дизъюнкция или строгая дизъюнкция).

Поток управления соединяет события с функциями, создавая хронологическую последовательность, и представлен как пунктирная стрелка.

UML

UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.

Использование

Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур. UML позволяет разработчикам достигнуть соглашения в графических обозначениях для представления общих понятий и больше сконцентрироваться на проектировании и архитектуре.