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

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Факультет переподготовки специалистов по математике и информатике

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

Дипломная работа слушателя

Веревкина Константина Владимировича

Содержание

1.       Введение

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

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

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

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

.1.2    Структура серии ISO 9000

.2       Стандарт ISO 9126 (1-4)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.2.2    Режимы модели COCOMO

.2.3    Уровни модели COCOMO

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

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

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

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

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

.3       Модель COCOMO II

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

.5       Вывод

.        Заключение.

Литература.

 

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

.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 10001 - 10020, в том числе все их части;

·        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 заключается в том, что модели Обеспечения Качества не были разработаны для какой-либо специфической области - они предназначены для применения во всех областях промышленности и для всех стран.

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

) ISO 9001

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

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

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

2) ISO 9002

Название: “Система Качества: Модель обеспечения качества при производстве, монтаже и обслуживании”.9002 применим в договорной ситуации когда:

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

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

) ISO 9003

Название: “Система Качества: Модель обеспечения качества при окончательном контроле и испытаниях”.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 12207), к которым применима метрика.

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

Уровень 2 - повторяемый уровень

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

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

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

Уровень 3 - определенный уровень

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

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

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

Уровень 4 - управляемый уровень

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

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

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

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

Уровень 5 - оптимизирующий уровень

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

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

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

Всего СММ определяет следующий минимальный набор требований: реализовать 18 <file:///D:\Documents\Лекции(10-я%20линия)\Тема09\(№08-1)КлючТребованияСММ.doc> ключевых областей процесса разработки ПО, содержащих 52 <file:///D:\Documents\Лекции(10-я%20линия)\Тема09\(№11)ЦелиКОП.doc> цели, 28 обязательств выполнения, 70 возможностей выполнения и 156 <file:///D:\Documents\Лекции(10-я%20линия)\Тема09\(№13)ПереченьДействий.doc> ключевых практик.

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

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

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

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

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), которая вычисляется как

= NUOprtr/2* (NOprnd / NUOprnd)

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

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

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

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

 = L - N + 2P,

где L - число дуг ориентированного графа;- число вершин;- число компонентов связности.

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

·      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-х годов Холстед ввел формальное определение уровня языка программирования, определив последний как

l = L2V,

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

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

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

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

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

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

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

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

3.       Исследование характеристик и связанных метрик, для определения корреляции, значимости, степени автоматизируемости.

.        Исследование корреляции между метриками, степени перекрытия, зависимости и недостатков.

.        Рафинирование множества метрик в целом во множество метрик, которые в совокупности адекватно отражают качество программного обеспечения.

.        Корректировка каждой метрики в итоговом множестве в контексте зафиксированных множеств характеристик и метрик.

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

Рис. 5.1. Дерево характеристик качества

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

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

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

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

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

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

Примерами метрик могут служить следующие показатели:

·        Метрики менеджмента:

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

o   Время разработки (Time-to-market). Мера времени от формирования заказа на программу до поставки. При итерационной разработке данная метрика модифицируется для измерения времени, требуемого для поставки заданного объема приращения функциональности, то есть скорости поставки.

o   Среда разработки (Software Engineering Environment). Процент целевых компьютерных ресурсов, используемых системой.

o   Использование системных ресурсов (System Resource Utilization). Мера способности производителя разрабатывать программное обеспечение высокого качества. Данная метрика может быть выражена в терминах модели «Software Acquisition Capability Maturirty Model» (SA - СММ)

Указанные метрики могут использоваться на этапах планирования и контроля проектов и других задач управления или использоваться в качестве параметров управления штатной ERP системы.

·        Метрики требований:

o   Соответствие требованиям (requirement conformance)

o   Стабильность требований (requirement stability)

o   Изменяемость требований(Requirement Convertibility)

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

·        Метрики качества ПП/ПС в целом:

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

o   Сложность интерфейсов и интеграции (complexity of interfaces and integration). Метрика, измеряющая степень сложности интерфейса или дополнительного программирования требуемого для интеграции компоненты в систему, которые требуются для тестирования, отладки и сопровождения, компенсирующего потерю качества.

o   Тестовое покрытие (test coverage). Степень полноты различных типов тестирования.

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

