Управление проектом ИС
Обзор гибких процессов
Гибкие методологии
Agile - методологии
- Нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения
- Когда меняются требования, команда разработчиков тоже меняется
- Команда с трудом может предсказать будущее проекта
- Существует точный план лишь на ближайшее время
- Более удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах.
Основные постулаты манифеста последователей гибких методологий (Agile Manifesto):
- Индивидуумы и их взаимодействие важнее процессов и инструментов
- Работоспособное программное обеспечение важнее обширной документации
- Сотрудничество с заказчиком важнее заключения контракта
- Готовность к изменениям важнее следования плану.
Agile - Методологии
Agile - Методологии
- ICONIX
- MSF for Agile Software Development
- Kanban in Software Development
- Scrum
- Lean Software Development
- DSDM (Dynamic System Development Method)
- AgileUP
- XP (eXtreme Programming)
- Crystal
- FDD (Feature Driven Development)
MSF for ASD
Microsoft Solutions Framework (MSF) for Agile Software Development.
- Используя типы рабочих элементов (WITs), отчеты и панели мониторинга, показанные на рисунке, команды могут планировать проекты и затем отслеживать ход реализации этих проектов, просматривать его и составлять соответствующие отчеты. Эти артефакты, основанные на принципах и значениях Agile, создаются при создании командного проекта с помощью шаблона процесса Microsoft Solutions Framework (MSF) for Agile Software Development.
- Последняя версия шаблона процесса Agile автоматически передается в Team Foundation Server (TFS) при установке или обновлении до последней версии TFS. Используйте Диспетчер шаблонов процессов, чтобы загружать и отправлять шаблоны процессов.
- Помимо WIT, отчетов и панелей мониторинга, команды обладают доступом к набору общих запросов рабочих элементов, чтобы отслеживать данные, анализировать ход выполнения и принимать решения.
AUP
- Моделирование используется для понимания бизнес-требования и предметной области
- Реализация – это преобразование модели в исполняемый код с модульными тестами
- Тестирование – способ поиска дефектов и верификации системы на предмет соответствия требованиям
- Размещение – доставка готовой системы пользователям
- Управление конфигурациями – управление доступом и версиями артефактов проекта
- Управление проектом – непосредственные активности, связанные с ходом проекта: управление и координация людей, управление рисками, управление финансами и так далее
- Среда – совокупность процессов, инструментов, стандартов и правил.
Kanban
Kanban
Цель – сократить время прохода задачи до «готовности».
Задача = ММФ – минимальная маркетинговая фича Уменьшение числа || выполняемых ЧЕЛОВЕКОМ задач (“work in progress”).
Визуализация задач.
Постоянное совершенствование производства.
Система очень проста, удобна как для веб-студий, так и для работы с фрилансерами.
Преимущества Kanban
Преимущества KANBAN
- Уменьшение числа параллельно выполняемых задач значительно уменьшает время выполнения каждой отдельной задачи
- Быстрое выявление проблемных задач
- Вычисление времени на выполнение усредненной задачи.
Основные правила Kanban
Основные правила
- Визуализация разработки
- Разделение работы на задачи
- Использование отметок о положение задачи в разработке
- Ограничение работ, выполняющихся одновременно, на каждом этапе разработки
- Измерение времени цикла (среднее время на выполнение одной задачи) и оптимизация процесса.
ICONIX
ICONIX
Методология разработки программного обеспечения, сфокусированная на анализе требований и моделировании.
В рамках ICONIX используется подмножество UML для анализа требований:
- Диаграмма вариантов использования;
- Диаграмма классов;
- Диаграмма робастности;
- Диаграмма последовательности.
Crystal Clear
Crystal Clear
«Легковесная» гибкая методология, созданная Алистером Коуберном (Cockburn, 2004).
Предназначена для небольших команд в 6-8 человек для разработки некритичных бизнес-приложений.
Семь методов/практик, три являются обязательными:
- Частая поставка продукта
- Улучшения через рефлексию
- Личные коммуникации
- Чувство безопасности
- Фокусировка
- Простой доступ к экспертам
- Качественное техническое окружение.
FDD
Feature-driven development – методология, созданная Джеффом Де Люка. Разработка ведется в пять этапов:
- Построение модели
- Создание списка функций
- Планирование реализации функций
- Создание архитектуры для функций
- Реализация функций.
Достоинством этой методологии стоит считать изначальную поддержку больших групп разработчиков, так как отдельные функции разрабатываются отдельными мини-командами во главе с ведущим разработчиком.
Разделение и координация происходят на этапах 3-4.
SCRUM
SCRUM
Роли:
- Владелец продукта (Product Owner) – ЛПР, отвечает за определение требований к продукту
- Команда (Team) – кроссфункциональные профессионалы
- Скрам-мастер (ScrumMaster) – организатор, отвечает за решение проблем и соблюдение методологии Scrum.
Фазы проекта:
- Подготовка (Pregame): общий план проекта, список основных требований к продукту, высокоуровневая архитектура продукта
- Реализация (Game): итеративное развитие продукта
- Завершение (Postgame): действия, необходимые для подготовки продукта к выходу на рынок.
Демо и ревью спринта
Демо и ревью спринта
- Проводит скрам-мастер при помощи команды в подготовке, длительность не более 4 часов
- Демонстрируется и оценивается инкремент продукта, созданный за последний спринт
- Решаемые задачи, препятствия, решенные и нерешенные проблемы
- Принимается решение о развитии системы.
Daily Scrum Meeting
Daily Scrum Meeting
- Проходит каждое утро в начале дня и не превышает 15 мин.
- Информирует членов команды о занятости в проекте
- Цель митинга – поделиться информацией, а не решать проблемы в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга
- Каждый член команнды отвечает на вопрос:
– Что сделано вчера?
– Что будет сделано сегодня?
– С какими проблемами столкнулся?
Сессия планирования спринта
Сессия планирования спринта
В начале каждого спринта проводится два митинга:
- В первом митинге спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда. Артефакт: Sprint Backlog
– Результат: цель спринта (Sprint Goal) и Sprint Backlog – функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.
- Во втором митинге участвуют Скрам Мастер, команда. Артефакт: в Sprint Backlog появляются задачи
– Результат: Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.
Организация спринта
Организация спринта
- Спринт начинается с сессии планирования (Sprint Planning Meeting) - определяется объем функциональности, которая будет реализована в течение спринта
- Ежедневно проводится собрание участников проекта - скрам- сессия (Daily Scrum Meeting)
- По завершению спринта проводится демонстрационная сессия (Sprint Review Meeting)
- В результате каждого спринта в продукте реализуется новый, заметный для владельца продукта, объем функциональности
- В конце каждого спринта продукт остается в работоспособном состоянии.
Команда
Команда
Кроссфункциональная, Самоорганизующаяся и самоуправляемая, только групповая оценка, в одном месте
- Отвечает за оценку элементов баклога
- Принимает решение по проектированию и реализации
- Разрабатывает ПО и предоставляет его заказчику
- Отслеживает собственный прогресс (вместе со Скрам Мастером)
- Отвечает за результат перед Product Owner.
Скрам мастер
Скрам мастер
- Создает атмосферу доверия
- Участвует в митингах в качестве организатора
- Устраняет препятствия
- Вскрывает проблемы и открытые вопросы видимыми
- Отвечает за соблюдение практик и процесса в команде
- Проводит Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.
Product Owner
Product Owner
- Отвечает за формирование видения продукта
- Управляет ROI (возврат инвестиций)
- Управляет ожиданиями заказчиков и всех заинтересованных лиц
- Координирует и приоритизирует Product backlog
- Предоставляет понятные и тестируемые требования команде
- Взаимодействует с командой и заказчиком
- Отвечает за приемку кода в конце каждой итерации.
Артефакты Scrum
Артефакты Scrum
Всего 3 документа:
- Журнал продукта (Product Backlog) – высокоуровневый список функциональных и технических требований, необходимых для реализации продукта
- Приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе
- Product Backlog постоянно пересматривается и дополняется – в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты.
- Журнал спринта (Sprint Backlog) – детализированный список функциональных и технических требований, необходимых для успешного завершения итерации
- График спринта (Burndown Chart) – показывает ежедневное изменение общего объема работ, оставшегося до завершения итерации.
Итерация в SCRUM
Итерация в SCRUM
- Основа Scrum - итеративная разработка
- В Scrum итерация называется Sprint, Результатом Sprint является готовый продукт (build).
XP
eXtreme Programming (XP) – Экстремальное программирование.
- Основная идея — устранить высокую стоимость изменений, вносимых в ПО в процессе как разработки, так и эксплуатации
- Цикл разработки - очень короткие итерации
- Четыре базовых действия:
– выслушивание заказчика
– проектирование
– кодирование
– тестирование
- Заказчик постоянно присутствует в группе разработчиков
- При принятии решений всегда стремятся выбрать самое простое, тесты пишутся еще до написания кода
- Сборка системы выполняется ежедневно.
Основные методики ХР
Основные методики ХР
- Игра в планирование (planning game)— быстро определяет перечень задач (объем работ), которые необходимо реализовать в следующей версии продукта, для этого рассматриваются бизнес- приоритеты и технические оценки
- Небольшие версии (small releases) — самая первая упрощенная версия системы быстро вводится в эксплуатацию, после этого через относительно короткие промежутки времени происходит выпуск версии за версией
- Метафора (metaphor) — эта простая общедоступная и общеизвестная история, которая коротко описывает, как работает вся система. Эта история управляет всем процессом разработки
- «Простой» проект (simple design) — в каждый момент времени система должна быть спроектирована так просто, как это возможно. Чрезмерная сложность устраняется, как только ее обнаруживают
- Тестирование (testing) — программисты постоянно пишут тесты для модулей. Заказчики пишут тесты, которые демонстрируют работоспособность и завершенность той или иной возможности системы
- Переработка (refactoring) — программисты реструктурируют систему, не изменяя при этом ее поведения. При этом они устраняют дублирование кода, улучшают коммуникацию, упрощают код и повышают его гибкость.
- Программирование парами (pair programming) — весь разрабатываемый код пишется двумя программистами на одном компьютере
- Коллективное владение (collective ownership) — в любой момент времени любой член команды может изменить любой код в любом месте системы
- Непрерывная интеграция (continuous integration) — система интегрируется и собирается множество раз в день. Это происходит каждый раз, когда завершается решение очередной задачи
- 40-часовая неделя (40-hour week) — программисты работают не более 40 часов в неделю. Никогда нельзя работать сверхурочно две недели подряд
- Заказчик на месте разработки (on-site customer) — в состав команды входит представитель Заказчика - пользователь системы. Он доступен в течение всего рабочего дня и способен отвечать на вопросы о системе
- Стандарты кодирования (coding standards) — программисты пишут весь код в соответствии с правилами, которые обеспечивают коммуникацию при помощи кода
XP – Что нужно знать разработчику
XP – Что нужно знать разработчику
- Что нужно сделать?
- Когда это нужно сделать?
- Когда это сделано?
XP – Что нужно знать заказчику
XP – Что нужно знать заказчику
- Как долго?
- Что сделано?
- Насколько хорошо?
XP – Что требуется от разработчика
XP – что требуется от разработчика
- Оценка времени
- Проектирование
- Программирование
- Качество
Основные черты XP
Основные черты XP
- Простота
- Общение
- Обратная связь
- Решительность
Agile - Документирование кода
Agile - Документирование кода
- Кому это нужно?
- Подсказки в IDE, автогенерация документации
- Поддержка актуальности документации в коде
- Код должен быть понятен САМ ПО СЕБЕ
- Модульные и функциональные тесты – тоже документирование.
Agile - Тестирование
Тестирование
- Код тестирует сам себя
- Тестирующее программное обеспечение
- Опережающее тестирование
- Тесты в качестве документации работы системы. Нет лишней работы.
Agile - Проектирование
Agile - Проектирование
- Отказ от длительного проектирования перед началом работы и выполнение проектирования на протяжении всего выполнения проекта
- В начале проекта выполняется лишь формирование общего представления. Для этого используются системные метафоры, на основе которых формируется высокоуровневая схема проекта
- Процесс разработки состоит из большого количества очень коротких циклов. Конечный результат этапа планирования – список задач, подлежащих реализации на следующей итерации.
12 Принципов Agile
12 Принципов Agile
- Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
- Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
- Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
- Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
- Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
- Рекомендуемый метод передачи информации—личный разговор (лицом к лицу);
- Работающее программное обеспечение—лучший измеритель прогресса;
- Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
- Постоянное внимание улучшению технического мастерства и удобному дизайну;
- Простота—искусство не делать лишней работы;
- Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
- Постоянная адаптация к изменяющимся обстоятельствам.
Обзор прогнозирующих процессов
Четыре «П» разработки ПО
Четыре «П» разработки ПО
- Персонал (кто это делает)
- Проект (выполнение необходимых действий)
- Продукт (артефакты)
- Процесс (способ, которым это делается)
Процесс
Процесс
Семейства процессов разработки ПО
- Прогнозирующие (predictive) = тяжеловесные (heavyweight)
– применяются при стабильных требованиях и многочисленной группе разработчиков разной квалификации;
- Облегченные, подвижные, гибкие, адаптивные (lightweight, agile)
– применяются при малочисленной группе квалифицированных разработчиков и грамотном заказчике, который имеет возможность участвовать в процессе.
Прогнозирующие методологии
Прогнозирующие методологии
- Обеспечивают защиту инвестиций в условиях формальных отношений «Заказчик-Исполнитель»
- Основываются на долгосрочном планировании ресурсов
- Обладают четким планом по получению результатов в терминах вех этапов и фаз
- Изменения требований обеспечиваются процедурой управления изменениями
- UP / RUP / EUP / OUP
- MSF / MOF
- Oracle Method (AIM/CDM/PJM/BPR /OSM)
- MIL-STD-498
- …
Oracle Method
Oracle Method
- CDM (Custom Development Method) - разработка прикладного ПО;
- PJM (Project Management Method) - управление проектом;
- AIM (Application Implementation Method) - внедрение прикладного ПО;
- BPR (Business Process Reengineering) - реинжиниринг бизнес-процессов;
- OCM (Organizational Change Management) - управление изменениями
- и др.
Степень обязательности
Степень обязательности
Методология необязательна, но может считаться фирменным стандартом; при формальном применении степень обязательности полностью соответствует ограничениям возможностей адаптации
- Прикладная система рассматривается в основном как программно-техническая система – нет поддержки преобразований организационной структуры, реально всегда происходящих при переходе к новой ИС.
- Другой фактической ориентацией методики является ее (исторически понятная) направленность на создание Информационной Системы с Базами Данных в достаточно традиционном понимании.
Степень адаптивности
Степень адаптивности
Ограничивается тремя разновидностями каскадной модели ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track) (еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle), "облегченный подход" (рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения).
Методология не предусматривает:
- включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным;
- удаление задачи (и порождаемых ею документов);
- изменение последовательности выполнения задач по сравнению с предложенной (тем более - по ходу процесса проектирования).
Доработка
AIM – процесс «Доработка»
Доработка (2)
AIM разделяет доработку:
- при «нехватке» возможностей приложения, касающихся функциональности
- при «нехватке» возможностей приложения, касающихся отчетов
- при «нехватке» возможностей приложения по предоставлению/ограничению доступа к функциям и данным
- при разработке программ автоматической конвертации (программ переноса бизнес-данных в новое приложение).
Доработка основного функционала BR.020 – BR.080 – MD.020
- BR.020 – выявление «дыр» функциональности приложения, предварительное формулирование решения, как можно устранить «дыры»
- BR.080 – первоначальная оценка предложенного предварительного решения
- MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат.
Последовательности задач
Последовательности задач (1)
Последовательности задач (2)
RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где:
- RD.020 – изучение существующих бизнес-процессов
- RD.030 – моделирование будущих бизнес-процессов
- RD.070 – выявление детальных требований к будущим бизнес-процессам
- BR.020 – отображение бизнес-процессов в функциональность приложения
- BR.080 – тестирование принятых решений
- MD.020 – оценка решений по доработке функциональности приложения
- MD.060 – проект расширений функциональности приложения
- DO.070 – разработка инструкций пользователя
- TE.110 – тестирование приложения
- PM.050 – установка приложения на систему периода эксплуатации
- CV.140 – ввод начальных данных
- PM.080 – запуск новой системы.
Методология Oracle CDM
Методология Oracle CDM
Стандарт, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах ИС с реализацией на инструментальных средствах Oracle.
Ориентирован на поддержку деятельности разработчика.
Процессы CDM
Процессы CDM
- RD - Определение производственных требований
- ES - Исследование существующих систем
- TA - Определение технической архитектуры
- DB - Проектирование и построение БД
- MD - Проектирование и реализация модулей
- CV - Конвертирование данных
- DO - Документирование
- TE - Тестирование
- TR - Обучение
- TS - Переход к новой системе
- PS - Поддержка и сопровождение.
Фазы ЖЦ ИС Oracle CDM
Внедрение и Эксплуатация
Внедрение и Эксплуатация
Анализируются
– производительность и
– целостность системы,
выполняется поддержка и, при необходимости, модификация системы.
Реализация
Реализация
- Создание и тестирование приложений
- Создаются программы, соответствующие всем требованиям проектных спецификаций
- Этап широко автоматизирован, т.к. Oracle CDM имеет специальное инструментальное средство Oracle Designer, в состав которого входят генераторы приложений.
Проектирование
Проектирование
- Требования преобразуются в формальные (детальные) спецификации ИС
- На основе концептуальных моделей вырабатываются технические спецификации будущей ИС:
– определяется структура и состав БД;
– специфицируется набор программных модулей
- Начальный вариант проектных спецификаций может быть получен автоматически с помощью специализированных утилит на основе созданной концептуальной модели.
Анализ
Анализ
- Проводится для формулирования детальных требований к ИС
- Разрабатываются детальные концептуальные модели предметной области, описывающие информационные потребности организации и особенности функционирования
- Результат: модели двух типов:
– информационные, отражающие структуру и общие закономерности предметной области;
– функциональные модели, описывающие особенности решающих задач.
Стратегия
Стратегия
- Моделирование и анализ процессов, описывающих деятельность организации, для которой создается ИС
- Цель: построение моделей существующих процессов, выявление их недостатков и возможных источников усовершенствования
- Эта фаза не является обязательной, если существующая технология работы организации и её оргструктуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорганизации.
MOF
Microsoft Operation Framework (MOF)
Цель заключается в предоставлении ИТ- подразделениям руководств, помогающих создавать, эксплуатировать и поддерживать ИТ-услуги, обеспечивая получение ожидаемых коммерческих преимуществ от конкретных инвестиций в ИТ с приемлемым уровнем риска.
Модель предназначена для создания среды, в которой компания и ИТ-подразделение смогут совместно работать над совершенствованием деятельности и использовать при этом проактивную модель, определяющую процессы и стандартные процедуры, направленные на повышение эффективности и продуктивности ИТ-услуг. MOF предлагает логический подход к принятию решений и обмену информацией при планировании, развертывании и поддержке ИТ- услуг.
MSF
MSF
Методология разработки программного обеспечения, предложенная корпорацией Microsoft.
Опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами при разработки решения.
MSF представляет собой согласованный набор концепций, моделей и правил.
Базовые принципы MSF
Базовые принципы MSF
- Единое видение проекта
- Проявляйте гибкость – будьте готовы к переменам
- Концентрируйтесь на бизнес-приоритетах
- Поощряйте свободное общение.
Структура MSF
Структура MSF
ДВЕ МОДЕЛИ:
- Модель ПРОЕКТНОЙ ГРУППЫ
- Модель ПРОЦЕССОВ
ТРИ ДИСЦИПЛИНЫ:
- Управления ПРОЕКТАМИ
- Управления РИСКАМИ
- Управления ПОДГОТОВКОЙ
EUP
Enterprise UP
- Расширенный вариант UP
- Разработан Scott W. Ambler and Larry Constantine в 2000, в 2005 модифицирован Ambler, John Nalbone and Michael Vizdos
- Добавлены новые фазы и потоки работ
- Цель – обеспечение системных процессов сопровождения КИС
- В 2013 году создана «agile-версия», доступная на http://www.enterpriseunifiedprocess.com/ .
Потоки работ масштаба предприятия
- Моделирование бизнес-процессов предприятия
- Управление портфелем (ценных бумаг)
- Архитектура предприятия
- Стратегическое повторное использование
- Управление персоналом
- Администрирование предприятия
- Совершенствование процесса программного обеспечения.
OUP
Open UP
- OpenUP – ограниченная версия RUP, адаптированная для небольших команд и agileпроектов
- OpenUP – итеративный процесс, который минимален, завершен, и расширяем
- Базируется на риск-менеджменте в интеративной разработке, управляется вариантами использованиями, архитектурно центрирован
- OpenUP представлен IBM Rational в 2005 группе Eclipse foundation и открыт для использования
- Доступен на http://epf.eclipse.org/wikis/openup/ .
RUP
Rational Unified Process (RUP)
Основан на шести лучших советах по организации процесса разработки программного обеспечения:
- Разрабатывайте итеративно
- Управляйте требованиями
- Пользуйтесь модульными архитектурами
- Используйте визуальное моделирование
- Не забывайте о проверке качества
- Следите за изменениями.
Проект
Проект
Организационная сущность, упорядоченная совокупность действий, необходимых для создания конечного продукта:
- Контакт с заказчиком
- Написание документации
- Проектирование
- Программирование
- Тестирование
- …
Продукт
Продукт
Артефакт – любая полезная информационная сущность, создаваемая и используемая сотрудниками при создании программного обеспечения (информационной системы).
Артефакты:
- Само приложение
- Спецификация требований
- Проектная модель
- Исходный и объектный код
- Тестовые процедуры
- …
Персонал
Персонал
Обсуждаются вопросы:
- Размеры коллектива
- Деление его на управляемые группы
- Способы управления
- Роли участников рабочего процесса
- Специализация
- Навыки
- Уровень квалификации/производительность
- Личностные качества, отношение к проекту
- Обучение
- …
Главная тема
Управление программным проектом
Проект, управление проектом
Проект – это упорядоченная совокупность действий, направленная на достижение наперёд заданной цели, ограниченная требованиями к:
- срокам
- стоимости
- уровню риска
- качеству ожидаемых результатов.
Понятие проекта 1
Понятие проекта 2
Управление проектами – это успешное управление изменениями некоторой материальной системы.
Понятие о риске
Понятие о риске
- Подверженность потере или ущербу
- Фактор, вещь, элемент или направление движения, заключающий вероятную опасность
- Угроза того, что какое-либо событие или действие неблагоприятно повлияет на возможности добиваться желаемого результата в бизнесе, реализовать цели и/или стратегические планы (Русское общество управления рисками).
Стратегии работы с рисками
Стратегии работы с рисками
Стратегии поведения
- Предотвращение риска: реорганизация проекта так, чтобы этот риск не мог на него воздействовать
- Передача риска: реорганизация проекта так, чтобы кто-то другой или что-то другое имели с ним дело (заказчик, продавец, банк, другой элемент и т.д.)
- Принятие и локализация риска: учесть этот риск как неизбежный. Подготовить план действий на случай появления этого риска и контролировать его симптомы.
RUP – работа с рисками
М. Фаулер. Классификация рисков
Политические риски
Существуют ли политические силы, которые могут оказаться на вашем пути и серьезно повлиять на выполнение вашего проекта?
Риски, связанные с квалификацией персонала
Риски, связанные с квалификацией персонала
- Ошибка, первая в рейтинге пост-анализа проекта:
- «Нам следовало больше внимания уделять обучению»
- Курсы
- «Играющий тренер»
- Семинары, обсуждения
- Текущий контроль и оперативная помощь.
Технологические риски
Технологические риски
- Компоненты, согласование компонент
- Вертикальные прототипы на ранних стадиях проекта
- Модульное построение (возможность замены)
- Анализ вновь поступающих UC – «сходимость» архитектуры.
Риски, связанные с требованиями
Риски, связанные с требованиями
- Варианты использования (UC) VS функции – Типичное взаимодействие Система-Пользователь, обеспечивающее достижение цели Пользователя – Выделение ключевых (essential) UC
- Модель предметной области
- Горизонтальные прототипы
Управление рисками
Что такое управление рисками? (РусРиск)
Это процесс:
- Систематического выявления потенциальных рисковых событий
- Оценки уровня их влияния
- Разработки решений по управлению, применяемых в стратегическом и оперативном управлении для обеспечения уверенности в достижении целей.
Атрибуты рисков
Атрибуты рисков
- Вероятность наступления
- Влияние на проект (серьезность)
- Значительность риска как интегральная характеристика -
- Шкала: высокий, существенный, умеренный, незначительный, низкий.
Прямой и косвенный риски
Прямой и косвенный риски
- Прямой риск – риск, который в существенной степени может контролироваться проектом
- Косвенный риск – риск, мало или вообще никак не управляемый проектом.
Успех
Успех
Достижение всех требований и ограничений, ожидаемых от проекта.
Определение риска IT-проекта
Определение риска IT-проекта (Новиков, RUP)
- Случайная переменная, которая в пределах нормального распределения может принимать значение, подвергающее опасности, либо исключающее успех проекта
- Что-то, находящееся на пути к успеху, в настоящее время неизвестное или трудно поддающееся определению.
Управление
программным проектом в RUP
Управление программными проектами в RUP
- Общая схема работ по управлению
- Двухуровневое планирование
- Работа с рисками
- Мониторинг и метрики
- Управление персоналом
- Управление бюджетом
- Управление контактами и контрактами.
На каждом этапе работ RUP разрабатывается своя группа моделей и документов (artifacts).
Основным результатом итеративного процесса является последовательное совершенствование моделей и документации (artifacts).
Фаза внедрения конечного
продукта
Фаза внедрения конечного продукта
- Основная задача фазы внедрения – доведение ПО до уровня, при котором оно может реально эксплуатироваться пользователями.
- При завершении фазы внедрения определяется, достигнуты или нет цели проекта и, возможно, принимается решение о следующей итерации цикла разработки. Здесь также уместно извлечь уроки из предыдущего опыта разработки в целях улучшения процесса в будущем.
Фаза детального проектирования
Фаза конструирования (детального проектирования)
- В течение фазы детального проектирования итеративно и пошагово разрабатывается конечный программный продукт.
- При этом реализуются функции системы, завершается проектирование, кодирование и тестирование ПО.
- О завершении фазы конструирования свидетельствует готовность программного обеспечения, организации – заказчика и пользователей к началу эксплуатации.
Фаза уточнения
Фаза уточнения (Elaboration)
Основными задачами фазы уточнения являются:
- Подробный анализ предметной области
- Определение не противоречащих друг другу базовых элементов архитектуры разрабатываемой системы
- Детализация плана проекта
- Выявление факторов риска, в наибольшей степени влияющих на успешное завершение проекта.
В завершении фазы уточнения подвергаются проверке детализированные характеристики системы, осуществляется окончательный выбор архитектуры и решаются проблемы, связанные с основными рисками проекта.
Начальная фаза разработки
Начальная фаза разработки (Inception Phase)
- Основная задача начальной фазы разработки - определение конечных целей проекта.
- Для этого выявляются все акторы, с которыми система должна взаимодействовать, определяется суть их деятельности и основные функции.
- Начальная фаза завершается принятием принципиального решения о целесообразности проведения дальнейшей разработки.
Управление программными
проектами (О`Коннел)
АНАЛИЗ И ПЛАНИРОВАНИЕ
1. Наглядное представление цели
2. Сделайте список задач
3. Должен быть 1 руководитель
4. Распределите задач по людям
5. Управляйте ожиданиями.
КОНТРОЛЬ И ВЫПОЛНЕНИЕ ПЛАНА
6. Используйте подходящий стиль руководства
7. Знайте, что происходит
8. Сообщайте людям, что происходит
9. Повторяйте пп. 1-8 до достижения п. 10
10. Приз
Приз
Повторяйте пп. 1-8 до достижения п. 10
Сообщайте людям, что происходит
Сообщайте людям, что происходит
- Руководитель, как часовой
- Движения извне:
- блокировать,
- либо, если вы не в состоянии это сделать, подвергнуть цензуре так, чтобы их угроза уменьшилась,
- либо, если и это не получается, передать группе таким способом, чтобы минимизировать их воздействие.
- Движения вовне:
- остановить движение информации наружу,
- или, если это нельзя сделать, разбавить её так, чтобы когда информация выйдет наружу, её истинный эффект был ослаблен,
- или, если это невозможно, передайте информацию таким образом, чтобы минимизировать эффект её воздействия на внешний мир.
Знайте, что происходит
Знайте, что происходит
- Завершающиеся задачи
- Запускаемые задачи
- Задачи в работе
- График:
– Изменений нет
– Поправимый сбой
– Сбой, приводящий к изменению графика.
Используйте подходящий стиль руководства
Используйте подходящий стиль руководства
- Несколько человек – тысячи человек
- Каждый – индивидуум со своими страхами, предубеждениями, желаниями, надеждами, опытом, проблемами, амбициями
- Как начать работу со столь сложным организмом?
- Как поддерживать рабочую атмосферу?
Управляйте ожиданиями
Управляйте ожиданиями
- Явные и скрытые риски
- «Заделы»
«поиск обновлений таблицы» «техническое обслуживание памяти»
Распределите задачи по людям
Распределить задачи по людям
- Удостовериться, что у каждой задачи есть исполнитель
- Принять во внимание др. занятия исполнителей
- Попытаться максимизировать силы той команды, которую Вы получили
Должен быть 1 руководитель
Должен быть один руководитель
- Лидерство
- Ответственность
- Полномочия
- Количество проектов...
Сделайте список задач
Сделай список задач и…
Наглядное представление цели
Наглядное представление цели
- Точное определение цели
- Обоснование цели (самомотивация)
- Мотивация команды
- Изменения цели и их контроль.
Признаки проектной деятельности
Признаки проектной деятельности:
- Однократность условий в их совокупности
- Отграничение от других замыслов
- Постановка цели, ограниченной во времени
- Ограничения финансового, персонального или другого рода
- Организация, специфичная для проекта.
Основные виды деятельности
программной инженерии
Основные виды деятельности программной инженерии:
- Бизнес-анализ
- Формирование видения
- Анализ требований
- Разработка архитектуры
- Тестирование
- Управление проектом
- Управление средой
- Управление конфигурацией
- Управление требованиями
- Усовершенствование
- Детальное проектирование
- Реализация
- Экспертиза (испытание)
- Документирование
- Обучение
- Внедрение
- Эксплуатация
- Сопровождение
