CMMI и ISO/IEC 15504 – сходства и различия.

Самым известным стандартом качества ПС считается CMM (Capability Maturity Model – модель оценки уровня зрелости процессов разработки ПС). Модель СММ предусматривает 5 уровней зрелости: 1. Начальный (управление кач-вом не ведется), 2. Повторяющийся (осущ-ся планирование пр.проектов), 3. Определенный (использует экспертные оценки кач-ва, координацию вз.действия групп, имеет пр-му обучения персонала), 4. Управляемый (использует менеджмент кач-ва ПО), 5. Оптимизируемый (включает управление измерениями процесса и имеет с-му предотвращения несоот-вия).

Стандарт СММ оказался крайне популярен в 90ые гг 20в., но имел ряд недостатков, основным из к-рых явл-ся недостаточно жесткая с-ма контроля за орг-циями, аккредитованными присваивать тот/иной уровень зрелости модели СММ.

Разрешить проблемы стандарта СММ призван новый стандарт CMMI (Capability Maturity Model Integrate – интегрированная модель оценки уровня зрелости процессов разработки программного обеспечения). В рамках CMMI были объединены все существующие варианты CMMI и исключены какие-либо противоречия при практическом применении стандарта в различных сферах деятельности. Для того, чтобы устранить необходимость выравнивания процессов организации, стандарт CMMI имеет более глубокую структуру и две формы представления:

1. классическую многоуровневую, соответствующую CMM;

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

Стандарты ISO серии 9000 обширная, наиболее распространённая во всем мире серия стандартов качества. В 1997 году, был выпущен стандарт ISO 9000-3: 1997, который оперировал терминологией, использующейся при разработке ПО и представлял собой адаптацию используемого в промышленности стандарта ISO 9000-1, который определял требования к системам менеджмента качества. В 2004г. стандарт заменён на новый стандарт ISO/IEC 90003: 2004. Новый стандарт ещё более приспособлен к специфике отрасли, он ссылается на модели жизненного цикла ПС и детально рассматривает вопросы, характерные для разработки ПО. Недостатком данного стандарта является то, что он не может быть использован для оценки уровня зрелости и для оценки результата программного проекта. Для устранения этого недостатка был выпущен специальный стандарт ISO/IEC 15504: 2004.

Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия, датированная 2004 г., предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI.

Уровни CMMI и ISO/IEC 15504: 2004

В целом стандарты ISO/IEC 15504 и CMMI взаимозаменяемы, в частности, для CMMI предусматривается режим сертификации, в соответствии с которым одновременно проводится и сертификация по ISO/IEC 15504. Однако, в системе стандартов ISO чуть больше опыта в области сертификации, а так же существуют дополнительные стандарты, расширяющие его применение.

Одним из таких стандартов является ISO/IEC 9126, который регламентирует качество программного продукта. Данный стандарт состоит из 4 частей, выпускаемых отдельно: 1. Модель качества, 2. Внешние метрики, 3. Внутренние метрики, 4. Качество при использовании метрик.

Данный стандарт предлагает комплексную иерархическую структуру, для описания качественных характеристик ПО. На текущий момент, данный стандарт является самым авторитетным стандартом, определяющий качество программного продукта.

Документ " Программа-методика испытания программного средства". Содержание и сфера применения

Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Программа и методика испытаний», определенного ГОСТ 19.101-77. 1. Общие положения: 1.1. Структура и оформление документа устанавливается в соответствии с ГОСТ 19.105-78. Составление информационной части (аннотации и содержания) является необязательным. 1.2. Документ «Программа и методика испытаний» должен содержать следующие разделы: объект испытаний; цель испытаний; требования к программе; требования к программной документации; состав и порядок испытаний; методы испытаний. В зависимости от особенностей документа допускается вводить дополнительные разделы.

