IT project management

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

Семинар

Управление ИТ проектами
Колтунова Екатерина
kate@koltunova.com
www.koltunova.com
www koltunova com
+ 7 (911) 250-22-47

Программа семинара
• Эволюция и современное состояние
теории управления ИТ проектами
– Концепции управления: Процессное управление
(BPR, BPI),
(BPR BPI) всеобщее управление качеством
б
(TQM), управление проектами, управление
изменениями.
– Классификация инструментальных средств
управления ИТ-проектами.
– История развития методологий управления ИТ-
проектами, концепции Ф. Брукса, У. Ройса, У.
Хамфри, Э. Йордона, Дж. Хайсмита и А. Коберна.
• Методологии, модели и стандарты
разработки ПО
ПО.
• Использование специализированных
методик в ИТ-проектах.

Инструментальные средства управления ИТ проектами
Языки
Методики Стандарты ЖЦ ПО
Техники моделирования

Формализованное представ
Итерационная
Оценка трудоемкости Анализ и оценка Последовательная
разработка. Структурные
риска
разработки ПО разработка Waterfall XP

объ
Iterative
Проектное управление графические
ф

ъектов, требований
(SEI TR 13)
COCOMO (ГОСТ 19 34 ISO 12 207)
19, 34,
development
PERT, CPM, Earned Value IDEF, DFD, eEPC

оценки, анализа и оптимизации
Вычислител
Таксономии и алгоритмы оценки Модели процессов ЖЦ ПО
Объектные
Управление
графические
себестоимостью
UML.
Activity Based Costing,
Модели зрелости Методологии Методологии
Standard Costing, Direct
Costing
льные методы для

й
вление
Costing (Maturity Models) разработки ПО внедрения ИС
Семантические
Классическая
Иерархическая модель On Target Axapta
Управление (совокупность
зрелости (CMM, CMMI)
производительностью стандартов ISO ГОСТ)

Лучша мировая практик управления разр
Performability Measurement
AcceleratedSAP
Метрики
р
RUP Rational Unified
Стандарты оценки и

ая
Process

Численные оценк показателей
улучшения процессов

продукта, проек
Объема
Концепции Oracle AIM
MSF Microsoft Solution SLOC, Function
Framework
SPICE
Опыт, и ре

Point, etc.
Lotus AVM
Реинжиниринг бизнес- Семейство (Accelerated Value
процессов (BPR, BPI) Сложности
методологий Crystal Method)
Tick IT

кта, процесса
ки
Х
Холстед, Д
Джилб,
б
ка
екомендации, лучш практики общег

Мак-Кейб
XP eXtreme Signature Scala
Всеобщее управление Programming
Методологии проектного
качеством (TQM)
менеджмен

управления в ИТ
Качества
Модели процессов, роли, рабочие продукты, область
применения
PRINCE (Project in
Управление проектами
шие

работкой ПО
нта

controlled environment)
(PM)
Стандарты – требования к рабочим продуктам

Индивидуальные
Стандарт на систему Стандарты Технические стандарты
Стандарты
техники
менеджмента пользовательского
качества
качества интерфейса
рф Форматы
р
Языки
Я
го

PSP Personal Software обмена Протоколы
ГОСТ 28195, ISO разработки
ISO 9000 GUI
Process данными
9126

Екатерина Колтунова www.koltunova.com

Концепция стратегических карт (Strategy Map)

Цели собственников в отношении роста организации,
производительности и т.д.
тд

Ценность для клиентов. Цены, качество, бренд,
дополнительный сервис. Сегментация рынка.

Бизнес-процессы для предоставления заявленных ценностей
для клиентов.

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