o   Профили ошибок (fault profiles). Метрика, измеряющая кумулятивное число обнаруженных ошибок.

o   Степень удовлетворения потребностей заказчика (customer satisfaction). Метрика, оценивающая степень соответствия программного обеспечения ожиданиям и требованиям заказчика. Данная метрика может быть оценена перед поставкой на этапе опытной эксплуатации на основе прогнозирующих параметров.

·        Метрики качества программного кода, выводимые из требований:

· Гибкость (flexability), которая аккумулирует ряд свойств:

o      Модульность (Modularity)

o   Изменяемость (Changeability)

o   Сопровождаемость (Maintainability)

· Адаптивность (adaptability), которая подразумевает:

o      Настраиваемость (customizability)

o   Переносимость (Portability)

o   Способность к взаимодействию (Interoperability)

Как правило, единственным доступным механизмом определения «ожиданий заказчика» являются требования (software requirement specifications). Требования Технического задания определяют функции программного обеспечения и нефункциональные требования, такие как производительность, надежность и т.п. Нетехнические требования, такие как цена, сроки поставки утверждаются в контрактных документах.

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

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

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

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

В процессе инжиниринга программных систем в дополнение к классическим метрикам должны быть включены в число наиболее важных такие метрики качества объектно-ориентированного дизайна как: надежность (reliability), сложность (complexity) и возможность повторного использования (reusabiblity).

При измерении факторов качества широко используется модель: фактор - критерий - измерение (factor - criteria - measurement). Установка связи фактор - критерий требует анализа составляющих факторов качества. Например:

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

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

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

Рис. 5.5. Модель: Фактор-Критерий-Метрика

В соответствии с анализом, каждому фактору ставятся в соответствие критерии и, далее, метрики для измерения критериев (рис. 5.5).

Далее конкретные метрики выводятся в соответствии с особенностями проекта из критериев качества: accuracy (точность), completeness (полнота), consistency (согласованность), module size (размер модулей), data coupling (связь модулей по данным), cohesion (связность), modularity (модульность), span of control (норма управляемости).

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

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

В качестве примера использования метрик я рассмотрел технологию оценки трудозатрат при разработке ПО в соответствии с международной моделью COCOMO(Constructive Cost Model).

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

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

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

Под термином «трудозатраты» в процессе разработки ПО подразумевается объем работ, который необходимо сделать для достижения какой-то цели. Эта величина может быть выражена разными единицами измерения. В качестве стандарта используются человеко-часы, человеко-дни, или, наиболее часто, человеко-месяцы.

Типичные ориентиры, используемые для оценки трудозатрат, как правило, включают следующее:

·   Задачи, выполняемые в будущем

o   Задачи по разработке ПО(проект, код, тестирование)

o   Дополнительные задачи по разработке(требования, система)

o   Задачи поддержки(CM, QA, менеджмент)

o   Задачи, требующие дополнительных трудозатрат(документы и т.д.)

·   Дополнительные денежные затраты(поездки, оборудование и т.д.)

·        Оценка размера ПО

·        Хронологические данные по трудозатратам и производительности

·        График высокого уровня

·        Процесс и методы

·        Языки программирования

·        ОС для целевой системы

·        Используемые инструменты

·        Уровень профессионального опыта

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

Типичные значения производительности:

·   50 - 300 SLOC/месяц для языков высокого уровня

·        60 - 500 SLOC/месяц для языков ассемблера

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

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

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

На рис. 6.1. показаны общие этапы оценивания

Рис. 6.1. Этапы оценивания.

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

Модель конструктивных затрат(Constructive Cost Model) относится к числу наиболее широко применяемых технологий оценивания. Основанная на регрессии модель была разработана Барри Б. Боэмом в начале 1970 годов. Было анализировано 63 программных проекта различных типов. При этом оценивался фактический размер(LOC), понесенные трудозатраты, а также фактическая длительность разработки ПО.

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

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

Метод регрессии обладает следующими признаками.

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

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

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

В линейных моделях значения параметра вычисляется по формуле ax+b, где a и b константы. Для их определения используется метод наименьших квадратов.

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

В модели COCOMO используются 3 режима, с помощью которых классифицируется сложность системы, а также среды разработки.

