Базовые принципы реализации метрологии и качества программного обеспечения

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Факультет переподготовки специалистов по математике и информатике Базовые принципы реализации метрологии и качества ПО Дипломная работа слушателя Веревкина Константина Владимировича

1. Введение

2. Понятие качества

3. Стандартизация качества

3.1 Семейство стандартов ISO 9000

3.1.1 Модель системы качества

3.1.2 Структура серии ISO 9000

3.2 Стандарт ISO 9126 (1−4)

4. Уровни зрелости процесса CMM

4.1 Зрелые и незрелые организации-разработчики ПО

4.2. Уровни зрелости (Maturity Levels)

4.3. Характеристики уровней зрелости

5. Количественное управление процессом. Метрология производственного процесса.

5.1 Основные классы метрик

5.1.1 Основные направления формирования метрик для оценки компьютерных программ

5.1.2 Метрические шкалы

5.2 Программометрика.

5.2.1 Примеры стандартных метрик.

5.3 Алгоритм формирования метрик

5.4 Качество программных компонент

5.5 Качество технического проекта

6. Практическое применение оценок в проектировании ПС.

6.1 Оценивание трудозатрат

6.2 Регрессионная модель COCOMO

6.2.1 Общее описание регрессионных моделей

6.2.2 Режимы модели COCOMO

6.2.3 Уровни модели COCOMO

6.2.4 Базовая модель COCOMO

6.2.5 Промежуточная модель COCOMO

6.2.6 Пример реализации промежуточной модели COCOMO

6.2.7 Детализированная модель COCOMO

6.2.8 Преимущества и недостатки модели COCOMO

6.3 Модель COCOMO II

6.4 Другие модели и методы

6.5 Вывод

7.

Заключение

.

Процессы разработки, приобретения и внедрения сложных систем, к которым относятся в частности программные комплексы, должны находиться под жестким управленческим контролем. В настоящее время практически во всех организациях обеспечивается контроль важнейших характеристик, связанных с производством и использованием программных продуктов, таких как время, финансовые средства, ресурсы и т. п. Однако в большинстве случаев вне пределов сферы контроля оказывается наиболее важная характеристика программных продуктов, ради которой, собственно и осуществляются затраты времени, финансовых средств и ресурсов — это качество продукта, поскольку «невозможно контролировать то, что нельзя измерить» («You Cannot Control What You Cannot Measure» — YCСWYCM).

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

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

В данной работе делается краткий обзор современных стандартов качества ПО, а также некоторых методов количественного измерения качества.

1. Понятие качества

Сейчас существует несколько определений качества, которые в целом совместимы друг с другом. Наиболее распространенные:

Определение ISO: Качество — это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям.

Определение IEEE: Качество программного обеспечения — это степень, в которой оно обладает требуемой комбинацией свойств.

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

Такой критерий должен:

· численно характеризовать набор основных целевых функций программного средства

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

· оценивать степени влияния на показатель качества различных внешних факторов;

· быть по возможности простым, хорошо измеримым и иметь малую дисперсию на широком диапазоне измерений.

Общее качество программной системы включает в себя на верхнем уровне ряд составляющих, которые должны быть приняты во внимание при управлении качеством:

1. Качество инфраструктуры (infrastructure quality): качество аппаратного и поддерживающего программного обеспечения (например, качество операционных систем, компьютерных сетей и т. п.).

2. Качество программного обеспечения (software quality): качество программного обеспечения информационной системы.

3. Качество данных (data quality): качество данных, использующихся информационной системой на входе.

4. Качество информации (information quality): качество информации, продуцируемое информационной системой.

5. Качество административного управления (administrative quality) — качество менеджмента, включая качество бюджетирования, планирования и календарного контроля.

6. Качество сервиса (service quality) — качество обучения, системной поддержки и т. п.

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

Управление качеством будет успешным, если под контролем находятся все измерения качества.

2. Стандартизация качества

3.1 Семейство стандартов ISO 9000

3.1.1 Модель системы качества

В условиях всеобщего качества цели качества могут быть сформулированы следующим образом: «Достижение наивысших результатов в удовлетворении запросов потребителя при минимальном использовании ресурсов и постоянном улучшении результатов» .

Модель, представленная на схеме (рис. 3.1), показывает путь к совершенствованию, для которого необходимы три основных компонента:

· результаты: демонстрируют способность предприятия удовлетворять запросы потребителя.

