7-software_engineering_management (1133547), страница 5

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

Текст из файла (страница 5)

Отчетность по результатам создается в соответствие с планом, а также, при выходе зазаданные ограничения проекта или параметров отдельных его работ.Хотелось бы обратить внимание на то, что современная практика управления проектами, вчастности, разработки и сопровождения программного обеспечения, требует обеспечениявозможности доступна к актуальным данным по проекту в любой момент времени.

По-сути внастоящее время возникает целый класс интегрированных инструментов испециализированных продуктов, часто называемый project dashboard (наиболее близкийперевод этого понятия на русский язык может звучать как “панель управления проектом”).Обычно, такие инструменты не только работают со “снимками” данных, сводя их воедино, нообращаются непосредственно к данным в системах конфигурационного управления,управления требованиями, сценариями тестирования, аудита кода, расписания проекта всоответствующих средствах управления проектами и т.п.3.5 Процесс контроля (Control Process)Выходы (результаты) процесса мониторинга обеспечивают базис, на основе которого принимаютсяте или иные решения.

Изменения в проект вносятся там, где это необходимо, и гдеассоциированные риски и их влияние смоделированы и могут быть управляемы (контролируемы).Эти изменения могут проводиться в форме корректирующих действий (например, повторногоCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru11Основы программной инженерии (по SWEBOK)Программная инженерия.

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

предыдущуюобласть знаний Software Configuration Management). При этом, решения должны документироватьсяи сообщаться (желательно, перед этим обсуждаться) всем заинтересованным сторонам, планы –корректироваться (там где это необходимо), а все необходимые данные должны заноситься вцентральную базу данных проекта (см. тему 6.3 Perform the Measurement Process).3.6 Ведение отчетности (Reporting)Отчеты проводятся за определенный и согласованный период времени, согласуясь с планомпроекта и адресуясь заинтересованным лицам (в том числе – “внешним”, со стороны заказчика). Впринципе, возможны выделить две группы отчетов – по общему состоянию проекта (именно, ониобычно адресованы и заказчику), а также детализированные отчеты, подготавливаемые чаще икасающиеся отдельных групп в команде проекта, отдельных работ, групп требований,функциональных модулей и т.п.4.

Обзор и оценка (Review and Evaluation)В критических точках проекта оценивается общий (по всему проекту) прогресс в достиженииустановленных целей и удовлетворении требований заинтересованных лиц. Аналогично, проводитсяоценка (assessment) эффективности процессов, <работы> персонала, а также инструментов иметодов, использованных в работах, проведенных за заданный промежуток времени.4.1 Определение удовлетворения требованиям (Determining Satisfaction of Requirements)Так как достижение удовлетворения пользователей является одной из наших принципиальныхцелей, представляется важным периодическая и формальная оценка прогресса в данном вопросе.Такая оценка проводится при достижении определенных вех (milestones) проекта, например, приутверждении разработанной архитектуры). При этом идентифицируются отклонения отсоответствующих ожиданий (планов) и проводятся необходимые действия, связанные срезультатами оценки отклонений (например, действия по корректировке плана).

Как было отмеченовыше (см. тему 3.5 “Процесс контроля”), во всех случаях проводится контроль изменений ипроцедуры конфигурационного управления, документируются принятые решения и обеспечиваетсянеобходимая отчетность. Дополнительную информацию, также имеющую отношение кобсуждаемому вопросу, можно найти в области знаний “Тестирование программного обеспечения”(Software Testing) в темах 2.2 “Цели тестирования” (Objectivies of Testing) и 2.3 “Оценка и аудит”(Reviews and Audits).4.2 Оценка продуктивности/результативности (Reviewing and Evaluation Performance)Периодическая оценка продуктивности специалистов, вовлеченных в проект, обеспечиваетпонимание того, насколько они следуют плану, и дает возможность идентифицировать вероятныепроблемы (например, конфликты между членами проектной команды).

Для оценки эффективностиприменяются различные методы, инструменты и техники. Сам процесс оценки являетсясистематическим, а процедуры – периодическими. Все это зависит от используемых управленческихтехник, применяемых методологий, организационных принципов, сложившейся культуры, то естьрассматривается, в том числе, в контексте специфики программной инженерии, дисциплиныуправления проектами и общего менеджмента.5. Закрытие (Closure)Проект закрывается/завершается (не путайте с прекращением проекта), когда все планы и процессывыполнены и завершены. На этой стадии в результатам проекта применяются критерии оценки егоуспешности. Когда принимается решение о закрытии проекта, выполняются действия поCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru12Основы программной инженерии (по SWEBOK)Программная инженерия.

Управление программной инженерией.архивированию проектных данных, анализу результатов, полученных в процессе работы надпроектом (post mortem analysis), и улучшению процессов (process improvement).5.1 Определение <критериев> закрытия проекта (Determining Closure)Проект закрывается, когда завершены специфицированные в плане проекта задачи и подтверждено<удовлетворительное> достижение критериев завершения (completion criteria) проекта. При этом, всезапланированные результаты (продукт, его модули и т.п.) должны быть переданы заказчику и/или вэксплуатацию с приемлемыми (с точки зрения требований) и принятыми (со стороны заказчика)характеристиками. Удовлетворение требованиям – проверено и подтверждено/утвержденозаказчиком, а цели проекта – достигнуты.

