IT project management

11,459 views

Published on

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

IT project management

  1. 1. Управление р ИТ-проектами Семинар
  2. 2. Управление ИТ проектами Колтунова Екатерина kate@koltunova.com www.koltunova.com www koltunova com + 7 (911) 250-22-47
  3. 3. Программа семинара • Эволюция и современное состояние теории управления ИТ проектами – Концепции управления: Процессное управление (BPR, BPI), (BPR BPI) всеобщее управление качеством б (TQM), управление проектами, управление изменениями. – Классификация инструментальных средств управления ИТ-проектами. – История развития методологий управления ИТ- проектами, концепции Ф. Брукса, У. Ройса, У. Хамфри, Э. Йордона, Дж. Хайсмита и А. Коберна. • Методологии, модели и стандарты разработки ПО ПО. • Использование специализированных методик в ИТ-проектах.
  4. 4. Инструментальные средства управления ИТ проектами Языки Методики Стандарты ЖЦ ПО Техники моделирования Формализованное представ Итерационная Оценка трудоемкости Анализ и оценка Последовательная разработка. Структурные риска разработки ПО разработка 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
  5. 5. Концепция стратегических карт (Strategy Map) Цели собственников в отношении роста организации, производительности и т.д. тд Ценность для клиентов. Цены, качество, бренд, дополнительный сервис. Сегментация рынка. Бизнес-процессы для предоставления заявленных ценностей для клиентов. Персонал, технологии, организационная культура – все, что необходимо для эффективной реализации процессов процессов. Екатерина Колтунова www.koltunova.com
  6. 6. Реинжиниринг бизнес-процессов BPR р рц • Впервые предложен Ф.Тейлором в 1900г. в статье Принципы научного менеджмента (The Principles of Scientific Management )). Эти идей легли в основу TQM. • Business Process Redesign – анализ и проектирование потоков р работ внутри и между организациями (Davenport & Short, 1990). ур ду р ц ( p , ) Ключевые цели: удовлетворение клиентов, результативность и эффективность. • «BPR - фундаментальное переосмысление и рад ал а фу да е ал ое ереос сле е радикальная реконструкция бизнес-процессов с целью достижения драматически сильных улучшений в критически важных в современных условиях уровнях критериев производительности, таких как стоимость, качество, услуги, скорость» М Хаммер, Дж. М. Х Д Чампи. • Суть феномена BPR – в реинтеграции процессов – реагирование на крайности специализации и разделения труда труда. Преодоление отрицательных эффектов стратегий Смита- Маркса-Гилбрета. Екатерина Колтунова www.koltunova.com
  7. 7. Три уровня усилий по улучшению процессов • Непрерывное улучшение процессов (Continuous Process Improvement, CPI) – устранение вариаций в качестве выпускаемых продуктов и оказываемых услуг. • Ре-дизайн бизнес-процессов (Business Process Redesign) - удаление активностей, не создающих g ) уд , дщ дополнительной стоимости. Сокращение времени выполнения процесса, снижение стоимости. • Реинжиниринг бизнес-процессов (Business process reengineering) – радикальная трансформация процессов с использованием новых технологий для достижения радикального выигрыша в производительности процесса, эффективности и качестве. Екатерина Колтунова www.koltunova.com
  8. 8. Определения бизнес-процесса бизнес процесса • М Хаммер Дж Чампи: «бизнес процесс - набор М. Хаммер, Дж. «бизнес-процесс активностей, которые преобразуют несколько видов входных характеристик в выход, имеющий ценность для потребителя» потребителя». • Т. Давенпорт: «бизнес-процесс - специфически упорядоченная во времени и в пространстве совокупность работ, с указанием начала и конца и точным определением входов и выходов». • Дж. Мартин использует близкое понятие потока потребительных ценностей (value stream). Поток потребительных ценностей - множество законченных состыкованных действий которые в совокупности действий, создают некоторую продукцию, имеющую потребительскую ценность для клиента. Екатерина Колтунова www.koltunova.com
  9. 9. Формализация (структурирование) процесса включает в себя определение: • целей процесса; й • владельца процесса; • сос а а и последовательности рабо состава ос е о а е ос работ; • условий входа и выхода (как для граничных работа, работа так и для работ внутри процесса); • входов и выходов (используемых материалов, производимой продукции, документации); • участников процесса (ответственность, роли и деятельности для каждого участника в разрезе работ). Екатерина Колтунова www.koltunova.com
  10. 10. Использование CASE-средств и моделирование бизнес-процессов •ИИнтерактивное моделирование с обсуждением: Paper-design, Yellow papers, whiteboards • Моделирование BPWin, ARIS, Visio – документы для обсуждения у у • Имитационное моделирование AnyLogic, iThink • Моделирование - как часть настройки системы (ARIS for NetWeaver, Hummerbird и другие системы DocFlow Visio .Net => DocFlow, Net BizTalk) Екатерина Колтунова www.koltunova.com
  11. 11. Методы реинжиниринга • Об Объединение дублирующих ф б функцийй • Устранение множественных уровней проверки и получения подтверждения • Снижение размера выпускаемых партий • Регулирование на основе спроса (demand pull) • Передача партнерам неэффективно выполняемых функций • Устранение перемещений в процессе выполнения данной работы •ООрганизация многофункциональных групп ( ф (команд). ) Екатерина Колтунова www.koltunova.com
  12. 12. Всеобщее управление качеством (TQM) • TQM (TQM Total Quality Management) представляет (TQM, T t l Q lit M t) собой совокупность принципов, статистических методов и методик повышения качества. д д • TQM – это система непрерывного улучшения, основанная на использовании вовлеченного (participative) ( ti i ti ) управления и сфокусированная на ф потребностях клиентов. • Ключевые элементы TQM: вовлечение сотрудников сотрудников, обучение, команды по решению проблем, статистические методы, долгосрочне цели, понимание, что система, а не люди, является причиной неэффективности. Екатерина Колтунова www.koltunova.com
  13. 13. Качество ПО • отсутствие ошибок (дефектов); • соответствие спецификации; • пригодность к использованию; • удобство использования (комфортабельность). ( о фор абе ос ) Екатерина Колтунова www.koltunova.com
  14. 14. Определение качества в ISO 8402 ОБЪЕКТ - то, что может быть индивидуально описано или рассмотрено Деятельность Система или Продукция Организация или процесс отдельное лицо КАЧЕСТВО - совокупность характеристик объекта, осносящиеся к его способности удовлетворять установленные и предполагаемые требования Екатерина Колтунова www.koltunova.com
  15. 15. Специфика управления качеством ПО •ООтсутствием точной повторяемости процессов, й жестко заданной технологии, индивидуальный характер производства ( р р рр д (проектная модель): д ) • Общие подходы методологии TQM (Total Quality Management) могут быть использованы при разработке ПО, но применение традиционных б ПО инструментов, к которым относятся гистограммы, временные ряды, д а ра ре е е р д , диаграммы Парето, причинно- аре о, р о следственные диаграммы, контрольные листки, контрольные карты, диаграммы рассеяния, связано с большими методологическими и технологическими трудностями. Екатерина Колтунова www.koltunova.com
  16. 16. Идеальное качество vs. good enough software •О Одним из аспектов, порождающих трудности в разработке ПО, становится требование идеального качества, выражаемого в терминах количества , р р ошибок, переносимости, независимости от платформы, и других. •И Идеальное качество недостижимо в б большинстве проектов, поэтому необходимо прийти к соглашению о ос е относительно того, какое качество является о о о, а ое а ес о ес достаточно хорошим, то есть определить требования к «достаточно хорошему» ПО (good enough software) Эдвард Йордон Екатерина Колтунова www.koltunova.com
  17. 17. Управление качеством за границами проектов • Достижение качества невозможно без культурных изменений в организации: принятии цели постоянного улучшения, уничтожения границ между функциональными отделами, организации постоянного обучения для всех сотрудников. • Управление качеством не может быть заменено р управлением функциональными требованиями и проектом, поскольку качество ПО определяется не только наличием функциональных возможностей и о оа е фу ц о а оз о ос е завершением проекта в срок, но возможностью его модификации, защитой от неправильного использования, легкости интеграции с другими приложениями. Решение проблемы создания системы качества лежит за границами отдельных проектов. проектов Екатерина Колтунова www.koltunova.com
  18. 18. Управление проектами и управление качеством • Практика управления разработкой программного обеспечения распадается на две основные сферы: управление проектами и управление качеством. • Управление проектами направлено на достижение целей отдельных проектов • Управление качеством направлено на повышение эффективности работы всей компании. Екатерина Колтунова www.koltunova.com
  19. 19. Проект р • уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, предпринятый чтобы достичь цели-задачи (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] Екатерина Колтунова www.koltunova.com
  20. 20. ИТ Проект • Использует стандартные методологии ур управления ИТ проектом р • Предполагает одновременное управление требованиями персоналом, требованиями, персоналом рисками, качеством, бюджетом (ресурсами) и изменениями ( ) • Кооперативная игра (две цели) • Несовершенство коммуникаций Екатерина Колтунова www.koltunova.com
  21. 21. Ф. Брукс об управлении ИТ-проектами • «… липовые графики нацеленные на желательную графики, дату, встречаются здесь значительно чаще, чем в любых других инженерных отраслях. Очень тяжело, рискуя потерять рабочее место, с энергией и б й любознательностью отстаивать срок, который определен без применения каких-либо количественных методов при недостатке данных и подкреплен, в основном, интуицией менеджеров» • «… трудности, испытываемы при управлении руд ос , с ае р у ра е крупными проектами, иного рода, нежели при управлении небольшими проектами, что связано с проблемами разделения труда. Я считаю важнейшей задачей сохранение концептуальной целостности самого продукта» Екатерина Колтунова www.koltunova.com
  22. 22. Подходы к управлению ИТ-проектами ИТ проектами • Проектный подход (менеджерский) • Технический подход (инженерный) ( р ) • Командный подход (психологический) Эффективно объединение всех подходов Екатерина Колтунова www.koltunova.com
  23. 23. Управление проектами: определение • уникальный процесс состоящий из набора взаимоувязанных и процесс, контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели-задачи (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] Екатерина Колтунова www.koltunova.com
  24. 24. ИТ проект: определения ИТ-проект: • В. Липаев. В В Липаев определяет проект как комплекс формально организованных мероприятий по достижению единой цели создания сложной системы с заданными характеристиками качества при ограниченных р ур р р ресурсах. • В CMMI “проект” – это управляемый набор взаимосвязанных ресурсов, который обеспечивает выпуск одного или нескольких продуктов для клиента или конечного пользователя. Этот набор продуктов обычно определяется в начале и управляется в б соответствие с планом. • Проект определяется как процесс, предприятие, намерение, усилие и действие Под проектом понимается комплекс работ действие. работ, направленных на достижение запланированной и, как правило, уникальной цели. На практике проект представляет собой совокупность процессов, обеспечивающих изменение у рц , щ технических или социальных систем. Проект включает в себя замысел (проблему), средства его реализации (решения проблемы) и получаемые в процессе реализации результаты. Екатерина Колтунова www.koltunova.com
  25. 25. Управление ИТ проектами: международная практика • 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. Екатерина Колтунова www.koltunova.com
  26. 26. Функции управления проектами • планирование — разработка и б сбалансированный анализ комплексов работ и ресурсов, направленных на достижение ресурсов целей проекта; • организация — разработка системы распределения ресурсов и назначение ответственных исполнителей; • контроль за ходом работ — сравнение плановых параметров работ с фактическими и выработка корректирующих воздействий. Екатерина Колтунова www.koltunova.com
  27. 27. Из чего состоит методология? • модели Методология — совокупность • техники методов и правил, • стандарты применяемых • концепции определенным • инструменты образом, • методики определенная процедура или совокупность процедур.
  28. 28. Модели зрелости и стандарты управления ИТ компаниями ИТ-компаниями (управленческий аспект) • CMM / CMMI – Capability Maturity Model (Интегрированная) – Модель зрелости процессов разработки. SEI. • SPICE - Стандарт ISO 15504 SPICE (Software Process Improvement and Capability dEtermination)) • TickIT - • Prince – Project in Controlled Environment – управление проектами в контролируемой среде рд Екатерина Колтунова www.koltunova.com
  29. 29. Проектные методологии р д (технический и командный аспект) • Классическая (каскадная методология) – стандарты ГОСТ 19, 34 • RUP – Rational Unified Process Рациональный унифицированный процесс. у • MSF – Microsoft Solution Framework • Семейство методологий Crystal (Agile Software Development) • XP - eXtreme Programming – экстремальное программирование Екатерина Колтунова www.koltunova.com
  30. 30. Два типа методологий adaptive vs. predictive Адаптивные методологии фокусируются на быстром отражении ф у ру р р происходыщих изменений. Когда меняются требования, команда разработчиков тоже меняется. Команда, участвующая в адаптивной разработке, с трудом может предсказать будущее. Существует точный план лишь на ближайшее время. Более удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах (Scrum (in management), Crystal Clear, Extreme Programming, Adaptive Software Development, DSDM, Feature Driven Development, Lean software development). •Прогнозируемы (предикативные) методологии фокусируются на детальном планировании б будущего. Известны запланированные задачи и И ресурсы на весь срок проекта. Команда с трудом реагирует на возможные имзенения. План оптимизирован исходя из состава работ и существующих требований. требований Изменеение требований может привести к существенному изменеению плана, а так же дизайна проекта. Часто создается специальный комитет по «управлению изменениями» (change control board) чтобы в проекте учитывались только самые важные требования. требования Екатерина Колтунова www.koltunova.com
  31. 31. Сравнение характеристик качества ISO/IEC 9126 и Б. Боэм Характеристики качества ISO/IEC 9126 SO/ C Характеристики качества Б. Боэм [11, стр. 22] Функциональность Надежность Надежность Учет человеческого фактора Понятность Удобство эксплуатации Эффективность Эффективность Модифицируемость Модифицируемость Мф Мобильность Мб Мобильность Оцениваемость
  32. 32. Объекты измерения и характеристики Объект измерения Характеристики Физические строки кода размер, повторное использование, исправления Логические строки кода р стоимость, распределение ресурсов, Рабочее время персонала степень загрузки работы, расписание, степень Сроки выполнения отдельных этапов р выполнения, готовность к завершению, вехи Проблемы и ошибки (дефекты) р (ф ) качество, тенденция к улучшению уу
  33. 33. Классификация метрик управления разработкой ПО Объект Объем Сложность Качество Риски Система Размер дистрибутива, Количество Время выполнения запроса Вероятность (внешние размер инсталлируемой одновременных Метрики надежности (время прекращения метрики) системы запросов, работы без сбоев, время функционирования распределенность, восстановления), (ухудшения) использование разных Среднее время между отказами платформ (MTFB) Корректность программы (степень соответствия спецификации) Код К Строки кода (SLOC) С (SLOC), Ц Цикломатическая Д Документированность ((отношение О Отношение числа (внутренние Объектные метрики: сложность; Объектные числа строк комментариев к ошибок (дефектов) к метрики) количество классов, метрики. объему); объему; отношение количество методов на Ожидаемое число дефектов сложности к объему класс Документация Количество слов, Уровень образования, Полнота Количество предложений, таблиц, количество сокращений, Непротиворечивость; неопределенных рисунков специальных терминов Согласованность интерфейса в формулировок, спецификациях программных сокращений. компонент Процесс Число функций, роли Количество функций, Качество процесса: количество процесса цикломатическая дефектов/объем. сложность (алгоритм Количество дефектов, процесса) ) обнаруженное в единицу времени б на различных этапах (просмотр, компиляция, тестирование) Проект Метод функциональных Наличие циклов, Время жизненного цикла; Время завершения, точек (FPUG Mark II) (FPUG, ветвление стоимость продукта необходимые ресурсы (отклонение от бюджета и расписания)
  34. 34. Аналитические модели в ИТ-проектах, используемы на на предконтрактной стадии • Определение стоимости проекта и оценка времени работы Эта работы. задача особенно актуальна для проектов с фиксированной суммой контракта (fixed cost contract). От решения этой задачи зависит как получение контракта, поскольку в условиях у р , уу конкуренции цена должна быть близка к издержкам (best bid), так и прибыльность компании, поскольку сумма контракта должна превышать затраты на разработку. Наиболее известной моделью этого вида является COCOMO II (Early Stage); • Определение наилучшего плана приемки работ и оплаты; Успех проекта во многом зависит от того, насколько эффективно будет решена эта задача особенно в тех случаях, когда задача, случаях финансирование проекта осуществляется из текущих выплат заказчика. Разработаны модели, позволяющие решать эту задачу для строительных компаний, например модель Рассела. • Оценка рисков – возможности финансовых убытков в случае превышения бюджета и возможность нарушения сроков. Екатерина Колтунова www.koltunova.com
  35. 35. Использование аналитических моделей в планировании ИТ-проектов: задачи • Оценка возможности выполнения проекта ( ц р (оценка концепции) цц) • Оценка дизайна, сравнение возможных вариантов реализации • Принятие решения об участии в тендере • Подготовка проектного предложения • Согласование договора. Екатерина Колтунова www.koltunova.com
  36. 36. Аналитические модели в ИТ-проектах используемые в ходе реализации проекта •ООптимизация использования ресурсов. Э Эта задача является наиболее сложной для много проектных задач. Кроме того, для работ, р д р ,д р , составляющих процесс разработки программного обеспечения, невозможно использовать одну функцию зависимости между длительностью работы и количеством ресурсов. Необходимо выделять дискретные значения • Определение статуса проекта, например, сетевая интерактивная модель контроля за ходом выполнения проекта Голенко – Гранберга [123] [123]. • Определение состава работ (WBS, work breakdown structure), связей между ними Екатерина Колтунова www.koltunova.com
  37. 37. Программа семинара • Эволюция и современное состояние теории управления ИТ проектами р • Методологии, модели и стандарты разработки ПО. – Модели зрелости 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 • Использование специализированных методик в ИТ-проектах. Екатерина Колтунова www.koltunova.com
  38. 38. 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 Екатерина Колтунова www.koltunova.com
  39. 39. Пять уровней зрелости CMM ур р Оптимизирующий (5) управление изменением процесса управление изменением технологии предотвращение дефектов Управляемый (4) управление качеством количественное управление Определенный (3) товарищеские обзоры межгрупповая координация технологи производства интегированное управление повышение квалификации определение процесса нацеленность процесса Повторяемый (2) управление конфигурацией обеспечение качества б управление субподрядчиками отслеживание проекта планирование проекта упрвление требованиями б Начальный (1)
  40. 40. Структура модели CMM ру ур д Уровни зрелости Сходную структуру имеет СММI ду ру уру показывают Staged Representation включают в себя Возможности процесса Ключевые области процесса достигают организуются через Цели Общие свойства определяют включают в себя Реализации Ключевые практики описывают Инфраструктуру или деятельности Екатерина Колтунова www.koltunova.com
  41. 41. CMMI vs. Six Sigma vs Екатерина Колтунова www.koltunova.com
  42. 42. SPICE • ISO/IEC TR 15504 SPICE Consolidated product. Software Process Assessment. p Version 1.0 Technical Report. Екатерина Колтунова www.koltunova.com
  43. 43. Структура SPICE Архитектура SPICE Процессы двумерна и состоит из quot;уровней возможностейquot;, насчитывается 6 (плюс 9 подлежат рассмотрению атрибутов процессов •32 правила менеджмента); определяет изменения определяет подходящие •категорий процессов (5) •типовых процессов (29), Оценка процессов •типовых практик (200). руководит руководит Совершенствование Определение мотивирует процессов возможностей На наш взгляд, «процесс» SPICE не является, по сути, процессом, а служит лишь контейнером для объединения практик, которые не привязаны к ЖЦ ПО, а реализуются в бизнес-контексте. Екатерина Колтунова www.koltunova.com
  44. 44. 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 Екатерина Колтунова www.koltunova.com
  45. 45. Шесть основных моделей MSF • Модель производственной архитектуры – набор принципов принципов, предусматривающих быстрое создание приложения посредством выпуска версий. Основная цель – сокращение времени и затрат. Используются четыре перспективы: бизнес, приложения, информация и технология. е оо • Модель проектной группы – описывает роли и обязанности каждого участника, распределение ответственности и работу группы; • Модель процесса разработки ПО – описывает фазы, этапы, виды фазы этапы деятельности и результаты процесса, и их связь с моделью проектной группы; • Модель управления рисками – описывает путь активного управления рисками; • Модель процесса проектирования – описывает трехфазный, ориентированный на конечного пользователя, непрерывный процесс рр разработки; • Модель приложения - реализует трехуровневый, ориентированный на сервисы метод проектирования и разработки ПО. Екатерина Колтунова www.koltunova.com
  46. 46. Сравнение ISO 9000, SPICE и CMM – решение о сертификации О Отличительные ISO 9000 SPICE CMM черты Основное назначение Определяет требования к Оценить и улучшить Оценить способность организации к системе качества процессы разработки разработке ПО и улучшить ПО процессы Что оценивается? Организация Процесс Организация Как оценивается? Удовлетворяет Уровень процесса на Уровень зрелости (от 2 до 5) требованиям основе рейтингов его Анализ документации и интервью ( / ) не основе (да/нет) практик, полученных анализа для экземпляров документации и процессов. интервью сотрудников ру сторонней организацией. Структура Простая структура. Сложная структура. Основу модели составляет Многоуровневый список Стандарт содержит структурированное описание требований к девять частей требований к организации, реализации различной структуры находящейся на определенном функций – 20 и назначения. уровне 1-5 ключевых Детальная модель Детальная модель элементов. эе е о. Абстрактная модель Аудит Внешний независимый Внутренняя оценка Внешний независимый
  47. 47. Модель процессов • Модели процессов представляют собой списки типовых процессов, выделяемых рц , д в стандартах. Екатерина Колтунова www.koltunova.com
  48. 48. Ф. Брукс. Виды деятельности в разработке ПО •фформулирование ф формальных конструкций;й • воплощения в реальном материале; • диалог с пользователями в реальной жизни. ао о зо а е реа ой з На основе этой классификации можно выделить: процесс проектирования проектирования, кодирования и документирования и анализ, обучение и внедрение. В результате концептуального проектирования создается сущность программы (essence), а результатом воплощения является второстепенная составляющая (accident). Екатерина Колтунова www.koltunova.com
  49. 49. Уровни процессов • Метапроцесс: - политика, приемы и практика, которые присущи некоторой организации при ведении интенсивного бизнес, связанного с ПО. В центре этого процесса находится экономика организации, долговременная стратегия и возврат инвестиций в ПО. • Макропроцесс - политика, приемы и практика, которые присущи некоторому проекту по созданию законченного ПО с учетом определенных ограничений по стоимости, срокам и качеству. В центре этого процесса находится создание адекватного варианта метапроцесса для конкретного набора ограничений. • Микропроцесс - политика, приемы и практика, присущие команде разработчиков некоторого проекта и направленные на получение результатов в процессе создания ПО. Главным для микропроцесса является создание промежуточного продукта адекватного качества с адекватными р ду д д функциональными возможностями настолько экономично и быстро, насколько это осуществимо на практике У. Ройс Екатерина Колтунова www.koltunova.com
  50. 50. Методологии разработки ПО и модели жизненного цикла •ККаскадная модель (ГОСТ 19) • Итерационная разработка – RUP – MSF • Быстрая разработка – eXtreme Programming (XP) – Agile Software development (Crystal Case, Crystal Clear, Scrum) • Индивидуальный процесс – PSP Personal Software Process Екатерина Колтунова www.koltunova.com
  51. 51. Модель процессов жизненного цикла ISO 12207 Основные процессы Вспомогательные процессы жизненного цикла жизненного цикла Заказ Документирование Управление конфигурацией Поставка Обеспечение качества Верификация Эксплуатация Аттестация Разработка Совместный анализ Аудит Сопровождение Решение проблем Организационные процессы жизненного цикла Управление Создание инфаструктуры Усовершенствование Обучение Екатерина Колтунова www.koltunova.com
  52. 52. Области процессов интегрированной модели зрелости CMMI • Управление процессами – активности пересекающие границы активности, проектов, развитие организации, обучение, разработка, оценка, совершенствование процессов. Обеспечивают способность организации документировать и распространять лучшие р ц ду р р р р у практики, обеспечивают обучение организации; • Управление проектами – активности, связанные с управлением проектами, включая планирование, контроль, управление рисками, взаимоотношения с подрядчиками, формирование команды; • Разработка – активности, связанные с проектированием и разработкой включая разработку требований и управление разработкой, ими, программирование, интеграцию, валидацию и верификацию; • Поддержка – активности обеспечивающие выполнение прочих активности, процессов: управление конфигурацией, обеспечение качества, оценка и измерения, анализ принятых решений Екатерина Колтунова www.koltunova.com
  53. 53. Модель процессов ORACLE CDM • RD - О Определение производственных требований, б й • ES - Исследование существующих систем, • TA - Определение технической архитектуры архитектуры, • DB - Проектирование и построение БД, • MD - Проектирование и реализация модулей модулей, • CV - Конвертирование данных, • DO - Документирование Документирование, • TE - Тестирование, • TR - Обучение, у , • TS - Переход к новой системе, • PS - Поддержка и сопровождение. Екатерина Колтунова www.koltunova.com
  54. 54. Процессы SPICE • Управление проектами (PRO) • Процессы «Покупатель- – планирование ЖЦ ПО поставщик» (CUS) – разработка плана проекта – приобретение программного – формирование команды проекта обеспечения (услуг) – управление требованиями – заключение контракта – управление качеством – определение потребностей покупателя – управление риском – осуществление совместных – управление ресурсами и проверок выполнение графика проекта – доставка и установка ПО – управление субконтрактами – обслуживание ПО • Поддерживающие процессы – оказание прочих услуг покупателю ( (SUP) ) – оценка степени удовлетворенности – разработка документации покупателя – управление конфигурацией • Производственные процессы – поддержка системы качества (ENG) – разрешение конфликтов рр ф – разработка требований к системе – дружеские обзоры – разработка требований к ПО • Организационные (ORG) – разработка ПО (программирование) – организация бизнеса – сборка ПО и тестирование ПО – определение процессов – тестирование системы6. поддержка – улучшение процессов системы и ПО – Обучение – обеспечение повторного использования – обеспечение среды разработки ПО – обеспечение специалистами
  55. 55. Процессы ИТ проектов • Процессы управления проектами — касающиеся организации и описания работ проекта (соответствуют Организационным процессам ISO 12207); • Процессы, ориентированные на продукт — касающиеся спецификации и производства продукта. Эти процессы определяются жизненным циклом проекта и зависят от области приложения (Основные и организационные процессы ЖЦ). Екатерина Колтунова www.koltunova.com
  56. 56. Процессы управления ИТ-проектами р ур р • процессы инициации - принятие решения о начале выполнения проекта; процессы планирования - определение целей и критериев успеха проекта и разработка рабочих схем их достижения; • процессы исполнения - координация людей и других ресурсов для выполнения плана; • процессы анализа - определение соответствия плана и исполнения рц рд проекта поставленным целям и критериям успеха и принятие решений о необходимости применения корректирующих воздействий; • процессы управления - определение необходимых корректирующих воздействий, воздействий их согласование утверждение и применение; согласование, • процессы завершения - формализация выполнения проекта и подведение его к упорядоченному финалу.
  57. 57. Основные процессы планирования р р • Планирование целей - проектное обоснование, основные этапы и цели проекта • Декомпозиция целей - декомпозиция на более мелкие и более управляемые компоненты • Определение состава операций (работ) проекта - составление перечня операций р рц • Определение взаимосвязей операций - документирование технологических взаимосвязей • Оценка длительностей или объемов работ • О Определение ресурсов ( (людей, оборудования, материалов) проекта– йб ) • Назначение ресурсов - определение ресурсов для выполнения операций проекта • Оценка стоимостей - определение составляющих стоимостей операций • Составление расписания выполнения работ • Оценка бюджета – по этапам, ф ц д , фазам, срокам ,р • Разработка плана исполнения проекта - интеграция результатов остальных подроцессов для составления полного документа. • Определение критериев успеха исполнения проекта. Екатерина Колтунова www.koltunova.com
  58. 58. Вспомогательные процессы планирования • Планирование качества - определение того, какие стандарты того качества использовать в проекте, и того, как эти стандарты достичь • Планирование организации - определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в р организации • Назначение персонала - назначение человеческих ресурсов на выполнение работ проекта • Планирование взаимодействия - определение потоков информации и способов взаимодействия, необходимых для участников проекта • Идентификация риска - определение и документирование событий риска, которые могут повлиять на проект • Оценка риска - оценка вероятностей наступления событий риска, их характеристик и влияния на проект • Разработка реагирования - определение необходимых действий для предупреждения рисков и реакции на угрожающие события • Планирование поставок - определение того, что, как и когда должно быть поставлено • Подготовка условий - выработка требований к поставкам и д у р р определение потенциальных поставщиков. Екатерина Колтунова www.koltunova.com
  59. 59. Процессы исполнения и контроля Под исполнением подразумеваются процессы реализации составленного плана. К основным процессам относиться сам процесс исполнения плана проекта. р Среди вспомогательных процессов отметим: • учет исполнения - подготовка и распределение необходимой для участников проекта информации с требуемой периодичностью • подтверждение качества - регулярная оценка исполнения проекта с д д целью подтверждения соответствия принятым стандартам качества • подготовка предложений -сбор рекомендаций, отзывов, предложений, заявок и т.д. д • выбор поставщиков - оценка предложений, выбор поставщиков и подрядчиков и заключение контрактов • контроль контрактов - контроль исполнения контрактов поставщиками и подрядчиками Екатерина Колтунова www.koltunova.com
  60. 60. Процессы анализа Процессы анализа включают как анализ плана, так и анализ исполнения проекта. К основным относятся те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта: • анализ сроков - определение соответствия фактических и прогнозных сроков исполнения операций проекта директивным или запланированным рц р др р • анализ стоимости - определение соответствия фактической и прогнозной стоимости операций и фаз проекта директивным или запланированным • анализ качества - мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определения путей устранения причин нежелательных результатов исполнения качества проекта; подтверждение целей- процесс формальной приемки результатов проекта его участниками (инвесторами, потребителями и т.д.). Вспомогательные процессы анализа рц • оценка исполнения - анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта • анализ ресурсов - определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов плановым значениям. Екатерина Колтунова www.koltunova.com

×