· процессы: инструменты для достижения результатов. Процессы должны тщательно контролироваться, давая возможность руководству предприятия предвидеть результаты и предотвращать проблемы.

· система качества: фундамент, на котором развиваются процессы, а следовательно, и результаты; почва, на которой могут развиться условия для непрерывного улучшения продукции.

Многие компании и потребители требуют от своих поставщиков наличия документированной Системы Качества. Эта система определяется следующим образом: «совокупность организационной структуры, методик, процессов и ресурсов, необходимых для осуществления общего руководства качеством».

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

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

Рис. 3.1. Модель совершенствования

3.1.2 Структура серии ISO 9000

Стандарты серии ISO 9000 — это пакет документов по обеспечению качества подготовленный членами международной делегации, известной как «ISO/Технический Комитет 176» (ISO/TC 176).

В настоящее время семейство (серия) ISO 9000 включает:

· все международные стандарты с номерами ISO 9000 — 9004, в том числе все части стандарта ISO 9000 и стандарта ISO 9004;

· все международные стандарты с номерами ISO 10 001 — 10 020, в том числе все их части;

· ISO 8402.

Три стандарта из серии ISO 9000 (ISO 9001, ISO 9002 и ISO 9003) являются основополагающими документами Системы Качества, описывающими модели обеспечения качества и представляющими три различные формы функциональных или организационных взаимоотношений в контрактной ситуации. Стандарты ISO 9000 и ISO 9004 не более чем справочники:

ISO 9000: «Общее руководство качеством и стандарты по обеспечению качества»

Часть 1: «Руководящие указания по выбору и применению». Это руководство было создано для оказания помощи потенциальным пользователям в решении вопроса предпочтительности той или иной модели обеспечения качества с учётом специфических договорных взаимоотношений.

Часть 2: «Общие руководящие указания по применению ISO 9001, ISO 9002 и ISO 9003». Данное руководство помогает пользователю прояснить трактовку требований стандартов ISO 9001, ISO 9002 и ISO 9003.

Часть 3: «Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения». Предназначен для помощи в трактовке требований стандарта ISO 9001 поставщикам интеллектуальной продукции.

Рис. 3.2. Структура семейства стандартов ISO 9000

Часть 4: Руководство по управлению программой надежности".

ISO 9004: «Общее руководство качеством и элементы системы качества». Этот документ предоставляет пользователю пакет руководств, с помощью которых система качества может быть разработана, осуществлена и установлена, т.к. он предоставляет информацию и предложения по осуществлению Системы Всеобщего Руководства Качеством, которая запускается после установки и (возможно) сертификации Системы Качества.

Ни ISO 9000, ни ISO 9004 не являются моделями Обеспечения Качества и не должны рассматриваться как обязательные требования. Таким образом, бессмысленно говорить о сертификации или регистрации по ISO 9000 или ISO 9004. Могут быть получены только сертификаты на соответствие ISO 9001, 9002 или 9003.

Семейство ISO 9000, особенно стандарты, предназначенные для использования в договорных случаях, для оценки или сертификации (ISO 9001, ISO 9002 и ISO 9003) — работает во всём мире во многих отраслях промышленности и экономики. Было специально разработано множество схем, учитывающих особенности отдельных секторов промышленности и экономики.

Общность и универсальность стандартов ISO 9000 заключается в том, что модели Обеспечения Качества не были разработаны для какой-либо специфической области — они предназначены для применения во всех областях промышленности и для всех стран.

Основные характеристики стандартов:

1) ISO 9001

Название: «Система Качества: Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании».

ISO 9001 является наиболее обширным стандартом; он применим в случае договорной ситуации, когда соответствие специфическим требованиям должно обеспечиваться в течение нескольких стадий, включающих: проектирование/разработку, производство, монтаж и обслуживание. Это применимо когда:

· необходимо проектирование продукции и требования к ней определены в виде эксплуатационных характеристик или они должны быть установлены;

· доверие к соответствию продукции может быть достигнуто путём соответствующей демонстрации поставщиком его возможностей в проектировании, разработке, производстве, монтаже и обслуживании.

2) ISO 9002

Название: «Система Качества: Модель обеспечения качества при производстве, монтаже и обслуживании».

ISO 9002 применим в договорной ситуации когда:

· специфические требования к продукции установлены в проекте или в технических условиях;

· доверие к соответствию продукции может быть достигнуто путём соответствующей демонстрации поставщиком его возможностей в производстве, монтаже и обслуживании.