Рис. 6.2 Режимы модели COCOMO

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

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

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

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

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

·        Промежуточный уровень. На этом уровне используются сведения о размере, режиме и 15 дополнительных параметров для определения необходимых трудозатрат. Дополнительные переменные называются драйверами затрат и имеют отношение к атрибутам продукта, персонала, компьютера и проекта, которые могут влиять на конечные трудозатраты. Произведение драйверов затрат называется корректировочным множителем среды(Environmental adjustment factor, EAF).

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

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

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

Входная переменная, используемая для оценки трудозатрат - количество строк кода KLOC. Для вычисления трудозатрат, выраженных в человеко-месяцах, используется следующая экспоненциальная формула:

Трудозатраты Е = a * (размер)b,

где а и b - константы, определенные на этапе регрессивного анализа(в зависимости от проекта), размер - тысячи строк кода(KLOC).

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

Таблица 6.1. Базовые формулы оценки необходимых для разработки времени и трудозатрат в модели СОСОМО

Режим	a	B	Формула для оценки трудозатрат a * (размер)b	Формула для определения времени разработки, месяцы
Органический	2.4	1.05	Е = 2.4 * (размер)1.05	TDEV = 2,5 * (E)0.58
Сблокированный	3.0	1.12	Е = 3.0 * (размер)1.12	TDEV = 2,5 * (Е)0.35
Внедренный	3.6	1.2	Е = 3.6 * (размер)1.2	TDEV = 2,5 * (Е)0.32

Очень просто можно определить среднюю численность персонала:

 = Е / TDEV

и производительность:

 = размер / трудозатраты.

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

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

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

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

Кроме показателя KLOC входными данными в этом случае являются значение драйверов затрат:

Трудозатраты(Е) = a * (размер)b * С,

где С - фактор корректировки трудозатрат (Effort adjustment factor, EAF)

 = C1 * C2 * … * Cn

 = 1 - драйвер затрат не применим

Ci > 1 - драйвер увеличивает затраты

Ci < 1 - драйвер уменьшает затраты

Таблица 6.2. Формулы для оценки трудозатрат в промежуточной модели СОСОМО

Режим	a	b	Формула для оценки трудозатрат a * (размер)b
Органический	3.2	1.05	Е = 3.2 * (размер)1.05 * С
Сблокированный	3.0	1.12	Е = 3.0 * (размер)1.12 * С
Внедренный	2.8	1.2	Е = 2.8 * (размер)1.2 * С

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

Драйверы затрат группируются в виде четырех категорий, как показано в табл. 6.3.

Таблица 6.3. Категории драйверов затрат в промежуточной модели COСOMO

Программный продукт	Компьютер	Персонал	Проект
Требуемая надежность ПО (RELY)	Ограничения времени выполнения (TIME)	Способности аналитика (АСАР)	Использование практики современного программирования (MODR)
Размер базы данных (DATA)	Ограничения основного хранилища (STOR)	Опыт в создании приложений (АЕХР)	Использование инструментов разработки ПО (TOOL)
Сложность программного продукта (CPLX)	Изменяемость виртуальной машины (VIRT)	Способности программиста (РСАР)	План требуемой разработки (SCED)
	Оборотное время компьютера (TURN)	Опыт в области виртуальных машин (VEXP)
		Опыт в области языков программирования (LEXP)

Атрибуты программного продукта

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

·   требуемая надежность - как правило, применяется в системах реального времени;

·        размер базы данных - в основном применяется в приложениях обработки данных;

·        сложность продукта - ограничения на время выполнения.

Атрибуты, связанные с аппаратными средствами

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

·   ограничения времени выполнения - применяются в том случае, когда быстродействие процессора является ограниченным;

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

·        изменяемость виртуальной машины - включает аппаратное обеспечение и операционную систему на целевом компьютере;

·        оборотное время компьютера - применяется при разработке.

Атрибуты проекта

Атрибуты, связанные с практикой и инструментами:

·   практика современного программирования - структурные или ОО-технологии;

·        современные инструменты программирования- CASE-инструменты, хорошие отладчики, инструменты, используемые при выполнении тестирования;

