Лекция 6. Управление программной инженерией (Software Engineering Management)

Управление:

· Интеграцией проекта.

· Содержанием проекта. 

· Сроками проекта. 

· Стоимостью проекта.

· Качеством проекта.

· Человеческими ресурсами проекта.

· Коммуникациями проекта.

· Рисками проекта.

· Поставками проекта.

 

Перейдем к рассмотрению

 

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

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

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

 Все блоки на рисунке пронумерованы для удобства ссылок по ходу изложения.     

Далее, как и всегда, будем вести изложение в соответствие с рис.6.1.

 

Рис.6.1. Управление программной инженерией

 

1. Инициирование и управление содержанием

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

  Если проект признан осуществимым, следующей задачей является специфицирование процедур проверки и изменения требований (см. Лекция 1 «Требования к программному обеспечению» – Software Requirements).

 

1.1. Определение и обсуждение требований (Determination and Negotiation of Requirements)

 

 Первичными работами, необходимыми для определения содержания, целей и ограничений проекта являются выбор и применение методов:

· определения (извлечения) требований;

· анализа их (например, моделирование сценариев);

· специфицирования и проверки (например, прототипирования).

 

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

Планирование программного проекта (Software Project Planning)

  Процесс планирования является итеративным и базируется на содержании, требованиях и оценке осуществимости проекта.    

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

При планировании также оцениваются и отбираются соответствующие процессы жизненного цикла.

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

Такие характеристики, обычно, связаны с вопросами качества, соблюдением сроков выполнения работ, усилиями, стоимостью и т.д.

Ресурсы распределяются по задачам таким образом, чтобы обеспечить оптимальную продуктивность (на персональном, командном и организационном уровне), использование средств (инфраструктуры, инструментов,...) и оборудования, а также строгое соблюдение проектного расписания.

Также должно проводится управление рисками и, в частности, необходимо определить «профиль рисков», принятый соответствующими заинтересованными лицами.

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

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

 

Планирование процесса (Process Planning)

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

Также должны быть выбраны методы и инструменты. На уровне проекта, методы и инструменты используются для декомпозиции проекта в виде набора задач, с ассоциированными входами, выходами и условиями завершения, например, в форме структуры декомпозиции работ – WBS (work breakdown structure). Это влияет на высокоуровневое (первичное) определение проектного расписания и организационной структуры. 

 

Таблица.6.1. Расчет средне взвешенного времени выполнения

Для наглядности составляется сетевая диаграмма проекта:

 

• Сетевая диаграмма – графическое отображение работ проекта и зависимостей между ними.

• Цель – сократить до минимума продолжительность проекта.

 

Как правило, сетевая диаграмма представляется в виде графа, в котором вершинами являются проектные работы, а взаимосвязь и последовательность работ отображается соединительными линиями, как показано на рис.6.2.

Рис.6.2. Пример сетевой диаграммы

Как показано на рисунке, работа в сетевой диаграмме отображается в виде прямоугольника, в котором содержится информации о работе: код в СДР (например: 1.1.), наименование и продолжительность работы.

Стрелками, обозначается последовательность и взаимосвязь работ. Взаимосвязи также могут характеризоваться временными показателями.

Например, на рисунке работы 1.1. и 1.2. связаны соединительной стрелкой со значением «+1д». Это означает, что работа 1.2. должна начаться через день после того как начнется работа 1.1.

На стрелке, соединяющей работы 1.2. и 3. стоит значение «-2д». Это означает, что работа 3 должна начаться за два дня до окончания работы 1.2.

Если на стрелке нет дополнительной информации, как например на стрелке, соединяющей работы 1.1. и 2., то это означает, что работа 2 начинается сразу как закончится работа 1.1.

Критическая работа – работа, увеличение продолжительности которой, влечет увеличение продолжительности всего проекта. На рисунке они отображены красным цветом (верхняя ветвь диаграммы – 3 блока).

Некритические работы имеют временной резерв. В случае, если этот временной резерв исчерпан в процессе реализации работы, она становится критической, т.е. продолжительность ее выполнения начинает влиять на продолжительность всего проекта.

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

Требования к ресурсам (люди, инструменты) транслируются в стоимостные ожидания. 

В совокупности, вся эта деятельность является итеративной и должна обсуждаться и проводиться до тех пор, пока не будет достигнут консенсус между менеджментом и инженерами входящими в команду проекта.

 

 

Закрытие (Closure)

Проект завершается (не путать с прекращением проекта), когда все планы и процессы выполнены и завершены.

На этой стадии к результатам проекта применяются критерии оценки его успешности.

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

Планирование процесса измерений (Plan the Measurement Process)

Включает следующие основные моменты.

Задание «организационной единицы»

Таким образом обеспечивается явный контекст измерений и связанные с ним ограничения. В качестве такой «единицы»  (в общем случае) могут выступать организационные процессы, прикладные домены (области деятельности или отдельных     работ) и т.п. Подробное описание характеристик организационной единицы в стандарте ISO 15939-02.

6.2.2. Идентификация информационных потребностей (в отношении результатов измерений)

Такие потребности, обычно, базируются на целях, ограничениях, рисках и проблемах на уровне заданной организационной единицы. 

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

Затем, должно быть выбрано подмножество аспектов, в     отношении которых будут проводиться измерения, и полученные результаты также должны быть документированы, персонал поставлен в известность о них, а заинтересованным лицам необходимо провести оценку аспектов измерений.

 

Выбор метрик (измерений)

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

 

6.2.4. Определение наборов собираемых данных, а также процедур анализа и ведения отчетности

