Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

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

Термин «процесс программной инженерии» (software engineering process) может интерпретироваться по-разному. И это соответственно может приводить к определенной путанице.

* С одной стороны, учитывая специфику оригинального термина в английском языке, где, с точки зрения грамматики, может существовать термин the software engineering process, он будет подразумевать единственно правильный способ выполнения задач (performing tasks) программной инженерии. Такие стандарты, как IEEE/ISO/ГОСТ 12207 говорят о процессах (во множественном числе - processes), подразумевая, что программная инженерия содержит множество процессов, например, процесс разработки (Development Process) и процесс конфигурационного управления (Configuration Management Process).

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

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

В данной работе мы попытаемся дать краткую характеристику процессу программной инженерии.

1. Реализация и изменение процесса программной инженерии

(Process Implementation and Change)

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

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

1.1 Инфраструктура процесса

Эта тема охватывает знания, связанные с инфраструктурой процесса программной инженерии и, в большой степени, базируется на стандартах IEEE/ISO/ГОСТ 12207 «Standard for Information Technology - Software Life Cycle Processes» и ISO 15504 «Information Technology - Software Process Assessment» (известен также как SPICE - Software Process Improvement and Capability Etermination).

Для внедрения процессов жизненного цикла необходимо обладать соответствующей инфраструктурой, подразумевая, что ресурсы (компетентный персонал, инструменты, финансирование) - доступны, а ответственность - распределена <по членам проектной команды и / или организационной единицы, в терминах структуры компании или организации, например, отдела или группы>. Выполнение этих задач является хорошим индикатором того, что менеджмент <управленческий персонал проекта / организации> реально прилагает усилия по поддержке процесса программной инженерии. Как следствие таких усилий могут создаваться различные комитеты и другие специализированные организационные структуры и органы, в общем случае называемые steering committee - «управляющая комиссия», обладающая наблюдательными функциями в отношении усилий, направленных на мониторинг, контроль и выработку рекомендаций по поддержке и улучшению процесса программной инженерии. На основе таких функций будем в дальнейшем использовать термин «наблюдательный орган», подчеркивая реальные задачи такой комиссии и возможность как формальной, так и неформальной его организации.

Наблюдательный орган является основой процессной инфраструктуры в проектной команде, подразделении или организации, в целом. Обычно, выделяют два типа инфраструктуры, применяемые на практике Software Engineering Process Group (SEPG, обычно, в русском языке для такой структуры используется приведенная англоязычная аббревиатура) и Experience Factory (EF, «фабрика опыта»).

1.2 Цикл управления программным процессом

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

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

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

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

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

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

2. Определение процесса

(Process Definition)

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

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

2.1 Модели жизненного цикла программного обеспечения

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

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

Большинство существующих моделей жизненного цикла ПО являются разновидностями трех классических моделей[2]:

· каскадной (ступенчатой или водопадной);

· эволюционной (итеративной или инкрементальной);

· спиральной.

Одной из первых, применяемых на практике моделей была каскадная модель, в которой каждая работа выполняется один раз и в том порядке, как они представлены в выбранной модели ЖЦ.

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

2.2 Процессы жизненного цикла программного обеспечения

Определения процессов жизненного цикла обычно являются более детальными, чем модели. Однако, определения процессов не описывают порядка их выполнения во времени (за это как раз и отвечают модели, прим. автора). Это означает, что, в принципе, процессы жизненного цикла программного обеспечения могут быть «выстроены» (во времени) соответственно любой модели жизненного цикла. Основным источником знаний по процессам является стандарт IEEE/ISO/ГОСТ 12207 «Information Technology - Software Lifecycle Processes» (структура этого стандарта автор рассматривает за рамками перевода и комментариев SWEBOK в самостоятельной главе книги, прим. автора).

По мнению автора, в рамках данных понятий жизненного цикла - «модель» и «процессы», возможно говорить, что совокупность модели, процессов и практик определяет метод / методологию <поддержки жизненного цикла>.

Стандарт IEEE 1074 «Standard for Developing Software Life Cycle Processes» предоставляет список процессов и действий по разработке и сопровождению программного обеспечения, а также список действий по поддержке самого жизненного цикла, который может быть отображен на процессы и организован таким же образом, как и любая модель жизненного цикла. Кроме того, этот стандарт идентифицирует и связывает другие стандарты IEEE с действиями по поддержке процессов жизненного цикла. В принципе, стандарт IEEE 1074 может быть использован для построения процессов, соответствующих любой модели жизненного цикла.

SWEBOK отмечает два стандарта, связанных с процессами сопровождения программного обеспечения - IEEE 1219 «Standard for Software Maintenance» и ISO 14764 «Standard for Software Engineering - Software Maintenance» (см. область знаний SWEBOK «Сопровождение программного обеспечения»).

Другие важные стандарты, предоставляющие определение процессов, включают:

* IEEE 1540: Standard for Software Risk Management - управление рисками программного обеспечения

* IEEE 1517: Standard for Software Reuse Processes - процессы повторного использования программного обеспечения

* ISO/IEC 15939: Standard for Software Measurement Process - процесс измерений в области программного обеспечения

