8-software_engineering_process (1133548), страница 2

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

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

На основе такихфункций будем в дальнейшем использовать термин “наблюдательный орган”, подчеркиваяреальные задачи такой комиссии и возможность как формальной, так и неформальной егоорганизации.Наблюдательный орган является основой процессной инфраструктуры в проектной команде,подразделении или организации, в целом. Обычно, выделяют два типа инфраструктуры,применяемые на практике Software Engineering Process Group (SEPG, обычно, в русском языке длятакой структуры используется приведенная англоязычная аббревиатура) и Experience Factory (EF,“фабрика опыта”).1.1.1 Software Engineering Process Group (SEPG)SEPG создается как центральный орган, принимающий на себя работу по process improvement совершенствованию процесса(-ов).

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

В этих случаях SEPG обычно возглавляетсявыделенным экспертом (или группой) в области постановки и совершенствования процессов.1.1.2 Experience Factory (EF)Концепция “фабрики опыта” отделяет проектную организацию (например, организационнуюструктуру, отвечающую за разработку программного обеспечения – ИТ-подразделение, группуразработки или проектную команду) от организации, отвечающей за улучшение процесса.Проектная организация, в этом случае, фокусируется на разработке и сопровождениипрограммного обеспечения, а EF – занята совершенствованием процесса программнойинженерии.Основной задачей EF является институализация (внедрение в повседневную практику)коллективного опыта и полученных уроков в масштабах организации на основе разработки,обновления и внедрения в проектную организацию “пакетов опыта” – experience packagesCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru4Основы программной инженерии (по SWEBOK)Программная инженерия.

Процесс программной инженерии.(например, руководств, моделей, курсов обучения и т.п.), <типовых> “активов процесса” – processassets. Проектная организация предлагает на рассмотрение EF свои продукты, планы,использовавшиеся при разработке, а также данные, собранные в процессе разработки иэксплуатации.Cложно провести четкую грань между SEPG и EF. Скорее, можно говорить о создании SEPG вформе “фабрики опыта” в крупных ИТ-подразделениях, например, международных компаний, илидостаточно крупных организациях, основной деятельностью которых является созданиепрограммного обеспечения.

В этом случае SEPG проводит пилотное внедрениеусовершенствованных или новых процессов в рамках одного или нескольких выбранных проектови, затем, распространяет этот опыт во всей организации. Так или иначе, отдача от SEPG/EFобычно заметна в проектно-ориентированных или проектных организациях, чья деятельностьпостроена в форме управления портфелем проектов (более подробную информацию о проектноориентированных организациях можно, например, найти в PMI PMBOK и других материалах ProjectManagement 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/95102.pdf) и разработанная в Институте программной инженерии Университета Карнеги-Меллон SEICMU модель IDEAL (Initiating – Diagnosing – Establishing – Acting – Learning).

Во всех случаяхоценка может проводиться по качественным и/или количественным показателям.На сегодняшний день наиболее проработанными и распространенными стандартами оценки исовершенствования процесса программной инженерии являются CMMI (де факто стандарт) иSCAMPI (разработанная в SEI CMU стандартная методика оценки совершенствования процессов –Standard CMMI Appraisal Method for Process Improvement), а также в ISO/IEC 15504 (де юроCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru5Основы программной инженерии (по SWEBOK)Программная инженерия. Процесс программной инженерии.стандарт), также известном как SPICE (Software Process Improvement and Capability Determination) иразработанным для аттестации зрелости процессов.1.4 Практические соображения (Practical Considerations)Реализация и изменение процесса является составной частью организационных изменений.

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

Также, можно найти множество отчетов и исследований пофакторам успеха, значимым для внедрения и изменения процесса (например, многие из такихисследований связаны с моделью CMMI и представлены на сайте SEI CMU http://sei.cmu.edu/).SWEBOK также отмечает роль “агентов” изменений, как лиц, часто создающих предпосылки,инициирующих изменения, а также специалистов, постоянно реализующих изменения в своейпрактике. Естественно, что реализация и изменение процесса может рассматриваться какконсалтинг. Он может быть внутренний (например, проводимый силами специалистов SEPG) иливнешний (с привлечением экспертов из других подразделений и организаций, частоспециализирующихся в данной области так же, как мы видим консультантов и внешнихуправляющих в области проектного менеджмента).

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

При этом, эти технологии могуткасаться как непосредственно самого программного обеспечения, так и связаны с самимпроцессом (например, технологии моделирования).Существует два распространенных подхода к оценке реализации и изменения процесса. Онисостоят в оценке самого процесса и в оценке результатов процесса (process outcomes),соответственно.2.

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

Важными факторами при определении процессаявляются природа работ (например, разработка или сопровождение), прикладная область(application domain), модель жизненного цикла и зрелость самой организации.2.1 Модели жизненного цикла программного обеспечения (Software Life Cycle Models)Модели жизненного цикла задают высокоуровневое определение фаз (стадий) разработкипрограммного обеспечения. Их целью не является предоставление детального определения, ноконцентрируется на ключевых работах и их взаимосвязях.

Примерами таких моделей* являютсяводопадная (каскадная - waterfall), модель прототипирования, эволюционной разработки,Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru6Основы программной инженерии (по SWEBOK)Программная инженерия. Процесс программной инженерии.инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения и критериивыбора моделей, ссылки на некоторые из которых, в частности, даны в оригинальной версииSWEBOK.* базовые модели жизненного цикла рассматриваются далее в отдельной главе.2.2 Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes)Определения процессов жизненного цикла обычно являются более детальными, чем модели.Однако, определения процессов не описывают порядка их выполнения во времени (за это как рази отвечают модели, прим.

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

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