3) ISO 9003

Название: «Система Качества: Модель обеспечения качества при окончательном контроле и испытаниях».

ISO 9003 применим в договорной ситуации когда:

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

Рис. 3.3. Три модели обеспечения качества и взаимосвязь между ISO 9001, 9002 и 9003

Международные стандарты семейства ISO 9000 описывают лишь минимальные требования (задают модель системы качества), которые необходимо выполнить предприятию с точки зрения доказательства производителем своей способности к качеству при поставках. Выбор модели и её реализация в системе качества — добровольное дело руководства предприятия. Выполнение требований стандарта — далеко не конечная цель работы предприятия по совершенствованию качества, а лишь хорошее начало такой работы.

3.2 Стандарт ISO 9126 (1−4)

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

В совместном стандарте ISO и Международной комиссии по электротехнике (IEC) ISO/IEC 9126:1991 «Оценивание программного продукта. Характеристики качества и руководящие указания по их применению» определены шесть основных характеристик верхнего уровня: функциональность (Functionality), надежность (Reliability), удобство использования (Usability), эффективность (Efficiency), сопровождаемость (Maintainability), переносимость (Portability) и дан предварительный перечень групповых характеристик второго уровня иерархии (подхарактеристик).

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

В более поздней версии (IEC) ISO/IEC 9126:1993 выделены несколько видоизмененные характеристики (показатели) качества с позиций пользователя, разработчика и управляющего проектом. Документом рекомендуется шесть основных характеристик — функциональная пригодность, надежность, применимость, эффективность, сопровождаемость и переносимость, детализированные 21 показателем.

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

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

Правильность (корректность) — способность программного средства обеспечивать правильные или приемлемые для пользователя результаты и внешние эффекты.

Способность к взаимодействию — свойство программных средств и их компонентов взаимодействовать с одной или большим числом компонентов внутренней и внешней среды.

Защищенность — способность компонентов программного средства защищать программы и информацию от любых негативных воздействий.

Надежность — обеспечение комплексом программ достаточно низкой вероятности отказа в процессе функционирования программного средства в реальном времени.

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

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

Сопровождаемость — приспособленность программного средства к модификации и изменению конфигурации и функций.

Мобильность (переносимость) — подготовленность программного средства к переносу из одной аппаратно-операционной среды в другую.

В настоящее время завершается разработка и формализован последний проект состоящего из четырех частей стандарта ISO 9126-(1−4) для замены редакций 1991 и 1993 годов.

Проект состоит из следующих частей под общим заголовком «Информационная технология — характеристики и метрики качества программного обеспечения»:

Часть 1. Характеристики и субхарактеристики качества Часть 2. Внешние метрики качества Часть 3. Внутренние метрики качества Часть 4. Метрики качества в использовании" .

Первая часть стандарта ISO 9126−1 — распределяет атрибуты качества программных средств по шести характеристикам, используемым в остальных частях стандарта. Исходя из принципиальных возможностей их измерения, все характеристики могут быть объединены в три группы, к которым применимы разные категории метрик:

· категорийные (описательные, номинальные) метрики предназначены для «измерения» функциональных возможностей программных средств;

· количественные метрики применимы для измерения надежности и эффективности сложных комплексов программ;

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

В этой части стандарта ISO 9126−1 даются также определения с уточнениями из остальных его частей для каждой характеристики программного средства, а также для субхарактеристик качества.

Вторая и третья части стандарта ISO 9126−2 и ISO 9126−3 посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств. Все таблицы содержат унифицированную рубрикацию, где отражены имя и назначение метрики; метод ее применения; способ измерения, тип шкалы метрики; тип измеряемой величины; исходные данные для измерения и сравнения; а также этапы жизненного цикла программного средства (по ISO 12 207), к которым применима метрика.

Четвертая часть стандарта ISO 9126−4 предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества программных средств. В ней обосновываются и комментируются выделенные показатели сферы использования (контекста) программных средств и группы выбранных метрик для пользователей.

3. Уровни зрелости процесса CMM

4.1 Зрелые и незрелые организации-разработчики ПО

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

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

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

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

Установленные процессы пригодны для использования и соответствуют реально применяемым способам проведения работ. По мере необходимости эти определенные процессы обновляются, а усовершенствования разрабатываются с помощью контролируемого пилотного тестирования и/или анализа затрат и прибылей. Распределение ролей и сфер ответственности в пределах определенного процесса четко определено на протяжении всего проекта и в рамках всей организации.

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

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

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