Реинжиниринг бизнес-процессов BPR
р рц
• Впервые предложен Ф.Тейлором в 1900г. в статье Принципы
научного менеджмента (The Principles of Scientific Management )).
Эти идей легли в основу TQM.
• Business Process Redesign – анализ и проектирование потоков
р
работ внутри и между организациями (Davenport & Short, 1990).
ур ду р ц ( p , )
Ключевые цели: удовлетворение клиентов, результативность и
эффективность.
• «BPR - фундаментальное переосмысление и рад ал а
фу да е ал ое ереос сле е радикальная
реконструкция бизнес-процессов с целью достижения
драматически сильных улучшений в критически важных в
современных условиях уровнях критериев производительности,
таких как стоимость, качество, услуги, скорость» М Хаммер, Дж.
М. Х Д
Чампи.
• Суть феномена BPR – в реинтеграции процессов –
реагирование на крайности специализации и разделения труда
труда.
Преодоление отрицательных эффектов стратегий Смита-
Маркса-Гилбрета.


Три уровня усилий по улучшению
процессов
• Непрерывное улучшение процессов (Continuous
Process Improvement, CPI) – устранение вариаций в
качестве выпускаемых продуктов и оказываемых
услуг.
• Ре-дизайн бизнес-процессов (Business Process
Redesign) - удаление активностей, не создающих
g ) уд , дщ
дополнительной стоимости. Сокращение времени
выполнения процесса, снижение стоимости.
• Реинжиниринг бизнес-процессов (Business process
reengineering) – радикальная трансформация
процессов с использованием новых технологий для
достижения радикального выигрыша в
производительности процесса, эффективности и
качестве.


Определения бизнес-процесса
бизнес процесса
• М Хаммер Дж Чампи: «бизнес процесс - набор
М. Хаммер, Дж. «бизнес-процесс
активностей, которые преобразуют несколько видов
входных характеристик в выход, имеющий ценность
для потребителя»
потребителя».
• Т. Давенпорт: «бизнес-процесс - специфически
упорядоченная во времени и в пространстве
совокупность работ, с указанием начала и конца и
точным определением входов и выходов».
• Дж. Мартин использует близкое понятие потока
потребительных ценностей (value stream). Поток
потребительных ценностей - множество законченных
состыкованных действий которые в совокупности
действий,
создают некоторую продукцию, имеющую
потребительскую ценность для клиента.


Формализация (структурирование)
процесса включает в себя определение:
• целей процесса;
й
• владельца процесса;
• сос а а и последовательности рабо
состава ос е о а е ос работ;
• условий входа и выхода (как для граничных
работа,
работа так и для работ внутри процесса);
• входов и выходов (используемых
материалов, производимой продукции,
документации);
• участников процесса (ответственность, роли
и деятельности для каждого участника в
разрезе работ).


Использование CASE-средств и
моделирование бизнес-процессов
•ИИнтерактивное моделирование с
обсуждением: Paper-design, Yellow papers,
whiteboards
• Моделирование BPWin, ARIS, Visio –
документы для обсуждения
у у
• Имитационное моделирование AnyLogic,
iThink
• Моделирование - как часть настройки
системы (ARIS for NetWeaver, Hummerbird и
другие системы DocFlow Visio .Net =>
DocFlow, Net
BizTalk)


Методы реинжиниринга
• Об
Объединение дублирующих ф
б функцийй
• Устранение множественных уровней проверки и
получения подтверждения
• Снижение размера выпускаемых партий
• Регулирование на основе спроса (demand pull)
• Передача партнерам неэффективно выполняемых
функций
• Устранение перемещений в процессе выполнения
данной работы
•ООрганизация многофункциональных групп (
ф (команд).
)


Всеобщее управление качеством
(TQM)
• TQM (TQM Total Quality Management) представляет
(TQM, T t l Q lit M t)
собой совокупность принципов, статистических
методов и методик повышения качества.
д д
• TQM – это система непрерывного улучшения,
основанная на использовании вовлеченного
(participative)
( ti i ti ) управления и сфокусированная на
ф
потребностях клиентов.
• Ключевые элементы TQM: вовлечение сотрудников
сотрудников,
обучение, команды по решению проблем,
статистические методы, долгосрочне цели,
понимание, что система, а не люди, является
причиной неэффективности.


