Эволюция подходов к управлению программными проектами.

 

За 50 лет развития программной инженерии накопилось большое количество моделей разработки ПО, но мы среди этого большинства моделей можем выделить главные:

1. Подход «как получится»

· Разомкнутая система управления

· Полное доверие техническим лидерам

· Представители бизнеса практически не участвуют в проекте

· Планирование неформальное и словесное

· Время и бюджет, как правило, не контролируются

1. Подход «водопад» или «каскадная модель»
• Жесткая последовательная схема управления, переход на каждый следующий этап только после завершения предыдущего
• Лучше предыдущего, но не эффективно
2. «Гибкое управление»

 

· Создание опорного базового проекта, включающего основные требования, изменения отклонений, новый расчет

· Гибкие методы позволяют учитывать внесение изменений и добавлений в программную реализацию

 

«ГОСТы»

По ГОСТам разработка производится по этапам, каждый из которых предполагает выполнение строго определенного набора работ – «каскадная модель».

 

«RUP» – Rational Unified Process – унифицированный процесс, разработанный сотрудниками компании Rational Software в качестве дополнения к языку UML.

Модель RUP описывает стандартный общий процесс, на основе которого проектная команда должна создать конкретный специализированный проект, ориентированный на конечного потребителя.

 

Выбор модели процесса

 

1. Тяжелые процессы (каскадная модель)

ПЛЮСЫ:

• Рассчитаны на среднюю квалификацию исполнителей
• Большая специализация исполнителей
• Низкие требования к стабильности команды

МИНУСЫ:

· Требуют существенной управленческой надстройки

· Более длительные стадии анализа и проектирования

· Более формализованные коммуникации (большое количество документации, которое передается от одного человека к другому)

 

1. Легкие модели

ПЛЮСЫ:

· Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурацией

· Упрощенные стадии анализа и проектирования

· Основной упор на разработку функциональности, совмещение ролей

· Неформальные коммуникации

НЕДОСТАТКИ:

· Эффективность разработки сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды

· Объемы и сложность выполняемых объектов ограничены

 

 

Успешность проекта

Для успешности программного проекта необходимо:

· Четко ставить цели

· Определять способ достижения целей

· Контролировать и управлять реализацией

· Анализировать угрозы и противодействовать им

· Создавать команду

 

Существует тест программного проекта на выживание. Так называемый check-лист из 33 пунктов. Каждый пункт этого теста оценивается от 0 до 3, применяются поправочные компоненты: для малых проектов 1,5, для средних (от 5 до 20 человек) – 1,25.

 

Организация проектной команды

 

Роли и ответственности участников типового проекта разработки ПО можно условно разделить на 5 групп:

1. АНАЛИЗ

Извлечение, документирование и сопровождение требований к продукту.

Группа анализа включает следующие роли:

• Бизнес-аналитик (построение модели предметной области)
• Бизнес-архитектор (разработка бизнес-концепции системы, определение общего видения продукта, его интерфейсы, поведение и ограничение)
• Системный аналитик (отвечает за перевод требований к продукту в функциональные требования к ПО)
• Специалист по требованиям (документирование и сопровождение требований к продукту)
• Менеджер продукта/функциональный заказчик (представляет интересы пользователей к продукту)
1. УПРАВЛЕНИЕ

Определение и управление производственными процессами.

Группа требования состоит из:

· Руководитель проекта (отвечает за достижение целей по срокам, бюджету и содержанию)

· Куратор проекта (оценка планов и исполнения проекта)

· Системный архитектор (разработка технической концепции системы, ключевых проектных решений)

· Руководитель группы тестирования (определяет цели, стратегию и управляет тестированием)

· Ответственный за управление изменениями, конфигурациями, за сборку и поставку программного продукта

1. ПРОИЗВОДСТВО

Проектирование и разработка ПО.

В производственную группу входят:

· Проектировщик (проектирование компонентов и подсистем в соответствии с общей архитектурой и разработка архитектурно-значимых модулей)

· Проектировщик баз данных

· Проектировщик интерфейса пользователя

· Разработчик (проектирование, реализация, отладка отдельных модулей).

 

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

 

1. ТЕСТИРОВАНИЕ

Тестирование ПО.

Группа тестирования в проекте состоит из ролей:

· Проектировщик тестов (разработка тестовых сценариев)

· Разработчик автоматизированных тестов

· Тестировщик (тестирование продукта, анализ и документирование)

1. ОБЕСПЕЧЕНИЕ

Производство дополнительных продуктов и услуг

Группа обеспечения, как правило, не входит в команду проекта, выполняет работу в рамках своей процессной деятельности. Сюда относятся следующие роли:

· Технический писатель (работа по ведению документации, написание инструкций и т.п.)

· Переводчик

· Дизайнер графического интерфейса

· Разработчик учебных курсов

· Тренер (обучение пользователей)

· Продажа и маркетинг (продвижение)

· Системный администратор

