Зачем явно определять процессы?
Поможем в ✍️ написании учебной работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

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

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

2.4.2.2 Нотации определения процессов

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

Инженеры должны иметь представление о следующих подходах:

1) диаграммах потоков данных (data flow diagrams);

2) нотации BPMN (Business Process Management Notation);

3) диаграмм деятельности UML (activity diagram),

4) в терминах целей процессов и получаемых на их выходе результатов (outcomes) (см. стандарт ISO 15504 “Information Technology - Software Process Assessment” - “SPICE”);

5) как наборе процессов и их декомпозиции в работы и задачи, определенный на естественном языке (см. стандарт IEEE/ISO/ГОСТ 12207);

6) диаграммах переходов и состояний (statechart);

7) SADT, IDEF0 и многих других.

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

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

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

 

2.4.2.4 Примеры определения процесса

 

2.4.3 Оценка процесса

В 1990 году стартовала европейская инициатива European Strategic Program for Information Technology (ESPRIT), целью которой было внедрение современных программных технологий в Европе. В основу инициативы легли работы Уотса Хампфри (Watts S. Humphrey) – идеолога CMMI, PSP (People Software Process) и многих других современных концепций программной инженерии как дисциплины. Результат этот инициативы был назван “Bootstrap” – “самонастройка”. В то время, как модель CMM – Capability Maturity Model (в частности, CMM-SW – CMM for Software), а потом и CMMI, разрабатывались с учетом потребностей крупных государственных структур США (в первую очередь, министерства обороны) и их подрядчиков, модель Bootstrap изначально была ориентирована на малые и средние коммерческие компании, с определенным акцентом на индивидуальные практики.
Оценка процесса (process assessment) проводится с использованием соответствующих моделей оценки (assessment models) и методов оценки (assessment methods).

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

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

Стандарт 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” к программной инженерии. Кроме того, существуют частные модели, охватывающие, например, только вопросы документирования, проектирования и т.п.

В конце данной лекции (если успеем) проведем небольшой обзор модели зрелости процессов программной инженерии (CMM-SW – Capability Maturity Model for Software).

2.4.4 Измерение процессов и продуктов

 

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

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

Ключевые понятия, термины и методы измерений в приложении к программному обеспечению определены в стандарте ISO 15939 “Software Engineering - Software Measurement Process”. Данный стандарт также определяет стандартный процесс для измерения характеристик процессов и продуктов.

Дата: 2019-02-19, просмотров: 210.