Содержание - Лаборатория ITLab
реклама
Министерство образования Российской Федерации Нижегородский Государственный Университет им. Лобачевского Факультет Вычислительной Математики и Кибернетики Проект ННГУ – “ТЭЛМА” Метрики качества программных проектов Выполнили: Теплова Н.Г. Иванов А.О. Проверил: Карпенко С.Н. Нижний Новгород 2004 Содержание 1. ВВЕДЕНИЕ ....................................................................................................................................................... 3 2. ПОНЯТИЕ КАЧЕСТВА ................................................................................................................................ 4 2.1.ОПРЕДЕЛЕНИЕ КАЧЕСТВА ................................................................................................................................... 4 2.2. МНОГОМЕРНОСТЬ КАЧЕСТВА ............................................................................................................................ 4 2.3. ИДЕНТИФИКАЦИЯ И КЛАССИФИКАЦИЯ ХАРАКТЕРИСТИК КАЧЕСТВА ............................................................... 5 2.4. ЦЕНА КАЧЕСТВА ................................................................................................................................................ 7 3. КАЧЕСТВО ПРОЦЕССА РАЗРАБОТКИ ................................................................................................... 9 3.1. КАЧЕСТВО ПРОЦЕССА И КАЧЕСТВО ПРОДУКТА ................................................................................................. 9 3.2. ИЗМЕРЕНИЕ КАЧЕСТВА ПРОЦЕССА .................................................................................................................. 10 3.2.1. ISO 9001 .................................................................................................................................................. 10 3.2.2. CMM ........................................................................................................................................................ 11 3.2.3. SPICE....................................................................................................................................................... 14 4. КАЧЕСТВО ПРОГРАММНОГО ПРОДУКТА ........................................................................................ 17 4.1. МЕТРИКИ МЕНЕДЖМЕНТА ............................................................................................................................... 18 4.2. МЕТРИКИ ТРЕБОВАНИЙ.................................................................................................................................... 18 4.3. МЕТРИКИ КАЧЕСТВА ........................................................................................................................................ 18 4.4. СТАНДАРТЫ, РЕГЛАМЕНТИРУЮЩИЕ ХАРАКТЕРИСТИКИ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ ..................... 19 4.5. ВЫБОР ПОКАЗАТЕЛЕЙ КАЧЕСТВА .................................................................................................................... 25 4.6. СТАНДАРТИЗАЦИЯ ОЦЕНИВАНИЯ КАЧЕСТВА ГОТОВОГО ПРОГРАММНОГО ПРОДУКТА ................................... 26 5. КАЧЕСТВО ТЕХНИЧЕСКОГО ПРОЕКТА ............................................................................................. 28 6. ИЗМЕРЕНИЕ КАЧЕСТВА НА ОСНОВЕ СОПРОВОЖДЕНИЯ ПРОДУКТА .................................. 30 7. ИНТЕГРАЛЬНАЯ ОЦЕНКА КАЧЕСТВА................................................................................................ 32 7.1 МЕТОДОЛОГИЯ МЕТРИЧЕСКОГО АНАЛИЗА КАЧЕСТВА...................................................................................... 32 8. ЗАКЛЮЧЕНИЕ.............................................................................................................................................. 36 9. ГЛОССАРИЙ ................................................................................................................................................. 37 СПИСОК ЛИТЕРАТУРЫ ..................................................................................................................................... 38 2 Когда вы можете измерить, то о чем вы говорите, и выразить это в числах, вы знаете кое-что об этом; но если вы не можете измерить это и выразить в числах, ваше знание скудно и неудовлетворительно. Лорд Кельвин 1. Введение Процессы разработки, приобретения и внедрения сложных систем, к которым относятся в частности программные комплексы, должны находится под жестким управленческим контролем. В настоящее время практически во всех организациях обеспечивается контроль важнейших характеристик, связанных с производством и использованием программных продуктов, таких как время, финансовые средства, ресурсы и т.п. Однако в большинстве случаев вне пределов сферы контроля оказывается наиболее важная характеристика программных продуктов, ради которой, собственно и осуществляются затраты времени, финансовых средств и ресурсов – это качество продукта, поскольку «невозможно контролировать то, что нельзя измерить» (“You cannot control what you cannot measure” ). Отсутствие возможности установки полного контроля вызывает рост количества необоснованных решений, увеличивает финансовые и проектные риски, связанные с разработкой и внедрением систем. Однако в настоящее время уже существуют организации, в которых накоплен достаточно большой опыт использования метрик в управлении качеством разрабатываемых и внедряемых программных продуктов. Использование апробированных подходов в управлении качеством разработки и внедрения крупных программных систем значительно повышает предсказуемость проектов, снижает финансовые и ресурсные издержки. Среди используемых метрик качества программного обеспечения есть универсальные метрики, которые применимы практически ко всем видам программного обеспечения. В то же время большая часть наиболее важных метрик в успешных проектах разрабатывается индивидуально на основе особенностей проекта и характеристик предметной области. 3 2. Понятие качества 2.1. Определение качества Сейчас существует несколько определений качества, которые в целом совместимы друг с другом. Приведем наиболее распространенные: Определение ISO: Качество - это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям. Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств. 2.2. Многомерность качества Общее качество программной системы включает в себя на верхнем уровне ряд составляющих, которые должны быть приняты во внимание при управлении качеством (рис. 1). Рис. 1. Многомерность качества Составляющие качества информационной системы (Information Systems Quality): Качество инфраструктуры (infrastructure quality): качество аппаратного и поддерживающего программного обеспечения (например, качество операционных систем, компьютерных сетей и т.п.). Качество программного обеспечения (software quality): качество программного обеспечения информационной системы. Качество данных (data quality): качество данных, использующихся информационной системой на входе. Качество информации (information quality): качество информации, продуцируемое информационной системой. Качество административного управления (administrative quality) – качество менеджмента, включая качество бюджетирования, планирования и календарного контроля. Качество сервиса (service quality) – качество обучения, системной поддержки и т.п. Кроме перечисленных составляющих качества должно быть принято во внимание качество обслуживаемого бизнес процесса. Анализ всех составляющих качества должен проводится с учетом сфер ответственности заинтересованных сторон, как внутренних участников исполняемого процесса (in-process stakeholder), так и пользователей процесса (end-of-process stakeholders). Управление качеством будет успешным, если под контролем находятся все измерения качества. В данном документе затрагиваются вопросы, касающиеся измерения качества программного обеспечения. 2.3. Идентификация и классификация характеристик качества Исследования метрического анализа качества показывают, что не существует единственной метрики, которая бы дала универсальный рейтинг качества программного обеспечения. Измерения качества дают спектр проектно-зависимых метрик, которые являются руководящей основой для принятия решений в процессе разработки, заказа и сопровождения программного обеспечения. Следует отметить, что метрики качества являются изначально неочевидной категорией. Исторически сначала были выделены ряд универсальных и неполных метрик на основе следующих шагов: 1. Определение множества характеристик, которые, являясь важными для программного обеспечения, допускают несложное измерение и не перекрываются. 2. Выделение кандидатов в метрики, которые измеряют степень удовлетворения указанным характеристикам. 3. Исследование характеристик и связанных метрик, для определения корреляции, значимости, степени автоматизируемости. 4. Исследование корреляции между метриками, степени перекрытия, зависимости и недостатков. 5. Рафинирование множества метрик в целом во множество метрик, которые в совокупности адекватно отражают качество программного обеспечения. 6. Корректировка каждой метрики в итоговом множестве в контексте зафиксированных множеств характеристик и метрик. На основе систематического применения данного подхода были выведены примеры универсальных характеристик программного обеспечения, структурно связанные в иерархию (рис. 2). 5 Рис. 2 Дерево характеристик качества Нижний слой характеристик в иерархии должен быть строго дифференцирован для того, чтобы исключить (или минимизировать) перекрытия. Данный слой должен состоять из примитивных характеристик, допускающих измерение. Измерение характеристик нижнего слоя может происходить путем ручного сбора информации, специальными автоматизированными средствами, возможен экспертный способ. Каждая из собранных метрик будет иметь собственные характеристики. Область применения метрик может локализоваться внутри проекта, внутри платформы разработки или быть универсальной. Степень влияния метрик на итоговое качество также является различным. Указанные свойства метрик должны быть документированы и доступны при их практическом использовании. Для мониторинга метрик качества и подготовки информации для принятия решений собранные метрики должны представляются в наглядном виде, обеспечивающим полноту информации, что особенно важно при отсутствии консолидированных метрик качества (рис. 3). 6 Рис. 3 Пример графического изображения качества Для конкретного проекта должно быть разработано или дополнено свое множество метрик, которое отражает назначение и особенности окружения разрабатываемого программного продукта. 2.4. Цена качества Понятие цены качества первоначально была введена Джураном (J.M. Juran) и Грином (F.M. Gryna) как стоимость в составе продукта, которая может быть сэкономлена, если все исполнители работают безупречно. Цена качества – важная категория, поскольку фактически она отражает стоимость работ на доработку, увеличенную стоимость сопровождения. Цена качества может быть разделена на два главных типа: согласованная (conformance) и несогласованная (non-conformance). Согласованная цена качества - это сумма, затраченная на достижение качества продукта. Она делится на цену предупреждения (Prevention cost) и цену контроля (Appraisal cost). Затраты предупреждения связаны с предупреждением дефектов прежде чем они произойдут. При разработке ПО примером затрат предупреждения являются затраты на обучение коллектива базовым методологиям, переход на современные технологии разработки, использование автоматизированных средств проектирования и разработки. Цена контроля включают измерение, оценивание или ревизию продукта для обеспечения гарантии соответствия между требованиями, стандартами качества и результатом. Для разработки программного обеспечения, например, затраты оценки включают в себя инспекцию программ, тестирование и измерение программных показателей. Несогласованная цена качества включает все издержки понесенные, вследствие выявления недостатков, возникновения ошибок и выхода из строя. Несогласованная цена качества включает внутренние и внешние издержки. Внутренние издержки связаны с проблемами, выявленными до того, как продукт отправлен заказчику. Для разработки программного обеспечения сюда включены затраты на переработку программ, повторную инспекцию и тестирование. Затраты связанные с ошибками, проявившимися при эксплуатации продукта у заказчика, относятся к внешним 7 издержкам. Для программного обеспечения, например, сюда включены затраты на сопровождение и поддержку, убытки от простоев и некорректного функционирования. Статистические исследования влияния процессов разработки на качество результирующего продукта показывают, что: 1. Совершенствование процесса разработки и внедрения программного обеспечения значительно уменьшают относительную (в пересчете на единицу объема программного продукта в выбранной метрике) несогласованную стоимость качества при сохранении согласованной стоимости качества на прежнем уровне. 2. Инвестиции в совершенствование процесса разработки программного продукта при условии раннего и адресного внедрения процедур улучшения качества ведут к значительному сокращению дефектов и дают высокий положительный экономический эффект (рис 4). Рис. 4. Цена качества 8 3. Качество процесса разработки 3.1. Качество процесса и качество продукта Проведенные исследования показывают: чем выше качество процесса разработки, тем выше качество разработанного в этом процессе качества программного обеспечения. Качество на каждой стадии проекта возрастает, во-первых, как прямое следствие зрелости процесса, во-вторых, вследствие использования промежуточного продукта более высокого качества, произведенного на предыдущей стадии (рис. 5). При этом подчеркивается, что значение второй причины обеспечивающей нарастание качества в процессе жизненного цикла для зрелых процессов оказывается гораздо более важным. Рис. 5 Концептуальная модель качества Отсюда вытекают следующие следствия: качество накапливается в продукте при сложном производстве кумулятивным образом, причем, вклад в качество, осуществленный на ранних стадиях, имеет более сильное влияние на конечный продукт, чем на более поздних стадиях. Это подтверждается всей практикой программирования, например, известно, что недостатки проектирования систем не могут быть компенсированы высоким качеством кодирования. тестирование и измерение качества должно происходить на всех стадиях жизненного цикла. Извлечение данных о качестве, которое было заложено на ранних стадиях, может быть очень дорогим, при отсутствии полных результатов промежуточного продукта на предыдущих стадиях, например, при отсутствии логического дизайна системы, требований к продукту и т.п. Таким образом, для управления качеством построения сложной системы необходимо производить выбор производителей на основе измерения степени зрелости и прозрачности используемых процессов разработки. Измерение качества процесса разработки подрядчиков является важной составной частью общего управления качеством, более важным, чем измерение качества результирующего продукта, производимого в ходе приемо-сдаточных испытаний. 9 3.2. Измерение качества процесса Современная индустрия программного обеспечения (ПО) характеризуется очень высокой степенью конкуренции. Для успешной работы на этом рынке компания должна разрабатывать, внедрять и сопровождать программное обеспечение быстро, в срок и с удовлетворительным качеством. Поэтому многие компании вкладывают деньги в улучшение качества процесса, памятуя о том, что подобное вложение денег обязательно окупается – изучение документированных случаев улучшения процессов разработки ПО показывает, что в успешных случаях наблюдается существенное улучшение производительности и качества со средним уровнем возврата вложений от 5:1 до 8:1. Существуют десятки различных подходов к обеспечению качества ПО, и у всех есть свои преимущества и недостатки. Рассмотрим наиболее распространенные и используемые стандарты, такие как ISO 9001, CMM (Capability Maturity Model) и SPICE (ISO/IEC 15504). Существуют и другие достаточно развитые стандарты, такие, как Bootstrap, во многом схожий с рассматриваемыми стандартами CMM и SPICE, Trillium, ориентированный на разработку продуктов в области телекоммуникаций и ISO 12207, посвященный жизненному циклу программного обеспечения, и другие. 3.2.1. ISO 9001 Одной из первых моделей качества стал стандарт ISO (Международной организации по стандартизации) серии 9000, первая версия которого была выпущена в 1987 году. С тех пор сертификаты ISO серии 9000 сохраняют неизменную популярность и признаются во всем мире. Для процесса разработки программ используется стандарт ISO 9001, предусматривающий проектирование в процессе производства. Следует отметить, что данный стандарт затруднительно использовать непосредственно в управлении качеством разработки программного обеспечения, поскольку изначально он ориентирован на разработку промышленных изделий. Специально для обеспечения процессов разработки программных систем организацией ISO, разработано руководство ISO 9000-3, которое формулирует требования модели качества ISO 9001 к организации процесса разработки программного обеспечения. Таким образом, для оценки качества процесса разработки в собственной организации или в организации подрядчиков могут использоваться требования руководства ISO 90003. В настоящее время повсеместно вводится в использование версия стандарта 2000 года, в котором во главу угла ставится управление процессом, однако в данной версии стандарта специфика, связанная с разработкой ПО отсутствует. Однако время не стоит на месте, и методики, положенные в основу стандартов серии ISO 9000, постепенно устаревают. Выделим наиболее существенные недостатки: недостаточная подробность стандарта, возможность самых различных его толкований в зависимости от представлений аудитора; неточность оценки качества процессов, задействованных при создании и внедрении программного обеспечения; отсутствие в стандарте механизмов, способствующих улучшению существующих процессов. трудность измерения уровня качества процесса разработки программного обеспечения в соответствии с предложенной моделью качества. 10 3.2.2. CMM Недостатки стандарта ISO 9001 заставили экспертов разрабатывать более совершенные решения в области обеспечения качества, что привело к созданию в начале 90-х годов целого ряда новых стандартов и методологий. Одним из наиболее удачных и содержательных стал стандарт Capability Maturity Model (CMM). Официальная история CMM (Capability Maturity Model, что обычно переводят как "модель зрелости процесса разработки ПО", хотя более верным по смыслу был бы перевод "модель совершенствования возможностей") начинается в 1991 году, когда американский институт SEI (Software Engineering Institute – Институт системного программирования при университете Карнеги-Меллон) опубликовал первую версию этого стандарта. Первоначально данная модель качества использовалась государственными, в частности военными, организациями при размещении заказов на разработку программного обеспечения. В настоящее время стандарт широко используется для анализа и сертификации процессов разработки программного обеспечения фирм, производящих сложное программное обеспечение в критичных областях применения. Важными преимуществами модели СММ является иерархическая вложенность моделей качества, которая позволяет измерять и сравнивать уровни качества процессов в различных организациях и обеспечивать эффективное совершенствование качество процессов. Главным понятием стандарта является зрелость организации. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, и решения зачастую просто импровизируются "на ходу". В этом случае велика вероятность превышения бюджета или заваливания сроков сдачи проекта, и потому менеджеры вынуждены заниматься только разрешением ближайших проблем. С другой стороны, в зрелой организации имеются четко определенные процедуры создания программных продуктов и управления проектами. Эти процедуры по мере необходимости уточняются и совершенствуются в пилотных проектах или с помощью анализа стоимость/прибыль. Оценки времени и стоимости выполнения работ основываются на накопленном опыте и достаточно точны. Наконец, в компании существуют стандарты на процессы разработки, тестирования и внедрения ПО, правила оформления конечного программного кода, компонент, интерфейсов и т.д. Все это составляет инфраструктуру и корпоративную культуру, поддерживающую процесс разработки программного обеспечения. Таковы базовые посылки стандарта CMM. Можно сказать, что стандарт в целом состоит из критериев оценки зрелости организации и рецептов улучшения существующих процессов. В этом наблюдается принципиальное различие с моделью, принятой в ISO 9001, так как в ISO 9001 сформулированы только необходимые условия для достижения некоторого минимального уровня организованности процесса, и не дается никаких рекомендаций по дальнейшему совершенствованию процессов. В модели CMM определено пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или (теоретически) понижаться. На рисунке 6 показаны некоторые технологии, внедрение которых необходимо для достижения различных уровней зрелости организации. Отметим, что каждый следующий уровень включает в себя все ключевые характеристики предыдущих. 11 Рис. 6 Пять уровней зрелости в модели CMM. Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию. Для достижения повторяемого уровня (repeatable level) на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение (причем обеспечивается следование этим стандартам) и существует специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень. Далее следует определенный уровень (defined level), который характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков, и не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях. На управляемом уровне (managed level) в организации устанавливаются количественные показатели качества – как на программные продукты, так и на процесс в 12 целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях. Наконец, оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например, с помощью создания и повторного использования компонент. При сертификации проводится оценка соответствия всех ключевых областей по 10балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям: 1. Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т.д.). 2. Насколько широко данная область применяется в организации (например, оценке в 4 балла соответствует фрагментарное применение). 3. Успешность использования данной области на практике (например, оценке в 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется при наличии систематического и измеримого положительного результата практически во всей организации). В принципе, можно сертифицировать только один процесс или подразделение организации, например, подразделение разработки программного обеспечения компании IBM сертифицировано на пятый уровень. Кстати, в мире существует совсем немного компаний, которые могут похвастаться наличием у них пятого уровня CMM хотя бы в одном из подразделений – таких всего около 50. С другой стороны, насчитывается несколько тысяч компаний, сертифицированных по 3 или 4 уровню, то есть существует колоссальный разрыв между оптимизированным уровнем зрелости и предыдущими уровнями. Однако еще больший разрыв наблюдается между количеством организаций начального уровня и числом их более продвинутых собратьев – по некоторым оценкам, свыше 70% всех компаний-разработчиков находится на первом уровне CMM. Интересен вопрос о соотношении уровней CMM со стандартом ISO 9001: на каком уровне CMM должна находиться организация, чтобы получить сертификат соответствия ISO 9001? На первый взгляд, для этого необходимо иметь как минимум 3 или 4 уровень CMM. Тем не менее, существуют примеры организаций 1-го уровня, имеющих сертификат ISO 9001. Одной из причин для возникновения подобных несуразиц является высокий уровень абстракции ISO 9001 и связанная с этим свобода его интерпретации аудитором. Иногда, как это ни странно, аудиторам не хватает элементарного знакомства с реальной практикой разработки программ. К сожалению, использование CMM затрудняют следующие проблемы: стандарт CMM является собственностью Software Engineering Institute и не является общедоступным (в частности, дальнейшая разработка стандарта ведется самим институтом, без заметного влияния остальной части программистского сообщества); оценка качества процессов организаций может проводиться только специалистами, прошедшими специальное обучение и аккредитованными SEI; стандарт ориентирован на применение в относительно крупных компаниях. 13 3.2.3. SPICE В 1991 году Международная организация по стандартизации инициировала работу по созданию единого стандарта оценки программных процессов. Стандарт получил имя SPICE (сокращение от Software Process Improvement and Capability dEtermination, определение возможностей и улучшение процесса создания программного обеспечения). Официально стандарт называется "ISO/IEC 15504: Information Technology - Software Process Assessment" и на данный момент существует в качестве рабочей версии, последний выпуск которой состоялся в мае 1998 года. Задачей SPICE является создание международного стандарта, в котором был бы учтен весь накопленный опыт в области разработки ПО. На рисунке 7 показаны наиболее значительные стандарты, идеи которых были использованы при создании SPICE: Рис.7 Предшественники стандарта SPICE Итак, стандарт SPICE унаследовал многие черты более ранних стандартов, в том числе и уже упоминавшихся ISO 9001 и CMM. Для этого пришлось прибегнуть к повышению уровня детализации стандарта. Следствием такого основательного подхода является большой объем стандарта (документация к нему содержит около 500 страниц). Больше всего SPICE напоминает CMM. Точно так же, как и в CMM, основной задачей организации является постоянное улучшение процесса разработки ПО. Кроме того, в SPICE тоже используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам. В таблице 1 приведен список уровней способностей модели SPICE и характерные для них процедуры управления. Отметим, что на данный момент не существует русского перевода стандарта SPICE, поэтому использованные термины не являются общепринятыми или официально зарегистрированными Уровни Название Уровень 0 Уровень 1 1.1 Уровень 2 2.1 2.2 Уровень 3 3.1 3.2 Процесс не выполняется Выполняемый процесс Измерение производительности процесса Управляемый процесс Управление производительностью Управление созданием продуктов Установленный процесс Документирование процесса Отслеживание ресурсов процесса 14 Уровень 4 4.1 4.2 Уровень 5 5.1 5.2 Предсказуемый процесс Измерение процесса Управление процессом Оптимизирующий процесс Изменение процесса Постоянное совершенствование Таблица 1 Уровни способностей процесса в стандарте SPICE Таким образом, процессы в модели SPICE могут быть представлены следующим образом: Рис. 8 Упрощенная модель оценки процессов в стандарте SPICE. Здесь Pn обозначает процессы, а CL (Capability Levels) обозначает уровни способностей этих процессов. Поэтому иногда говорят, что модель SPICE является двумерной – на одной оси откладываются процессы, а на другой оси – достигнутый уровень возможностей для этих процессов. Во время оценки и улучшения качества процессов выполняются следующие задачи (рис. 9): Рис. 9 Основные элементы стандарта SPICE 10. Оценка процесса происходит путем сравнения процесса разработки ПО, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов, полученных на этом этапе, помогает определить сильные и слабые стороны процесса, а также внутренние риски, присущие данному процессу. Это помогает оценить эффективность процессов, определить причины ухудшения качества и связанные с этим издержки во времени или стоимости. 15 Определение возможностей процесса позволяет оценить возможности улучшения данного процесса. Очень часто определение возможностей процесса производится компанией-поставщиком, чтобы убедить существующих или потенциальных заказчиков в своей способности достичь заданных показателей. 10. В результате предыдущих шагов, в организации может появиться понимание необходимости улучшения того или иного процесса. К этому моменту цели совершенствования процесса уже четко сформулированы и остается только техническая реализация поставленных задач. После этого весь цикл работ начинается сначала. Одним из важных достоинств SPICE является его открытость и свободное распространение. В таблице 2 кратко сформулированы преимущества SPICE по сравнению с ISO 9001: 10. SPICE ISO 9001 Объемный и подробный документ Детальная модель Улучшение процесса и определение возможностей Шесть уровней возможностей процессов Требования к оценке процесса, руководство по применению Краткий документ Абстрактная модель Только сертификация Сертификация/отказ Только модель Может быть детализирован с помощью SPICE Дополняет ISO 9001 Таблица 2. Сравнение стандартов SPICE и ISO 9001 SPICE предоставляет более полный набор средств по обеспечению качества и улучшению процессов, чем ISO 9001. Поэтому для обеспечения качества процессов разработки ПО мы рекомендуем использовать именно SPICE. Это поможет организации заметно улучшить существующие процессы, а затем при необходимости получить и сертификат ISO 9001. Использовать SPICE можно и в небольших компаниях – об этом свидетельствуют результаты работы проекта SPIRE, в рамках которого проводилось внедрение процессов улучшения качества в малых (менее 50 человек) компаниях из различных стран Европы. Как показал этот опыт, и при небольших денежных вложениях в маленьких компаниях можно добиться существенного увеличения производительности труда и улучшения качества произведенных продуктов. 16 4. Качество программного продукта На начальных этапах жизненного цикла (ЖЦ) программных средств (ПС) разработчики и/или заказчики предварительно формулируют цель проекта и детализируют ее в концепции, техническом задании или в спецификации требований. Эта детализация, прежде всего, состоит в выборе набора функций, которые должна будет выполнять информационная система (ИС) и ее программные средства. Каждая функция должна быть описана характеристиками качества, которые уточняют и конкретизируют требования к их содержанию и реализации. В ряде стандартов и публикаций большое внимание уделяется процессам обеспечения качества продукции, технологий и услуг, в частности, в жизненном цикле сложных программных средств. Однако во многих случаях умалчивается, что означает высокое качество, какими характеристиками оно описывается, как его следует измерять и сравнивать с требованиями, формализованными в контракте, техническом задании или спецификациях. Кроме того, некоторые из характеристик частично отсутствуют в согласованных документах, что приводит к разному их учету или к пропуску при испытаниях. Отсутствие четкого представления и описания в документах понятий и значений характеристик качества ПС приводит к конфликтам между заказчиками – пользователями и разработчиками – поставщиками из-за разной трактовки одних и тех же характеристик. Неопределенности и пробелы в формализации характеристик качества комплексов программ оставляют широкое поле для произвола при оценивании их качества и к проявлению дефектов и ошибок при применении ПС пользователями. Возрастание сложности и ответственности задач, решаемых программами, а также возможного ущерба от недостаточного качества их результатов, значительно повысило актуальность проблемы точного описания требований к характеристикам качества и их измерения на различных этапах ЖЦ ПС. Разработчикам, поставщикам, заказчикам и пользователям необходимо усвоить, что тщательное и корректное определение, выбор номенклатуры и оценивание стандартизированных характеристик качества ПС, существенно, а иногда критически, влияет на последующее качество функционирования информационных систем. Типовой набор характеристик, субхарактеристик и атрибутов качества комплексов программ, представленный в базовых стандартах, следует использовать как исходные данные и шаблоны при подготовке технических заданий и спецификаций требований к качеству ПС. Корректировка состава и значений параметров позволяет уточнять и адаптировать этот набор характеристик ПС для конкретных проектов и потребителей и сокращать дефекты вследствие неоднозначности и некорректности описаний требований к качеству. Методы стандартизированного оценивания и измерения различных характеристик качества следует использовать при подготовке конкретных методик испытаний качества проектов ПС. Целеустремленный выбор и оценивание стандартизированных характеристик следует применять как основу для сравнения качества программных средств разных поставщиков и выявления среди них предпочтительных. Разработка современных больших программных систем в настоящее время все более базируется на компонентной разработке (Component Base System – CBS). Технология построения CBS позволяет значительно снизить стоимость и время разработки. В то же время возрастает риск, связанный с использованием в системе программных компонент разработанных различными производителями. Наиболее действенный способ решения данной проблемы состоит в использовании метрик для управления качеством и рисками при построении CBS, с целью измерения различных факторов влияющих на конечное качество продукта и устранения источников риска. Метрики качества при этом должны быть использованы для обеспечения принятия 17 решений на различных этапах жизненного цикла разработки по экономической целесообразности использования компонент. Исходные коды компонент, как правило, являются недоступными для конструкторов системы, кроме того, в них предусматривается сложный структурированный интерфейс. Следствием этого является значительное различие между метриками, которые обычно применимы для традиционных систем и метриками для CBS. Большинство традиционных метрик используются на этапе планирования и разработки. Ключевым для управления качеством при использовании метрик в разработке компонентных систем является выбор метрик качества применимых на всех этапах жизненного цикла и оценивающих как качество процесса, так и качество продукта. При выборе метрик главными показателями являются: адекватность метрик целям качества, прозрачность и четкость интерпретации и экономическая эффективность получения. Примерами метрик могут служить метрики менеджмента, метрики требований и метрики качества. 4.1. Метрики менеджмента Цена (Cost) – расходы на приобретение/разработку Время разработки (Time-to-market) Среда разработки (Software Engineering Environment) Использование системных ресурсов (System Resource Utilization) Указанные метрики могут использоваться на этапах планирования и контроля проектов и других задач управления или использоваться в качестве параметров управления штатной ERP системы. Метрика «cost» измеряет общую цену, включая цену анализа рынка, приобретения, интеграции и улучшения качества. Метрика «time-to-market» - мера времени от формирования заказа на программу до поставки. При итерационной разработке данная метрика модифицируется для измерения времени, требуемого для поставки заданного объема приращения функциональности, то есть скорости поставки. Метрика «System resource utilization» - определяет процент целевых компьютерных ресурсов, используемых системой. «Software engineering environment» - мера способности производителя разрабатывать программное обеспечение высокого качества. Данная метрика может быть выражена в терминах модели «Software Acquisition Capability Maturirty Model (SA – СММ). 4.2. Метрики требований Соответствие требованиям (requirement conformance) Стабильность требований (requirement stability) Метрики требований дают возможность контролировать спецификации, изменение требований, а также степень их удовлетворения. 4.3. Метрики качества Адаптируемость (adaptability) Сложность интерфейсов и интеграции (complexity of interfaces and integration) 18 Тестовое покрытие (test coverage) Надежность (reliability) Профили ошибок (fault profiles) Степень удовлетворения потребностей заказчика (customer satisfaction) «Adaptability» - мера гибкости системы, оценивает способность системы адаптироваться к изменениям требований либо перепроектированием системы, либо интеграцией приложений. «Complexity of interfaces and integration» - метрика, измеряющая степень сложности интерфейса или дополнительного программирования требуемого для интеграции компоненты в систему, которые требуются для тестирования, отладки и сопровождения, компенсирующего потерю качества. Метрики «test coverage» указывают степень полноты различных типов тестирования. «Reliability»- метрика, оценивающая вероятность работы системы без отказов. Данная метрика может быть получена в рамках традиционного подхода. «Fault profiles» - метрика, измеряющая кумулятивное число обнаруженных ошибок. «Customer satisfaction» - метрика, оценивающая степень соответствия программного обеспечения ожиданиям и требованиям заказчика. Данная метрика может быть оценена перед поставкой на этапе опытной эксплуатации на основе прогнозирующих параметров. 4.4. Стандарты, регламентирующие характеристики качества программных средств Выбор и формирование требований к ПС состоит в анализе необходимых свойств, характеризующих качество их функционирования с учетом технологических и ресурсных возможностей разработчиков. При этом под качеством функционирования понимается множество свойств, обусловливающих пригодность ПС обеспечивать надежное и своевременное представление требуемой информации потребителю для ее дальнейшего использования по назначению. В соответствии с принципиальными особенностями, назначением и свойствами каждого ПС при проектировании должны выбираться номенклатура и значения характеристик качества, необходимых для эффективного применения пользователями, которые впоследствии отражаются в спецификациях требований и в технической документации на конечный продукт. Каждая характеристика качества может использоваться, если определена ее метрика, мера и шкала и может быть указан способ ее измерения и сопоставления с требующимся значением. Для конкретных ПС доминирующие критерии качества выделяются при проектировании и определяются требованиями технического задания и функциональным назначением. Они должны, прежде всего, отражать функциональную пригодность для применения с заданными целями. Основой формального регламентирования показателей качества ПС является международный стандарт ISO 9126:1991 (ГОСТ Р ИСО / МЭК 9126-93) – "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению". Развитие этого международного стандарта проводится в направлении уточнения, детализации и расширения описаний характеристик качества комплексов программ. Для замены редакции 1991 года завершается разработка проекта стандарта ISO 9126-1-4, состоящего из четырех частей: Часть 1: Модель качества; Часть 2: Внешние метрики качества; Часть 3: Внутренние метрики качества; Часть 4: Метрики качества в использовании. 19 Стандарт ISO 9126:1991 предполагается заменить на две взаимосвязанные серии стандартов: ISO 9126:1-4 (проект) – "Качество программных средств" - и утвержденный стандарт ISO 14598 – 1-6:1998-2000 – "Оценивание программного продукта". В первой части стандарта ISO 9126-1 приводится схема взаимосвязи частей стандарта ISO 9126 и частей стандарта ISO 14598, а также область применения, нормативные ссылки, термины и определения. Определяется модель характеристик качества ПС и ее связи с жизненным циклом. Модель детализируется в последующих частях стандарта. Требования пользователя к качеству в спецификациях должны в процессе верификации преобразовываться в требования к внешнему качеству, а затем в требования к внутреннему качеству. Процессы реализации требований к внутреннему качеству должны обеспечивать внешнее качество, а последнее - воплощаться в качество для пользователей. Кратко описаны компоненты этой модели преобразования и реализации требований к составляющим качества. Модель внутренних и внешних характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками: Функциональная пригодность детализируется: пригодностью для применения; корректностью (правильностью, точностью); способностью к взаимодействию; защищенностью. Надежность рекомендуется характеризовать: уровнем завершенности (отсутствия ошибок); устойчивостью к дефектам; восстанавливаемостью; доступностью – готовностью. Эффективность рекомендуется отражать: временной эффективностью; используемостью ресурсов. Применимость (практичность) предлагается описывать: понятностью; простотой использования; изучаемостью; привлекательностью. Сопровождаемость предлагается представлять: удобством для анализа; изменяемостью; стабильностью; тестируемостью. Переносимость (мобильность) предлагается отражать: адаптируемостью; простотой установки – инсталляции; сосуществованием – соответствием; замещаемостью. Дополнительно каждая характеристика сопровождается субхарактеристикой согласованность, которая должна отражать отсутствие противоречий с иными стандартами и нормативными документами, а также с другими показателями в данном стандарте. В стандарте ISO 9126 отсутствуют методики количественного измерения характеристик и сопоставления с требованиями спецификаций, а также рекомендации, на каких этапах ЖЦ ПС их целесообразно применять. 20 В стандарте выделена модель характеристик качества в использовании. В этой модели используются иные базовые характеристики по сравнению с моделью внутреннего и внешнего качества. Основными характеристиками качества ПО в использовании рекомендуются: системная эффективность применения программного продукта по назначению; продуктивность – производительность при решении основных задач ПС, достигаемая при реально ограниченных ресурсах в конкретной внешней среде применения; безопасность – надежность функционирования комплекса программ и возможный риск от его применения для людей, бизнеса и внешней среды; удовлетворение требований и затрат пользователей в соответствии с целями применения ПС. Вторая и третья части стандарта ISO 9126:2,3 посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных ПС. Взаимосвязь метрик качества в этих частях стандарта отражена одинаковыми моделями, аналогичными модели первой части стандарта. Показано, что внутреннее и внешнее качества относятся непосредственно к самому программному продукту, а метрики качества в использовании проявляются в эффекте от его применения и зависят от внешней среды. Между тремя типами метрик и характеристик качества существует взаимовлияние сверху вниз и зависимость снизу вверх. Изложены содержание и общие рекомендации по использованию соответствующих метрик и взаимосвязей между типами метрик. Основное содержание метрик качества в этих частях стандарта представлено в восьмом разделе в виде описаний и 27 иллюстративных таблиц к ним. Для этого в предыдущем седьмом разделе описаны рубрики и рекомендации, как читать и использовать таблицы метрик субхарактеристик и атрибутов качества ПС Четвертая часть стандарта ISO 9126-4 предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества ПС. В ней повторена концепция трех типов метрик, а также аннотированы рекомендуемые виды измерений характеристик ПС: прямые, непрямые и индикаторы свойств (категорийные). Рассмотрена модель качества в использовании. Отмечаются необходимость идентификации назначения и специфики потребителей программного продукта, особенности выбора целей оценивания качества для различных сфер и этапов применения ПС. Обосновываются и комментируются выделенные показатели сферы (контекста) использования ПС и группы выбранных метрик для пользователей. В отличие от характеристик, описанных в предыдущих частях стандарта, в этой части для качества в использовании рекомендуется четыре: эффективность; продуктивность; удовлетворение требований и защищенность. Приводятся подробные рекомендации для описания и оценивания выделенных характеристик качества в использовании: специфика определения целей и контекста среды пользователя; выбор, селекция и интерпретация каждой из выделенных метрик; выделение и утверждение критериев для реализации и оценивания качества; интерпретация результатов измерений. Даны рекомендации по проектированию процессов оценивания, по оформлению пользовательских тестов, обобщению собранных данных и подготовке отчетов о результатах оценивания качества программного продукта. Характеристики, субхарактеристики и атрибуты качества ПС с позиции возможности и точности их измерения можно разделить на три типа, особенности которых следует уточнять при их выборе: категорийный - описательный, отражающий набор свойств и общие характеристики объекта – его функции, категории ответственности, 21 защищенности и важности, которые могут быть представлены номинальной шкалой категорий-свойств; количественный – представляемый множеством упорядоченных, числовых точек, отражающих непрерывные закономерности и описываемые интервальной или относительной шкалой, которые можно объективно измерить и численно сопоставить с требованиями; качественный – содержащий несколько упорядоченных или отдельных значений – категорий, которые характеризуются порядковой или точечной шкалой набора категорий (есть – нет, хорошо – плохо), устанавливаются, выбираются и оцениваются в значительной степени субъективно и экспертно. К первому типу относятся показатели качества, которые характеризуются наибольшим разнообразием значений – свойств программ и наборов данных и охватывают весь спектр классов, назначений и функций современных ПС. Эти свойства можно сравнивать только в пределах однотипных ПС и трудно упорядочивать по принципу предпочтительности. К этому типу, прежде всего, относится Функциональная пригодность, являющаяся самой важной и доминирующей характеристикой любых ПС. Номенклатура и значения всех остальных показателей качества непосредственно определяются требуемыми функциями программного средства и в той или иной степени влияют на выполнение этих функций. Поэтому выбор функциональной пригодности ПС, подробное и максимально корректное описание ее свойств являются исходными данными для установления требуемых значений всех остальных стандартизированных показателей качества. Ко второму типу относятся достаточно достоверно и объективно измеряемые численные характеристики ПС. Значения этих характеристик обычно в наибольшей степени влияют на функциональные возможности и метрики в использовании ПС. Поэтому выбор и обоснование требуемых их значений должны проводиться наиболее аккуратно и достоверно уже при системном проектировании ПС. Их субхарактеристики могут быть описаны упорядоченными шкалами объективно измеряемых значений, требуемые численные величины которых могут быть установлены и выбраны заказчиками или пользователями ПС. Такими характеристиками являются Надежность и Эффективность комплексов программ (таблица 3). Надежность может отражаться временем наработки на отказ, средним временем восстановления, а также коэффициентом готовности – вероятностью застать ПС в работоспособном состоянии при нормальной эксплуатации. Эти величины могут выбираться и фиксироваться в техническом задании или спецификации требований, и сопровождаться методикой объективных, численных измерений при квалификационных испытаниях для сопоставления с требованиями. Для каждой из них может быть установлен допустимый диапазон определения численных значений и требуемая точность измерений. Атрибуты временной эффективности тесно связаны между собой и влияют на функциональную пригодность ПС. Длительность решения основных задач, пропускная способность по числу их решений за некоторый интервал времени, длительность ожидания результатов (отклика), и некоторые другие характеристики динамики функционирования ПС, могут быть выбраны и установлены количественно в спецификациях требований заказчиком. Эта субхарактеристика не всегда может быть выбрана и достаточно точно зафиксирована на начальных этапах разработки, но она может количественно измеряться и последовательно уточняться в жизненном цикле ПС. Используемость ресурсов ЭВМ, если она не достигает критических значений, когда некоторого ресурса становится недостаточно, менее существенно влияет на функциональную пригодность ПС. Однако избыток ресурсов снижает экономическую эффективность информационной системы и должен сохраняться в минимальной степени. Выбор и количественное измерение степени использования различных ресурсов ЭВМ, может значительно влиять на функциональную пригодность ПС. 22 Таблица 3. Характеристики качества Надежность Завершенность: наработка на отказ при отсутствии рестарта Устойчивость: наработка на отказ при наличии автоматического рестарта относительные ресурсы на обеспечение надежности и рестарта Восстанавливаемость: длительность восстановления Доступность-готовность: относительное время работоспособного функционирования Эффективность Временная эффективность: время отклика – получения результатов на типовое задание пропускная способность – число типовых заданий, исполняемых в единицу времени Используемость ресурсов: относительная величина использования ресурсов ЭВМ при нормальном функционировании программного средства Мера Шкала часы 10-1000 часы 10-1000 % 10-90 минуты 10-2 - 10 вероятность 0,7 - 0,99 секунды 1-1000 Число в минуту 1-1000 Вероятность 0,7 - 0,99 Третий тип стандартизированных показателей качества ПС трудно полностью описать измеряемыми количественными значениями и их некоторые субхарактеристики имеют описательный, качественный вид (таблица 4). В зависимости от функционального назначения ПС по согласованию с заказчиком можно определять экспертно степень необходимости этих свойств и балльные значения реализации их атрибутов. Например, не всегда может требоваться мобильность программ на иные операционные и аппаратные платформы, а также выбор и оценка соответствующих субхарактеристик, которые можно полностью исключать из метрик качества в использовании. В других случаях мобильность можно оценивать категориями: отличная, хорошая, удовлетворительная или неудовлетворительная. Такие оценки могут проводиться экспертно на основе анализа возможной трудоемкости и длительности процессов переноса комплекса программ на новую платформу. 23 Сопровождаемость может иметь ограниченный характер редкой полной замены программ на вновь разработанные версии, и тем самым, сливаться с процессами разработки или осуществляться как непрерывная поддержка множества пользователей консультациями, адаптациями и корректировками программ. В зависимости от этого различаются функции и трудоемкость процессов сопровождения, которая может использоваться как обобщенная качественная характеристика при выборе и установлении требований к этому показателю качества. Соответственно качественно могут быть установлены субхарактеристики сопровождаемости и описаны требуемые их свойства. Практичность тесно связана с функциональной пригодностью. Обобщенно этот показатель можно отразить трудоемкостью и длительностью, которые необходимы для изучения и полного освоения функций и технологии применения соответствующего ПС. Каждая из субхарактеристик практичности имеет ряд качественных атрибутов, которые могут выбираться и оцениваться экспертно с учетом функционального назначения ПС, а также надежности и ресурсной эффективности комплекса программ. Некоторые из этих атрибутов можно квалифицировать количественно, но в целом атрибуты и субхарактеристики практичности представляются отдельными точками на шкале категорий признаков. Таблица 4. Характеристики качества Практичность Понятность: четкость концепции ПС демонстрационные возможности наглядность и полнота документации Простота использования: простота управления функциями комфортность эксплуатации среднее время ввода заданий среднее время отклика на задание Изучаемость трудоемкость изучения применения ПС продолжительность изучения объем эксплуатационной документации объем электронных учебников Привлекательность: субъективные или экспертные оценки Сопровождаемость Мера Шкала порядковая Отличная; хорошая; удовлетворит. неудовлетворит. порядковая Отлич.; хорошая; удовлет.;неудовл. секунды 1 - 1000 Чел.-часы 1 - 1000 Часы 1 - 1000 Страницы 1 - 1000 Кбайты 1 - 1000 порядковая порядковая Анализируемость: 24 Отлич.; хорошая; удовлет.;неудовл. Отлич.; хорошая; удовлет.;неудовл. стройность архитектуры программ унифицированность интерфейсов полнота и корректность документации Изменяемость: трудоемкость подготовки изменений длительность подготовки изменений Стабильность: устойчивость к негативным проявлениям при изменениях Тестируемость: трудоемкость тестирования изменений длительность тестирования изменений Мобильность Адаптируемость: трудоемкость адаптации длительность адаптации Простота установки: трудоемкость инсталяции длительность инсталяции Сосуществование соответствие: стандартизация интерфейсов с аппаратной и операционной средой Замещаемость: трудоемкость замены компонентов длительность замены компонентов Чел.-часы Часы 1-1000 1-1000 порядковая Отлич.; хорошая; удовлет.;неудовл. Чел.-часы 1-1000 часы 1-1000 порядковая Отлич.; хорошая; удовлет.;неудовл. Чел.-часы 1-1000 часы 1-1000 Чел.-часы часы 1-100 1-100 Чел.-часы часы 1-100 1-100 порядковая Отлич.; хорошая; удовлет.;неудовл. Чел.-часы 1-100 часы 1-100 4.5. Выбор показателей качества Исходными данными и высшим приоритетом при выборе показателей качества в большинстве случаев являются назначение, функции и функциональная пригодность соответствующего программного средства. Достаточно полное и корректное описание этих свойств должно служить базой для определения значений большинства остальных характеристик и атрибутов качества. Принципиальные и технические возможности и точность измерения значений атрибутов характеристик качества всегда ограничены в соответствии с их содержанием. Это определяет рациональные диапазоны значений каждого атрибута, которые могут быть выбраны на основе здравого смысла, а также путем анализа прецедентов в спецификациях требований реальных проектов. 25 Процессы выбора и установления метрик и шкал для описания характеристик качества программных средств можно разделить на два этапа: выбор и обоснование набора исходных данных, отражающих общие особенности и этапы жизненного цикла проекта программного средства и его потребителей, каждый из которых влияет на определенные характеристики качества комплекса программ; выбор, установление и утверждение конкретных метрик и шкал измерения характеристик и атрибутов качества проекта для их последующей оценки и сопоставления с требованиями спецификаций в процессе квалификационных испытаний или сертификации на определенных этапах жизненного цикла программного средства. На первом этапе за основу следует брать всю базовую номенклатуру характеристик, субхарактеристик и атрибутов, стандартизированных в ISO 9126. Их описания желательно предварительно упорядочить по приоритетам с учетом назначения и сферы применения конкретного проекта программного средства. Далее необходимо выделить и ранжировать по приоритетам потребителей, которым необходимы определенные показатели качества проекта программного средства с учетом их специализации и профессиональных интересов. Подготовка исходных данных завершается выделением номенклатуры базовых, приоритетных показателей качества, определяющих функциональную пригодность программного средства для определенных потребителей. На втором этапе, после фиксирования исходных данных, которое должен выполнить потребитель оценок качества, процессы выбора номенклатуры и метрик начинаются с ранжирования характеристик и субхарактеристик для конкретного проекта и их потребителя. Далее этими специалистами для каждого из отобранных показателей должна быть установлена и согласована метрика и шкала оценок субхарактеристик и их атрибутов для проекта и потребителя результатов анализа. Для показателей, представляемых качественными признаками, желательно определить и зафиксировать в спецификациях описания условий, при которых следует считать, что данная характеристика реализуется в программном средстве. Выбранные значения характеристик качества и их атрибутов должны быть предварительно проверены разработчиками на их реализуемость с учетом доступных ресурсов конкретного проекта и при необходимости откорректированы. 4.6. Стандартизация оценивания качества готового программного продукта Методологии оценивания характеристик качества готовых программных средств и их компонентов (программного продукта) на различных этапах жизненного цикла посвящен базовый международный стандарт ISO 14598-1-6:1998-2000 – "Оценивание программного продукта. Часть 1. 1999. Общий обзор. Часть 2. 2000. Планирование и управление. Часть 3. 2000. Процесс для разработчиков. Часть 4. 1999. Процесс для приобретателей. Часть 5. 1998. Процесс для оценщиков (испытателей). Часть 6. Документирование оценки модулей" (проект). В первой части изложена концепция и методология применения стандарта. Отмечается глубокая связь его положений со стандартами ISO 12207 и ISO 9126. При этом ссылки на последний стандарт даются на новые редакции проектов его частей. Рекомендуется общая схема процессов оценивания характеристик качества программ, описанная более подробно в последующих четырех разделах. В схему процессов оценивания входят: 26 установка и формализация исходных требований для оценивания – определение целей испытаний; идентификация типа метрик программного средства; выделение адекватных показателей и требуемых значений атрибутов качества; формализация принципов и особенностей оценивания при проведении экспертиз и измерений характеристик качества программного средства; селекция метрик качества; установление рейтингов и уровней приоритета метрик субхарактеристик и атрибутов; выделение критериев для проведения измерений; планирование и проектирование процессов оценивания характеристик и атрибутов качества в жизненном цикле ПС; выполнение измерений для оценивания; сравнение результатов с критериями и требованиями; обобщение и оценка результатов. В этом стандарте, так же, как в ISO 9126, выделяются характеристики качества: для пользователей; внешние и внутренние показатели, а также схема взаимосвязи внутренних и внешних характеристик качества и их атрибутов. Для каждой характеристики качества рекомендуется формировать шкалу измерений с выделением требуемых, допустимых и неудовлетворительных значений. Изложена концепция планирования и управления процессами оценивания, а также их связь с процессами управления жизненным циклом ПС. Представлены общие рекомендации по организации, технологии, инструментальному оснащению и проведению испытаний качества ПС. При подготовке к оцениванию рекомендуется преобразовывать и структурировать технологию и процедуры использования ПС для выявления небольших групп или отдельных атрибутов качества для их последовательного удобного измерения. Выделены разделы: концепция оценивания; специфика определения требований к процессам оценивания; идентификация характеристик и атрибутов качества для конкретных пользователей результатов испытаний. Требования к процессам оценивания рекомендуется структурировать на главные (функциональные), организационные, проектные, а также выделять внутренние и внешние показатели качества и их измерение. Рекомендуемая технология выполнения оценивания программ включает: специфицирование внешних и внутренних атрибутов определяемых субхарактеристик качества; планирование и проектирование процессов их оценивания; реализацию процессов испытаний и оценивания выделенных характеристик качества; анализ результатов и обобщение выводов о реальном качестве программного продукта. Реализация процессов оценивания должна быть достаточно автономной и независимой, однако, коррелированной с этапами жизненного цикла конкретного проекта ПС в соответствии с применяемой, адаптированной версией стандарта ISO 12207:1995. Характеристики и атрибуты качества рекомендуется использовать в терминах и понятиях новых (еще не утвержденных) версий четырех частей стандарта ISO 9126, а также путем применения шкал количественных и/или балльных оценок свойств или уровней качества с несколькими градациями. Стандарт по оцениванию предлагается применять: лабораториям по тестированию комплексов программ и их компонентов, поставщикам, потребителям, пользователям и сертификационным организациям при оценивании качества программных средств на различных этапах жизненного цикла. 27 5. Качество технического проекта Измерение качества проектирования является очень важной составляющей частью в процессе обеспечения качества программного продукта. Особую важность это приобретает при объектно–ориентированном проектировании программных систем. Объектно–ориентированная разработка программ вводит новые факторы качества, связанные с повторным использованием ранее выполненных наработок и выполнением модификаций. Идеально повторное использование и модификация может быть произведена на нескольких уровнях: уровень исходного кода, физический дизайн, логический дизайн, требования, - и до различной степени: в рамках системы, в рамках проекта, в рамках компании. Процесс модификации программной системы включает три главных фазы: реструктуризация (создание логически эквивалентной системы); обратный инжиниринг (reverse engineering, анализ системы с целью выделения системных компонент, их функций и взаимосвязей, включая спецификации верхнего уровня системы); прямой инжиниринг (forward engineering, разработка системы от спецификаций до кодирования и внедрения). В настоящее время выполняется большое количество проектов, связанных с переводом использующихся унаследованных систем в объектно-ориентированные системы для увеличения их срока жизни и функционального развития. Критичным в таких проектах является контроль качества, на который ложится задача гарантировать обеспечение роста или неуменьшения уровня потребительских характеристик программных систем. В процессе инжиниринга программных систем в дополнение к классическим метрикам должны быть включены в число наиболее важных такие метрики качества объектно-ориентированного дизайна как: надежность (reliability), сложность (complexity) и возможность повторного использования (reusabiblity). Измерение качества проектирования является принципиально важной частью процесса разработки, поскольку, как показывает статистика стоимость ошибки проектирования в среднем на два порядка выше стоимости ошибки кодирования. При измерении факторов качества широко используется модель: фактор а критерий а измерение (factor а criteria а measurement). Установка связи фактор а критерий требует анализа составляющих факторов качества. Например: Надежность – фактор, отражающий возможность установления явных соответствий между требованиями к системе и ее реализацией. Данное соответствие устанавливается через дизайн системы. Игнорирование этого обстоятельства является частой причиной выпуска ненадежных систем. Сложность – фактор, отражающий трудность понимания, реализации и модификации. Сложные проектные решения трудно реализовывать, при этом они чреваты большими ошибками при реализации. Возможность повторного использования – фактор, отражающий степень применимости проектных решений в различных контекстах. Наличие таких решений значительно уменьшают размер проекта, повышают выветренность решений и более высокую степень соответствия проблемной области. В соответствии с анализом, каждому фактору ставятся в соответствие критерии и, далее, метрики для измерения критериев (рис. 10). 28 Рис. 10 Модель: Фактор>Критерий>Метрика Далее конкретные метрики выводятся в соответствии с особенностями проекта из критериев качества: accuracy (точность), completeness (полнота), consistency (согласованность), module size (размер модулей), data coupling (связь модулей по данным), cohesion (связность), modularity (модульность), span of control (норма управляемости). 29 6. Измерение качества на основе сопровождения продукта Одной из главных путей способов повышения качества является путь анализа практического опыта использования данного продукта или процесса и использования полученных данных для его совершенствования. Речь идет о так называемой парадигме QIP – Quality Improvement Paradigm. Парадигма совершенствования качества дает систематический подход к организации процессов сбора практического опыта, систематизации накопленной информации и подготовке результирующих выводов для улучшения качества. Одним из главных процессов в дисциплине разработки программ, где этот опыт должен накапливаться, является процесс сопровождения. Потеря значимой информации на этапе сопровождения или несистематический недостаточно формальный процесс сбора информации неизбежно дает недостаточно объективную или искаженную основу для принятия технических решений о путях развития и совершенствования программной системы Парадигма улучшения качества представляет собой схему для применения научного подхода в контексте дисциплины инженерии программного обеспечения для совершенствования процесса разработки и связанных с ним результирующих программных продуктов. Наиболее применимым способом реализации парадигмы улучшения качества является иерархический подход формирования информации: от целей к вытекающим из них вопросам, от вопросов - к метрикам (рис. 11). Рис. 11 Модель: Цели>Вопросы>Метрики Другой частью метода является стандартный научный подход к выработке решений: формулирование проблемы, сбор данных и планирование, формирование гипотез, подготовка к проверке, исполнение проверки, анализ результатов, формулировка решения (рис. 12). Важно подчеркнуть, что данный процесс должен идти строго на метрической основе. В противном случае полезность получаемых результатов значительно снижается. 30 Рис. 12. Вывод решений (научный подход) Итогом процесса является накопление знаний о качестве. Для больших систем, находящихся длительное время в эксплуатации, в особенности для распределенных систем необходимым условием здесь является регулярность структур базы данных о качестве. Одним из наиболее эффективных решений является организация информации в виде так называемых фреймов качества: (рис. 13). Рис. 13. Фрейм качества База знаний о качестве находящегося на сопровождении программного продукта является очень точным и достаточным источником для формирования требований к новой версии продукта и принятия решений, основанных на количественном анализе, о развитии существующих подсистем, создании новых версий, снятии с эксплуатации и т.п. 31 7. Интегральная оценка качества Интегральная оценка качества производится на основе анализа взаимовлияния различных параметров характеризующих качество продукта (рис. 14). Рис.14. Диаграмма влияния для подмножества метрик качества 7.1 Методология метрического анализа качества В настоящее время разработано множество метрик качества программного обеспечения общего назначения, таких как сложность, модульность, тестируемость и т.п. Использование данных метрик, безусловно, очень полезно, вместе с тем следует учитывать, что универсальные метрики в совокупности не дают полного численного описания уровня качества. В частности, вследствие универсальности им присущи следующие недостатки: они базируются в большей степени на лексических и синтаксических характеристиках и не учитывают семантическую составляющую продукта; они сконструированы без учета особенностей требуемой предметной области, операционного окружения и методологии разработки. Традиционные метрики не учитывают качество обрабатываемых данных и взаимодействие данных с потоком вычислений. Для обеспечения полноты измерения качества требуется на ранних стадиях проекта на основе анализа целей проекта, области применения, ограничений и характеристик разработать проектно-ориентированные (design-oriented) или структурные метрики (structural metrics) качества. Термин «проектно-ориентированный» в данном контексте означает, что метрики разрабатываются в виде стандарта качества проекта на его ранних стадиях и представляют собой правила или нормы (guideline), которым должен удовлетворять промежуточный или конечный продукт. Термин структурный означает, что метрики разрабатываются структурным методом сверху - вниз (top – down) для обеспечения целостности и полноты. 32 Измерение качества в соответствии с данными метриками состоит в вычислении отклонения фактических характеристик продукта от норм и правил. Методология создания метрик качества указанным способом утверждена в стандарте IEEE 1061. Схематически методология создания метрик качества состоит из следующих шагов: Первый шаг (верхний уровень иерархии): Определение нетехнического уровня (то есть уровня предназначенного для менеджеров, пользователей, заказчика): Формирование требований качества Выбор свойств (атрибутов), установка приоритетов и связи с требованиями Присвоение атрибутов факторам качества, которые отражают представление заказчика на качество. Установка измерений для факторов качества. Определение допустимых коридоров для величин качества. Второй шаг (средний уровень иерархии): Определение технического уровня (то есть уровня предназначенного для аналитиков, конструкторов, разработчиков): Осуществление декомпозиции факторов качества в измеряемые характеристики программного обеспечения, определяемые как суб-факторы. Третий шаг (нижний уровень иерархии): Декомпозиция суб-факторов в метрики, которые могут быть применены непосредственно к программному продукту или процессу разработки. Данные метрики служат как непрямые меры (индикаторы) прямых измерений факторов качества на верхних уровнях иерархии. Иными словами это уровень разработанных правил и норм, которым должен удовлетворять продукт или процесс с тем, чтобы были выполнены факторы качества (рис. 15). Рис. 15. Схема вывода метрик качества Для иллюстрации метода можно привести следующие примеры: Факторы качества программной системы: Переносимость (portability) – усилия, требуемые для переноса системы с одной платформы на другую. Надежность (reliability) – ожидаемая степень корректного выполнения системой требуемых функций Тестируемость (testability) – усилия, требуемые для тестирования функций программы Прямые измерения факторов качества: 33 Переносимость (portability) – трудоемкость - количество чел.-час., требуемое для переноса программы с платформы X на платформу Y. Допустимый порог: 1 чел.-час. на 1K строк исходного кода . Надежность (reliability) – среднее время наработки на отказ. Допустимый порог: 120 операционных дней. Тестируемость (testability) – трудоемкость – количество чел.-час., требуемое для полного тестирования 90% всех модулей. Допустимый порог 10 чел.-час. на 1K строк исходного кода. Следующий шаг – проведение декомпозиции приведенных факторов на суб-факторы (рис. 16). Рис. 16. Пример структуры факторов качества Должны быть даны определения суб-факторов качества. Примеры требуемых определений по Артуру (Arthur L.A.): Точность (accuracy) – правильность вычислений и контроля; Сложность (complexity) – трудность разработки и модификации; Совместимость (consistency) – использование унифицированной технологии проектирования и разработки на протяжении всего цикла разработки; Устойчивость к ошибкам (error tolerance) – степень ущерба от возникающих ошибок; Универсальность (generality) – широта потенциального использования; Аппаратная независимость (hardware independence) – степень применимости программы на другом аппаратном обеспечении; Оснащенность средствами контроля (instrumentation) – степень контроля программы собственного выполнения и идентификации возникающих ошибок; Модульность (modularity) – степень функциональной независимости программных компонент; Удобочитаемость (readability) – уровень смыслового наполнения комментирования, соответствие стандартам кодирования и именования; Простота (simplicity) – легкость понимания программы; Системная независимость (system independence) степень независимости от нестандартных характеристик системного окружения и ограничений. 34 Окончательно, для приведенных суб-факторов должны быть определены правила (нормы) и метрики. В случае возможности, целесообразно использовать стандартные метрики для проведения измерений. Приведем несколько примеров: Сложность (complexity): – использование метрики цикломатической сложности Мак Каба (McCabe’s cyclomatic complexity metric) Устойчивость к ошибкам (error tolerance): использование правила (нормы): «все модули должны содержать обработчики предопределенных исключительных ситуаций. Все обрабатываемые исключительные ситуации должны быть либо распространены на внешний уровень, либо разрешены». Метрики и правила (нормы) могут быть использованы для планирования уровня качества и для непосредственных измерений. Например, метрикой для правила может быть количество нарушений нормы на единицу объема программного обеспечения. Важным свойством приведенных иерархических метрик является возможность предсказания уровня качества, которое может быть выведено на основе измерения непрямых метрик. При этом получение измерения на верхнем уровне иерархии производится обычно расчетом взвешенной суммы метрик нижнего уровня. Преимущества методологии качества IEEE основано на возможности обеспечения полноты управления качеством в проектах разработки программного обеспечения. При этом эффективность управления качеством будет зависеть от тщательности проектирования иерархической структуры метрик качества на основе целей и особенностей конкретного проекта разработки программного обеспечения. Важной особенностью подхода IEEE является возможность управлять качеством на всех этапах жизненного цикла разработки программного обеспечения, поскольку разработанные правила и нормы (guidelines) для всех факторов качества являются не только метриками, но и инструкциями, выполнение которых может планироваться до исполнения и контролироваться в процессе работы. Детальная разработка системы качества по данной методике требует времени и средств, поэтому в практике разработки программных систем она используется при создании и внедрении высококритичных программных систем с высокой стоимостью разработки (системы управления транспортом, системы военного назначения, системы обеспечения безопасности, банковские системы и т.п.) 35 8. Заключение Опыт управления качеством показывает, что финансовые затраты, произведенные для улучшения качества продукта, являются безусловно целесообразными и дают в итоге высокий экономический эффект. Причина, по которой многие организации воздерживаются от таких расходов, состоит, прежде всего, в трудностях связанных с планированием и оценкой результатов повышения качества. Частой является ситуация, когда реализуется решение о повышении качества, основываясь на неформальных, интуитивных способах оценки качества. Это неизбежно ведет к неэффективному расходованию ресурсов и фактически увеличивает реальную цену качества. Тщательно проведенный метрический анализ качества в соответствии с целями разработки создает основу для корректного планирования и контроля затрат на качество для достижения требуемых показателей и эффективности использования ресурсов. 36 9. Глоссарий Возможность процесса разработки ПО (software process capability) описывает ожидаемый результат, который можно достигнуть, следуя процессу разработки. Зрелость процесса разработки ПО (software process maturity) – это степень определенности, управляемости, измеряемости и эффективности процесса разработки ПО. Качество (quality) – степень соответствия системы, компоненты, процесса или службы потребностям и ожиданиям клиента или пользователя. Количественное управление процессом (quantitative process management) заключается в выявлении причин для особых отклонений процесса от планируемого и подобающего исправления этих причин (таким образом, качество процесса измеряется не в количестве написанных строк кода или найденных ошибок, а в соответствии процесса исходному плану). Обеспечение качества ПО (software quality assurance) предназначено для информирования руководства об успешности и зрелости процесса разработки ПО и конечных продуктах Определение процесса (process definition) - это рабочее определение набора мер, необходимых для достижения намеченных целей. Характеризуется стандартами, процедурами, обучением, средствами и методами. Планирование проекта (software project planning) устанавливает разумные планы для разработки ПО, на основе которых производится управление программным проектом. Постоянное улучшение процессов (continuous process improvement) обеспечивает повышение производительности, качества продуктов и уменьшение цикла разработки ПО. Предотвращение дефектов (defect prevention) заключается в определении причин возникновения дефектов и в принятии мер по предотвращению их дальнейшего возникновения. Программный процесс (software process) – набор технологических процедур, используемых организацией для планирования, управления, выполнения, контроля и улучшения работ по созданию ПО. Производительность программного процесса (software process performance) представляет собой реальные результаты венедрения программного процесса. Управление качеством (software quality management) – это процесс, состоящий из численного измерения качества процесса разработки ПО, формулирования определенных целей по улучшению качества и их достижению. Управление конфигурацией ПО (software configuration management) создает и поддерживает целостность продуктов программного проекта в течение всего жизненного цикла ПО. Управление изменениями технологий (technology change management) помогает определить и организованно внедрить на предприятии потенциально выгодные новые технологии (т.е. средства, методы и процессы). Управление программным проектом (software project tracking and oversight) состоит в отслеживании степени успешности и продвижении программного проекта и в принятии соответствующих мер при возникновении существенных отклонений проекта от плана. Управление субподрядчиками (software subcontract management) заключается в выборе квалифицированных субподрядчиков и эффективном управлении ими. Управление требованиями (requirements management) – это процесс приведения в соответствие представлений пользователя о желаемых результатах и формулируемых требований к разработчику программного проекта. Список литературы 1. Попов «Метрики качества программного обеспечения» http://www.pmprofy.ru/content/rus/67/672-article.asp 2. В.В. Липаев «Оценка качества программных средств» ”Сетевой журнал” №3.2002 http://www.setevoi.ru 3. В.В. Липаев «Стандартизация характеристик и оценивания качества программных средств» http://www.fostas.ru/library/Lipaev_6.rtf 4. А. А.Терехов, В. Туньон «Современные модели качества программного обеспечения» Журнал BYTE/Россия, №12, 1999 http://www.interface.ru/misc/qs.htm 5. М. Аншина «Страсти по качеству» http://www.interface.ru/mrp/quality.htm 6. Немного истории о качестве http://www.m2bc.ru/qs_kratk_obz_2 7. Классическая философия качества http://www.interface.ru/mrp/qf_classic.htm 8. Джеффри Воас «Качество ПО: восемь мифов» Журнал "Открытые Системы", #09-10/1999 http://www.naumen.ru/go/company/obj1041600305/obj1042103182?prn=1 9. IEEE Standard Dictionary of Measures to Produce Reliable Software iel_cgi982.1.4.pdf 10. IEEE Standard for Software Verification and Validation iel_cgi1012.8.pdf 11. Supplement for IEEE Standard for Software Verification and Validation iel_cgi1012a_8.pdf 38