Это включает в себя коллекцию процедур и расписаний, хранение, проверку, анализ, отчетность и конфигурационное управление собираемыми данными. (см. стандарт ISO 15939-02, раздел 5.2.4).

 

6.2.5. Определение критериев оценки информационных продуктов (т.е. результатов измерений)

На критерии оценки влияют технические и бизнес цели, сформулированные прежде для соответствующей организационной единицы. Результаты измерений ассоциированы с создаваемым продуктом (являющемся целью проекта), а также с процессами, обеспечивающими управление и измерения в проекте. (см. стандарт ISO 15939-02, раздел     5.2.5).

 

6.2.6. Оценка, утверждение и предоставление ресурсов для проведения измерений

 

1. План измерений должен быть оценен и утвержден уполномоченными лицами. Это включает:

· процедуры сбора данных, их хранения, анализа и отчетности;

· критерии оценки;

· расписание и распределение ответственности.

 

Критерии обзора и оценки этих артефактов должны быть установлены на уровне организационной единицы или выше. 

Такие критерии должны принимать во внимание существующий опыт, доступность ресурсов и     потенциальный срыв проекта когда предлагается изменение существующих практик. 

 

2. Ресурсы должны быть доступны для реализации запланированных и утвержденных задач по ведению измерений.

Доступность ресурсов может быть распределена по стадиям внедрения изменений в процесс измерений.

Например, когда изменения производятся изначально в «пилотном» режиме, а уже затем, становятся составной частью стандартного     процесса (т.е. используемого в рамках всего проекта, подразделения или организации).

Также, необходимо уделять внимание ресурсам, необходимым для успешного внедрения новых процедур и измерений (метрик) (см. стандарт ISO 15939-02, раздел 5.2.6.2).

 

 6.2.7. Внедрение технологий поддержки измерений

Это включает оценку доступных технологий, выбор наиболее соответствующих (заданному контексту и ограничениям), их приобретение и освоение и, наконец, внедрение в     повседневную практику.

 

Сбор данных

Данные должны собираться, верифицироваться (напомним, что «верификация» - это проверка на соответствие каким либо критериям, подтверждение истинности) и сохраняться для дальнейшего использования (см. стандарт ISO 15939-02, раздел 5.3.2).

Обсуждение результатов

Полученный «информационный продукт» должен быть    документирован и передан пользователям и заинтересованным лицам. (см. стандарт ISO 15939-02, раздел 5.3.4) для обсуждения и последующей оценки.

 

Лекция 6. Управление программной инженерией (Software Engineering Management)

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

Управление программной инженерией может быть определено, как приложение вопросов управления, а именно – планирования, координации, количественной оценки, мониторинга, контроля и отчетности – к инженерной деятельности. Цель - систематическое, упорядоченное, количественно измеряемое обеспечение разработки и сопровождения программных систем (IEEE 610.12-90, Standard Glossary for Software Engineering Terminology).

В то же время, существуют факторы, специфичные для программных продуктов, понижающие эффективность управления, это:

· Со стороны клиентов (потребителей, заказчиков) часто отсутствует понимание сложности, порожденной самой природой программной инженерии, в частности связанной с влиянием изменяющихся требований.

· Зачастую, заказчики сами толком не знают чего хотят.

· В результате, программные системы часто строятся с применением итеративных процессов, вместо последовательного выполнения и закрытия работ.

· Уровень новизны и сложности программных систем весьма высок (и не достаточно применять уже существующие наработки и опыт).

· Применяемые технологии обладают высокой скоростью изменения, обновления и старения.

 

В программной инженерии, управленческая деятельность происходит на трех уровнях:

1. Организационное управление и управление   

инфраструктурой.

2. Управление проектами.

3. Планирование и контроль программ количественной   

оценки.

 Вопросы организационного менеджмента важны с точки зрения влияния на программную инженерию в контексте управления полномочиями сотрудников или корпоративными политиками (например безопасности).

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

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

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

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

  Необходимо уделять особое внимание вопросам коммуникаций между сотрудниками, заказчиками, пользователями. Управление коммуникациями, создание естественных условий для их развития – один из ключевых элементов успеха. 

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

 Наконец, управление портфелями (проектов разработки и работ по сопровождению) позволяет сформировать и развивать общее видение в отношении всех существующих, обновляемых и создаваемых программных активов на уровне ИТ - подразделения и организации, в целом.

Все это, в конечном счете, обеспечивает более эффективное управление ресурсами, а, значит, и возможность интенсивного, а не экстенсивного развития организации.

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

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

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

   В контексте управления программной инженерией особую важность имеют следующие направления.

Управление:

· Интеграцией проекта.

· Содержанием проекта. 

· Сроками проекта. 

· Стоимостью проекта.

· Качеством проекта.

· Человеческими ресурсами проекта.

· Коммуникациями проекта.

· Рисками проекта.

· Поставками проекта.

 

Перейдем к рассмотрению

 

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

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

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

 Все блоки на рисунке пронумерованы для удобства ссылок по ходу изложения.     

Далее, как и всегда, будем вести изложение в соответствие с рис.6.1.

 

Рис.6.1. Управление программной инженерией

 

1. Инициирование и управление содержанием

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

  Если проект признан осуществимым, следующей задачей является специфицирование процедур проверки и изменения требований (см. Лекция 1 «Требования к программному обеспечению» – Software Requirements).

 

1.1. Определение и обсуждение требований (Determination and Negotiation of Requirements)

 

 Первичными работами, необходимыми для определения содержания, целей и ограничений проекта являются выбор и применение методов:

· определения (извлечения) требований;

· анализа их (например, моделирование сценариев);

· специфицирования и проверки (например, прототипирования).

 

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