Качество ПО
• отсутствие ошибок (дефектов);
• соответствие спецификации;
• пригодность к использованию;
• удобство использования
(комфортабельность).
( о фор абе ос )


Определение качества в ISO 8402

ОБЪЕКТ - то, что может быть индивидуально описано или рассмотрено

Деятельность Система или
Продукция Организация
или процесс отдельное лицо

КАЧЕСТВО - совокупность характеристик объекта, осносящиеся к его способности
удовлетворять установленные и предполагаемые требования


Специфика управления
качеством ПО
•ООтсутствием точной повторяемости процессов,
й
жестко заданной технологии, индивидуальный
характер производства ( р
р рр д (проектная модель):
д )
• Общие подходы методологии TQM (Total Quality
Management) могут быть использованы при
разработке ПО, но применение традиционных
б ПО
инструментов, к которым относятся гистограммы,
временные ряды, д а ра
ре е е р д , диаграммы Парето, причинно-
аре о, р о
следственные диаграммы, контрольные листки,
контрольные карты, диаграммы рассеяния, связано
с большими методологическими и технологическими
трудностями.


Идеальное качество vs. good
enough software
•О
Одним из аспектов, порождающих трудности в
разработке ПО, становится требование идеального
качества, выражаемого в терминах количества
, р р
ошибок, переносимости, независимости от
платформы, и других.
•И
Идеальное качество недостижимо в б большинстве
проектов, поэтому необходимо прийти к соглашению
о ос е
относительно того, какое качество является
о о о, а ое а ес о ес
достаточно хорошим, то есть определить
требования к «достаточно хорошему» ПО (good
enough software)
Эдвард Йордон


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

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


Проект
р
• уникальный процесс, состоящий из набора взаимоувязанных и
контролируемых работ с датами начала и окончания и
предпринятый,
предпринятый чтобы достичь цели-задачи (objective)
цели задачи
соответствия конкретным требованиям, включая ограничения
по времени, затратам и ресурсам [ISO/TR 10006: 1997 (E).
Quality Management – Guidelines to quality in project Management];
• процесс достижения поставленной цели-задачи (objective) в
рамках особого, конкретного комплекса условий [ISO 9000:2000
Quality Management Systems – Fundamental and Vocabulary].
• предприятие (намерение), которое в значительной степени
характеризуется неповторимостью условий в их совокупности,
например: задание цели; временные, финансовые, людские и
другие ограничения; разграничения от других намерений;
специфическая для проекта организация его
осуществления [DIN 69901. Германия, 1987];
• временное усилие (действие) предпринятое для создания
(действие),
уникального продукта или услуги [A Guide to the Project
Management Body of Knowledge. PMI Standards Committee. 2000
Edition., 2000]


ИТ Проект
• Использует стандартные методологии
ур
управления ИТ проектом
р
• Предполагает одновременное
управление требованиями персоналом,
требованиями, персоналом
рисками, качеством, бюджетом
(ресурсами) и изменениями
( )
• Кооперативная игра (две цели)
• Несовершенство коммуникаций


Ф. Брукс об управлении
ИТ-проектами
• «… липовые графики нацеленные на желательную
графики,
дату, встречаются здесь значительно чаще, чем в
любых других инженерных отраслях. Очень тяжело,
рискуя потерять рабочее место, с энергией и
б й
любознательностью отстаивать срок, который
определен без применения каких-либо
количественных методов при недостатке данных и
подкреплен, в основном, интуицией менеджеров»
• «… трудности, испытываемы при управлении
руд ос , с ае р у ра е
крупными проектами, иного рода, нежели при
управлении небольшими проектами, что связано с
проблемами разделения труда. Я считаю важнейшей
задачей сохранение концептуальной целостности
самого продукта»