Уровень зрелости производственного процесса — это степень, до которой тот или иной процесс определен, управляем, измеряем, контролируем и эффективен. Зрелость подразумевает потенциал для роста продуктивности и отражает как полноту производственного процесса организации, так и постоянство, с которым организация применяет этот процесс во всех своих проектах. Производственный процесс достаточно хорошо понимается персоналом зрелой организации, обычно благодаря разработанной документации и проведенному обучению, и этот процесс постоянно контролируется и улучшается участвующими в нем сотрудниками. Продуктивность зрелого процесса разработки всегда хорошо известна. Зрелый производственный процесс подразумевает возможность постепенного улучшения качества своих результатов и производительности за счет стабильного повышения дисциплины своего выполнения.

4.2 Уровни зрелости (Maturity Levels)

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

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

4.3 Характеристики уровней зрелости

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

Уровень 1 — Начальный уровень:

Находясь на начальном уровне, организация обычно не может обеспечить устойчивый процесс разработки и сопровождения ПО. Когда в организации отсутствует культура управления, преимущества применения хороших решений в процессе проектирования исчезают из-за неэффективного планирования и плохой работы систем согласования.

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

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

Рис. 4.1. Уровни зрелости производственного процесса.

Уровень 2 — повторяемый уровень На повторяемом уровне установлены политики управления проектом разработки и процедуры их применения. Планирование и управление новым проектом базируется на опыте работы с подобными проектами. Целью достижения уровня 2 является институционализация таких процессов эффективного управления проектами разработки, которые позволяют организациям воспроизводить успешные практики прежних проектов, хотя конкретные процессы различных проектов могут различаться. Эффективный процесс может быть охарактеризован как проверенный на практике, документированный, обязательный к выполнению, обучаемый, измеряемый и открытый для дальнейшего усовершенствования.

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

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

Уровень 3 — определенный уровень На определенном уровне, стандартный процесс разработки и сопровождения ПО в рамках организации надежно документирован, включая как процессы программной инженерии, так и управления, и эти процессы интегрированы в единое целое. Этот стандартный процесс в материалах CMM называется стандартным производственным процессом организации. Процессы, установленные на уровне 3, используются (и, по мере необходимости, изменяются) для помощи менеджерам и техническому персоналу в более эффективном выполнении своих задач. При стандартизации своих производственных процессов организация использует эффективные практики программной инженерии. Существует группа, которая ответственна за работы по координации производственного процесса организации, т. е. группа инженерии производственного процесса (SEPG). Реализована общая для организации программа обучения, гарантирующая, что персонал и руководящее звено обладают знаниями и навыками, требующимися для выполнения назначенных им ролей.

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

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

Уровень 4 — управляемый уровень На управляемом уровне организация устанавливает количественные показатели качества (метрики) как для программных продуктов, так и для процессов их разработки. Для важных работ производственных процессов всех проектов выполняются измерения продуктивности и качества, как часть организационной программы измерений. Для сбора и анализа данных, получаемых от производственных процессов отдельных проектов, используется корпоративная база данных по производственным процессам. Производственные процессы уровня 4 оснащены инструментальными средствами для проведения точно определенных и согласованных измерений.

Эти измерения формируют количественную основу для оценки продуктов и производственных процессов проектов.

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

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

Уровень 5 — оптимизирующий уровень Находясь на оптимизирующем уровне, вся организация полностью сосредоточена на непрерывном усовершенствовании производственного процесса. Организация обладает средствами профилактического выявления слабых мест процесса и его улучшения с целью предотвращения появления дефектов. Данные по эффективности производственного процесса используются для выполнения стоимостного анализа новых технологий и предлагаемых изменений производственного процесса организации. Выявляются новшества, использующие наилучшие методы программной инженерии, которые затем распространяются на всю организацию в целом.

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

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

Всего СММ определяет следующий минимальный набор требований: реализовать 18 ключевых областей процесса разработки ПО, содержащих 52 цели, 28 обязательств выполнения, 70 возможностей выполнения и 156 ключевых практик.

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

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

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

программный обеспечение разработка стандарт

4. Количественное управление процессом. Метрология производственного процесса

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

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

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

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

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

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

Одним из стандартов используемым для измерения качества ПО является стандарт ISO/IEC 9126, в котором даются некоторые критерии качества, а также представлены формализованные метрические показатели этих критериев.