· Специалист по инструментальным средствам и др.

 

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

 

Один человек может исполнять несколько ролей. Возможно такое совмещение:

• Руководитель проекта + системный аналитик (системный архитектор)
• Системный архитектор + разработчик
• Системный аналитик + проектировщик тестов (+ технический писатель)
• Системный аналитик + проектировщик интерфейса пользователя

 

15.02.10

Лекция 2. Язык UML

 

Список сокращений:

UML (Unified Modeling Language) – язык (система обозначений), используемый при объектно-ориентированном анализе и проектировании для моделирования свойств создаваемой системы

ОО – объектно-ориентированный

UP (Unified Process) – унифицированный процесс

OMG (Object Management Group) – группа управления объектами

MDA (Model Driven Architecture) – архитектура, управляемая моделью

CIM (Computer-Independent Model) – абстрактная управляемая моделью

PIM (Platform-Independent Model) – платформонезависимая модель

PSM (Platform-specific Model) – платформозависимая модель

 

UML – язык визуального моделирования для объектно-ориентированного моделирования. Унифицированный процесс (UP) обеспечивает каркас процесса производства программного обеспечения, так как указывает, как осуществлять процесс объектно-ориентированного анализа и проектирования.

 

Существует три способа использования UML:

• UML как эскиз, при котором используется схематическое изображение диаграмм, помогающее визуализировать программную систему. Условно: проект «на салфетке», VISIO и т.п.
• UML как модель. Более формальный и точный подход, при котором составляется подробное описание программной системы. Это как набор архитекторских планов или чертеж машины. Такой подход требует использования настоящего инструмента моделирования. Rational Software Modeling
• UML как исполняемый проект. С помощью MDA UML-модели возможна компиляция рабочего кода в соответствующей среде программирования.

UML

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

Рождение UML

До 1994 года существовало несколько конкурирующих языков и методологий визуального моделирования. Очевидные лидеры: Гради Бутч, Джеймс Рамбо, Джекапсон, объединив свои усилия, создали язык UML, который стал открытым промышленным стандартом. Rational Corporation.

 

UML постоянно расширяется и модифицируется, как промышленный стандарт. Унификация UML заключается в следующем:

• Жизненный цикл разработки ПО поддерживается визуальным синтаксисом UML (от постановки требований до реализации)
• UML используется в различных областях приложений (от аппаратных встроенных систем реального времени до систем поддержки принятия решений)
• UML является независимым от языков и платформ
• UML последовательно сохраняет применение небольшого набора своих диаграмм

 

Объекты UML

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

 

В UML-модели есть два аспекта:

· Статическая структура (описывает какие типы объектов важны для моделирования системы, и как они взаимосвязаны)

· Динамическое поведение (описывает жизненные циклы этих объектов и то, как они взаимодействуют друг с другом для обеспечения требуемой функциональности системы)

 

UML моделирует мир, как систему взаимодействующих объектов. Объект – это цельный блок, состоящий из данных и функциональности.

 

Структура UML

Как визуальный язык UML имеет структуру:

v Строительные блоки (основные элементы, отношения и диаграммы)

Сущности – это сами элементы модели. Это существительные UML-модели. Все UML-сущности можно разделить на:

• Структурные сущности – это существительные, такие как:
• класс,
• интерфейс,
• прецедент,
• компонент,
• узел
• Поведенческие сущности – это глаголы, такие как:
• Взаимодействие
• Деятельности
• Группирующие сущности – это пакеты для группировки семантически связанных элементов моделей и модули, образующие единые целое.
• Сущности-аннотации – это примечания, которые можно добавлять в модель.

 

Отношения, связывающие сущности. Определяют как семантически связаны две или более сущности. Позволяют показать взаимодействие в пределах модели двух или более сущностей

 

Тип отношения	UML-синтаксис	Краткая семантика
Источник	Цель
Зависимость		Исходный элемент зависит от целевого элемента и изменение последнего может повлиять на первый
Ассоциация		Описание набора связей
Агрегация		Целевой элемент является частью исходного элемента (ромбик не закрашен)
Композиция		Строгая, более ограниченная форма агрегирования
Включение		Исходный элемент содержит целевой элемент
Обобщение		Исходный элемент является специализацией более обобщенного целевого элемента и может замещать его
Реализация		Исходный элемент гарантированно выполняет контракт, определенный целевым элементом

 

 

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

 

Модель – это хранилище всех сущностей и отношений. Существует 13 различных типов диаграмм:

 

Структурные диаграммы:

· Пакетов

· Классов

· Компонентов

· Развертывания

· Объектов

· Композитных структур

Диаграммы поведения:

· Прецедентов использования

· Деятельности

· Конечных автоматов

Диаграммы взаимодействий:

· Последовательностей

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

· Обзоров взаимодействий

· Синхронизации

 

v Общие механизмы – пути достижения определенных целей

v Архитектура, как представление архитектуры будущей системы