Подходы к управлению ИТ-проектами
ИТ проектами

• Проектный подход (менеджерский)
• Технический подход (инженерный)
( р )
• Командный подход (психологический)

Эффективно объединение всех подходов


Управление проектами:
определение
• уникальный процесс состоящий из набора взаимоувязанных и
процесс,
контролируемых работ с датами начала и окончания и
предпринятый, чтобы достичь цели-задачи (objective)
соответствия конкретным требованиям, включая ограничения
р р , р
по времени, затратам и ресурсам [ISO/TR 10006: 1997 (E).
Quality Management – Guidelines to quality in project Management];
• процесс достижения поставленной цели-задачи (objective) в
рамках особого, конкретного комплекса условий [ISO 9000 2000
б й 9000:2000
Quality Management Systems – Fundamental and Vocabulary].
• предприятие (намерение), которое в значительной степени
характеризуется неповторимостью условий в их совокупности
совокупности,
например: задание цели; временные, финансовые, людские и
другие ограничения; разграничения от других намерений;
специфическая д проекта организация его
цф для р р ц
осуществления [DIN 69901. Германия, 1987];
• временное усилие (действие), предпринятое для создания
уникального продукта или услуги [A Guide to the Project
M
Management Body of Knowledge. PMI Standards Committee. 2000
tB d fK ld St d d C itt
Edition., 2000]

ИТ проект: определения
ИТ-проект:
• В. Липаев.
В В Липаев определяет проект как комплекс формально
организованных мероприятий по достижению единой цели
создания сложной системы с заданными характеристиками
качества при ограниченных р ур
р р ресурсах.
• В CMMI “проект” – это управляемый набор взаимосвязанных
ресурсов, который обеспечивает выпуск одного или нескольких
продуктов для клиента или конечного пользователя. Этот набор
продуктов обычно определяется в начале и управляется в
б
соответствие с планом.
• Проект определяется как процесс, предприятие, намерение,
усилие и действие Под проектом понимается комплекс работ
действие. работ,
направленных на достижение запланированной и, как правило,
уникальной цели. На практике проект представляет собой
совокупность процессов, обеспечивающих изменение
у рц , щ
технических или социальных систем. Проект включает в себя
замысел (проблему), средства его реализации (решения
проблемы) и получаемые в процессе реализации результаты.


Управление ИТ проектами:
международная практика
• ISO/IEC 9126 : I f
Information t h l
ti technology - S ft
Software
Product Evaluation - Quality characteristics and
guidelines for their use – 1991.
g
• ISO/IEC TR 15504 SPICE Consolidated product.
Software Process Assessment. Version 1.0 Technical
R
Report.
t
• MK II Functional Point Analysis Counting Practices
Manual Version 1 3 1 United Kingdom Software
Manual, 1.3.1.
Metrics Association, 1998. — 92 p.
• Paulk M. C., Cutis B., Chriss M. B., Weber Ch. V.
Capability Maturity Model for Software, Version 1.1
CMU SEI, 1993. — 533 p.


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


Из чего состоит методология?
• модели Методология —
совокупность
• техники
методов и правил,
• стандарты
применяемых
• концепции определенным
• инструменты образом,
• методики определенная
процедура или
совокупность
процедур.

Модели зрелости и стандарты
управления ИТ компаниями
ИТ-компаниями
(управленческий аспект)
• CMM / CMMI – Capability Maturity Model
(Интегрированная) – Модель зрелости
процессов разработки. SEI.
• SPICE - Стандарт ISO 15504 SPICE (Software
Process Improvement and Capability
dEtermination))
• TickIT -
• Prince – Project in Controlled Environment –
управление проектами в контролируемой
среде
рд