·        сжатие (или расширение) графика- отклонение от идеала всегда удручает, но меньшая степень отклонения всегда лучше, чем большая.

Атрибуты персонала

Некоторые атрибуты применяются для описания исполнителей работ:

·   способности аналитика;

·        опыт в создании приложений;

·   способности программиста;

·        опыт в области виртуальных машин, включая операционную систему и аппаратное обеспечение;

·        опыт в области языков программирования, включая инструменты и практику.

Другие драйверы затрат

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

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

·        изменяемость машины, предназначенной для разработки - нестабильные ОС, компиляторы, CASE-инструменты и т.д.;

·        требования безопасности - применяются для классифицированных программ;

·        доступ к данным - иногда является весьма затрудненным;

·        влияние стандартов и навязанных методов;

·        влияние физического окружения.

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

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

Поскольку драйверы затрат являются мультипликативными, в случае, если драйвер затрат не влияет на трудозатраты, его значение равно 1. При этом конечное значение C не изменяется. Подобные драйверы затрат называются нормальными либо "номинальными". Например, если опыт в области языков программирования (LEXP) команды в рассматриваемой организации больше, чем аналогичный показатель в любой другой организации в этом городе, значение LEXP будет оставаться равным 1. Это связано с тем, что превосходящие способности в области языков программирования нормируются в данной среде. Оценщик может выполнять поиск условий, при наступлении которых возрастает показатель трудозатрат (произведение всех драйверов затрат превышает 1) либо значение этого показателя уменьшается (произведение всех драйверов затрат меньше 1). При поиске применяется критерий «обычности» для данной среды. Как правило, объем трудозатрат увеличивается в случае, если применяется новая технология, команда разработчиков только что сформирована либо состоит из неопытных в данной области программистов, имеет место повышенная сложность технологической проблемы либо имеют место другие условия, отличные от стандартных. Если же требуется меньше трудозатрат, то это означает, что подобные проблемы были успешно разрешены ранее.

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

В качестве практической реализации метрики я разработал приложение (приложение 1 <COCOMOCalc.xls>), которое позволяет оценить в рамках модели COCOMO характеристики проекта на ранних стадиях жизненного цикла: значение EAF(Effort adjustment factor), оценки трудозатрат (в человеко-месяцах), а также ожидаемую продолжительность проекта и среднюю производительность работы персонала. Входными данными являются размер проекта в KLOC и соответствующие драйверы затрат. Также приведены комментарии для каждого драйвера и возможных принимаемых значений.

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

Драйвер затрат	Множитель	Примечание
Атрибуты программного продукта
Требуемая надежность ПО (RELY)	выберите из списка
номинальный	1,00	Средние возмещаемые потери
	1,00
Размер базы данных(DATA)	выберите из списка
высокий	1,08	100<БД байт/прог. SLOC<1000
	1,08
Сложность программного продукта(CPLX)	выберите из списка	Сложность вычислительных операций
высокий	1,15	Базовый числовой анализ: многомерная интерполяция, обычные дифференциальные уравнения, базовые операции усечения/округления
	1,15
Атрибуты компьютера
Ограничения времени выполнения(TIME)	выберите из списка
номинальный	1,00	Используется<=50% доступного времени выполнения
	1,00
Ограничение главного хранилища(STOR)	выберите из списка
высокий	1,06	Используется 70% доступного хранилища
	1,06
Изменяемость виртуальной машины(VIRT)	выберите из списка
высокий	1,00	Изменения: верхние 6 мес, нижние 2 нед
	1,00
Оборотное время компьютера(TURN)	выберите из списка
номинальный	1,00	Средний обход(<4 часов)
	1,00
Атрибуты персонала
Способности аналитика(ACAP)	выберите из списка
высокий	0,86	75-й процентиль
	0,86
Опыт в создании приложений(AEXP)	выберите из списка
номинальный	1,00	3 года
	1,00
Способности программиста(PCAP)	выберите из списка
номинальный	1,00	55-й процентиль
	1
Опыт в области виртуальных машин(VEXP)	выберите из списка
номинальный	1,00	1 год
	1
Опыт в области языков программирования(LEXP)	выберите из списка
номинальный	1,00	1 год
	1,00
