Модель потока работ показывает последовательность действий, выполняемых людьми на различных этапах разработки ПО. Для каждого действия указываются входы, выходы (результаты) и связи по входам и выходам.
Модель потоков данных представляет процесс в виде последовательного преобразования данных. Каждое преобразование может выполняться одним или несколькими действиями.
Ролевая модель показывает роли заинтересованных лиц, участвующих в процессе, а также действия и результаты, за которые они отвечают.
2.2 Основные модели жизненного цикла
// сократить
Существует множество моделей процессов жизненного цикла систем и программных средств, но три из них в международных стандартах обычно квалифицируются как фундаментальные:
1) каскадная;
2) итеративная или инкрементная;
3) эволюционная (или спиральная).
Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла конкретного проекта (Липаев, 2006). Следует отметить, что различия между этими моделями существуют только в теории. На практике спиральная модель может быть дополнена элементами каскадной и компонентной. Задача программного инженера -подобрать правильную их комбинацию, ориентируясь только на конечный результат.
2.2.1 Каскадная (водопадная) модель
Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе (рисунок 2.1).
Рисунок 2.1 – Каскадная модель жизненного цикла
На рисунке изображены типичные фазы каскадной модели жизненного цикла и соответствующие активы проекта, являющиеся для одних фаз выходами, а для других – входами.
Будучи (некогда) активно используема, эта модель продемонстрировала свою “проблемность” в подавляющем большинстве ИТ-проектов, за исключением, может быть, отдельных проектов обновления программных систем для критически-важных программно-аппаратных комплексов (например, авионики или медицинского оборудования). Практика показывает, что в реальном мире, особенно в мире бизнес-систем, каскадная модель не должна применяться. Специфика таких систем (если можно говорить о “специфике” для подавляющего большинства создаваемых систем) – требования характеризуются высокой динамикой корректировки и уточнения, невозможностью четкого и однозначного определения требований до начала работ по реализации (особенно, для новых систем) и быстрой изменчивостью в процессе эксплуатации системы.
| Фредерик Брукс во втором издании своего классического труда “Мифический человеко-месяц” так описывает главную беду каскадной модели [Брукс, 1995, с.245]: “Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы.” |
Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой модели, можно привести достаточно… Достаточно для отказа от каскадной модели жизненного цикла.
2.2.2 Итеративная и инкрементальная модель – эволюционный подход
Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально.
С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental). Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта).
Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и еѐ развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. Чистая инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации как полную версию системы.
Итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Однако, разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада.
Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему:
- можно очень рано начать тестирование пользователями;
- можно принять стратегию разработки в соответствии с бюджетом, полностью защищающую от перерасхода времени или средств (в частности, за счет сокращения второстепенной функциональности).
Таким образом, Значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. В свою очередь, снижение неопределенности позволяет уменьшить риски.
Рисунок 2.2 иллюстрирует некоторые идеи эволюционного подхода.
Рисунок 2.2 – Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла.
Наиболее известным и распространенным вариантом эволюционной модели является спиральная модель.
2.2.3 Спиральная модель
| Риск – это неопределённое событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие на проект, приводящее к потерям или приобретениям времени или финансов. |
Рисунок 2.3 – Спиральная модель c контрольными точками проекта
Спиральная модель обладает рядом преимуществ:
Модель уделяет специальное внимание раннему анализу возможностей повторного использования.
Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта.
Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Это достигается явно определенными работами по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки.
Модель, ориентированная на риски, позволяет в контексте конкретного проекта решить задачу приложения адекватного уровня усилий, определяемого уровнем рисков, связанных с недостаточным выполнением тех или иных работ.
Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего. Этот аспект позволяет избежать часто встречающегося отношения к поддержке и сопровождению как ко “второсортной” деятельности.
Модель позволяет решать интегрированный задачи системной разработки, охватывающей и программную и аппаратную составляющие создаваемого продукта.
Подход, основанный на управлении рисками и возможности своевременного отбрасывания непривлекательных альтернатив (на ранних стадиях проекта) сокращает расходы и одинаково применим и к аппаратной части, и к программному обеспечению.
2.3 Структура процессов жизненного цикла
2.3.1 Классификация процессов ЖЦ по ГОСТ Р 12207-2010
Стандарт ГОСТ Р ИСО/МЭК 12207-2010 описывает множество процессов (групп процессов), разбитых по 7 категориям (рисунок 2.4, раздаточный материал лекции).
Рисунок 2.4 – Процессы ЖЦ ПС по ГОСТ Р ИСО/МЭК 12207-2010
Примечание: разумеется, в нашем курсе мы не сможем затронуть все указанные процессы – ограничимся только ключевыми процессами (без которых не обходится ни один цикл разработки программных систем). Им будут посвящены почти все оставшиеся лекции (3-10).
Рассмотрим далее отдельные категории процессов, описываемые стандартом 12207 (2010).
2.3.2 Процессы соглашения
Процессы соглашения определяют действия, необходимые для выработки соглашений между двумя организациями. Если реализуется процесс приобретения, то он обеспечивает средства для проведения деловой деятельности с поставщиком продуктов, предоставляемых для применения в функционирующей системе, услугах поддержки этой системы или элементах системы, разработанных в рамках проекта. Если реализуется процесс поставки, то он обеспечивает средства для проведения проекта, в котором результатом является продукт или услуга, поставляемые приобретающей стороне.
Примечания:
Цель процесса приобретения состоит в получении продукта и (или) услуги в соответствии с потребностями приобретающей стороны. Процесс начинается с выяснения потребностей заказчика и заканчивается приемкой продукта и (или) услуги, необходимых приобретающей стороне.
Цель процесса поставки заключается в обеспечении приобретающей стороны продукцией или услугой, удовлетворяющей согласованным требованиям.
2.3.3 Процессы организационного обеспечения проекта
Процессы организационного обеспечения проекта осуществляют управление приобретением и поставкой продукта или услуги через инициализацию, поддержку и управление проектами. Эти процессы обеспечивают ресурсы и инфраструктуру, необходимые для поддержки проектов, и гарантируют удовлетворение организационных целей и установленных соглашений. Однако, они не претендуют на роль полной совокупности процессов, реализующих управление деловой деятельностью организации.
Процессы организационного обеспечения проекта включают в себя:
1) процесс управления моделью жизненного цикла;
2) процесс управления инфраструктурой;
3) процесс управления портфелем проектов;
4) процесс управления людскими ресурсами;
5) процесс управления качеством.
В общем случае процессы организационного обеспечения проекта, предусмотренные стандартом 12207 (2010), являются процессами, ориентированными на программные средства.
Примечания:
Цель процесса управления моделью жизненного цикла заключается в определении, сопровождении и обеспечении гарантии наличия политик, процессов жизненного цикла, моделей жизненного цикла и процедур для использования организацией. Данный процесс предусматривает политики, процессы и процедуры жизненного цикла, согласованные с целями организации, которые определяются, адаптируются, совершенствуются и сопровождаются для поддержки отдельных потребностей проекта в пределах задач и функций организации и которые готовы к применению с использованием эффективных испытанных методов и инструментария.
Цель процесса управления инфраструктурой заключается в снабжении проекта обеспечивающей инфраструктурой и услугами для поддержки организации и целей проекта в течение всего жизненного цикла. Данный процесс определяет, предоставляет и обслуживает средства, инструментарий, активы коммуникационных и информационных технологий, необходимые для деловой деятельности организации.
Цель процесса управления портфелем проектов заключается в инициации и поддержке необходимых, достаточных и подходящих проектов для выполнения стратегических целей организации. Данный процесс совершает инвестирование адекватных фондов и ресурсов организации, а также санкционирует полномочия, необходимые для осуществления выбранных проектов. Он выполняет постоянную квалификацию проектов с целью подтверждения их обоснованности или может быть переориентирован на обоснование продолжения инвестирования.
Целью управления людскими ресурсами является обеспечение организации необходимыми людскими ресурсами и поддержание их компетентности согласно потребностям деловой деятельности. Процесс гарантирует обеспечение поддержки персонала, обладающего навыками, опытом и квалификацией для выполнения процессов жизненного цикла, направленных на достижение целей организации, проекта и заказчика.
Целью процесса управления качеством является гарантия того, что продукты, услуги и реализации процессов жизненного цикла соответствуют целям организации в области качества и удовлетворяют заказчика.
2.3.4 Процессы проекта
Процессы проекта составляют основу планирования, оценки и управления проектом. Принципы, связанные с этими процессами, могут применяться в любой области управления организацией. (2010).
Существуют две группы процессов проекта:
1) процессы управления проекта;
2) процессы поддержки проекта.
Процессы управления проектом применяются для создания и развития планов проекта, оценки фактического выполнения и продвижения относительно плановых заданий и управления выполнением проекта вплоть до полного его завершения. Отдельные процессы управления проектом могут привлекаться в любое время жизненного цикла и на любом уровне иерархии проекта в соответствии с планами проекта или возникновением непредвиденных событий. Процессы управления проектом применяются на уровне строгости и формализации, зависящих от риска и сложности проекта. Процессы управления проектом включают в себя:
1) процесс планирования проекта;
2) процесс управления и оценки проекта.
Процессы поддержки проекта формируют специфическую совокупность задач, ориентированных на выполнение специальных целей управления. Все эти процессы очевидны при осуществлении управления любой инициируемой деятельностью, располагаясь по нисходящей от организации в целом вплоть до отдельного процесса жизненного цикла и его задач. Процессы поддержки проекта включают в себя:
1) процесс управления принятием решений;
2) процесс управления рисками;
3) процесс управления конфигурацией (будет рассмотрен подробно в лекции 8);
4) процесс управления информацией;
5) процесс измерений.
Примечания:
Цель процесса планирования проекта состоит в составлении и доведении до заинтересованных сторон эффективного и выполнимого плана. Данный процесс определяет область применения управления проектом и технических мероприятий, результаты процесса, проектные задачи и поставки, устанавливает графики для выполнения задач проекта, включая критерии достижения и ресурсы, необходимые для выполнения задач проекта.
Цель оценки проекта и процесса управления заключается в определении состояния проекта и гарантии того, что проект выполняется в соответствии с планами и графиками работ в пределах бюджета и удовлетворяет техническим параметрам. При необходимости этот процесс включает в себя переориентацию деятельности в рамках проекта, корректировку выявленных отклонений и изменений, связанных с управлением другими проектами или с техническими процессами. Соответственно переориентация может включать в себя перепланирование.
Цель процесса управления принятием решений заключается в выборе из существующих альтернатив наиболее предпочтительного направления проектных действий. Данный процесс является реакцией на возникающие в течение жизненного цикла системы запросы на принятие решений, направленных на достижение заданных, желаемых или оптимальных результатов вне зависимости от происхождения или источника таких запросов. Альтернативные действия анализируются, выбирается и указывается направление действий. Решения и их обоснования документируются для поддержки принятия будущих решений.
Цель процесса управления рисками заключается в постоянном определении, анализе, обработке и мониторинге рисков. Процесс управления рисками является непрерывным процессом для систематичной адресации риска по всему жизненному циклу системного или программного продукта или услуги. Это может быть применимо к рискам, связанным с приобретением, разработкой, сопровождением или применением по назначению системы.
Цель процесса управления конфигурацией состоит в установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны.
Цель процесса управления информацией состоит в своевременном предоставлении заинтересованным сторонам релевантной, своевременной, полной, достоверной и, если требуется, конфиденциальной информации в течение и соответственно после завершения жизненного цикла системы. В рамках данного процесса реализуется создание, сбор, преобразование, хранение, поиск, распространение и использование информации. Процесс управляет информацией, включая техническую, проектную, организационную, пользовательскую информацию, а также информацию, содержащуюся в соглашениях.
Цель процесса измерений заключается в сборе, анализе и составлении отчетов о данных, относящихся к разработанным продуктам и процессам, реализованным в пределах определенного организационного подразделения, для поддержки эффективного менеджмента процессов и объективной демонстрации качества этих продуктов.
2.3.5 Технические процессы
Технические процессы используются для определения требований к системе, преобразования требований в полезный продукт, для тиражирования продукта (где это необходимо), применения продукта, обеспечения требуемых услуг, поддержания обеспечения этих услуг и изъятия продукта из обращения, и т.д.
Технические процессы определяют деятельность, которая дает возможность реализовывать организационные и проектные функции для оптимизации пользы и снижения рисков. Эта деятельность обеспечивает возможность продуктам и услугам обладать такими свойствами, как своевременность и доступность, результативность затрат, а также функциональность, безотказность, ремонтопригодность, продуктивность, приспособленность к применению, и другими качественными характеристиками, требуемыми приобретающими и поддерживающими организациями. Она также предоставляет возможность продуктам и услугам соответствовать ожиданиям или требованиям гражданского законодательства, включая факторы здоровья, безопасности, защищенности и факторы, относящиеся к окружающей среде.
Технические процессы состоят из следующих процессов:
1) определение требований пользователей;
2) анализ системных требований;
3) проектирование архитектуры системы;
4) процесс реализации;
5) процесс комплексирования системы;
6) процесс квалификационного тестирования системы;
7) процесс инсталляции программных средств;
8) процесс поддержки приемки программных средств;
9) процесс функционирования программных средств;
10) процесс сопровождения программных средств;
11) процесс изъятия из обращения программных средств.
Большинство технических процессов схожи с процессами реализации программных средств, но сохраняют важные различия, например, анализ системных требований и анализ требований к программным средствам начинаются с разных исходных позиций и имеют разные предназначения.
Примечания:
Цель процесса определения требований пользователей состоит в выявлении требований к системе, выполнение которых может обеспечивать предоставление услуг, необходимых пользователям в заданной среде применения.
Цель анализа системных требований состоит в преобразовании определенных требований пользователей в совокупность необходимых системных технических требований, которыми будут руководствоваться в проекте системы.
Цель процесса проектирования архитектуры системы заключается в определении того, как системные требования следует распределить относительно элементов системы.
Цель процесса реализации заключается в создании заданных элементов системы.
Цель процесса интеграции системы заключается в объединении системных элементов (включая составные части технических и программных средств, ручные операции и другие системы, при необходимости) для производства полной системы, которая будет удовлетворять системному проекту и ожиданиям заказчика, выраженным в системных требованиях.
Цель процесса квалификационного тестирования системы заключается в подтверждении того, что реализация каждого системного требования тестируется на соответствие и система готова к поставке.
Цель процесса инсталляции программных средств заключается в установке программного продукта, удовлетворяющего заданным требованиям, в целевую среду применения.
Цель процесса поддержки приемки программных средств заключается в содействии приобретающей стороне в обеспечении уверенности в том, что продукт соответствует заданным требованиям.
Цель процесса функционирования программных средств заключается в применении программного продукта в предназначенной для него среде и обеспечении поддержки заказчиков программного продукта.
Цель процесса сопровождения программных средств заключается в обеспечении эффективной по затратам поддержки поставляемого программного продукта.
Цель процесса прекращения применения программных средств состоит в обеспечении завершения существования системного программного объекта.
2.3.6 Процессы реализации программных средств
Процессы реализации программных средств используются для создания конкретного элемента системы (составной части), выполненного в виде программного средства. Эти процессы преобразуют заданные характеристики поведения, интерфейсы и ограничения на реализацию в действия, результатом которых становится системный элемент, удовлетворяющий требованиям, вытекающим из системных требований.
Специальным процессом является процесс реализации программных средств, выражающий специфически программную особенность процесса реализации категории технические процессы.
Цель процесса реализации программных средств заключается в создании заданных элементов системы, выполненных в виде программных продуктов или услуг. В ходе этого процесса происходит преобразование заданных поведенческих, интерфейсных и производственных ограничений в действия, которые создают системный элемент, выполненный в виде программного продукта или услуги.
Результатом процесса реализации программных средств является создание программной составной части, удовлетворяющей как требованиям к архитектурным решениям, что подтверждается посредством верификации, так и требованиям пользователей, что подтверждается посредством валидации.
Процесс реализации программных средств включает в себя несколько специальных процессов более низкого уровня:
1) процесс анализа требований к программным средствам;
2) процесс проектирования архитектуры программных средств;
3) процесс детального проектирования программных средств;
4) процесс конструирования программных средств;
5) процесс комплексирования (интеграции) программных средств;
6) процесс квалификационного тестирования программных средств.
Примечания:
Цель процесса анализа требований к программным средствам заключается в установлении требований к программным элементам системы.
Цель процесса проектирования архитектуры программных средств заключается в обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно требований.
Цель процесса детального проектирования программных средств заключается в обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно установленных требований и архитектуры программных средств, а также существенным образом детализируются для последующего кодирования и тестирования.
Цель процесса конструирования программных средств заключается в создании исполняемых программных блоков, которые должным образом отражают проектирование программных средств.
Цель процесса интеграции программных средств заключается в объединении программных блоков и программных компонентов, создании интегрированных программных элементов, согласованных с результатами проектирования программных средств, которые демонстрируют, что функциональные и нефункциональные требования к программным средствам удовлетворяются на полностью укомплектованной или эквивалентной ей операционной платформе.
Цель процесса квалификационного тестирования программных средств заключается в подтверждении того, что комплектованный программный продукт удовлетворяет установленным требованиям.
2.3.7 Процессы поддержки программных средств
Процессы поддержки программных средств предусматривают специально сфокусированную совокупность действий, направленных на выполнение специализированного программного процесса. Любой поддерживающий процесс помогает процессу реализации программных средств как единое целое с обособленной целью, внося вклад в успех и качество программного проекта.
Существует восемь таких процессов:
1) процесс управления документацией программных средств;
2) процесс управления конфигурацией программных средств;
3) процесс обеспечения гарантии качества программных средств;
4)
| Верификация подтверждает, что «вы создали продукт так, как и намеревались это сделать», а Валидация подтверждает, что «вы создали правильный продукт» |
5) процесс валидации программных средств;
6) процесс ревизии программных средств;
7) процесс аудита программных средств;
8) процесс решения проблем в программных средствах.
Примечания:
Цель процесса управления документацией программных средств заключается в разработке и сопровождении зарегистрированной информации по программным средствам, созданной некоторым процессом.
Цель процесса управления конфигурацией программных средств заключается в установлении и сопровождении целостности программных составных частей процесса или проекта и обеспечении их доступности для заинтересованных сторон.
Цель процесса обеспечения гарантии качества программных средств заключается в предоставлении гарантии соответствия рабочей продукции и процессов предварительно определенным условиям и планам.
Цель процесса верификации программных средств заключается в подтверждении того, что каждые программный рабочий продукт и (или) услуга процесса ил и проекта должным образом отражают заданные требования.
Цель процесса валидации программных средств заключается в подтверждении того, что требования выполняются для конкретного применения рабочего программного продукта.
| Чем отличается ревизия от аудита? |
Цель процесса аудита программных средств заключается в независимом определении соответствия выбранных продуктов и процессов требованиям, планам и соглашениям.
Цель процесса решения проблем в программных средствах заключается в обеспечении гарантии того, что все выявленные проблемы идентифицируются, анализируются, контролируются и подвергаются управлению для осуществления их решения.
2.3.8 Процессы повторного применения программных средств
Группа процессов повторного применения программных средств состоит из трех процессов, которые поддерживают возможности организации использовать повторно составные части программных средств за границами проекта. Эти процессы уникальны, поскольку, в соответствии с их природой, они используются вне границ какого-либо конкретного проекта.
Процессами повторного применения программных средств являются:
1) процесс проектирования доменов;
2) процесс менеджмента повторного применения активов;
3) процесс менеджмента повторного применения программ.
Примечания:
Цель процесса проектирования доменов (как я понимаю) заключается в разработке и сопровождении моделей понятий предметной области, архитектуры программных средств и других активов, которые могут быть использованы в рамках определенной предметной области.
Цель процесса управления повторным применением активов заключается в управлении жизненным циклом повторно применяемых активов от концепции до отмены применения.
Цель процесса управления повторным применением программ заключается в планировании, создании, руководстве, управлении и мониторинге повторного применения программ в организации при систематическом использовании возможностей повторного применения.
2.4 Управление процессами ЖЦ
В данном подразделе будет рассмотрена концепция управления процессами, предлагаемая SWEBOK.
Цель управления процессами программной инженерии состоит в реализации новых и лучших процессов в реальной практике конкретных специалистов, проектов или организации (отдельных ее групп подразделений или организации, в целом). SWEBOK определяет 4 основные области знаний, связанные с управлением процессами:
1) реализация и изменение процесса;
2) определение процесса;
3) оценка процесса;
4) измерения процессов и продуктов.
2.4.1 Реализация и изменение процесса
Реализация и изменение процесса фокусируется на организационных изменениях. Данные области знаний описывают инфраструктуру, действия, модели и практические соображения по реализации процесса и его изменении.
Инфраструктура процесса
Для внедрения процессов жизненного цикла необходимо обладать соответствующей инфраструктурой, подразумевая, что ресурсы (компетентный персонал, инструменты, финансирование) – доступны, а ответственность – распределена <по членам проектной команды и/или организационной единицы, в терминах структуры компании или организации, например, отдела или группы>. Выполнение этих задач является хорошим индикатором того, что менеджмент <управленческий персонал проекта/организации> реально прилагает усилия по поддержке процесса программной инженерии. Как следствие таких усилий могут создаваться различные комитеты и другие специализированные организационные структуры и органы, в общем случае называемые steering committee – “управляющий комитет”, обладающий наблюдательными функциями в отношении усилий, направленных на мониторинг, контроль и выработку рекомендаций по поддержке и улучшению процесса программной инженерии. На основе таких функций будем в дальнейшем использовать термин “наблюдательный орган”, подчеркивая реальные задачи такой комиссии и возможность как формальной, так и неформальной его организации.
Наблюдательный орган является основой процессной инфраструктуры в проектной команде, подразделении или организации, в целом. Обычно, выделяют два типа инфраструктуры, применяемые на практике Software Engineering Process Group (SEPG, обычно, в русском языке для такой структуры используется приведенная англоязычная аббревиатура) и Experience Factory (EF, “фабрика опыта”).
SEPG создается как центральный орган, принимающий на себя работу по совершенствованию процессов. SEPG берет на себя ответственность по множеству вопросов, связанных с этой задачей в терминах инициирования улучшений, поддержки существующего процесса и его постоянного совершенствования.
Часто SEPG формируется из нескольких ведущих членов проектной команды (если, SEPG создается в рамках проекта) или на уровне подразделения или всей организации. При этом, в большинстве случаев, SEPG не включает “освобожденных” специалистов и, таким образом, ее члены всегда находятся в контексте реальных проблем, с которыми сталкиваются выполняя свои “основные” обязанности. Исключение, обычно, составляют SEPG, формируемые для достижения определенных организационных целей - приведения процессов в соответствие тем или иным требованиям и, в частности, для достижения того или иного уровня зрелости процессов (рассмотрим далее, что это такое), обеспечения качества в рамках национального стандарта и т.п. В этих случаях SEPG обычно возглавляется выделенным экспертом (или группой) в области постановки и совершенствования процессов.
Концепция фабрики опыта отделяет проектную организацию (например, организационную структуру, отвечающую за разработку программного обеспечения – ИТ-подразделение, группу разработки или проектную команду) от организации, отвечающей за улучшение процесса. Проектная организация, в этом случае, фокусируется на разработке и сопровождении программного обеспечения, а EF – занята совершенствованием процесса программной инженерии.
Основной задачей фабрики опыта является институализация (внедрение в повседневную практику) коллективного опыта и полученных уроков в масштабах организации на основе разработки, обновления и внедрения в проектную организацию “пакетов опыта” (например, руководств, моделей, курсов обучения и т.п.), типовых активов процесса. Проектная организация предлагает на рассмотрение фабрике опыта свои продукты, планы, использовавшиеся при разработке, а также данные, собранные в процессе разработки и эксплуатации.
Управление процессами в области программного обеспечения состоит из четырех действий, представленных в рамках итеративного цикла. Это позволяет получать и анализировать отклики на постоянной основе и, <более оперативно> совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK
Дата: 2019-02-19, просмотров: 413.
