Качество, как многомерная характеристика программного обеспечения, наиболее сложно для количественной оценки, в отличие от других характеристик, описанных выше. Более того, некоторые параметры качества требуют, в большей степени, применения качественной, а не количественной оценки. Детальное обсуждение вопросов оценки качества представлено в области знаний SWEBOK “Software Quality” (тема 3.4). ISO разработала соответствующие модели качества программного обеспечения и связанных с ним метрик (см. стандарт ISO 9126 “Software Engineering
- Product Quality”, части 1-4).
4.3 Качество результатов измерений (Quality Of Measurement Results)
Качество результатов измерений (точность, воспроизводимость, повторяемость, изменяемость, случайность ошибок измерений) является основой программ проведения количественных оценок для получения эффективных и ограниченных (ограниченного количества значимых) результатов. Ключевые характеристики результатов измерений и связанного с ними качества инструментов измерения (в первую очередь, обоснованности используемого математического аппарата) определены в международном словаре метрологии ISO (International vocabulary on metrology).
Теория количественной оценки устанавливает основу для возможных измерений. Измерения (и соответствующие типы “размерностей” или “шкал”) описаны в этой теории как систематическое определение численных величин для представления свойств объектов.
SWEBOK подчеркивает важность определения масштабов измерений и понимания каждого типа “размерности” (как мы увидим далее, под этим термином могут подразумеваться определенные категории метрических показателей - метрик) с учетом связи с последующим выбором методов анализа данных. Выразительная сторона размерностей связана с классификацией метрик. Для этого теория количественных оценок предлагает последовательность наложения все более детальных ограничений для выделения соответствующих (и все более специализированных) групп метрик. Если метрические показатели используются только для отметки объектов с целью классификации (например, в простейшем случае, бинарной классификации - “да/нет”, “удовлетворяет/не удовлетворяет”), такие значения называют номинальными (nominal). Если значения определяются для ранжирования (ranking) объектов (например, “хороший”, “лучший чем”, “наилучший ”), эти показатели называют порядковыми (ordinal). Если величины метрических показателей определяются относительно заданных единиц измерений, такие показатели называют интервальными (interval). Наконец, встречаются пропорциональные (ratio) показатели (основывающиеся на оценке взаимного отношения различных значений показателей, каждое из которых измеряется разницей между величиной показателя и нулем).
Хотелось бы обратить внимание на описание концепции и использования метрических показателей в специальной главе “Метрические показатели, применяемые при оценке размера программ” русского перевода книги “Управление программными проектами” [Фатрелл, Шафер и Шафер, 2003, глава 21, с.692-748].
4.4 Информационные модели (Software Information Models)
По мере сбора данных и наполнения ими репозитория измерений, становится возможно построить соответствующие информационные модели на основе собранных данных и имеющихся знаний.
Эти модели применяются для анализа, классификации и предсказания характеристик и поведения измеряемых объектов>. Оценка моделей необходима для обеспечения достаточной степени точности и понимания их ограничений. Также необходимо отметить важность работ, направленных на уточнение моделей как в процессе ведения проекта, так и после его завершения.
4.4.1 Построение модели (Model building)
Построение модели включает калибрование и оценку модели. Ориентированный на цель подход к измерениям наполняет процесс построения модели необходимым содержанием, то есть модель конструируется для ответа на значимые вопросы и достижения целей совершенствования создаваемого программного обеспечения. На этот процесс также оказывают влияние неявные ограничения используемых метрических показателей и связанных с ними методов анализа.
Модель калибруется и оценивается на основании уже накопленных результатов наблюдений (например, по недавно выполненным проектам или проектам, аналогичным данному по используемым технологиям и т.п.) и сравнения ее эффективности с точки зрения соответствия прогнозов реальным данным.
4.4.2 Внедрение модели (Model implementation)
Внедрение модели включает интерпретацию и уточнение моделей. Откалиброванные модели применяются в отношении процесса, их результаты интерпретируются и оцениваются в контексте процесса/проекта, после чего модели уточняются в тех аспектах, где это необходимо.
4.5 Техники количественной оценки процессов (Process Measurement Techniques)
Определенные техники измерения процесса могут использоваться для анализа процессов программной инженерии и идентификации их преимуществ и недостатков (сильных и слабых сторон). Такие техники применяются во многих случаях для инициирования или оценки влияния (последствий) внедрения или изменения процессов.
Качество результатов измерений, в терминах точности, повторяемости и воспроизводимости, связано с инструментальной составляющей и используемой концепцией оценки и точкой зрения в отношении измерений (например, когда оценивающее лицо - ассессор - выставляет оценки по конкретным процессам).
Техники измерения процесса классифицируются по двум типам: аналитическая и эталонная (benchmarking). Эти два типа используются вместе, так как основываются на различных типах информации.
4.5.1 Аналитические техники (Analytical techniques)
Аналитические техники характеризуются, как зависящие от “количественных свидетельств того, где необходимы усовершенствования и где инициативы по совершенствованию оказались успешны". Аналитический тип, иллюстрируемый, например, подходом QIP (Quality Improvement Paradigm) состоит из цикла “понимание-проверка-приложение”. Техники, представленные ниже, приведены в качестве других примеров аналитического подхода к измерениям и отражают достаточно типичную практику реализации такого <аналитического> взгляда на проведение количественной оценки. Будут или нет использоваться эти техники в практике конкретной организации зависит, как минимум, от зрелости ее организационной культуры и используемых процессов.
• Экспериментальные исследования (Experimantal Studies). Проводятся в специально подготовленном “окружении” для оценки <нового или измененного> процесса. Обычно новый (или измененный) процесс сравнивается с существующим для определения того, в какой степени “старый” процесс дает лучшие результаты, по сравнению с новым процессом.
Другой тип экспериментальных исследований - “симуляция” процесса (моделирование его поведения и результатов, прим. автора). Этот тип исследований может использоваться для анализа поведения процесса, выяснения потенциальных возможностей усовершенствования процесса, предсказания результатов процесса (для того случая, если существующий процесс изменяется определенным образом) и контроля выполнения процесса. В качестве первичных данных для симуляции процесса, обычно, используются данные текущего (существующего) процесса.
• Обзор (оценка) определения процесса (Process Definition Review) подразумевает, каким образом оценивается определение процесса для идентификации его недостатков и потенциальных аспектов совершенствования. Один из легких способов анализа процесса - сравнение его с существующими стандартами (например, IEEE/ISO/ГОСТ 12207). При таком подходе метрические показатели обычно не собираются, или, в случае их наличия, играют лишь “поддерживающую” (второстепенную) роль. Специалисты, выполняющие анализ определения процесса, используют свои знания, опыт и другие возможности для принятия решения какие изменения процесса могут потенциально привести к желаемому результату в отношении “выходов” процесса (получаемого программного продукта или его отдельных элементов). Наблюдения (observations) за выполнением процесса также могут дать дополнительные данные, позволяющие идентифицировать возможные пути совершенствования процесса.
• Ортогональная классификация дефектов (Orthogonal Defect Classification) - техника, которая может быть использована для связывания (отображения) сбоев с их потенциальными причинами. В данном контексте может быть полезен для детального ознакомления стандарт IEEE 1044 “Standard for the Classification of Software Anomalies”, классифицирующий возможные сбои (аномалии) в работе программного обеспечения.
• Анализ причин (Root Case Analysis) является еще одной популярной техникой, часто используемой на практике. Эта техника предполагает “спуск” от обнаруженного сбоя к идентификации его причины, изменяя сам процесс (или, по аналогии, код программного обеспечения, если бы речь шла о поиске дефекта, приводящего к сбою) до тех пор, пока сбой не исчезнет и реструктурируя процесс с тем, чтобы обнаруженная проблема не повторялась в будущем.
Описанная выше ортогональная классификация дефектов может использоваться для определения категорий различных сбоев и, соответственно, путей обнаружения их причин. Такая классификация добавляет количественные показатели к технике анализа причин.
• Статистический контроль процесса (Statistical Process Control, SPC) - эффективный путь для определения стабильности (или отсутствия стабильности) процесса.
• Индивидуальный программный процесс (Personal Software Process, PSP) определяет серию возможных улучшений в индивидуальной практике разработки программного обеспечения. Предполагает движение “снизу-вверх”, включая сбор персональных данных и их интерпретацию для повышения индивидуальной продуктивности специалистов.
Хотя SWEBOK это и не упоминает, однако, существует и развитие PSP - Team Software Process (TSP), направленный на аспекты повышения качества командной работы, включая совершенствование взаимодействия между членами проектной команды.
4.5.2 Эталонные техники (Benchmarking techniques)
Этот тип техник основывается на идентификации “совершенной” организации процесса и связанных с ней практиках и инструментах. Предполагается, что если менее опытная команда (организация, компания) применяет успешные подходы более опытной организации, принимаемой
в качестве эталона, менее опытная команда также станет “совершенной”, то есть улучшит свои процессы до уровня данного успешного примера. Данная техника уделяет специальное внимание оценке зрелости организации и/или потенциальных возможностей ее процессов (ресурсов, культуры, бизнес-практик и т.п.).
В определенной степени, CMMI (и аналогичные модели в области управления проектами, например, PMI OPM3 и менеджмента качества, например, Six Sigma) предоставляют обоснованный и подтвержденный базис для использования эталонной техники.
Лекция 10. Программная инженерия
Инструменты и методы программной инженерии (Software Engineering Tools and Methods)
Лекция базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK®, 2004. Содержит перевод описания области знаний SWEBOK® “Software Engineering Tools and Methods”, с комментариями и замечаниями.
"Основы программной инженерии" разработаны на базе IEEE Guide to SWEBOK® 2004 в соответствии с IEEE SWEBOK 2004 Oopyright and Reprint Permissions: "This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy."
Программная инженерия
Инструменты и методы программной инженерии (Software Engineering Tools and Methods)
1.8 Инструменты поддержки процессов (Software Engineering Process Tools)....................... 7
1.9 Инструменты обеспечения качества (Software Quality Tools)............................................ 7
1.10 Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues) . 8
2. Методы программной инженерии (Software Engineering Methods)....................................... 8
2.1 Эвристические методы (Heuristic Methods)....................................................................... 8
2.2 Формальные методы (Formal Methods)............................................................................ 8
2.3 Методы прототипирования (Prototyping Methods)............................................................ 9
Программные инструменты предназначены для обеспечения поддержки процессов жизненного цикла программного обеспечения. Инструменты позволяют автоматизировать определенные повторяющиеся действия, уменьшая загрузку инженеров рутинными операциями и помогая им сконцентрироваться на творческих, нестандартных аспектах реализации выполняемых процессов. Инструменты часто проектируются с целью поддержки конкретных (частных) методов программной инженерии, сокращая административную нагрузку, ассоциированную с “ручным” применением соответствующих методов. Так же, как и методы программной инженерии, инструменты призваны сделать программную инженерию более систематической деятельностью и по своему содержанию (предлагаемой функциональности) могут варьироваться от поддержки отдельных индивидуальных задач вплоть до охвата всего жизненного цикла (в этом случае часто говорят об инструментальной платформе или просто платформе разработки).
Методы программной инженерии накладывают определенные структурные ограничения на деятельность в рамках программной инженерии с целью приведения этой деятельности в соответствие с заданным систематическим подходом и более вероятным и скорым, с точки зрения соответствующего метода, достижением успеха. Методы обычно предоставляют соответствующие соглашения (нотацию), словарь <терминов и понятий> и процедуры выполнения идентифицированных (и охватываемых методом) задач, а также рекомендации по оценке и проверке <выполняемого> процесса и <получаемого в его результате> продукта. Методы, как и инструменты, варьируются по содержанию (охватываемой области применения) от отдельной фазы жизненного цикла (или даже процесса) до всего жизненного цикла. Данная область знаний касается только методов, охватывающих множество фаз (этапов) жизненного цикла. Те методы, применение которых фокусируется на отдельных фазах жизненного цикла или частных процессах, описаны в соответствующих областях знаний.
Существует множество детальных описаний и руководств по конкретным инструментам, и исследований, посвященных анализу (и категоризации, в первую очередь, со стороны аналитиков) уже применяемых и новых инструментальных средств (и вероятным направлениям их развития). В таком контексте, общее техническое описание инструментов программной инженерии, действительно, может отпугнуть. (В то же время, с точки зрения автора, при всей неоднозначности любой категоризации инструментов, может быть сформирован общий взгляд на их целевую функциональность, пусть в чем то и спорный, что, отразится в определенных случаях ниже в соответствующих авторских комментариях). Одна из основных сложностей такого описания, в общем случае, заключается в высокой изменчивости и быстром эволюционировании программных
инструментов. Конкретные аспекты функциональности инструментов достаточно быстро изменяются, что усложняет приведение конкретных актуальных примеров.
Данная область знаний охватывает все процессы жизненного цикла и, соответственно, связана со всеми другими областями знаний SWEBOK.
Рисунок 1. Область знаний “Инструменты и методы программной инженерии” [SWEBOK, 2004, с. 10-1, рис. 1]
Первые пять тем данной секции соответствуют первым пяти областям знаний SWEBOK - требования, проектирование, конструирование, тестирование и сопровождение. Следующие четыре темы касаются оставшихся четырех областей знаний - конфигурационного управления, управления программной инженерией, процессов и качества, соответственно. Также в данной секции представлена еще одна тема - “Дополнительные аспекты инструментального обеспечения” (в оригинале SWEBOK она называется “Miscellaneous”), посвященная таким вопросам как, например, интеграция инструментов, которые потенциально касаются всех классов инструментов.
1.1 Инструменты работы с требованиями (Software Requirements Tools)
SWEBOK говорит о том, что инструменты, применяемые для работы с требованиями могут быть классифицированы в две категории: средства моделирования (modeling) и средства трассировки (traceability). Однако, на практике, моделирование требований, все же, является частью управления требований, как, кстати, и трассировка. В принципе, инструменты трассировки могут быть рассмотрены как самостоятельная категория, в силу своей значимости при проведении анализа требований, в первую очередь, анализа влияний требований и изменений (т.н. “impact analysis”). Но моделирование требований лишь часть управления требованиями. Поэтому, в приведенной ниже классификации предлагаемая модификация оригинального SWEBOK состоит в
том, что вместо “инструментов моделирования требований” используется термин “инструменты управления требованиями”, при сохранении оригинального содержания данной темы SWEBOK. Соответственно,
• Инструменты управления требованиями (моделирования требований - Requirements modeling tools). Эти инструменты используются для извлечения (eliciting), анализа, специфицирования и проверки программных требований.
• Инструменты трассировки требований (Requirement traceability tools). Эти инструменты становятся все более важными по мере повышения сложности программного обеспечения. В силе того, что они также относятся и к другим процессам жизненного цикла, здесь они представлены в качестве самостоятельной категории средств работы с требованиями.
Необходимо заметить, что трассировка является неотъемлемой частью полноценной работы с требованиями, что приводит к естественному объединению предлагаемых SWEBOK категорий инструментов в единый класс “инструментов управления требованиями”, функциональное содержание которых может варьироваться, например, в зависимости от сложности проектов и уровня зрелости процессов. Если мы обратимся, например, к модели CMMI Staged, мы увидим, что на 2-м уровне зрелости речь идет об “управлении требованиями” - Requirement Management, а на 3-м уровне зрелости обсуждается “разработка требований” - Requirement Development, обладающая более ёмким содержанием. В то же самое время, с технократической точки зрения, требования могут восприниматься и как элементы конфигураций, наравне с запросами на изменения и другими активами проекта (см. область знаний SWEBOK “Конфигурационное управление”). Таким образом, в ряде случаев (что подтверждается конкретными программными средствами, доступными на рынке программного обеспечения), в качестве инструмента работы с требованиями может выступать и система конфигурационного управления, если, конечно, она изначально не ограничена базовой функциональностью контроля версий <файлов>. С другой стороны, сегодняшние средства моделирования на основе UML и BPMN могут также рассматриваться как элементы инструментального обеспечения работы с требованиями, что часто отражается в их функциональности, включающей тесную интеграцию с “классическими” средствами управления требованиями, а сама интеграция воплощена не только в визуальном представлении работы с репозиториями требований, но и в автоматизации трассировки между моделями (и/или их элементами) и требованиями, соответственно.
Эта тема охватывает инструменты для создания и проверки программного дизайна. Существует большое разнообразие таких инструментов, использующих различные нотации (соглашения, в том числе визуальные) и методы. Несмотря на такое разнообразие, <авторами SWEBOK> не было найдено <адекватной> классификации этих инструментов.
Однако, в данном случае, все же возможно разделение инструментов по нескольким критериям, например, применяемым базовым нотациям моделирования и проектирования (SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т.п.) или целевым задачам (бизнес-моделирование, проектирование БД, объектно-ориентированное проектирование, интеграционное/SOA-проектирование и т.п.).
1.3 Инструменты конструирования (Software Construction Tools)
Данная тема касается инструментальных средств конструирования программного обеспечения, в соответствии с пониманием “конструирования”, заданным соответствующей областью знаний SWEBOK, рассматривавшейся ранее. Эти инструменты используются для производства и трансляции программного представления (например, исходного кода), достаточно детального и явного для машинного выполнения.
документирование все же является не только и не столько частью редактора, сколько самостоятельной функциональностью, пусть часто и тесно интегрированной с редактором.
• Компиляторы и генераторы кода (compilers and code generators). Традиционно, компиляторы являлись неинтерактивными (командными) трансляторами исходного кода. Однако, существует тенденция (с точки зрения автора, более чем явная, что отмечено ниже) интеграции компиляторов и редакторов в интегрированные среды программирования. К этому классу также относятся препроцессоры, линковщики/загрузчики, а также генераторы кода (за исключением, может быть, объектноориентированных средств проектирования, поддерживающих связь с исходным кодом и имеющих тенденцию быть тесно интегрированными с новым поколением IDE).
• Интерпретаторы (interpreters). Эти инструменты обеспечивают исполнение программ посредством эмуляции. Они могут поддерживать действия по конструированию программного обеспечения, предоставляя для исполнения программ окружение, более контролируемое и поддающееся наблюдению, чем это обычно способна сделать та или иная операционная система.
Хочется отметить определенное “слияние”, если так можно выразиться, между компиляторами и интерпретаторами. Ярким тому свидетельством является использование так называемой just-in-time компиляции - компиляции “на лету”, когда промежуточный программный код, по мере исполнения или с опережением (например, в процессе запуска/загрузки программы) преобразуется в набор инструкций, исполняемых непосредственно средствами операционной системы, но под контролем среды исполнения, в первую очередь, с точки зрения безопасности. Такого рода подход стал родоначальником ряда современных программных платформ, например, Java и .NET. На этом фоне, возможно было бы объединить интерпретаторы с компиляторами и генераторами кода, как средства непосредственной подготовки (трансляции) исходного кода к исполнению.
• Отладчики (debuggers). Эти инструменты было принято выделить в самостоятельную категорию, так как они поддерживают процесс конструирования программного обеспечения, но, в то же время, <функционально> отличаются от редакторов и компиляторов.
С точки зрения классификации инструментов необходимо выделить явно и давно присутствующие на рынке: “интегрированные средства разработки” (IDE - integrated developers environment), а также программные библиотеки/библиотеки компонент (frameworks, libraries, components), без которых просто невозможно представить сегодняшний процесс разработки, да и рынок программных средств, в целом. Кроме того, в данной теме можно говорить и о таких функционально ёмких “супер”-категориях, как “программная платформа” (например, Java, J2EE и Microsoft .NET) и “платформа облачных вычислений” (например, Microsoft Azure, Amazon и др.), которые включают наравне с инструментами, как таковыми, и определенные модели конструирования, преобразования и выполнения кода. При таком подходе, вероятно, обоснованным было бы введение класса “элементарных” или “базовых инструментов конструирования”, к которому можно было бы отнести редакторы, компиляторы, интерпретаторы, отладчики, средства документирования и библиотеки, а также класса “комплексных средств конструирований’ - интегрированных сред и различных платформ, что, безусловно, не претендует на истину в последней инстанции и является одной из возможных точек зрения.
• Генераторы тестов (test generators). Эти инструменты помогают в разработке сценариев тестирования.
• Инструменты оценки тестов (test evaluation tools). Эти инструменты поддерживают оценку результатов выполнения тестов, помогая определить в какой степени и где именно обнаруженное поведение ^тестируемого объекта> соответствует ожидаемому поведению.
• Средства управления тестами (test management tools). Эти средства обеспечивают поддержку всех аспектов процесса тестирования программного.
• Инструменты анализа производительности (performance analysis tools). Эти инструменты используются для количественной оценки и анализа производительности программного обеспечения, являющегося специализированным видом тестирования, цель которого - в оценки поведения программ в части производительности, в отличие от тестирования <корректности> функционального поведения.
Последний класс инструментов тестирования, в какой-то степени, показывает недостаточность предложенной классификации, упуская, например, инструменты функционального тестирования, средства тестирования безопасности, инструменты тестирования пользовательского интерфейса, инструменты нагрузочного тестирования и др., соответствующие, различным целям тестирования, представленным в секции 2.2 области знаний SWEBOK “Тестирование”, и естественно задающим “подвиды” возможного класса “специализированных или целевых инструментов тестирования’’, к которым, в частности, относится тестирование производительности.
Эта тема охватывает инструменты, особенно важные для обеспечения сопровождения существующего программного обеспечения, подверженного модификациям. SWEBOK идентифицирует две категории таких инструментов:
• Инструменты облегчения понимания (comprehension tools). Эти инструменты помогают человеку в понимании программ. Примерами могут служить различные средства визуализации.
• Инструменты реинжиниринга (reengineering tools). Эти инструменты поддерживают деятельность по реинжинирингу, описанную в области знаний SWEBOK “Software Maintenance”.
Средства “обратного” инжиниринга (reverse engineering) помогают в процессе восстановления для существующего программного обеспечения таких артефактов, как спецификация и описание дизайна (архитектуры), которые, в дальнейшем, могут быть трансформированы для генерации нового продукта на основе функциональности существующего.
Последнее замечание, в сочетании с типичной функциональностью современных средств проектирования, поддерживающих анализ исходного кода (в случае объектно-ориентированных систем) и его визуализацию (в том числе, поведенческую, например, в виде диаграмм UML Sequence), позволяет объединить упомянутые категории инструментов в единый класс “инструментов реинжиниринга”. В то же время, деятельность по сопровождению и поддержке, в частности, касающаяся сбоев и исправления обнаруженных ошибок в программном обеспечении, требует, в определенной степени, отнесения к этой теме и средств конфигурационного управления, рассматриваемых ниже (например, в части обработки запросов на изменения).
1.6 Инструменты конфигурационного управления (Software Configuration Management Tools) Инструменты конфигурационного управления делятся на три категории:
• Инструменты отслеживания (tracking) дефектов, расширений и проблем.
• Инструменты управления версиями.
• Инструменты сборки и выпуска. Эти инструменты предназначены для управления задачами сборки и выпуска продуктов, а также включают средства инсталляции.
Дополнительная информация по данной теме представлена в области знаний SWEBOK “Конфигурационное управление”.
1.7 Инструменты управления инженерной деятельностью (Software Engineering Management Tools)
Средства управления деятельностью по программной инженерии делятся на три категории:
• Инструменты планирования и отслеживания проектов. Эти средства используются календарного планирования работ, количественной оценки усилий и стоимостных ожиданий, связанных с проектами.
Рисунок 1. Область знаний “Инструменты и методы программной инженерии” [SWEBOK, 2004, с. 10-1, рис. 1]