Перечисленные процессы, в общем случае, требуютвовлечения всех заинтересованных лиц. Результаты их выполнения документируются, включаяподтверждения со стороны заказчика о соответствии результатов проекта заданным требованиям(client acceptance list, например, по результатам приемочных, или, как их еще называют, приемосдаточных тестов) и, если это необходимо, включая также отчеты об оставшихся/требующихдоработки проблемах (known problems).5.2 Работы по закрытию проекта (Closure Activities)После того, как принято и утверждено решение о закрытии проекта (также говорят о “подтверждениизакрытия/завершения проекта”) создается архив материалов в соответствии с утвержденнымизаинтересованными лицами методами, местоположением, формой и заданной длительностьюхранения.

База данных измерений <в организации> обновляется в соответствии с полученнымифинальными данными проекта и проводится пост-проектный анализ этих данных. Анализ позавершении проекта помогает в оптимизации процессов, практик и организационной структуры (см.область знаний Software Engineering Process).6. Измерения в программной инженерии (Software Engineering Measurement)Важность и роль количественных оценок - измерений - в управленческих практиках широко известна,растет с каждым годом и уже не раз подчеркивалась в SWEBOK.

Эффективные измерениястановятся одним из краеугольных камней организационной зрелости.Ключевые термины и методы по измерениям в программной инженерии определены в стандартеISO/IEC 15939:2002 Software Engineering - Software Measurement Process (2002 г.), основывающемсяна международном словаре метрологии, выпущенном ISO в 1993 году. Несмотря на это, в различнойлитературе встречаются разные термины, например, часто термин “metric” – метрика (на русскомязыке выглядит предпочитительным использовать именно этот термин) используется вместо“measure” – измерение.Данная тема следует указанному международному стандарту ISO/IEC 15939, который описываетпроцесс, определяющий действия/работы (activities) и задачи (tasks)*, необходимые для реализациипроцесса ведения измерений, а также включающий информационную модель измерений.* “действия/работы” - activities, “задачи” – tasks: термин “задача” используется для болееглубокого уровня детализации, чем “действия/работы”; термины “действия” и “работы”, как выуже заметили, часто используются взаимозаменяемым образом.

Так или иначе, это вопросдоговоренности о терминологии при организации WBS (Work Breakdown Structure) –структуры декомпозиции работ.6.1 Установление и поддержка процесса ведения измерений (Establish and Sustain MeasurementCommitment)Формулируются требования в отношении измерений. Каждая попытка измерения должнаруководствоваться организационными целями и следовать набору измерений, выполняемыхв отношении требований, в соответствии с принятыми организационными или проектнымистандартами.

Например, в качестве организационной цели может выступать “выпуск нарынок новых продуктов первыми”. Это, в свою очередь, может порождать требование того,Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru13Основы программной инженерии (по SWEBOK)Программная инженерия. Управление программной инженерией.что факторы, способствующие достижению цели также должны быть оцененыколичественно, с тем, чтобы проект могу быть управляем в процессе достижения заданногорезультата. Для этого необходимо:- Определить содержание измерений. Необходимость принять, в каких масштабах – науровне какой организационной единицы* будут проводиться измерения – только в однойфункциональной области, в рамках проекта, на уровне комплекса проектов или ворганизации, в целом.

Все последующие задачи по ведению измерений, связанные ссоответствующими требованиями, ведутся в рамках принятого содержания измерений.Безусловно, в дополнение к этому необходимо идентифицировать всех заинтересованныхлиц, ассоциированных и вовлеченных в проведение измерений.- Заручиться поддержкой менеджеров и персонала в ведении измерений. Такая поддержкадолжна быть оформлена формально, сообщена персоналу и поддержана соответствующимиресурсами (см. ниже).* организационная единица - organizational unit: этот термин хоть и не очень удачен вSWEBOK, но будет использоваться достаточно часто в контексте ведения измерений дляописания границ измерений.

При этом часто подразумевается не фиксированная структурнаяединица в организации, а некая “единица деятельности”, в отношении которой проводятсяизмерения – операция, задача, работа, проект, программа, деятельность организации, вцелом.Выделяются соответствующие ресурсы для проведения измерений. Организационнаяподдержка измерений является основным фактором успеха, так как назначение ресурсовпросто необходимо для реализации процесса ведения измерений. Назначение ресурсоввключает распределение ответственности (например, пользователь, аналитик и т.п.) вотношении различных задач процесса измерения и предоставление необходимогофинансирования, обучения, инструментов и поддержки процесса сопровождения напостоянной основе.6.2 Планирование процесса измерений (Plan the Measurement Process)Задание “организационной единицы” (в частности, в понимании “единицы деятельности”, какописывалось выше).

Характеристики

Список файлов книги