Атрибуты проекта
Использование практики современного программирования(MODP)	выберите из списка
высокий	0,91	Общее использование
	0,91
Современные инструменты программирования(TOOL)	выберите из списка
низкий	1,10	Базовые мини-инструменты
	1,10
Требуемый график разработки(SCED)	выберите из списка
номинальный	1,00	100% номинала
	1,00
	Итого: C =	1,133
Число строк кода(KLOC):	10
Трудозатраты (человеко-месяцы):
Органический режим	Сблокированный режим	Встроенный режим
40,69	44,82	50,29
Длительность проекта (мес.)
10,58	11,35	12,78
Производительность(SLOC/чел-мес)
245,75	223,11	198,83

Если, например, проект сблокированного режима, то получаем трудозатраты 44.82 чел/мес. Для сравнения, в базовой модели COCOMO трудозатраты будут соответственно 39.56 чел/мес. Если при выполнении проекта привлечь более квалифицированный персонал, увеличив, соответственно PCAP и LEXP с номинальных значений до высоких, трудозатраты будут равны 36.62 чел/мес. Если при этом затраты на персонал возрастают с $1700 до $2000 на чел/мес., то разница в затратах будет следующая:

,82 чел/мес. * $1700 / чел/мес. = $76194

.62 чел/мес. * $2000 / чел/мес. = $73240

Разница равна $2954.

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

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

Хотя рассмотренные 15 драйверов затрат способствуют лучшему использованию сред, в которых отсутствуют либо оказывают незначительное влияние хронологические данные, они не могут применяться одинаковым образом в нескольких организациях либо даже в одной организации на протяжении длительного периода времени. Данные из 63 оригинальных проектов Боэма могут применяться до тех пор, пока не будут собраны фактические данные. После того как станут доступными фактические данные, с их помощью будут изменены исходные данные, а модель будет калиброваться до тех пор, пока она не будет полностью соответствовать данному типу приложения и данной организационной среде либо среде и приложению одновременно. Многие производители поддерживают автоматизированные инструменты, предназначенные для выполнения оценок, имеющих заданные размер и сложность. Многие из этих инструментов обеспечивают автоматизированную поддержку добавления фактических данных и калибровку модели путем изменения показателя, коэффициента, значений драйвера затрат либо всех трех параметров одновременно. Калиброванная модель может быть создана путем использования пяти точек данных (проект, для которого определяются размеры, временной период, а также трудозатраты, которые являются наблюдаемыми).

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

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

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

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

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

Анализ драйверов затрат производится отдельно для каждого компонента. Подсистемы и модули наследуют драйверы затрат системы. Они называются: RELY, VIRT, TURN, MODP, TOOL и SCED. Модули наследуют драйверы затрат подсистемы. Эти драйвера называются: DATA, TIME, STOR, АСАР, АЕХР (проявляется тенденция к применению одних и тех же модулей внутри подсистемы). Драйверы затрат модуля имеют такие названия: KLOC, AAF, CPLX, PCAP, VEXP и LEXP. Драйвер AAF является новым - результат адаптации существующих модулей. Дополнительная информация доступна до этапа изменения существующего ПО - благодаря этим данным обеспечиваются более корректные оценки. Как правило, большинство создаваемых программных продуктов не разрабатываются "с нуля", а являются результатом повторного использования существующих модулей, реализуемых с помощью новейших методов (например, объектно-ориентированных). Использование детализированной модели СОСОМО зачастую эквивалентно дополнительным трудозатратам. Следует отметить, что затраты на этапе повторного использования не всегда равны нулю. Ведь не обойтись без трудозатрат на этапе работы с существующим кодом и разработки соответствующего интерфейса. Затраты на переписывание системы могут быть меньшими, чем продолжение ее поддержки (по причине энтропии структуры). Однако переписывание старой системы может быть более дорогостоящим, чем создание "новой" системы. Распространено мнение, согласно которому точка экономической безубыточности достигается в результате изменения 20% кода; после прохождения точки безубыточности повторное использование кода не будет эффективным.

