Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Нотации определения процесса (Notations for Process Definitions) Процессы могут определяться на различных уровнях абстракции. В свою очередь, могут быть определены и различные элементы процессов – действия, продукты (артефакты) и ресурсы. При этом, могут использоваться детальные фреймворки, структурирующие типы информации, требуемой для определения процессов. Существует ряд нотаций, используемых для определения процессов. Ключевое отличие между ними заключается в типах информации, которая определяется, контролируется и используется тем или иным фреймворком. Инженеры должны иметь представление о следующих подходах: диаграммах потоков данных (data flow diagrams), в терминах целей процессов и получаемых на их выходе результатов (outcomes) (см. стандарт ISO 15504 “Information Technology - Software Process Assessment” - “SPICE”), как наборе процессов и их декомпозиции в работы и задачи, определенный на естественном языке (см. стандарт IEEE/ISO/ГОСТ 12207), диаграммах переходов и состояний (statechart), SADT, IDEF0 и многих других. Хотя SWEBOK приводит расширенный список диаграмм/нотаций, вероятно, в силу своей “консервативности”, не упоминает, например, activity- диаграммы UML, хотя они могут использоваться в практике для описания бизнес-процессов, в частности, и для описания процессов программной инженерии. Ряд нотаций разработан и используется в рамках конкретных (частных) фреймворков/методологий, например, RUP. Кроме того, существует успешный опыт по использованию достаточно нотации BPMN – Business Process Management Notation для описания процессов программной инженерии. Спецификация BPMN определяет графическое представление бизнес- процессов в форме диаграмм бизнес-процессов – Business Process Diagram (BPD). Первый стандарт BPMN был выпущен 3 мая 2004 года консорциумом The Business Process Management Initiative – BPMI.org (http://www.bpmi.org). Предоставляя развитые выразительные средства для определения процессов как комплекса взаимосвязанных действий, событий и артефактов, сгруппированных по участникам, BPMN позволяет достаточно легко сформировать в рамках одной диаграммы BPD цельный взгляд на процессы. Адаптация процесса (Process Adaptation) Важно отметить, что предопределенные процессы, даже стандартизированные, должны адаптироваться в соответствии с локальными (конкретными) потребностями, например, организационным контекстом, размером проекта, регулирующих требованиях, индустриальных практиках и корпоративной культурой. Ряд стандартов, в первую очередь, IEEE/ISO/ГОСТ 12207 и ISO 15504, содержат механизмы и рекомендации по процессу адаптации и его совершенствованию. Автоматизация (Automation) Автоматизированные средства либо поддерживают сами работы по определению процессов (например, позволяя описывать процессы с использованием тех или иных диаграмм и нотаций) и/или предоставляют соответствующие руководства по определению процессов (например, RUP, EUP или MSF). В случаях, когда проводится процесс анализа, некоторые инструменты обеспечивают различные формы симуляции моделируемых (определяемых) процессов. Оценка процесса (Process Assessment) Оценка процесса (process assessment) проводится с использованием соответствующих моделей оценки (assessment models) и методов оценки (assessment methods). Во многих случаях вместо термина “assessment” используется термин “appraisal” (подразумевая саму процедуру оценки, например, CMMI Appraisal). В свою очередь, термин “appraisal” заменяют на “capability evaluation”, когда говорят об оценке способностей/потенциальных возможностей, например, с целью заключения контракта/договора подряда на проведение соответствующих работ. Оценка процесса(-ов) может проводиться как неформально, подразумевая часто внутрикорпоративные инициативы по повышению качества, и формально (то есть с получением аттестационного документа), в том числе, с привлечением внешних специалистов по оценке и, часто, с целью подтверждения соответствующего качества/уровня зрелости процессов. Модели оценки процесса (Process Assessment Models) Модель оценки задает, что именно признается лучшими практиками оценки. Эти практики могут касаться только “технических” работ программной инженерии (например, проектирования или кодирования), а могут иметь отношение и к вопросам управления, системной инженерии, управления персоналом и т.п. Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и требования соответствия к другим моделям. В каждом конкретном случае используется та или иная существующая модель – CMM-SW, CMMI, Bootstrap 2 . Также имеются и другие модели, например, 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” к программной инженерии. Кроме того, существуют частные модели, охватывающие, например, только вопросы документирования, проектирования и т.п. * В 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 изначально была ориентирована на малые и средние коммерческие компании, с определенным акцентом на индивидуальные практики. Также и в системной инженерии существуют модели зрелости, применимые в отношении программного обеспечения, когда программы являются частью системы. SWEBOK отмечает, что ряд моделей применим к небольшим организациям. Существуют две основных архитектуры моделей оценки: непрерывная (continuous) и этапная (staged). Отличия между ними заключаются во взгляде на порядок оценки процессов. Выбор соответствующей архитектуры и модели оценки в конкретной организации должен базироваться на ее целях и потребностях (например, необходимости совершенствования тех или иных процессных областей или официального подтверждения внешним асессором достижения организацией четвертого уровня зрелости всего процесса программной инженерии по CMMI). Методы оценки процесса (Process Assessment Methods) Для надлежащего проведения оценки соответствующие методы <оценки> позволяют получить количественные параметры, характеризующие возможности оцениваемого процесса (или зрелости организации, в целом). Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement) фокусируется на совершенствовании процесса внутри организации, а метод SCE (Software Capability Evaluation) касается процессов у подрядчиков 3 . Требования в обоих типах методов отражают те лучшие практики оценки, которые описаны в стандарте ISO 15504. Эти методы были разработаны для модели CMM-SW. С выходом CMMI (интегрированной модели, объединяющей различные модели CMM), соответственно, получило развитие новое семейство методов - SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Деятельность, выполняемая в процессе оценки, распределение усилий по соответствующим работам и общая атмосфера оценки (касающаяся, в первую очередь, степени формализации, сопутствующей оценке) могут серьезно отличаться, в зависимости от того, направлена ли оценка на совершенствование процессов или проводится в контексте контракта/ договора подряда. SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment – внутренняя деятельность в организации, направленная на оценку и совершенствование собственного процесса в рамках всей организации. Evaluation подразумевает аудит и мониторинг процессов поставщика (подрядчика, исполнителя) со стороны заказчика, в первую очередь, в процессе самого выполнения работ, т.е. уже после заключения контракта/договора подряда. CBA-IPI относится к общей категории методов Software Process Assessment (SPA) как части работ по совершенствованию процессов – Software Process Improvements (SPI). SPI как деятельность по совершенствованию процесса(-ов) сегодня считается достаточно общим термином, используемым за рамками CMM/CMMI, например, в контексте таких фреймворков, как ISO 15504 или TQM (Total Quality Management). Существует определенная критика моделей, методов (да и самой идеи) оценки. Такая критика, обычно, основана на эмпирической природе оценки. Однако, по прошествии определенного периода времени, после публикации таких критических материалов, опыт и практика индустрии сформировали достаточно четкие доказательства (в том числе, собрав необходимые статистические данные – см. отчеты SEI CMU по результатам внедрения и использования CMMI) обоснованности современных принципов, моделей и методов оценки. Измерения в отношении процессов и продуктов (Process and Product Measurement) В силу того, что приложение количественных оценок к программной инженерии может быть достаточно сложным, в частности, в терминах моделирования или методов анализа, существует ряд фундаментальных аспектов измерений в программной инженерии, лежащих в основе многих более детальных измерений и процессов анализа. Более того, результаты усилий по совершенствованию процессов и продуктов, могут быть оценены только в том случае, если установлены количественные характеристики заданных параметров <процессов и продуктов> для заданных вех или, более точно (так как измерения, все же, выходят за рамки вех конкретных проектов, если, конечно, сама SPI- деятельность не позиционировать как проект, что, конечно, возможно), так называемых “базовых линий” (baseline 4 ). термин baseline обычно используется в контексте управления изменениями, требованиями и, часто, конфигурациями, в целом, для именования временных “срезов” всего комплекса соответствующих активов. Измерения могут проводиться для поддержки инициирования реализации и изменения процессов и для оценки результатов таких работ. Также, измерения могут выполняться и в отношении самих продуктов. Ключевые понятия, термины и методы измерений в приложении к программному обеспечению определены в стандарте ISO 15939 “Software Engineering - Software Measurement Process” и международном словаре метрологии ISO. ISO 15939 также определяет стандартный процесс для измерения характеристик процессов и продуктов. Необходимо отметить, что в литературе встречаются некоторые терминологические отличия, например, термин “метрика” (metric) часто используется вместо термина “измерение” (measure) 5 ** В данном переводе эти термины используются взаимозаменяемым образом, за исключением случаев, когда контекст обсуждения предполагает разделение процесса измерения – “измерения”, как такового, и критериев/параметров или результатов измерения – “метрик”. Измерения в отношении процессов (Process Measurement) Используемый здесь термин “process measurement” – “измерения в отношении процесса” подразумевает сбор, анализ и интерпретацию количественной информации о процессе. Измерения используются для идентификации сильных и слабых сторон процесса (strenghts and weaknessess) и для оценки процесса после того, как он реализован и/или изменен. Также, проведение количественной оценки процесса может преследовать и другие цели. Например, соответствующие измерения полезны для управления программными проектами. В обсуждаемом здесь контексте, фокус измерений в отношении процессов направлен на оценку реализации и/или изменения процесса. Рисунок 2 иллюстрирует важность предположений, делаемых в большинстве программных проектов, в которых процесс непосредственно влияет на результаты проекта. Соответствующий контекст воздействует на связь между процессом и его результатом. Другими словами, это означает, что связь процесс-результат процесса находится в зависимости от контексте. Рисунок 2. Связь между процессом и его результатами (или “выходом процесса” - process outcome). Далеко не каждый процесс обладает положительным влиянием на получаемые результаты. Например, внедрение инспекции <получаемого> программного обеспечения может сократить усилия и стоимость по тестированию, но может и увеличить время, если каждая инспекция приводит к нарушению расписания просто в силу продолжительности соответствующих инспекционных действий. Поэтому, рекомендуется использовать множество метрических показателей (метрик), по которым оценивается процесс и его результат(ы), безусловно, в контексте значимых для бизнеса характеристик. Хотя определенные усилия могут направляться на решение вопросов использования соответствующего инструментария, главный ресурс, который нуждается управлении – персонал. Как результат, наиболее важные метрики касаются оценки продуктивности команд и процессов (например, может использоваться оценка функциональных точек, производимых на единицу трудозатрат 5 ассоциированного с этим уровня опыта в программной инженерии, в целом, и в отдельных технологиях, в частности. трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или “человеко- месяц”; здесь полезно обратиться к юбилейному второму изданию классического труда Фреда Брукса “Мифический человеко-месяц” [Брукс, 1995]. Результаты процесса могут, например, оцениваться в отношении качества продукта (как число сбоев на тысячу строк кода – KLOC, Kilo-Lines of Code или на функциональную точку – FP, Function Point), сопровождаемость (усилия, необходимые для реализации определенного типа изменений), продуктивность (LOC, Lines Of Code или FP за человеко-месяц), время вывода продукции на рынок (time-to-market) или степень удовлетворенности потребителей (по измерениям результатов опросов пользователей). Метод оценки связи между процессом и его “выходом” (результатом) зависит от конкретного контекста, например, масштабов (размеров) организации. В общем случае, мы фокусируемся на результатах процесса. Однако, для достижения заданных результатов (например, в терминах более высокого качества, лучшей сопровождаемости, большей удовлетворенности пользователей) мы должны внедрить соответствующие процессы. Конечно, не только процессы непосредственно влияют на результат <проекта>. Существуют и другие факторы, играющие не менее важную роль, например, возможности инструментов и потенциал, знания и опыт специалистов. Когда оценивается влияние изменения процессов, такие факторы должны учитываться (например, попытка внедрения развитых процессов программной инженерии при отсутствии ресурсов или в неподготовленной организационной среде практически наверняка приведет к краху таких инициатив). Кроме того, важна степень институализации процессов (process institualization или process fidelity – следование заданным процессам как повседневная практика работы). Фактор институализации в большинстве случаев объясняет, почему “хорошие” процессы не приводят к желаемому результату, когда процессы полностью или частично остаются лишь на бумаге. 6 Измерения в отношении программных продуктов (Software Product Measurement) Измерения в отношении программного продукта включают количественную оценку его размера, структуры и качества. данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке оригинального варианта SWEBOK 2004, поэтому, далее, нумерация тем смещена. Оценка размера (Size measurement) Размер программного продукта чаще всего оценивается по его “длине” (например, в количестве строк кода в модулях, страниц спецификаций требований и других документов) или функциональности (например, по количеству функциональных точек в спецификации). Принципы количественной оценки “функционального” размера программного обеспечения описываются в стандартах: IEEE 14143-1 “Information Technology - Software Measurement - Functional Size Measurement - Part 1:Definitions of Concepts” ISO 19761 “Software Engineering - Cosmic FPP - A Functional Size Measurement Method” ISO 20926 “Software Engineering - IFPUG 4.1 Unadjusted Functional Size Measurement Method- Counting Practices Manual” ISO 20968 “Software Engineering-MK II Function Point Analysis – Counting Practices Manual” Оценка структуры (Structure measurement) Существует широкий спектр метрик, которые можно использовать для оценки структуры программного обеспечения – в отношении высокоуровневого и низкоуровневого дизайна, а также артефактов кода для анализа потоков работ, потоков данных, вложенности <вызовов>, структур контроля, модульности, взаимодействия и т.п. Оценка качества (Quality measurement) Качество, как многомерная характеристика программного обеспечения, наиболее сложно для количественной оценки, в отличие от других характеристик, описанных выше. Более того, некоторые параметры качества требуют, в большей степени, применения качественной, а не количественной оценки. Детальное обсуждение вопросов оценки качества представлено в области знаний SWEBOK “Software Quality” (тема 3.4). ISO разработала соответствующие модели качества программного обеспечения и связанных с ним метрик (см. стандарт ISO 9126 “Software Engineering - Product Quality”, части 1-4). Качество результатов измерений (Quality Of Measurement Results) Качество результатов измерений (точность, воспроизводимость, повторяемость, изменяемость, случайность ошибок измерений) является основой программ проведения количественных оценок для получения эффективных и ограниченных (ограниченного количества значимых) результатов. Ключевые характеристики результатов измерений и связанного с ними качества инструментов измерения (в первую очередь, обоснованности используемого математического аппарата) определены в международном словаре метрологии ISO (International vocabulary on metrology). Теория количественной оценки устанавливает основу для возможных измерений. Измерения (и соответствующие типы “размерностей” или “шкал”) описаны в этой теории как систематическое определение численных величин для представления свойств объектов SWEBOK подчеркивает важность определения масштабов измерений и понимания каждого типа “размерности” (как мы увидим далее, под этим термином могут подразумеваться определенные категории метрических показателей - метрик) с учетом связи с последующим выбором методов анализа данных. Выразительная сторона размерностей связана с классификацией метрик. Для этого теория количественных оценок предлагает последовательность наложения все более детальных ограничений для выделения соответствующих (и все более специализированных) групп метрик. Если метрические показатели используются только для отметки объектов с целью классификации (например, в простейшем случае, бинарной классификации - “да/ нет”, “удовлетворяет/не удовлетворяет”), такие значения называют номинальными (nominal). Если значения определяются для ранжирования (ranking) объектов (например, “хороший”, “лучший чем”, “наилучший”), эти показатели называют порядковыми (ordinal). Если величины метрических показателей определяются относительно заданных единиц измерений, такие показатели называют интервальными (interval). Наконец, встречаются пропорциональные (ratio) показатели (основывающиеся на оценке взаимного отношения различных значений показателей, каждое из которых измеряется разницей между величиной показателя и нулем). Хотелось бы обратить внимание на описание концепции и использования метрических показателей в специальной главе “Метрические показатели, применяемые при оценке размера программ” русского перевода книги “Управление программными проектами” [Фатрелл, Шафер и Шафер, 2003, глава 21, с.692-748]. |