ТСПП - Практическое задание 1. Основы Swebok

требованиям – проверено и подтверждено/утверждено заказчиком, а цели проекта – достигнуты. Перечисленные процессы, в общем случае, требуют вовлечения всех заинтересованных лиц. Результаты их выполнения документируются, включая подтверждения со стороны заказчика о соответствии результатов проекта заданным требованиям (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 Measurement Commitment)

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

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

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

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

* организационная единица - 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).

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

* в данной теме в отношении результатов измерений часто используется термин ―информационный продукт‖ – information product.

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

oПлан измерений должен быть оценен и утвержден соответствующими заинтересованными лицами. Это включает процедуры сбора данных, их хранения, анализа и отчетности; критерии оценки; расписание и распределение ответственности. Критерии обзора и оценки этих артефактов должны быть установлены на уровне организационной единицы или выше. Такие критерии должны принимать во внимание существующий опыт, доступность ресурсов и потенциальный срыв проекта когда предлагается изменение существующих практик. Утверждение (approval) <выделения ресурсов> демонстрирует поддержку и принятие обязательств по проведению измерений. (см. стандарт ISO 15939-02, раздел 5.2.6.1 и приложение F).

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

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).

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

Анализ данных и создание информационного продукта (как результата измерений, позволяющего принимать на его основе те или иные решения). Данные могут агрегироваться, трансформироваться или записываться как часть процесса анализа в соответствии с природой данных и информационными потребностями. Обычно результаты анализа представляются в форме соответствующих графиков, численных характеристик или других индикаторов, интерпретируемых и передаваемых, в конце концов, заинтересованным лицам. Результаты и сделанные на их основе заключения должны быть оценены (reviewed) в соответствии с процессом, определенным в организации (который может быть формальным или неформальным). Лица, предоставляющие данные и проводящие измерения, должны участвовать в процессе обзора и оценки (review) данных для обеспечения соответствия их содержательной стороны и точности, а также выполнения действий, обоснованных результатами последующего анализа. (см. стандарт ISO 15939-02, раздел 5.3.3 и приложение G).

Обсуждение результатов. Полученный ―информационный продукт‖ должен быть документирован и передан пользователям и заинтересованным лицам. (см.

стандарт ISO 15939-02, раздел 5.3.4).

6.4Оценка измерений (Evaluate Measurement)

Оценка информационного продукта. Такая оценка проводится на соответствие специфицированным критериям оценки и определяет сильные и слабые стороны (strengths and weaknesses*) полученного информационного продукта. Оценка может

проводиться в рамках внутренних процессов или внешнего аудита и должна включать анализ отзывов от лиц, использующих полученные результаты. Сделанные выводы (в англоязычных источниках по оценке и совершенствованию процессов повсеместно используется термин ―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).

Определение потенциальных возможностей улучшения/усовершенствований (improvements) <процесса проведения измерений>. Такие рекомендации по улучшению могут заключаться в изменении формата используемых количественных индикаторов, единиц измерения или изменений в их классификации (категориях метрик). Необходимо определять стоимости и отдачу (benefits) от предлагаемых улучшений и отобрать те из них, которые соответствуют целям и критериям измерений, после чего сформулировать действия, необходимые для внедрения выбранных улучшений. Предполагаемые улучшения должны быть обсуждены и утверждены заинтересованными лицами. Отсутствие потенциальных улучшений (если они не были идентифицированы в результате проведенного анализа) также должно быть обсуждено с заинтересованными лицами.

8.Процесс программной инженерии

(Software Engineering Process по SWEBOK)

Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK.

Содержит перевод описания области знаний SWEBOK ―Software Engineering Process‖, с замечаниями и комментариями.

Процесс программной инженерии (Software Engineering Process)

1. Реализация и изменение процесса (Process Implementation and Change)

1.1 Инфраструктура процесса (Process Infrastructure)

1.2 Цикл управления программным процессом (Software Process Management Cycle) 1.3 Модели реализации и изменения процесса (Models for Process Implementation and

Change)

1.4 Практические соображения (Practical Considerations)

2. Определение процесса (Process Definition)

2.1 Модели жизненного цикла программного обеспечения (Software Life Cycle Models)

2.2 Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes) 2.3 Нотации определения процесса (Notations for Process Definitions)

2.4 Адаптация процесса (Process Adaptation)

2.5 Автоматизация (Automation)

3. Оценка процесса (Process Assessment)

3.1 Модели оценки процесса (Process Assessment Models) 3.2 Методы оценки процесса (Process Assessment Methods)

4. Измерения в отношении процессов и продуктов (Process and Product Measurement)

4.1 Измерения в отношении процессов (Process Measurement)

4.2 Измерения в отношении программных продуктов (Software Product Measurement) 4.3 Качество результатов измерений (Quality Of Measurement Results)

4.4 Информационные модели (Software Information Models)

4.5 Техники количественной оценки процессов (Process Measurement Techniques)