Действия по разработке проекта разбиваются на фазы. В работах Боэма (Boehm) используются четыре основных фазы: требования (RQ), разработка проекта продукта (PD), детализированный дизайн продукта (DD), кодирование и тестирование разрабатываемого модуля (CUT). Интеграция и тестирование (IT), а также поддержка (MN) описываются на протяжении всего жизненного цикла. Фазы могут применяться для разбиения систем, подсистем, и/или модулей. На каждой фазе могут применяться различные множители трудозатрат. Различные значения множителей драйверов затрат устанавливаются на каждом из трех уровней иерархии программных продуктов (система, подсистема, модуль), а также на каждой фазе (RPD, DD, CUT, IT) внутри иерархий.

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

Ниже перечислены преимущества модели СОСОМО:

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

·        применяемый в данном случае процесс является повторяемым;

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

·        он является достаточно универсальным и может поддерживать различные "режимы" и "уровни";

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

·        возможна высшая степень калибровки с опорой на предыдущий опыт;

·        обязательная документация;

·        простота в применении.

Ниже перечислены недостатки модели СОСОМО:

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

·        игнорируется документация и другие требования;

·        игнорируются атрибуты заказчика - навыки, кооперирование, знания и способность к реагированию;

·        слишком упрощается влияние вопросов безопасности;

·        игнорируются проблемы обеспечения безопасности ПО;

·        не учитывается среда разработки ПО;

·        игнорируются уровни взаимодействия персонала;

·        игнорируются многие вопросы, связанные с аппаратным обеспечением

·        все уровни зависят от оценки размера - точность оценки размера влияет на точность оценки трудозатрат, времени разработки, подбор персонала и оценку производительности;

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

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

Также в этой модели исключаются следующие компоненты:

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

· менеджмент (обычно выполняется менеджмент на уровне строк, а не общий менеджмент);

· накладные расходы;

·        расходы на командировки и другие побочные расходы;

·        системная интеграция и поддержка тестирования;

·        поддержка тестовых полей;

·        компьютеры;

·        источники поставок;

·        определенное место в офисе.

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

При использовании модели СОСОМО предполагается наличие очень простого базового уровня трудозатрат, используемого при управлении конфигурацией и обеспечении качества. В этом случае используется примерно 5% общего бюджета (основываясь на типичной коммерческой практике, принятой при использовании модели СОСОМО). Показатели затрат могут быть увеличены в 2-4 раза при разработке современного ПО с учетом сложности современных программных продуктов.

Согласно Боэму (Boehm), трудозатраты изначально были распределены таким образом, чтобы 30% приходилось на дизайн, 30% на кодирование и тестирование модуля, а 40% на интеграцию и тестирование.

Рис. 6.3 Фазы, включенные в модель COCOMO.

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

6.3     Модель COCOMO II

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

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

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

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

В композиционной прикладной модели СОСОМО II для выполнения оценок применяется метод объектных точек. При использовании этой модели предполагается использование интегрированных CASE-инструментов с целью выполнения быстрого прототипирования. Объекты включают экраны, отчеты и модули, имеющие отношение к языкам программирования третьего поколения. Оценивается количество физических объектов, сложность каждого объекта, а также вычисляется взвешенный итог (подсчитывается количество объектных точек). Также оценивается процентное соотношение показателей повторного использования и ожидаемой производительности. На основе этой информации может выполняться оценка трудозатрат.

В модели СОСОМО II явным образом обеспечивается доступ к дополнительной информации на поздних стадиях проекта, обрабатываются нелинейные затраты при повторном использовании программных компонентов, а также оцениваются эффекты воздействия нескольких факторов по шкале показателей убытков. Некоторые из перечисленных параметров представляют собой оценку оборота персонала, географическое распределение команды, а также "зрелость" процесса разработки в том виде, в котором она описывается Институтом SEI. В этой модели также проверяются некоторые значения коэффициента, и устраняется присутствие "сосредоточенных неоднородностей" в старой модели (связанных с "режимами разработки", поддержкой и адаптацией).

Фактически СОСОМО II включает три различные модели.

·   Композиционная прикладная модель - эта модель подходит для проектов, созданных с помощью современных инструментальных средств, применяемых для «строительства» GUI. Модель основывается на новых объектных точках.