В ряде ситуаций процессы программной инженерии определяться принимая во внимание организационные процессы управления качеством. ISO 9001 формулирует требования к процессам управления качеством, а ISO 9003 интерпретирует эти требования в отношении организаций, занимающихся разработкой программного обеспечения (ISO/IEC 90003:2004, Software and Systems Engineering - Guidelines for the Application of ISO9001:2000 to Computer Software).

Некоторые процессы жизненного цикла придают особое значение быстрому вводу в эксплуатацию (rapid delivery) программных систем и глубокой вовлеченности пользователей <в процесс разработки>. Такие процессы называют agile-методами - быстрыми, живыми, подвижными. К ним относится, например, экстремальное программирование - eXtreme Programming (XP, см. работы Кента Бека - Kent Beck). Отличительной особенностью этих методов является гибкость в вопросах планирования, когда план проекта активно корректируется по мере продвижения к цели проекта.

Другие процессы уделяют специальное внимание принятию решений на основе оценки рисков (см. работы Барри Боэма - Barry W. Boehm).

2.3 Адаптация процесса

Важно отметить, что предопределенные процессы, даже стандартизированные, должны адаптироваться в соответствии с локальными (конкретными) потребностями, например, организационным контекстом, размером проекта, регулирующих требованиях, индустриальных практиках и корпоративной культурой. Ряд стандартов, в первую очередь, IEEE/ISO/ГОСТ 12207 и ISO 15504, содержат механизмы и рекомендации по процессу адаптации и его совершенствованию.

2.4 Автоматизация

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

Существуют и инструменты, которые поддерживают большую часть упомянутых выше нотаций по определению процессов (например, Borland Together и IBM/Rational, прим. автора). Так или иначе, по мнению автора, высокая динамика развития современных инструментов обеспечивает широкий спектр средств, позволяющих с их использованием добиться четкого, понятного и однозначно интерпретируемого описания любых бизнес-процессов и, в частности, процессов программной инженерии.

3. Оценка процесса

Оценка процесса (process assessment) проводится с использованием соответствующих моделей оценки (assessment models) и методов оценки (assessment methods). Во многих случаях вместо термина «assessment» используется термин «appraisal» (подразумевая саму процедуру оценки, например, CMMI Appraisal, прим. автора). В свою очередь, термин «appraisal» заменяют на «capability evaluation», когда говорят об оценке способностей / потенциальных возможностей, например, с целью заключения контракта / договора подряда на проведение соответствующих работ.

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

3.1 Модели оценки процесса

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

Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и требования соответствия к другим моделям. В каждом конкретном случае используется та или иная существующая модель - CMM-SW, CMMI, Bootstrap*. Также имеются и другие модели, например, ISO 9000-3 (теперь именуемый как ISO 90003) «Software and Systems Engineering - Guidelines for the Application of ISO9001:2000 to Computer Software», являющаяся приложением общей модели качества ISO 9001 «Quality Management Systems - Requirements» к программной инженерии. Кроме того, существуют частные модели, охватывающие, например, только вопросы документирования, проектирования и т.п.

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

SWEBOK отмечает, что ряд моделей применим к небольшим организациям. Автор рекомендует обратить внимание на результаты пилотного приложения CMMI к малым организациям - CMMI in Small Settings Toolkit, опубликованном на сайте SEI CMU в 2004 году (http://www.sei.cmu.edu/cmmi/adoption/toolkit-elements.html).

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

3.2 Методы оценки процесса

Для надлежащего проведения оценки соответствующие методы <оценки> позволяют получить количественные параметры, характеризующие возможности оцениваемого процесса (или зрелости организации, в целом) Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement) фокусируется на совершенствовании процесса внутри организации, а метод SCE (Software Capability Evaluation) касается процессов у подрядчиков*. Требования в обоих типах методов отражают те лучшие практики оценки, которые описаны в стандарте ISO 15504. Эти методы были разработаны для модели CMM-SW. С выходом CMMI (интегрированной модели, объединяющей различные модели CMM), соответственно, получило развитие новое семейство методов - SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Деятельность, выполняемая в процессе оценки, распределение усилий по соответствующим работам и общая атмосфера оценки (касающаяся, в первую очередь, степени формализации, сопутствующей оценке, прим. автора) могут серьезно отличаться, в зависимости от того, направлена ли оценка на совершенствование процессов или проводится в контексте контракта / договора подряда.

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

Заключение

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

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

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

Литература

1. Введение в програмную инженерию и управление жизненным циклом програмного обеспечения = Guide to Software Engineering Base of Knowledge (SWEBOK): пер. с англ. С. Орлик [Электронный ресурс]. - Режим доступа: http://sorlik.blogspot.com/

2. Ехлаков Ю.П. Введение в программную иженерию: учебное пособие/ Ю.П. Ехлаков. - Томск: Эль Контент, 2011. -148 с.

3. Мытник С.А. Проектирование информационных систем: учебное пособие / С.А. Мытник. - Томск: Томск.гос. университет систем управления и радиоэлектроники, 2008. - 100 с.

4. Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных. «СУБД», 1999.

5. Силич В.А. Моделирование и анализ бизнес-процессов: учебное пособие / В.А. Силич, М.П. Силич. - Томск: Томск.гос. университет систем управления и радиоэлектроники, 2010. - 212 с.

6. ГОСТ 28806-90. Качество программных средств. Термины и определения [Электронный ресурс]. - Режим доступа: http://vsegost.com/Catalog/10/10605.shtml

Размещено на Allbest.ru