производятся необходимые результаты (deliverables; активы, артефакты проекта - например, архитектурные документы, тестовые сценарии).
• [9] в SWEBOK используется как “план проекта” в единственном числе, так и “планы” - во множественном числе, подразумевающие, судя по контексту, отдельные задачи проекта.
3.2 Управление контрактами с поставщиками (Supplier Contract Management)
Включает подготовку и выполнение соглашений с поставщиками, мониторинг деятельности поставщиков, принятие у поставщиков продуктов, использование и интеграцию этих продуктов в рамках проектных работ.
3.3 Реализация процесса по ведению измерений (Implementation of Measurement Process)
Данный процесс выполняется на протяжении всего проекта, обеспечивая сбор всех необходимых данных (см. 6.2 Plan the Measurement Process и 6.3 Perform the Measurement Process).
3.4 Процесс мониторинга (Monitor Process)
Соблюдение плана проверяется постоянно и через предопределенные интервалы времени. Анализируются выходы (outputs) и условия завершения <задач>. Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых характеристик (например, через процедуры обзора/оценки и аудита - review, audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному моменту, используемые ресурсы - все это исследуется к каждой дате оценки. При этом, оценивается и корректируется профиль рисков, а также, производится проверка удовлетворения требований качества.
Моделируются и анализируются данные измерений. Анализ расхождений (variance analysis) <плана с реальным выполнением проекта> базируется на оценке отклонений реальных данных от планируемых и ожидаемых. Такой анализ может проводиться в отношении оценки перерасхода средств (cost overrun), нарушения расписания и других важных характеристик - ограничений проекта Часто выполняется “внешний” (например, с привлечением представителей заказчика) анализ качества и других измеряемых данных (например, анализ плотности дефектов - defect density analysis). Проводится повторное (уточняющее) выявление рисков и оценка их последствий (risk exposure and leverage), разрабатывается дерево решений, проводится моделирование (рисков и действий по их предотвращению) и другие работы - уже в контексте полученных данных. Все эти работы позволяют обнаруживать проблемы и идентифицировать исключения, основываясь на выходе за рамки приемлемых границ тех или иных параметров проекта (в частности, характеристик качества). Отчетность по результатам создается в соответствие с планом, а также, при выходе за заданные ограничения проекта или параметров отдельных его работ.
тестирования определенных компонент) и могут приводить к изменению плана, работ, документов и других активов проекта. При этом, важно контролировать (идентифицировать, оценивать и принимать решения) прямые и косвенные влияния любых изменений.
В некоторых случаях, это может приводит к прекращению проекта. Во всех случаях необходимо проводить контроль изменений и процедур конфигурационного управления (см. предыдущую область знаний 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)
Проект закрывается/завершается (не путайте с прекращением проекта), когда все планы и процессы выполнены и завершены. На этой стадии в результатам проекта применяются критерии оценки его успешности. Когда принимается решение о закрытии проекта, выполняются действия по
архивированию проектных данных, анализу результатов, полученных в процессе работы над проектом (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)[10], необходимые для реализации процесса ведения измерений, а также включающий информационную модель измерений.
• * “действия/работы” - activities, “задачи”- tasks: термин “задача” используется для более глубокого уровня детализации, чем “действия/работы”; термины “действия” и “работы”, как вы уже заметили, часто используются взаимозаменяемым образом. Так или иначе, это вопрос договоренности о терминологии при организации WBS (Work Breakdown Structure) - структуры декомпозиции работ.
6.1 Установление и поддержка процесса ведения измерений (Establish and Sustain Measurement Commitment)
что факторы, способствующие достижению цели также должны быть оценены количественно, с тем, чтобы проект могу быть управляем в процессе достижения заданного результата. Для этого необходимо:
-Определить содержание измерений. Необходимость принять, в каких масштабах - на уровне какой организационной единицы[11] будут проводиться измерения - только в одной функциональной области, в рамках проекта, на уровне комплекса проектов или в организации, в целом. Все последующие задачи по ведению измерений, связанные с соответствующими требованиями, ведутся в рамках принятого содержания измерений. Безусловно, в дополнение к этому необходимо идентифицировать всех заинтересованных лиц, ассоциированных и вовлеченных в проведение измерений.
-Заручиться поддержкой менеджеров и персонала в ведении измерений. Такая поддержка должна быть оформлена формально, сообщена персоналу и поддержана соответствующими ресурсами (см. ниже).
*организационная единица - organizational unit: этот термин хоть и не очень удачен в SWEBOK, но будет использоваться достаточно часто в контексте ведения измерений для описания границ измерений. При этом часто подразумевается не фиксированная структурная единица в организации, а некая “единица деятельности”, в отношении которой проводятся измерения - операция, задача, работа, проект, программа, деятельность организации, в целом.
• Выделяются соответствующие ресурсы для проведения измерений. Организационная поддержка измерений является основным фактором успеха, так как назначение ресурсов просто необходимо для реализации процесса ведения измерений. Назначение ресурсов включает распределение ответственности (например, пользователь, аналитик и т.п.) в отношении различных задач процесса измерения и предоставление необходимого финансирования, обучения, инструментов и поддержки процесса сопровождения на постоянной основе.
6.2 Планирование процесса измерений (Plan the Measurement Process)
• Задание “организационной единицы” (в частности, в понимании “единицы деятельности”, как описывалось выше). Таким образом обеспечивается явный контекст измерений и связанные с ним ограничения. В качестве такой “единицы” (в общем случае) могут выступать организационные процессы, прикладные домены (области деятельности или отдельных работ) и т.п. См. подробное описание характеристик организационной единицы в уже упомянутом стандарте ISO 15939-02 (ISO/IEC 15939:2002 Software Engineering - Software Measurement Process, раздел 5.2.1).
• Идентификация информационных потребностей <в отношении результатов измерений>. Такие потребности, обычно, базируются на целях, ограничениях, рисках и проблемах на уровне заданной организационной единицы. В основе указанных аспектов лежат различные цели - организационные, проектные и т.п. Все эти аспекты (как и порождающие их цели) должны быть четко идентифицированы и для них должны быть определены соответствующие приоритеты. Затем, должно быть выбрано подмножество аспектов, в отношении которых будут проводиться измерения, и полученные результаты также должны быть документированы, персонал поставлен в известность о них, а заинтересованным лицам необходимо провести требуемую оценку аспектов измерений (см. стандарт ISO 15939-02, раздел 5.2.2).
• Выбор метрик (измерений). Кандидаты в метрики должны быть выбраны на основе приоритетов информационных потребностей и других критериев - таких, как стоимость сбора данных, возможность срыва процессных работ при сборе данных (например, в силу недостатка ресурсов), легкость анализа, легкость получения точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и приложение C).
анализ, отчетность и конфигурационное управление собираемыми данными. (см. стандарт ISO 15939-02, раздел 5.2.4).
• Определение критериев оценки информационных продуктов (т.е. результатов измерений). На критерии оценки влияют технические и бизнес цели, сформулированные прежде для соответствующей организационной единицы. Результаты измерений[12] ассоциированы с создаваемым продуктом <являющемся целью проекта>, а также с процессами, обеспечивающими управление и измерения в проекте. (см. стандарт ISO 15939-02, раздел
5.2.5 и приложения D, E).
* в данной теме в отношении результатов измерений часто используется термин “информационный продукт” - information product.
• Оценка, утверждение и предоставление ресурсов для проведения измерений.
- План измерений должен быть оценен и утвержден соответствующими заинтересованными лицами. Это включает процедуры сбора данных, их хранения, анализа и отчетности; критерии оценки; расписание и распределение ответственности. Критерии обзора и оценки этих артефактов должны быть установлены на уровне организационной единицы или выше. Такие критерии должны принимать во внимание существующий опыт, доступность ресурсов и потенциальный срыв проекта когда предлагается изменение существующих практик. Утверждение (approval) <выделения ресурсов> демонстрирует поддержку и принятие обязательств по проведению измерений. (см. стандарт ISO 15939-02, раздел 5.2.6.1 и приложение F).
- Ресурсы должны быть доступны для реализации запланированных и утвержденных задач по ведению измерений. Доступность ресурсов может быть распределена по стадиям внедрения изменений в процесс измерений, например, когда изменения производятся изначально в “пилотном” режиме, а уже затем, становятся составной частью стандартного процесса (т.е. используемого в рамках всего проекта, подразделения или организации). Также, необходимо уделять внимание ресурсам, необходимым для успешного внедрения новых процедур и измерений (метрик). (см. стандарт ISO 15939-02, раздел 5.2.6.2).
• Овладевание и внедрение технологий поддержки <измерений>. Это включает оценку доступных технологий, выбор наиболее соответствующих (заданному контексту и ограничениям) технологий, их приобретение и овладевание ими и, наконец, внедрение в повседневную практику. (см. стандарт ISO 15939-02, раздел 5.2.7).
6.3 Выполнение процесса измерений (Perform the Measurement Process)
• Интеграция процедур проведения измерений с соответствующими процессами. Процедуры измерения (например, сбор данных) должны быть интегрированы в оцениваемые процессы. Это может приводить к изменению самих процессов для адаптации действий по сбору или генерации необходимых данных. Это может подразумевать и анализ существующих процессов для минимизации дополнительных усилий, и оценку влияния на сотрудников, необходимые для реального принятия процедур проведения измерений. Важно понимать и принимать во внимание моральные и другие аспекты “человеческого фактора”, без которых проведение измерений, как дополнительная (к функциональной) деятельность будет восприниматься лишь как помеха основной работе. Более того, процедуры измерений должны обсуждаться с теми, кто непосредственно предоставляет данные; может потребоваться соответствующее обучение персонала; необходимо обеспечить и соответствующую поддержку (по аналогии с технической поддержкой программного обеспечения). Анализ данных и процедуры отчетности должны быть интегрированы в организационные и/или проектные процессы. (см. стандарт ISO 15939-02, раздел 5.3.1).
• Анализ данных и создание информационного продукта (как результата измерений, позволяющего принимать на его основе те или иные решения). Данные могут агрегироваться, трансформироваться или записываться как часть процесса анализа в соответствии с природой данных и информационными потребностями. Обычно результаты анализа представляются в форме соответствующих графиков, численных характеристик или других индикаторов, интерпретируемых и передаваемых, в конце концов, заинтересованным лицам. Результаты и сделанные на их основе заключения должны быть оценены (reviewed) в соответствии с процессом, определенным в организации (который может быть формальным или неформальным). Лица, предоставляющие данные и проводящие измерения, должны участвовать в процессе обзора и оценки (review) данных для обеспечения соответствия их содержательной стороны и точности, а также выполнения действий, обоснованных результатами последующего анализа. (см. стандарт ISO 15939-02, раздел 5.3.3 и приложение G).
• Обсуждение результатов. Полученный “информационный продукт” должен быть документирован и передан пользователям и заинтересованным лицам. (см. стандарт ISO 15939-02, раздел 5.3.4).
6.4 Оценка измерений (Evaluate Measurement)
• Оценка информационного продукта. Такая оценка проводится на соответствие специфицированным критериям оценки и определяет сильные и слабые стороны (strengths and weaknesses[13]) полученного информационного продукта. Оценка может проводиться в рамках внутренних процессов или внешнего аудита и должна включать анализ отзывов от лиц, использующих полученные результаты. Сделанные выводы (в англоязычных источниках по оценке и совершенствованию процессов повсеместно используется термин “lessons learned” - “полученные уроки”) должны быть записаны в соответствующую базу данных (иногда называемую также “базой знаний” - “knowledgebase”). (см. стандарт ISO 15939-02, раздел 5.4.1 и приложение D).
* strengths and weaknesses - два из четырех элементов SWOT-анализа. SWOT - Strengths, Weaknesses, Opportunities, Threats - сильные стороны, слабые стороны, возможности, угрозы. Обычно представляется как квадрант четырех указанных факторов.
• Оценка процесса проведения измерений. Данная оценка проводится на соответствие специфицированным критериям оценки и определяет сильные и слабые стороны самого процесса. Оценка может проводиться в рамках внутренних процессов или внешнего аудита и должна включать анализ отзывов от лиц, использующих полученные результаты. Сделанные выводы должны быть записаны в соответствующую базу данных. (см. стандарт ISO 15939-02, раздел 5.4.1 и приложение D).
Лекция 9. Программная инженерия
Процесс программной инженерии (Software Engineering Process)
Лекция базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK®, 2004. Содержит перевод описания области знаний SWEBOK® “Software Engineering Process”, с комментариями и замечаниями.
"Основы программной инженерии" разработаны на базе IEEE Guide to SWEBOK® 2004 в соответствии с IEEE SWEBOK 2004 Oopyright and Reprint Permissions: "This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy."
Программная инженерия
Процесс программной инженерии (Software Engineering Process)
3. Оценка процесса (Process Assessment)............................................................................. 8
3.1 Модели оценки процесса (Process Assessment Models)..................................................... 8
3.2 Методы оценки процесса (Process Assessment Methods)................................................... 9
4. Измерения в отношении процессов и продуктов (Process and Product Measurement)..... 10
4.1 Измерения в отношении процессов (Process Measurement)............................................. 10
4.2[14] Измерения в отношении программных продуктов (Software Product Measurement)...... 11
4.3 Качество результатов измерений (Quality Of Measurement Results)................................. 12
4.4 Информационные модели (Software Information Models)................................................. 13
4.5 Техники количественной оценки процессов (Process Measurement Techniques)............... 13
Область знаний “Процесс программной инженерии” (Software Engineering Process) может быть рассмотрена на двух уровнях. Первый уровень содержит техническую и управленческую деятельность на протяжении процессов жизненного цикла программного обеспечения, включающих приобретение, разработку, сопровождение и вывод из эксплуатации программных систем. Второй уровень - “мета-уровень”, связанный с определением, реализацией, оценкой, измерением, управлением, изменением и совершенствованием самих процессов жизненного цикла программного обеспечения. Первый уровень освещен в других областях знаний SWEBOK. Второй уровень рассматривается в данной области знаний.
Термин “процесс программной инженерии” (software engineering process) может интерпретироваться по-разному и это, соответственно, может приводить к определенной путанице.
• С одной стороны, учитывая специфику оригинального термина в английском языке, где (с точки зрения грамматики) может существовать термин the software engineering process, он будет подразумевать единственно правильный способ выполнения задач (performing tasks) программной инженерии. Такое предположение заведомо отбрасывается SWEBOK, так как “единственно правильного” процесса быть не может. Такие стандарты, как IEEE/ISO/ГОСТ 12207 говорят о процессах (во множественном числе - processes), подразумевая что программная инженерия содержит множество процессов, например, процесс разработки (Development Process) и процесс конфигурационного управления (Configuration Management Process).
• Вторая интерпретация связана с общим (general) обсуждением процессов, связанных с программной инженерией. Данная точка зрения отражена в названии этой области знаний и является одной из наиболее часто подразумеваемых при использовании термина “процесс программной инженерии”.
уровне организации. Такой подход также рассматривается в данной области знаний (та или иная интерпретация обычно зависит от контекста обсуждения).
Данная область знаний связана со всеми элементами управления процессами жизненного цикла программного обеспечения, в которых процедурные (управленческие) или технологические изменения применяются к совершенствованию процесса или продукта.
Процесс программной инженерии касается не только крупных организаций. Более того, связанные с данным процессом действия могут и должны применяться небольшими организациями, командами и отдельными специалистами.
Цель управления процессами программной инженерии состоит в реализации новых и лучших процессов в реальной практике конкретных специалистов, проектов или организации (отдельных ее групп подразделений или организации, в целом).
Данная область знаний не адресуется напрямую вопросам управления персоналом (human resources management, HRM). Эти темы исследуются, например, в People CMM (People Capabililty Maturity Model) и процессах системной инженерии (см. стандарты ISO 15288 “Systems Engineering
- System Life Cycle Process” и IEEE 1220 “Standard for the Application and Management of the Systems Engineering Process”).
Также, необходимо понимать, что многие процессы программной инженерии порождаются и тесно связаны с другими дисциплинами, например, управлением (management), хотя иногда эти процессы и называют по-другому в контексте этих дисциплин.
Рисунок 1. Область знаний “Процесс программной инженерии” [SWEBOK, 2004, с.9-2, рис. 1] 1. Реализация и изменение процесса (Process Implementation and Change)
Данная секция фокусируется на организационных изменениях. Она описывает инфраструктуру, действия, модели и практические соображения по реализации процесса и его изменении.
Ниже рассматривается ситуация, в которой те или иные процессы реализуются впервые (например, процесс проведения инспекций в проекте или охват полного жизненного цикла программного обеспечения) и где изменяются уже существующие (используемые) процессы. Речь пойдет о том, что называют эволюцией процесса (process evolution). Существующие практики
рассматриваются в контексте часто необходимой модификации. Если требуемые модификации достаточно обширны, это приводит и к необходимости изменения организационной культуры.
1.1 Инфраструктура процесса (Process Infrastructure)
Эта тема охватывает знания, связанные с инфраструктурой процесса программной инженерии и, в большой степени, базируется на стандартах IEEE/ISO/ГОСТ 12207 “Standard for Information Technology - Software Life Cycle Processes” и ISO 15504 “Information Technology - Software Process Assessment” (известен также как SPICE - Software Process Improvement and Capability dEtermination).
Для внедрения процессов жизненного цикла необходимо обладать соответствующей инфраструктурой, подразумевая, что ресурсы (компетентный персонал, инструменты, финансирование) - доступны, а ответственность - распределена <по членам проектной команды и/или организационной единицы, в терминах структуры компании или организации, например, отдела или группы>. Выполнение этих задач является хорошим индикатором того, что менеджмент <управленческий персонал проекта/организации> реально прилагает усилия по поддержке процесса программной инженерии. Как следствие таких усилий могут создаваться различные комитеты и другие специализированные организационные структуры и органы, в общем случае называемые steering committee - “управляющий комитет”, обладающий наблюдательными функциями в отношении усилий, направленных на мониторинг, контроль и выработку рекомендаций по поддержке и улучшению процесса программной инженерии. На основе таких функций будем в дальнейшем использовать термин “наблюдательный орган’’, подчеркивая реальные задачи такой комиссии и возможность как формальной, так и неформальной его организации.
Наблюдательный орган является основой процессной инфраструктуры в проектной команде, подразделении или организации, в целом. Обычно, выделяют два типа инфраструктуры, применяемые на практике Software Engineering Process Group (SEPG, обычно, в русском языке для такой структуры используется приведенная англоязычная аббревиатура) и Experience Factory (EF, “фабрика опыта”).
1.1.1 Software Engineering Process Group (SEPG)
SEPG создается как центральный орган, принимающий на себя работу по process improvement - совершенствованию процесса(-ов). SEPG берет на себя ответственность по множеству вопросов, связанных с этой задачей в терминах инициирования <улучшений> и поддержки существующего процесса и его постоянного совершенствованиям
Рисунок 1. Область знаний “Процесс программной инженерии” [SWEBOK, 2004, с.9-2, рис. 1] 1. Реализация и изменение процесса (Process Implementation and Change)