МиСПИСиТ-Тема4

更多类似内容

Отель_и_гостиницы

由AceTon Norris

группа М 2202-В Педагогический процесс

由Галина Ярмоленко

Информационная безопастность

由Alice Tokmyanina

Методы педагогического исследования

由Геращенко Ольга

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

Обзор гибких процессов

Гибкие методологии

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

• Agile Unified Process (AUP) – упрощенная версия IBM Rational Unified Process, созданная
• Скоттом Амблером и состоящая из семи методов:

1. Моделирование используется для понимания бизнес-требования и предметной области
2. Реализация – это преобразование модели в исполняемый код с модульными тестами
3. Тестирование – способ поиска дефектов и верификации системы на предмет соответствия требованиям
4. Размещение – доставка готовой системы пользователям
5. Управление конфигурациями – управление доступом и версиями артефактов проекта
6. Управление проектом – непосредственные активности, связанные с ходом проекта: управление и координация людей, управление рисками, управление финансами и так далее
7. Среда – совокупность процессов, инструментов, стандартов и правил.

Kanban

Kanban

Цель – сократить время прохода задачи до «готовности».

Задача = ММФ – минимальная маркетинговая фича Уменьшение числа || выполняемых ЧЕЛОВЕКОМ задач (“work in progress”).

Визуализация задач.

Постоянное совершенствование производства.

Система очень проста, удобна как для веб-студий, так и для работы с фрилансерами.

Преимущества Kanban

Преимущества KANBAN

• Уменьшение числа параллельно выполняемых задач значительно уменьшает время выполнения каждой отдельной задачи
• Быстрое выявление проблемных задач
• Вычисление времени на выполнение усредненной задачи.

Основные правила Kanban

Основные правила

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

ICONIX

ICONIX

Методология разработки программного обеспечения, сфокусированная на анализе требований и моделировании.

В рамках ICONIX используется подмножество UML для анализа требований:

• Диаграмма вариантов использования;
• Диаграмма классов;
• Диаграмма робастности;
• Диаграмма последовательности.

Crystal Clear

Crystal Clear

«Легковесная» гибкая методология, созданная Алистером Коуберном (Cockburn, 2004).

Предназначена для небольших команд в 6-8 человек для разработки некритичных бизнес-приложений.

Семь методов/практик, три являются обязательными:

1. Частая поставка продукта
2. Улучшения через рефлексию
3. Личные коммуникации
4. Чувство безопасности
5. Фокусировка
6. Простой доступ к экспертам
7. Качественное техническое окружение.

FDD

Feature-driven development – методология, созданная Джеффом Де Люка. Разработка ведется в пять этапов:

1. Построение модели
2. Создание списка функций
3. Планирование реализации функций
4. Создание архитектуры для функций
5. Реализация функций.

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

Разделение и координация происходят на этапах 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

1. Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
2. Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
3. Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
4. Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
5. Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
6. Рекомендуемый метод передачи информации—личный разговор (лицом к лицу);
7. Работающее программное обеспечение—лучший измеритель прогресса;
8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
9. Постоянное внимание улучшению технического мастерства и удобному дизайну;
10. Простота—искусство не делать лишней работы;
11. Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
12. Постоянная адаптация к изменяющимся обстоятельствам.

Обзор прогнозирующих процессов

Четыре «П» разработки ПО

Четыре «П» разработки ПО

• Персонал (кто это делает)
• Проект (выполнение необходимых действий)
• Продукт (артефакты)
• Процесс (способ, которым это делается)

Процесс

Процесс

Семейства процессов разработки ПО

• Прогнозирующие (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)

Основными задачами фазы уточнения являются:

1. Подробный анализ предметной области
2. Определение не противоречащих друг другу базовых элементов архитектуры разрабатываемой системы
3. Детализация плана проекта
4. Выявление факторов риска, в наибольшей степени влияющих на успешное завершение проекта.

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

Начальная фаза разработки

Начальная фаза разработки (Inception Phase)

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

Управление программными проектами (О`Коннел)

АНАЛИЗ И ПЛАНИРОВАНИЕ

1. Наглядное представление цели

2. Сделайте список задач

3. Должен быть 1 руководитель

4. Распределите задач по людям

5. Управляйте ожиданиями.

КОНТРОЛЬ И ВЫПОЛНЕНИЕ ПЛАНА

6. Используйте подходящий стиль руководства

7. Знайте, что происходит

8. Сообщайте людям, что происходит

9. Повторяйте пп. 1-8 до достижения п. 10

10. Приз

Приз

Повторяйте пп. 1-8 до достижения п. 10

Сообщайте людям, что происходит

Сообщайте людям, что происходит

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

Знайте, что происходит

Знайте, что происходит

• Завершающиеся задачи
• Запускаемые задачи
• Задачи в работе
• График:

– Изменений нет

– Поправимый сбой

– Сбой, приводящий к изменению графика.

Используйте подходящий стиль руководства

Используйте подходящий стиль руководства

• Несколько человек – тысячи человек
• Каждый – индивидуум со своими страхами, предубеждениями, желаниями, надеждами, опытом, проблемами, амбициями
• Как начать работу со столь сложным организмом?
• Как поддерживать рабочую атмосферу?

Управляйте ожиданиями

Управляйте ожиданиями

• Явные и скрытые риски
• «Заделы»

«поиск обновлений таблицы» «техническое обслуживание памяти»

• Управление требованиями

Распределите задачи по людям

Распределить задачи по людям

• Удостовериться, что у каждой задачи есть исполнитель
• Принять во внимание др. занятия исполнителей
• Попытаться максимизировать силы той команды, которую Вы получили 

Должен быть 1 руководитель

Должен быть один руководитель

• Лидерство
• Ответственность
• Полномочия
• Количество проектов...

Сделайте список задач

Сделай список задач и…

Наглядное представление цели

Наглядное представление цели

• Точное определение цели
• Обоснование цели (самомотивация)
• Мотивация команды
• Изменения цели и их контроль.

Признаки проектной деятельности

Признаки проектной деятельности:

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

Основные виды деятельности программной инженерии

Основные виды деятельности программной инженерии:

• Бизнес-анализ
• Формирование видения
• Анализ требований
• Разработка архитектуры
• Тестирование
• Управление проектом
• Управление средой
• Управление конфигурацией
• Управление требованиями
• Усовершенствование
• Детальное проектирование
• Реализация
• Экспертиза (испытание)
• Документирование
• Обучение
• Внедрение
• Эксплуатация
• Сопровождение