5.1 Основные классы метрик

5.1.1 Основные направления формирования метрик для оценки компьютерных программ

В исследовании метрик ПО различают два основных направления :

· поиск метрик, характеризующих наиболее специфические свойства программ, т. е. метрик оценки самого ПО

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

По виду информации, получаемой при оценке качества ПО метрики можно разбить на три группы :

· метрики, оценивающие отклонение от нормы характеристик исходных проектных материалов. Они устанавливают полноту заданных технических характеристик исходного кода.

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

· метрики, по которым принимается решение о соответствии конечного ПО заданным требованиям. Они позволяют оценить соответствие разработки заданным требованиям.

В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям :

· оценки топологической и информационной сложности программ;

· оценки надежности программных систем, позволяющие прогнозировать отказовые ситуации;

· оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования;

· оценки уровня языковых средств и их применения;

· оценки трудности восприятия и понимания программных текстов, ориентированные на психологические факторы, существенные для сопровождения и модификации программ;

· оценки производительности труда программистов для прогнозирования сроков разработки программ и планирования работ по созданию программных комплексов.

Согласно стандарту ISO 9126 все метрики можно разделить на 3 группы:

· категорийные (описательные, номинальные) метрики предназначены для «измерения» функциональных возможностей программных средств

· количественные метрики применимы для измерения надежности и эффективности сложных комплексов программ

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

5.1.2 Метрические шкалы

В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы.

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

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

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

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

5.2 Программометрика

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

Новые научное и прикладное направление, возникшее в информатике всего два десятилетия назад — метрическая теория программ (программометрика), обеспечило значительное продвижение в решении некоторых из этих проблем.

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

Современное состояние программометрики позволяет с удовлетворительной для практики точностью решать следующие задачи:

· количественный анализ возможности и целесообразности разработки автоматизированных процедур и функций ИС в заданной постановке;

· численная оценка основных параметров будущего ПС (объем, количество модулей, уровней иерархии, надежность в начальный период эксплуатации) на основе постановок задач;

· планирование и управление разработкой ПС, оценка трудоемкости его создания, технико-экономическое обоснование;

· решение вопросов, связанных с метрологией качества ПС.

5.2.1 Примеры стандартных метрик

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

· NUOprtr (Number of Unique Operators) — число уникальных операторов программы, включая символы — разделители, имена процедур и знаки операций (словарь операторов);

· NUOprnd (Number of Unique Operands) — число уникальных операндов программы (словарь операндов);

· Noprtr (Number of Operators) — общее число операторов в программе;

· Noprnd (Number of Operands) — общее число операндов в программе.

Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М. Холстед вводит следующие оценки:

· словарь программы (Halstead Program Vocabulary) HPVoc = NUOprtr + NUOprnd;

· длина программы (Halstead Program Length) HPLen = Noprtr + Noprnd;

· объем программы (Halstead Program Volume) HPVol = HPLen log2 HPVoc.

Далее Холстед вводит оценку сложность программы (Halstead Difficulty), которая вычисляется как

HDiff = NUOprtr/2* (NOprnd / NUOprnd)

Используя HDiff Холстед вводит оценку HEff (Halstead Effort):

HEff = HDiff* HPVol, с помощью, которой описывается усилия программиста при разработке.

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

Для вычисления цикломатического числа Маккейба CC (Cyclomatic Complexity) применяется формула:

CC = L — N + 2P,

где L — число дуг ориентированного графа;

N — число вершин;

P — число компонентов связности.

К метрикам сложности также относится:

· NORM (Number of Remote Methods) — количество вызываемых удаленных методов. При формировании значения этой метрики просматриваются все конструкторы и методы класса, и подсчитывается количество вызываемых удаленных методов. Удаленным методом является метод, который не определен в классе и его родителях.

· RFC (Response for Class) — отклик на класс — количество методов, которые могут вызываться экземплярами класса. Эта метрика вычисляется как сумма количества локальных методов и количества удаленных методов.

· WMPC1 (Weighted Methods per Class 1) — взвешенная насыщенность класса — дает относительную меру его сложности; если считать что все методы имеют одинаковую сложность, то это будет просто число методов в классе. Эта метрика определяется суммой сложности всех методов класса, где каждый метод взвешивается подсчетом его цикломатического числа. Количество методов и их сложность связаны для определения времени и усилий, которые потребуются для разработки и поддержки класса. Вообще, класс, который имеет большее количество методов среди классов одного с ним уровня, является более сложным; скорее всего, он специфичен для данного приложения и содержит наибольшее количество ошибок. Для расчета данной метрики используются только методы определенные в конкретном классе, все методы, наследуемые от родительского класса, не включаются.