·        Модель ранней разработки проекта - Эта модель применяется для получения приближенных оценок проектных затрат и периода выполнения проекта перед тем, как будет определена архитектура в целом. В этом случае используется небольшой набор новых драйверов затрат и новых уравнений оценки. Также в качестве базы используется набор не настраиваемых функциональных точек либо KSLOC.

·        Пост-архитектурная модель - наиболее детализированная модель СОСОМО II, которая используется после разработки общей архитектуры проекта, В состав этой модели включены новые драйверы затрат, новые правила подсчета строк, а также новые уравнения.

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

Применяется также другая математическая модель оценивания, называемая менеджментом жизненного цикла разработки ПО (Software Lifecycle Management, SLIM). Этот инструмент имеет отношение к QSM. Благодаря использованию модели SLIM специалист по оценке может использовать анализ линейного программирования, в котором рассматриваются ограничения разработки, имеющие отношение к затратам (трудозатратам), и поддерживается помесячное распределение трудозатрат и проверка совместимости для данных, имеющих отношение к программным системам одного размера.

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

размер = С * К1/3 * td4/3

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

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

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

6.5     Вывод

Рис. 6.4. Неопределенность оценок в зависимости от стадии

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

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

7. Заключение

В данной работе были рассмотрены основные принципы реализации качества при разработке ПО. Для обеспечения высокой эффективности и качества при производстве ПО было разработано множество стандартов. В этой работе были рассмотрены стандарты серии ISO9000, ISO9126 и CMM. На сегодняшний день многие IT компании сертифицированы стандартом ISO9000. Несмотря на высокий уровень абстракции, он дает набор практик для реализации документированного процесса на предприятии. Это не конечная цель, а скорее база для дальнейшего развития. Стандарт CMM в большей степени ориентирован на производителей ПО. В рамках CMM вводится понятие 5 уровней зрелости процесса - начальный, повторяемый, определенный, управляемый и оптимизирующий, каждый из которых включает свои определенные характеристики.

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

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

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

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

Литература

1.       Метрики качества программного обеспечения <http://www.pmprofy.ru/content/rus/67/672-article.asp>

2.   Круглов М.Г., Сергеев С.К., Шишков Г.М. и др. Менеджмент систем качества. Учебн. пособие - М.: ИПК, Изд-во стандартов, 1997.

.     Р.Фатрелл, Д.Шафер, Л.Шафер. Управление программными проектами: достижение оптимального качества при минимуме затрат - М., «Вильямс», 2003

4.       М.Кантор. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения - М., «Вильямс», 2002.

.        В.В.Липаев. Обеспечение качества программных средств - М., «Синтег», 2001.

6.   Свиткин М.З., Мацута В.Д., Рахлин К.М. Менеджмент качества и обеспечение качества продукции на основе международных стандартов ИСО.- С-Пб. Изд-во ВСЕГЕИ, 1999

7.       С. Макконнелл. Совершенный код - С-Пб. Изд-во «Питер», 2007

8.       Guidelines: Metrics <http://sux.csu.ac.ru/proxy/000000A/ftp/www.csu.ru/pub/dwl/Unified_v2000.02.10.149/RationalUnifiedProcess2000/copyrite/copyrite.htm>

9.   Международный стандарт ISO 9000-3. Стандарты в области административного управления качеством и обеспечения качества. - Часть 3. Руководящие указания по применению стандарта ISO 9001-94 при разработке, поставке, установке и обслуживания компьютерного программного обеспечения. - ISO 9000-3: (1991 г.), 1997г.

10. The Capability Maturity Model. Guidelines for Improving the Software Process - Carnegie Mellon University, Software Engineering Institute. 2000

11.     Оценка факторов, влияющих на качество программных продуктов <http://www.osp.ru/cio/2001/11-12/171992/>

.        Программометрика <http://www.fb.nstu.ru/~kafedra_ei/Metod/Programm.doc>

.        Software Engineering Baselines <http://www.dacs.dtic.mil/techs/baselines/productivity.html>

.        Modern Empirical Cost and Schedule Estimation Tools <http://www.dacs.dtic.mil/techs/estimation/comparison.shtml>

.        Software cost estimation www.comp.lancs.ac.uk/computing/resources/IanS/SE7/SampleChapters/ch26.pdf <http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/SampleChapters/ch26.pdf>