Проектные методологии
р д
(технический и командный аспект)
• Классическая (каскадная методология) –
стандарты ГОСТ 19, 34
• RUP – Rational Unified Process Рациональный
унифицированный процесс.
у
• MSF – Microsoft Solution Framework
• Семейство методологий Crystal (Agile
Software Development)
• XP - eXtreme Programming – экстремальное
программирование


Два типа методологий
adaptive vs. predictive
Адаптивные методологии фокусируются на быстром отражении
ф у ру р р
происходыщих изменений. Когда меняются требования, команда
разработчиков тоже меняется. Команда, участвующая в адаптивной
разработке, с трудом может предсказать будущее. Существует точный план
лишь на ближайшее время. Более удаленные во времени планы
существуют лишь как декларации о целях проекта, ожидаемых затратах и
результатах (Scrum (in management), Crystal Clear, Extreme Programming,
Adaptive Software Development, DSDM, Feature Driven Development,
Lean software development).
•Прогнозируемы (предикативные) методологии фокусируются на
детальном планировании б будущего. Известны запланированные задачи и
И
ресурсы на весь срок проекта. Команда с трудом реагирует на возможные
имзенения. План оптимизирован исходя из состава работ и существующих
требований.
требований Изменеение требований может привести к существенному
изменеению плана, а так же дизайна проекта. Часто создается
специальный комитет по «управлению изменениями» (change control board)
чтобы в проекте учитывались только самые важные требования.
требования


Сравнение характеристик качества
ISO/IEC 9126 и Б. Боэм
Характеристики качества ISO/IEC 9126
SO/ C Характеристики качества Б. Боэм
[11, стр. 22]
Функциональность Надежность

Надежность Учет человеческого фактора
Понятность

Удобство эксплуатации Эффективность

Эффективность Модифицируемость

Модифицируемость
Мф Мобильность
Мб

Мобильность Оцениваемость

Объекты измерения и
характеристики
Объект измерения Характеристики

Физические строки кода
размер, повторное использование,
исправления
Логические строки кода
р

стоимость, распределение ресурсов,
Рабочее время персонала
степень загрузки

работы, расписание, степень
Сроки выполнения отдельных этапов
р выполнения, готовность к
завершению, вехи

Проблемы и ошибки (дефекты)
р (ф ) качество, тенденция к улучшению
уу