2. Содержание разделов: 2.1. В разделе «Объект испытаний» указывают наименование, область применения и обозначение испытуемой программы. 2.2. В разделе «Цель испытаний» должна быть указана цель проведения испытаний. 2.3. В разделе " Требования к программе" должны быть указаны требования, подлежащие проверке во время испытаний и заданные в техническом задании на программу. 2.4. В разделе " Требования к программной документации" должны быть указаны состав программной документации, предъявляемой на испытания, а также специальные требования, если они заданы в техническом задании на программу. 2.5. В разделе " Средства и порядок испытаний" должны быть указаны технические и программные средства, используемые во время испытаний, а также порядок проведения испытаний. 2.6. В разделе " Методы испытаний" должны быть приведены описания используемых методов испытаний. Методы испытаний рекомендуется по отдельным показателям располагать в последовательности, в которой эти показатели расположены в разделах " Требования к программе" и " Требования к программной документации". В методах испытаний должны быть приведены описания проверок с указанием результатов проведения испытаний (перечней тестовых примеров, контрольных распечаток тестовых примеров и т. п.). 2.7. В приложение к документу могут быть включены тестовые примеры, контрольные распечатки тестовых примеров, таблицы, графики и т. п.

1. Каскадная модель ЖЦ – основной особенностью каскадной модели ЖЦ является наличие ярко выраженной последовательности выполнения этапов разработки направленных на достижение конечного результата, при этом с любой стадией, как правило, можно вернуться на любую предшествующую стадию разработки. Выделяют следующие основные этапы каскадной модели ЖЦ:

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

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

- Проектирование – в ходе которого формируется интегрированная системная модель будущего программного средства. Проектирование включает создание следующих представлений: Архитектура программного средства; Модульная структура программных средств – набор модулей; Алгоритмическая структура программного средства; Структура данных; Входной и выходной интерфейс; входные и выходные формы данных.

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

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

- Тестирование – состоит в выполнении определенных мероприятий направленных на выявление дефектов в функциях, логике и форме реализации программного средства;

- Сопровождение – состоит во внедрении всевозможных изменений в программные средства, изменения могут быть связанны с: Исправлением ошибок; Адаптацией к изменениям внешней для программы среды; Адаптацией программного средства к новому требованию заказчика. Достоинства каскадной модели ЖЦ: Позволяет планировать по времени все этапы проекта; Упорядочивает ход проектирования благодаря наличию строго оговоренных правил. Недостатки каскадной модели ЖЦ: Возможно организационные проблемы связанные с тем что реальные проекты часто требуют отклонения от сложившейся в последовательности шагов; Предполагается на начальном этапе наличия точной формулировки исходных требований к программным средствам, хотя на практике это трудно достижимо; Экономический – результаты проекта доступны заказчику только после его окончания.

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

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

3. Испытание ПС процесс проведения комплекса мероприятий, исследующих пригодность ПС для успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика. Целью испытания является экспериментальное определение фактических (достигнутых) характеристик свойств испытываемого ПС и определение степени соответствия созданного комплекса программ техническому заданию, полученному от заказчика. Эти характеристики могут быть как количественными, так и качественными. Важно, чтобы на их основе можно было сделать вывод о пригодности данного ПС к использованию по своему назначению. Если вывод отрицательный, то образец ПС возвращается на доработку. Таким образом, перекрывается доступ недоброкачественной продукции к пользователю. Длительность испытания зависит от типа, конфигурации (сложности) ПС, а также от целей и степени автоматизации рассматриваемого технологического процесса. В подготовку испытаний ПС входят: — составление и согласование плана-графика проведения испытания; — разработка, комплектование, испытание и паспортизация программно-технических средств, используемых при испытаниях; — анализ пригодности испытательных средств, используемых во время предварительных испытаний, для проведения приемочных испытаний; — анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС; — проверка и согласование с представителем Заказчика конструкторской документации на ПС, предъявляемой при испытаниях; — разработка, согласование и утверждение программ и методик испытаний; — аттестация специалистов на допуск к проведению испытаний; — приемка испытываемого опытного образца ПС на носителе данных и документации; — проведение мероприятий, направленных на обеспечение достоверности испытаний.

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

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

По согласованию с разработчиком (заказчиком) устанавливается последовательность испытаний ПО с учетом следующих этапов: 1. Проверка документации. 2. Проверка разделения ПО и наличия защищенных интерфейсов (с использованием программных средств, в том числе на основе анализа исходного кода). 3. Проверка соответствия утвержденному типу (идентификация) (на основе анализа документации и с использованием программных средств, в том числе на основе анализа исходного кода). 4. Испытание (тестирование) ПО с целью установления правильности функционирования и определения его свойств и характеристик и тестирование обработки данных (с использованием аппаратных и программных средств, в том числе на основе анализа исходного кода). 5. Тестирование защищенности ПО и данных (с использованием программных средств, в том числе на основе анализа исходного кода).

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

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