Область знаний ―Процесс программной инженерии‖ (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 создается как центральный орган, принимающий на себя работу по processimprovement - совершенствованию процесса(-ов). SEPG берет на себя ответственность по множеству вопросов, связанных с этой задачей в терминах инициирования <улучшений> и поддержки <существующего процесса и его постоянного совершенствования>.

Часто SEPG формируется из нескольких ведущих членов проектной команды (если, SEPG создается в рамках проекта) или на уровне подразделения или всей организации. При этом, в большинстве случаев, SEPG не включает ―освобожденных‖ специалистов и, таким образом, ее члены всегда находятся в контексте реальных проблем, с которыми сталкиваются выполняя свои ―основные‖ обязанности. Исключение, обычно, составляют SEPG, формируемые для достижения определенных организационных целей - приведения процессов в соответствие тем или иным требованиям и, в частности, для достижения того или иного уровня зрелости CMMI, обеспечения качества в рамках ISO или SixSigma и т.п. В этих случаях SEPG обычно возглавляется выделенным экспертом (или группой) в области постановки и совершенствования процессов.

1.1.2 Experience Factory (EF)

Концепция ―фабрики опыта‖ отделяет проектную организацию (например, организационную структуру, отвечающую за разработку программного обеспечения – ИТподразделение, группу разработки или проектную команду) от организации, отвечающей за улучшение процесса. Проектная организация, в этом случае, фокусируется на разработке и сопровождении программного обеспечения, а EF – занята совершенствованием процесса программной инженерии.

Основной задачей EF является институализация (внедрение в повседневную практику) коллективного опыта и полученных уроков в масштабах организации на основе разработки, обновления и внедрения в проектную организацию ―пакетов опыта‖ – experience packages (например, руководств, моделей, курсов обучения и т.п.), <типовых> ―активов процесса‖ – process assets. Проектная организация предлагает на рассмотрение EF свои продукты, планы, использовавшиеся при разработке, а также данные, собранные в процессе разработки и эксплуатации.

Cложно провести четкую грань между SEPG и EF. Скорее, можно говорить о создании SEPG в форме ―фабрики опыта‖ в крупных ИТ-подразделениях, например, международных компаний, или достаточно крупных организациях, основной деятельностью которых является создание программного обеспечения. В этом случае SEPG проводит пилотное внедрение усовершенствованных или новых процессов в рамках одного или нескольких выбранных проектов и, затем, распространяет этот опыт во всей организации. Так или иначе, отдача от SEPG/EF обычно заметна в проектно-

ориентированных или проектных организациях, чья деятельность построена в форме управления портфелем проектов (более подробную информацию о проектноориентированных организациях можно, например, найти в PMI PMBOK и других материалах Project Management Institute). В общем случае, говоря об инфраструктуре процессов, обычно используют именно термин SEPG для обоих типов организации команд, фокусирующихся на процессе разработки программных систем.

1.2 Цикл управления программным процессом (Software Process Management Cycle)

Управление процессами в области программного обеспечения состоит из четырех действий, представленных в рамках итеративного цикла. Это позволяет получать и анализировать отклики на постоянной основе и, <более оперативно> совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK:

Establish Process Infrastructure – создание инфраструктуры процесса. Задачи – обеспечить согласие и поддержку заинтересованных лиц (в первую очередь, менеджмента) в работах по реализации и изменении процесса; получить

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

Planning – планирование. Задача (цель) – понять (сформулировать) текущие бизнесцели и потребности в процессе, необходимые отдельным специалистам, проекту и/или организации, в целом; идентифицировать сильные и слабые стороны (см. концепцию SWOT-анализа в различных источниках) <существующего процесса и планируемых на данной итерации нововведений и/или изменений> и разработать план реализации и изменения процесса.

Process Implementation and Change – реализация и изменение процесса. Задача

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

Process Evaluation – оценка процесса. Задача (цель) – понять, насколько хорошо процесс реализован, получены или нет ожидаемые преимущества от его внедрения. Результат анализа становится ―входом‖ для следующей итерации.

1.3Модели реализации и изменения процесса (Models for Process Implementation and Change)

Существует две распространенные модели внедрения процесса – Quality Improvement Paradigm – QIP (Software Engineering Laboratory, Software Process Improvement Guidebook, NASA/GSFC, Technical Report SEL-95-102, April 1996, http://sel.gsfc.nasa.gov/website/documents/online-doc/95-102.pdf) и разработанная в Институте программной инженерии Университета Карнеги-Меллон SEI CMU модель

IDEAL (Initiating – Diagnosing – Establishing – Acting – Learning). Во всех случаях оценка может проводиться по качественным и/или количественным показателям.

На сегодняшний день наиболее проработанными и распространенными стандартами оценки и совершенствования процесса программной инженерии являются CMMI (де факто стандарт) и SCAMPI (разработанная в SEI CMU стандартная методика оценки совершенствования процессов – Standard CMMI Appraisal Method for Process Improvement), а также в ISO/IEC 15504 (де юро стандарт), также известном как SPICE (Software Process Improvement and Capability Determination) и разработанным для аттестации зрелости процессов.

1.4 Практические соображения (Practical Considerations)

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

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