Классификация метрик управления разработкой ПО
Объект Объем Сложность Качество Риски
Система Размер дистрибутива, Количество Время выполнения запроса Вероятность
(внешние размер инсталлируемой одновременных Метрики надежности (время прекращения
метрики) системы запросов, работы без сбоев, время функционирования
распределенность, восстановления), (ухудшения)
использование разных Среднее время между отказами
платформ (MTFB)
Корректность программы (степень
соответствия спецификации)
Код
К Строки кода (SLOC)
С (SLOC), Ц
Цикломатическая Д
Документированность ((отношение О
Отношение числа
(внутренние Объектные метрики: сложность; Объектные числа строк комментариев к ошибок (дефектов) к
метрики) количество классов, метрики. объему); объему; отношение
количество методов на Ожидаемое число дефектов сложности к объему
класс
Документация Количество слов, Уровень образования, Полнота Количество
предложений, таблиц, количество сокращений, Непротиворечивость; неопределенных
рисунков специальных терминов Согласованность интерфейса в формулировок,
спецификациях программных сокращений.
компонент
Процесс Число функций, роли Количество функций, Качество процесса: количество
процесса цикломатическая дефектов/объем.
сложность (алгоритм Количество дефектов,
процесса)
) обнаруженное в единицу времени
б
на различных этапах (просмотр,
компиляция, тестирование)
Проект Метод функциональных Наличие циклов, Время жизненного цикла; Время завершения,
точек (FPUG Mark II)
(FPUG, ветвление стоимость продукта необходимые ресурсы
(отклонение от
бюджета и
расписания)

Аналитические модели в ИТ-проектах,
используемы на на предконтрактной стадии
• Определение стоимости проекта и оценка времени работы Эта
работы.
задача особенно актуальна для проектов с фиксированной
суммой контракта (fixed cost contract). От решения этой задачи
зависит как получение контракта, поскольку в условиях
у р , уу
конкуренции цена должна быть близка к издержкам (best bid),
так и прибыльность компании, поскольку сумма контракта
должна превышать затраты на разработку. Наиболее известной
моделью этого вида является COCOMO II (Early Stage);
• Определение наилучшего плана приемки работ и оплаты; Успех
проекта во многом зависит от того, насколько эффективно
будет решена эта задача особенно в тех случаях, когда
задача, случаях
финансирование проекта осуществляется из текущих выплат
заказчика. Разработаны модели, позволяющие решать эту
задачу для строительных компаний, например модель Рассела.
• Оценка рисков – возможности финансовых убытков в случае
превышения бюджета и возможность нарушения сроков.


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

Аналитические модели в ИТ-проектах
используемые в ходе реализации проекта
•ООптимизация использования ресурсов. Э Эта
задача является наиболее сложной для много
проектных задач. Кроме того, для работ,
р д р ,д р ,
составляющих процесс разработки программного
обеспечения, невозможно использовать одну
функцию зависимости между длительностью работы
и количеством ресурсов. Необходимо выделять
дискретные значения
• Определение статуса проекта, например, сетевая
интерактивная модель контроля за ходом
выполнения проекта Голенко – Гранберга [123]
[123].
• Определение состава работ (WBS, work breakdown
structure), связей между ними

Программа семинара
• Эволюция и современное состояние теории управления ИТ
проектами
р
• Методологии, модели и стандарты разработки
ПО.
– Модели зрелости SW-CMM CMMI Стандарт оценки
SW CMM, CMMI,
возможностей процессов SPICE (ISO 15504), методология
PRINCE.
– Методологии повышения эффективности собственной
разработки Personal Software Process (PSP) и повышения
эффективности командной разработки Team Software Process
(TSP).
– Проектные методологии ГОС 19, 34, Rational Unified Process,
р д ,, ,
Семейство методологий Crystal, SCRUM, eXtreme Programming
(XP), Microsoft Solutions Framework (MSF), принципы быстрой
адаптивной разработки Agile Software Development.
– Методологии внедрения информационных систем: On Target
Axapta, AcceleretedSAP, Oracle AIM, Lotus AVM, Signature Scala.
– Классификация процессов разработки ПО. Метапроцессы.
Области процессов CMMI. Модели процессов ISO 12207, Oracle
CDM, SPICE,
CDM SPICE RUP
• Использование специализированных методик в ИТ-проектах.

Capability Maturity Model – модель зрелости
SW-CMM / CMMI

• CMM - Paulk M. C., Cutis B., Chriss M. B.,
Weber Ch V C
W b Ch. V. Capability M t it M d l f
bilit Maturity Model for
Software, Version 1.1 CMU SEI, 1993. — 533 p.
• CMMI - C
Capability M t it M d l® I t
bilit Maturity Model® Integration
ti
(CMMISM), Version 1.1 Continuous
Representation CMU/SEI 2002 TR 011 ESC
CMU/SEI-2002-TR-011 ESC-
TR-2002-011 CMMI Product Team Copyright
2002 by Carnegie Mellon University 725 p
University. p.
• SEI – Software Engineering Institute


Пять уровней зрелости CMM
ур р
Оптимизирующий (5)
управление изменением процесса
управление изменением технологии
предотвращение дефектов
Управляемый (4)
управление качеством
количественное управление
Определенный (3)
товарищеские обзоры
межгрупповая координация
технологи производства
интегированное управление
повышение квалификации
определение процесса
нацеленность процесса
Повторяемый (2)
управление конфигурацией
обеспечение качества
б
управление субподрядчиками
отслеживание проекта
планирование проекта
упрвление требованиями
б
Начальный (1)

Структура модели CMM
ру ур д
Уровни зрелости

Сходную структуру имеет СММI
ду ру уру
показывают

Staged Representation
включают в себя

Возможности процесса
Ключевые области
процесса

достигают

организуются через

Цели

Общие свойства

определяют

включают в себя

Реализации

Ключевые практики

описывают

Инфраструктуру или
деятельности

CMMI vs. Six Sigma
vs


SPICE
• ISO/IEC TR 15504 SPICE Consolidated
product. Software Process Assessment.
p
Version 1.0 Technical Report.


Структура SPICE
Архитектура SPICE
Процессы
двумерна и состоит из
quot;уровней возможностейquot;,
насчитывается 6 (плюс 9
подлежат рассмотрению
атрибутов процессов
•32 правила менеджмента);
определяет изменения определяет подходящие
•категорий процессов (5)
•типовых процессов (29),
Оценка процессов

•типовых практик (200).
руководит руководит

Совершенствование Определение
мотивирует
процессов возможностей

На наш взгляд, «процесс» SPICE не является, по
сути, процессом, а служит лишь контейнером для
объединения практик, которые не привязаны к
ЖЦ ПО, а реализуются в бизнес-контексте.

MSF Определение
MSF. Определение.
• Система моделей MSF (Microsoft Solution Framework) была
разработана как часть общей методологии Microsoft (Microsoft
Enterprise Framework), которая так же включает в себя MRF
(
(Microsoft Readiness Framework) и MOF (
) (Microsoft Operations
p
Framework). В настоящий момент не предусмотрена
сертификация компаний на соответствие MSF, система
моделей используется не как стандарт, а как руководство,
отвечая не на вопрос, «что делать?», а предоставляя
вопрос делать?»
конкретные рекомендации и отвечая на вопрос «как?».
• MSF используется на этапе проектирования, разработки
приложений и внедрения приложений. Первоначально в момент
приложений
создания в 1994 году MSF представляла собой описание
решения проблем бизнеса с помощью технических средств,
постепенно обобщая лучшую практику групп разработки,
внедрения, клиентов и партнеров MiMicrosoft.
ft


Шесть основных моделей MSF
• Модель производственной архитектуры – набор принципов
принципов,
предусматривающих быстрое создание приложения посредством
выпуска версий. Основная цель – сокращение времени и затрат.
Используются четыре перспективы: бизнес, приложения, информация
и технология.
е оо
• Модель проектной группы – описывает роли и обязанности каждого
участника, распределение ответственности и работу группы;
• Модель процесса разработки ПО – описывает фазы, этапы, виды
фазы этапы
деятельности и результаты процесса, и их связь с моделью проектной
группы;
• Модель управления рисками – описывает путь активного управления
рисками;
• Модель процесса проектирования – описывает трехфазный,
ориентированный на конечного пользователя, непрерывный процесс
рр
разработки;
• Модель приложения - реализует трехуровневый, ориентированный на
сервисы метод проектирования и разработки ПО.


Сравнение ISO 9000, SPICE и CMM –
решение о сертификации
О
Отличительные ISO 9000 SPICE CMM
черты
Основное назначение Определяет требования к Оценить и улучшить Оценить способность организации к
системе качества процессы разработки разработке ПО и улучшить
ПО процессы
Что оценивается? Организация Процесс Организация
Как оценивается? Удовлетворяет Уровень процесса на Уровень зрелости (от 2 до 5)
требованиям основе рейтингов его Анализ документации и интервью
( / ) не основе
(да/нет) практик, полученных
анализа для экземпляров
документации и процессов.
интервью
сотрудников
ру
сторонней
организацией.
Структура Простая структура. Сложная структура. Основу модели составляет
Многоуровневый список Стандарт содержит структурированное описание
требований к девять частей требований к организации,
реализации различной структуры находящейся на определенном
функций – 20 и назначения. уровне 1-5
ключевых Детальная модель Детальная модель
элементов.
эе е о.
Абстрактная модель
Аудит Внешний независимый Внутренняя оценка Внешний независимый

Модель процессов
• Модели процессов представляют собой
списки типовых процессов, выделяемых
рц , д
в стандартах.


Ф. Брукс. Виды деятельности в
разработке ПО
•фформулирование ф формальных конструкций;й
• воплощения в реальном материале;
• диалог с пользователями в реальной жизни.
ао о зо а е реа ой з
На основе этой классификации можно
выделить: процесс проектирования
проектирования,
кодирования и документирования и анализ,
обучение и внедрение.
В результате концептуального проектирования
создается сущность программы (essence), а
результатом воплощения является
второстепенная составляющая (accident).


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


Методологии разработки ПО и
модели жизненного цикла
•ККаскадная модель (ГОСТ 19)
• Итерационная разработка
– RUP
– MSF
• Быстрая разработка
– eXtreme Programming (XP)
– Agile Software development (Crystal Case, Crystal
Clear, Scrum)
• Индивидуальный процесс – PSP Personal
Software Process


Модель процессов жизненного
цикла ISO 12207
Основные процессы Вспомогательные процессы
жизненного цикла жизненного цикла

Заказ Документирование

Управление конфигурацией
Поставка

Обеспечение качества

Верификация
Эксплуатация

Аттестация

Разработка Совместный анализ

Аудит
Сопровождение

Решение проблем

Организационные
процессы жизненного цикла
Управление Создание инфаструктуры

Усовершенствование Обучение


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


Модель процессов ORACLE CDM
• RD - О
Определение производственных требований,
б й
• ES - Исследование существующих систем,
• TA - Определение технической архитектуры
архитектуры,
• DB - Проектирование и построение БД,
• MD - Проектирование и реализация модулей
модулей,
• CV - Конвертирование данных,
• DO - Документирование
Документирование,
• TE - Тестирование,
• TR - Обучение,
у ,
• TS - Переход к новой системе,
• PS - Поддержка и сопровождение.


Процессы SPICE
• Управление проектами (PRO)
• Процессы «Покупатель-
– планирование ЖЦ ПО
поставщик» (CUS)
– разработка плана проекта
– приобретение программного
– формирование команды проекта
обеспечения (услуг)
– управление требованиями
– заключение контракта
– управление качеством
– определение потребностей
покупателя – управление риском
– осуществление совместных – управление ресурсами и
проверок выполнение графика проекта
– доставка и установка ПО – управление субконтрактами
– обслуживание ПО • Поддерживающие процессы
– оказание прочих услуг покупателю (
(SUP)
)
– оценка степени удовлетворенности – разработка документации
покупателя – управление конфигурацией
• Производственные процессы – поддержка системы качества
(ENG) – разрешение конфликтов
рр ф
– разработка требований к системе – дружеские обзоры
– разработка требований к ПО
• Организационные (ORG)
– разработка ПО (программирование)
– организация бизнеса
– сборка ПО и тестирование ПО
– определение процессов
– тестирование системы6. поддержка
– улучшение процессов
системы и ПО
– Обучение
– обеспечение повторного
использования
– обеспечение среды разработки ПО
– обеспечение специалистами

Процессы ИТ проектов
• Процессы управления проектами —
касающиеся организации и описания работ
проекта (соответствуют Организационным
процессам ISO 12207);
• Процессы, ориентированные на продукт —
касающиеся спецификации и производства
продукта. Эти процессы определяются
жизненным циклом проекта и зависят от
области приложения (Основные и
организационные процессы ЖЦ).

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

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


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

Процессы исполнения и контроля

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


Процессы анализа
Процессы анализа включают как анализ плана, так и анализ исполнения проекта.

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


IT project management

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (13)

Mehr von Kate Koltunova

Mehr von Kate Koltunova (18)

IT project management