· WMPC2 (Weighted Methods per Class 2). Эта метрика является мерой сложности класса, полагающая, что класс с большим количеством методов, чем другой, является более сложным, и что метод с большим количеством параметров также является более сложным. Для расчета данной метрики используются только методы определенные в конкретном классе, все методы, наследуемые от родительского класса, не включаются.

· LOCOM1 (Lack of Cohesion of Methods 1) — недостаток связности методов. Связность — это степень взаимодействия между элементами отдельного модуля, характеристика его насыщенности.

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

Для каждой пары методов класса определяется набор полей, к которым они имеют доступ. Если множество полей имеет доступ к непересекающемуся множеству полей класса, то число P увеличивается на 1. Если оба метода используют хотя бы одно общее поле, то параметр Q увеличивается на 1. После рассмотрения каждой пары методов результат вычисляется как RESULT = (P > Q)? (P — Q): 0. Высокое значение этой метрики говорит о высокой связности методов — это означает, что потребуются большие усилия при тестировании этих методов, так как методы могут воздействовать на одни и те же атрибуты класса. Это также говорит о низкой готовности к повторному использованию. Метрика была определена Чидамбером и Кемерером (Chidamber & Kemerer) в 1993.

· LOCOM2 (Lack of Cohesion of Methods 2) — связанность методов — мера насыщенности абстракции. Класс, который может вызывать существенно больше методов, чем равные ему по уровню классы, является более сложным. У класса с низкой связанностью можно подозревать случайную или неподходящую абстракцию: такой класс должен быть переабстрагирован на несколько классов или его обязанности должны быть переданы другим существующим классам. Метрика подсчитывает процентное отношение методов, не имеющих доступа к специфичным атрибутам класса ко всем атрибутам данного класса.

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

· LOCOM3 (Lack of Cohesion of Methods 3) — измеряет степень различия методов в классе по атрибутам.

Рассмотрим множество методов M1, M2, …, Mm. Эти методы имеют доступ к набору атрибутов данных класса A1, A2, …, Aa. Положим a (Mk) = число атрибутов с которым работает метод Mk, а m (Ak) = число методов которые имеют доступ к атрибуту Ak. Тогда LOCOM3 = (1/a * SUM1a (m (Ai)-m))/(1-m)*100. Низкое значение этой меры говорит о хорошей декомпозиции в классе выражаемой в его простоте и понятности и готовности к повторному использованию. Высокое значение отсутствия связности увеличивает сложность, повышает вероятность ошибок в процессе разработки.

Данная метрика была предложена Хендерсоном-Шеллером в 1995.

В эту группу метрик также попадают базовые метрики:

· LOC (Lines Of Code) — количество строк кода

· NOC (Number Of Classes) — количество классов Улучшение значений метрических характеристик из этой группы говорит о положительном эффекте от применения оптимизирующего метода/подхода. Например, уменьшение значений метрик Холстеда, цикломатической сложности говорит о том, что полученная реализация в целом лучше по соображениям топологической сложности. Уменьшение уровня связности, взвешенности метода на класс или отклика класса говорит об улучшенной функциональной декомпозиции. Уменьшение количества строчек кода также говорит о положительном эффекте, если ту же функциональность можно изложить при помощи нового улучшающего подхода за меньшее количество строк.

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

Уровень языковых средств и их применения:

Одним из следствий субъективного представления об «уровне» алгоритмического языка явилась разработка в предыдущие десятилетия невероятно большого количества языков программирования, их версий и т. п. В программистском сообществе сформировалось стойкое убеждение, что возможно создание такого языка «высокого» или «сверхвысокого» уровня, который позволит осуществить прорыв в технологии производства ПС.

В начале 80-х годов Холстед ввел формальное определение уровня языка программирования, определив последний как

= L2V,

где L — уровень реализации программы, а V — ее объем.

Статистические исследования, проведенные на огромном фактическом материале, показали, что величина действительно зависит только от конкретного языка программирования и практически не зависит от объема программы, так как

Иными словами, =const в пределах одного и того же языка.

5.3 Алгоритм формирования метрик

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