Стрелковое оружие
Автор работы: Пользователь скрыл имя, 09 Ноября 2013 в 11:54, отчет по практике
Описание работы
Увеличивающая в мировом масштабе конкуренция среди организаций разработчиков ПО,
повышение требований конечного пользователя к качеству и надежности программных
средств привело их разработчиков к пониманию важности вопросов стандартизации в
области качества.
Содержание работы
Введение
Раздел 1 Стандарты в области обеспечения качества программных систем
1.1 Основные положения стандартов серии ИСО 9000
1.2 Применение ИСО 9001 при разработке ПО
1.3. Показатели качества ПО в ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126
1.4. Модели и метрики оценки качества ПО
Раздел 2 Стандарты, определяющие жизненный цикл ПО
2.1 Модели жизненного цикл программного обеспечения
2.2 Стадии разработки ПО, регламентированных ГОСТами
2.3 Жизненный цикл разработки ПО с повышенными требованиями к безопасности
системы
2.4 Процессы жизненного цикла разработки ПО
2.5 Сравнительный анализ рассмотренных жизненных циклов ПО
Раздел 3 Документирование в процессах жизненного цикла ПО
3.1 Документация и ее роль в обеспечении качества
3.2 Требования стандартов к программной документации
Раздел 4 Оценка процесса разработки программного обеспечения
4.1 Основные положения
4.2 Эталонная модель
4.3 Выполнение оценки
4.4 Модель оценки
Приложение
Литература
Файлы: 1 файл
Содержание
Введение
Раздел 1 Стандарты в области обеспечения качества программных систем
1.1 Основные положения стандартов серии ИСО 9000
1.2 Применение ИСО 9001 при разработке ПО
1.3. Показатели качества ПО в ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126
1.4. Модели и метрики оценки качества ПО
Раздел 2 Стандарты, определяющие жизненный цикл ПО
2.1 Модели жизненного цикл программного обеспечения
2.2 Стадии разработки ПО, регламентированных ГОСТами
2.3 Жизненный цикл разработки ПО с повышенными требованиями к безопасности
системы
2.4 Процессы жизненного цикла разработки ПО
2.5 Сравнительный анализ рассмотренных жизненных циклов ПО
Раздел 3 Документирование в процессах жизненного цикла ПО
3.1 Документация и ее роль в обеспечении качества
3.2 Требования стандартов к программной документации
Раздел 4 Оценка процесса разработки программного обеспечения
4.1 Основные положения
4.2 Эталонная модель
4.3 Выполнение оценки
4.4 Модель оценки
Приложение
Литература
Введение
Увеличивающая в мировом масштабе конкуренция среди организаций разработчиков ПО,
повышение требований конечного пользователя к качеству и надежности программных
средств привело их разработчиков к пониманию важности вопросов стандартизации в
области качества.
Для того чтобы поддерживать конкурентоспособность своей организации разработчики
ПО должны применять все более эффективные, рентабельные методы, технологии,
инструментальные средства, способствующие постоянному повышению качества и более
совершенному удовлетворению потребителей ПО.
Требования потребителей часто включаются в технические условия (ТУ) или
неформализованные требования, описанные на некотором вербальном языке. Однако
технические условия и неформализованные требования сами по себе не гарантируют их
удовлетворение в конечном продукте, так как в настоящее время существует проблема
выработки приемлемых требований к программному продукту, а также ряд других
проблем, возникающих в процессе разработки конечного продукта. Это соображение
привело к разработке стандартов, руководств, руководящих документов, относящихся к
системам качества и дополняющих релевантные требования к ПО, установленные в
технических требованиях. Международные стандарты серии ИСО 9000 впервые создали
общую основу для стандартов на системы качества, применимых в различных областях
деятельности человека. Основные положения серии стандартов ИСО 9000 рассмотрены в
разделе 1 данного учебного пособия.
Международные стандарты серии ИСО 9000 устанавливают, какие именно элементы
должны включаться в систему качества, но не то, каким образом конкретная организация
должна реализовать эти элементы. Введение единообразных систем качества не является
целью этих стандартов. Потребности различных организаций отличаются друг от друга.
На проект и реализацию системы качества обязательно оказывают влияние конкретные
цели, продукция и процессы, а также специфические методы данной организации.
Международные стандарты серии ИСО 9000 основаны на понимании того факта, что
всякая работа выполняется с помощью сети процессов. Каждый процесс имеет входные
факторы, а выходом является результаты процесса - продукция, осязаемая и не осязаемая.
Каждая организация существует для того, чтобы выполнять работу, добавляющую
стоимость. В процессе получения конечного продукта должны быть выполнены
многочисленные операции, включающие в себя организацию, проектирование,
управление технологическими процессами, маркетинг, обучение, управление людскими
ресурсами, стратегическое планирование, поставку, техническое обслуживание и т.д.
Принимая во внимание сложную структуру большинства организаций, важно выделить
основные процессы, а также упростить и ранжировать процессы в зависимости от целей
административного управления качеством.
Любая организация должна определить и установить свою сеть процессов и интерфейсов,
и управлять ею. Организация создает, совершенствует и обеспечивает постоянный
уровень качества своей продукции с помощью сети процессов. Это концептуальная
основа стандартов серии ИСО 9000. В разделе 2 учебного пособия рассмотрены процессы
жизненного цикла ПО и стандарты, их определяющие. Основное внимание в данном
разделе уделено отечественным стандартам 19-ой и 34-ой системы, проекту
международного стандарта ИСО/МЭК 12207, а также документу DO - 178B,
устанавливающему аспекты сертификации программ для авиационных систем.
В стандарте ИСО 2382-1дано следующее определение программного обеспечения (ПО).
ПО - это интеллектуальный продукт, состоящий из программ, процедур, правил и любой
другой связанной с ними документации, относящихся к функционированию системы
обработки данных. Таким образом, документация является неотъемлемой частью ПО и ей,
а также процессу ее формирования, должно уделяться пристальное внимание. Раздел 3
посвящен вопросам документирования процессов жизненного цикла ПО. В нем
рассмотрена роль документации в обеспечении качества ПО, приведены требования
стандартов к документации, разрабатываемой в процессе создания ПО, основные типы и
виды программной документации.
В разделе 4 учебного пособия рассматривается проект стандарта ИСО/МЭК 15504,
являющийся дополнением к другим международным стандартам и другим моделям для
оценки возможности и эффективности организаций и процессов.
ИСО/МЭК 15504 включает намерения серии ISO 9000 обеспечить уверенность в
управлении качества поставщика, обеспечивая пользователей структурой для независимой
оценки возможности потенциальных поставщиков удовлетворить их потребности. Оценка
процесса обеспечивает пользователей способностью оценить возможности процесса на
непрерывной шкале простым и сравнимым способом, а не использовать характеристики
качества, базирующиеся на ISO 9001. Кроме того, структура, описанная в проекте
стандарта ИСО/МЭК 15504, предоставляет возможность регулировать область оценки для
покрытия специфических интересующих процессов, а не всех процессов, используемых
организацией. Стандартизация - наиболее перспективное направление развития
передовых информационных технологий в проектировании, производстве и менеджменте,
и любые усилия в этом направлении должны всячески приветствоваться.
Кроме того, стандартизация процесса разработки и эксплуатации ПО способствует
контролю, оценке и регламентации труда всех участников данного процесса, побуждает к
дисциплине.
Так как стандартизация способствует лучшему контролю и регламентации труда занятых
в процессе разработки специалистов, побуждает их, прежде всего, к дисциплине, а не к
свободному самовыражению в изобретении остроумных трюков и уловок, то введение
стандартов наталкивается на определенный саботаж с их стороны. Необходимо отметить,
что, во-первых, взятые на вооружение и используемые стандарты намного полезнее, чем
хорошие стандарты, записанные на бумаге, а во-вторых, хорошие стандарты получаются
не сразу и в процессе систематического применения и совершенствования плохие
стандарты можно довести до хороших.
Авторы учебного пособия выражают огромную признательность и благодарность доктору
технических наук Ломако А.Г. за предоставленный материал по моделям и метрикам
оценки качества программного обеспечения, приведенный в подразделе 1.4.
Раздел 1
Стандарты в области обеспечения качества программных систем
Прежде чем рассматривать стандарты, регламентирующие аспекты качества
программного обеспечения, необходимо сначала обсудить общие вопросы, касающиеся
качества любого вида продукции. К общим вопросам относятся определения и
терминология в данной области, основные концепции качества, роль документации в
обеспечении качества продукции, а также выбор и применение международных
стандартов качества. Безусловно, основными стандартами в области качества стали
международные стандарты серии ИСО 9000, разработанный Международной
организацией по стандартизации. Следующий подраздел посвящен рассмотрению общих
вопросов, перечисленным выше, в свете стандартов серии ИСО 9000.
1.1 Основные положения стандартов серии ИСО 9000
Во-первых, под стандартами серии ИСО 9000 понимаются все международные стандарты,
разработанные Техническим комитетом 176 Административное управление качеством и
обеспечении качества. Международной организации по стандартизации (ИСО). В
настоящее время серия содержит все международные стандарты с номерами от 9000 до
9004 (включая все части ИСО 9000 и ИСО 9004), от 10001 до 10020 (включая все части), а
также ИСО 8402. Ниже приведены названия основных стандартов, составляющих данную
серию.
ИСО 9000-1-94 Стандарты в области административного управления качеством и
обеспечения качества. Часть 1. Руководящие положения по выбору к применению.
ИСО 9000-2-93 Стандарты в области административного управления качеством и
обеспечения качества. Часть 2. Общие руководящие положения по применению ИСО
9001,ИСО 9002 и ИСО 9003.
ИСО 9000-3-91 Стандарты в области административного управления качеством и
обеспечения качества. Часть 3. Руководящие положения по применению ИСО 9001 при
разработке, поставке и техническом обслуживании ПО.
ИСО 9000-4-93 Стандарты в области административного управления качеством и
обеспечения качества. Часть 4. Руководящие положения по административному
управлению программой общей надежности.
ИСО 9001-94 Системы качества. Модель для обеспечения качества при проектирование,
разработке, производстве, монтаже и обслуживании.
ИСО 9002-94 Системы качества. Модель для обеспечения качества при производстве,
монтаже и обслуживании.
ИСО 9003-94 Системы качества. Модель для обеспечения качества при контроле готовой
продукции и заключительных испытаниях.
ИСO 9004-1-94 Административное управление качеством и элементы системы качества.
Часть 1. Руководящие положения.
ИСО 9004-2-91 Административное управление качеством и элементы системы качества.
Часть 2. Руководящие положения по услугам.
ИСО 9004-3-93 Административное управление качеством и элементы системы качества.
Часть 3. Руководящие положения по обработанным материалам.
ИСО 9004-4-93 Административное управление качеством и элементы системы качества.
Часть 4. Руководящие положения по повышению качества.
ИСО 10011-1-90 Системы качества. Руководящие положения по проверкам. Часть 1.
Проверки.
ИСО 10011-2-91 Системы качества. Руководящие положения по проверкам. Часть 2.
Критерии квалификации экспертов-аудиторов систем качества.
ИСО 10011-3-91 Системы качества. Руководящие положения по проверкам. Часть 3.
Административное управление программами проверок.
ИСО 10012-1-92 Обеспечение качества измерительного оборудования. Требования. Часть
1. Системы метрологического обеспечения измерительного оборудования.
ИСО 10013 Руководства по качеству. Положения по разработке. (На стадии издания).
ИСО 8402-94 Управление качеством и обеспечение качества. Словарь.
Увеличившаяся в настоящее время конкуренция между организациями, производителями
продукции, в том числе и программного обеспечения, приводит к установлению более
жестких требований к качеству это продукции. Для того чтобы быть
конкурентоспособными, организации должны применять эффективные системы, ведущие
к повышению качества продукции и более совершенному удовлетворению требований
своих заказчиков. Правильно сформулированные и полные требования заказчика,
включенные в технические условия, еще не гарантирует того, что эти требования будут
полностью удовлетворены, так как в системе поставок и обеспечения организации
имеются недостатки. Это соображение обусловило разработку стандартов, относящихся к
системам качества и дополняющих требования заказчика к продукции. Межународные
стандарты серии ИСО 9000 предназначены для создания общей основы стандартов на
системы качества. Под системой качества понимается, согласно ИСО 8402, совокупность
организационной структуры, методик, процессов и ресурсов, необходимых для
осуществления общего руководства качеством продукции, производимой организацией.
Система административного управления качеством организации - те аспекты общей
функции управления, используемой организацией, которые определяют политику в
области качества выпускаемой продукции, цели организации и ее ответственность, а
также осуществляют их с помощью средств планирования, управления, обеспечения и
улучшения качества в рамках системы качества. Кроме цели организации, на систему
административного управления качеством влияют выпускаемая ей продукция и
характерные для этой организации методы производства. В силу того, что методы
производства организаций, работающих даже в одной сфере, различны, да и цели
организации не всегда едины, системы качеств этих организаций не совпадает. Основной
задачей системы административного управления качеством является усовершенствование
систем и процессов для повышения качества продукции.
Стандарты серии ИСО 9000 устанавливают, какие именно элементы должны быть
включены в систему качества, тогда как организация сама должна реализовать их с учетом
конкретных целей, продукции и процессов, а также специфических методов,
используемых данной организацией.
Кроме того, руководящие положения и требования стандартов серии ИСО 9000 выражены
в терминах целей системы качества, которые должны быть достигнуты, и не
предписывают способы достижения этих целей, оставляя право выбора этих способов
руководству организации. Стандарты данной серии отличают требования к системам
качества от требований заказчика к продукции. Требования к системам качества являются
дополнительными по отношению к техническим требованиям к продукции. Например,
ИСО 12207 устанавливает жизненный цикл разработки программного обеспечения.
Процессы и модели качества, соответствующие процессу обеспечения качества (2.3 по
ИСО 12207) устанавливаются стандартами серии ИСО 9000.
ИСО 9000-1 идентифицирует четыре общие категории продукции, охватывающие все
виды продукции, поставляемые любой организацией:
1. Технические средства.
2. Программное обеспечение.
3. Обработанные материалы.
4. Услуги.
Требования к системам качества, установленные в международных стандартах серии ИСО
9000 применимы ко всем четырем общим категориям продукции, но терминология и
некоторые положения и аспекты систем административного управления качеством могут
быть различными. Это видно из названий стандартов ИСО 9004 - 2 и ИСО 9004 - 3.
Необходимо отметить, что любая организация предлагает продукцию, как минимум, двух
категорий. Например, организация, занимающаяся разработкой программного
обеспечения, дополнительно предоставляет своим заказчикам услуги по сопровождению
разработанного ПО.
Целью руководящих положений и требований международных стандартов серии ИСО
9000 является удовлетворение требований с позиции четырех аспектов, являющихся
ключевыми для качества продукции.
1. Качество благодаря определению потребностей заказчиков в продукции. Первый аспект
- это качество благодаря определению и модернизации продукции с целью ее
соответствия требованиям и возможностям рынка.
2. Качество благодаря конструкции. Второй аспект - это качество благодаря встраиванию
в продукцию характеристик, способствующих тому, чтобы она отвечала требованиям и
возможностям рынка. Другими словами, качество благодаря конструкции - это те
свойства конструкции, которые влияют на бесперебойность работы изделия в переменных
условиях производства и применения.
3. Качество благодаря соответствию конструкции. Третьим аспектом является качество
благодаря поддержанию постоянного соответствия конструкции, реализации
характеристик, заложенных в проект.
4. Качество благодаря техническому обслуживанию. Четвертый аспект - это качество
благодаря техническому обслуживанию продукции в процессе ее эксплуатации по мере
необходимости, чтобы сохранить желаемые характеристики.
Серия стандартов ИСО 9000 со всей полнотой обеспечивает общие руководящие
положения, качающиеся административного управления, и требования к внешнему
обеспечению качества относительно четырех аспектов.
Международные стандарты серии ИСО 9000 основаны на понимании того факта, что
всякая работа выполняется с помощью процессов (см. рис.1). Каждый процесс имеет
входные факторы. Выходом процесса является результат - продукция, осязаемая и не
осязаемая. Сам процесс является (или должен являться) преобразованием, добавляющим
стоимость. В каждом процессе принимают участие в той или иной мере люди и/или
другие ресурсы. Выходом может быть, например, программа, банковская услуга, готовое
(или промежуточное) изделие любой основной категории продукции. Существуют
возможности сделать измерения на входе, на различных стадиях процесса, а также на
выходе.
Как показано на рис.2 , входы и выходы могут быть нескольких типов: связанные с
продукцией (сплошные линии на рис.2) (например, сырье, готовое изделие) и связанные с
информацией (пунктирные линии) (например, требования к продукции, информационные
характеристики). Данный рисунок представляет процессы поставщика с процессами
субпоставщиком и потребителем в сети поставок. В структуре это сети различные
входные и выходные факторы перемещаются в разных направлениях. Термин продукция
относиться здесь ко всем четырем основным категориям продукции.
Административное управление качеством осуществляется с помощью управления
процессами в организации. Управление процессом имеет две стороны:
управление структурой и функционированием самого процесса, в рамках которго
перемещается продукция или информация;
управление качеством продукции или информации внутри структуры.
Принимая во внимание сложную структуру большинства организаций, важно выделить
основные процессы, а также упростить и ранжировать процессы в зависимости от целей
административного управления качеством. Примером сложной сети процессов может
служить организация, разрабатывающая программное обеспечение согласно ИСО/МЭК
12207 и DO-178.
Рис.1.1 Все работы выполняются с помощью процессов.
Рис.1.2 Взаимосвязь процессов в сети поставок при наличии потоков, связанных с
продукцией и информацией.
Любая организация должна определить и установить свою сеть процессов и интерфейсов,
и управлять ею. Организация создает, совершенствует и обеспечивает постоянный
уровень качества своей продукции с помощью выполнения сети процессов. Это
концептуальная основа стандартов серии ИСО 9000. Процессы и их интерфейсы должны
быть объектами анализа и постоянного совершенствования в целях обеспечения качества
производимой продукции.
При оценке систем качества любой организации, стандарт ИСО 9000-1 рекомендует
задать три важных вопроса относительно каждого оцениваемого процесса сети.
Определены ли эти процессы и документированы ли их процедуры?
Применяются ли эти процессы в полной мере и выполняются ли они согласно
документации?
Эффективны ли эти процессы в достижении ожидаемых результатов?
Результат оценки есть совокупность ответов на эти вопросы, связанные соответственно с
подходом, применением и результатом. Оценка системы качества может различаться по
охватываемой области и включать различные виды деятельности.
Одним из важнейших видов такой деятельности, выполняемой систематически, является
оценка статуса и адекватности системы качества, проводимую руководством организации
согласно стандартам ИСО 9001, 9002, 9003. Выводы, сделанные в процессе оценки
системы качества должны вести к повышению ее эффективности и экономичности.
Источником информации для таких выводов являются также результаты внутренних и
внешних проверок системы качества.
Внутренние проверки качества, проводимые самой организацией (первая сторона),
обеспечивают информацию для эффективного анализа со стороны руководства и
корректирующих, предупреждающих и усовершенствующих действий.
Внешние проверки, проводимые заказчиками продукции (второй стороной) и
независимыми органами (третьей стороной) обеспечивают, соответственно, доверие
заказчика к поставщику и получение сертификата, обеспечив тем самым доверие к целому
ряду потенциальных потребителей продукции организации.
Необходимо также обратить внимание на то, в каких ситуациях может применяться
стандарты серии ИСО 9000 и способ использования данной серии поставщиком.
Международные стандарты серии ИСО 9000 предназначены для применения в следующих
четырех ситуациях.
1. Как руководящие положения по административному управлению качеством. Система
качества в этой ситуации должна повысить свою собственную эффективность, чтобы
выполнить требования к качеству продукции экономичным и оптимальным способом.
2. В условиях заключения контракта между первой и второй стороной. В данной ситуации
потребитель требует, чтобы определенные элементы и процессы системы качества стали
частью системы качества поставщика, указывая при этом конкретную модель обеспечения
качества.
3. При утверждение или регистрации второй стороной. Это та ситуация, в которой
система качества оценивается заказчиком. Поставщик может получить официальное
признание соответствие его продукции стандарту.
4. При сертификации или регистрации третьей стороной. В этой ситуации систему
качества оценивает орган по сертификации, и организация соглашается поддерживать
такую систему качества для всех потребителей своей продукции.
Поставщик может выбрать любой из двух способов использования стандартов серии ИСО
9000: способ, мотивированный руководством и способ, мотивированным
заинтересованным лицом. Наиболее распространенным считается второй способ.
При использование способа, мотивированного заинтересованным лицом, поставщик
изначально вводит систему качества как ответ на непосредственные требования
потребителей. Система качества должна соответствовать требованиям стандартов ИСО
9001, 9002, 9003. Руководство организации играет ведущую роль при этом способе, но
движущей силой является внешнее заинтересованное лицо (потребители).
При использование способа, мотивированного руководством, именно руководство
организации начинает прилагать усилия по определению будущих потребностей и
тенденций рынка. Инструкцией по первоначальному установлению системы качества,
повышающей качество продукции, является стандарт ИСО 9004-1 (и другие части ИСО
9004). Далее поставщик может применить стандарты ИСО 9001, 9002 или 9003, как
модель обеспечения качества для демонстрации адекватности системы качества с целью
получения сертификата. Система качества, реализуемая этим способом, более емкая и
плодотворная, чем реализуемая первым способом.
В стандартах серии ИСО 9000 уделяется пристальное внимание подготовке и
использованию документации, как виду деятельности, добавляющем стоимость.
Соответствующая документация играет значительную роль в следующих видах
деятельности по обеспечению качества:
в достижении требуемого качества продукции;
оценке систем качества;
в повышении качества;
в сохранении достигнутого уровня качества.
При внутренних и внешних проверках документация на процедуры свидетельствует о том,
что процессы определены, процедуры утверждены и находятся под контролем. Только в
данных обстоятельствах проверки гарантируют полную оценку адекватности применения
и выполнения сети процессов организации.
Кроме того, документация играет немаловажную роль в повышении качества продукции.
Если процедуры документированы, применяются и выполняются, то есть возможность
определить, как они выполняются.
Далее более подробно будет рассмотрен стандарт ИСО 9001, в котором определена
модель для обеспечения качества при проектирование, разработке, производстве, монтаже
и обслуживании всех видов продукции, включая программное обеспечение.
1.2 Применение ИСО 9001 при разработке ПО
С прогрессом в области информационных технологий увеличилось количество продукции
программного обеспечения и, соответственно, возросла роль управления качеством этой
продукции. Одним из путей создания системы управления качеством является разработка
руководящих положений по обеспечению качества программного обеспечения.
Требования к общей системе качества, при двусторонней контрактной схеме,
опубликованы в стандарте ИСО 9001. Однако процесс разработки и обслуживания
программного обеспечения отличается от такого же процесса для большинства других
типов промышленной продукции. Поэтому для такой быстро развивающейся области
технологии необходимо разрабатывать дополнительные руководящие положения к
системе качества там, где задействована продукция программного обеспечения, принимая
во внимание современный уровень развития этой области технологии.
Природа развития программного обеспечения такова, что некоторые виды деятельности
связаны лишь с отдельными фазами процесса разработки, тогда как другие могут
относиться ко всему процессу. Ниже будут отражены эти различия, а также руководящие
положения, содействующие применению стандарта ИСО 9001 организациям,
разрабатывающим, поставляющим и обслуживающим продукцию программного
обеспечения.
Руководящие положения предназначены для описания предлагаемых средств управления
и методов разработки программного обеспечения, отвечающего требованиям покупателя.
Это достигается, в первую очередь, предотвращением несоответствия продукции на всех
стадиях, начиная от разработки и кончая техническим обслуживанием.
1. Структура системы качества
Руководство поставщика должно определить и документально оформить свою политику,
цели и обязательства в области качества. Поставщик должен обеспечить понимание этой
политики, ее осуществление и внедрение на всех уровнях в конкретной организации.
Ответственность, полномочия и взаимодействие всего персонала, который руководит,
выполняет и проверяет работу, оказывающую влияние на качество, должно быть четко
определены. Особенно это касается персонала, которому необходимы организационная
свобода и полномочия для:
проведения мероприятий, направленных на предупреждение случаев несоответствия
продукции;
выявление и регистрация любых проблем в области качества продукции;
инициирования, выработки рекомендаций или обеспечения выполнения решений в
установленном порядке;
проверка выполнения решений;
контроля за дальнейшей обработкой несоответствующей продукции, ее поставкой или
монтажом до тех пор, пока выявленные дефекты или неудовлетворительные условия не
будут устранены.
Поставщик должен определить требования к внутренней проверке, обеспечить
необходимые средства и назначить специально подготовленный персонал для ее
проведения. Проверка должна включать контроль, испытание и регулирование процессов
проектирования, производства, монтажа и обслуживания и/или продукции; анализ проекта
и проверки системы качества, процессов и/или продукции должны выполняться
персоналом, независимым от тех, кто несет непосредственную ответственность за
выполненную работу.
Поставщик должен назначить представителя руководства, который независимо от других
обязанностей должен иметь определенные полномочия и нести ответственность за
выполнение и соблюдение требований стандарта ИСО 9001.
Система качества, удовлетворяющая требования ИСО 9001, должна периодически
анализироваться руководством поставщика с тем, чтобы гарантировать постоянную
пригодность и эффективность системы. Следует вести протоколы подобных анализов.
Покупатель должен сотрудничать с поставщиком с тем, чтобы своевременно обеспечить
его всей необходимой информацией и разрешить возникающие проблемы.
Покупатель должен назначит представителя, ответственного за связь с поставщиком по
вопросам контракта. Этот представитель должен иметь полномочия решать следующие
связанные с контрактом вопросы (но не ограничиваться ими):
определять требования покупателя к поставщику;
отвечать на вопросы поставщика;
принимать предложения поставщика;
заключать соглашения с поставщиком;
гарантировать соблюдение организацией, представляющей покупателя, соглашений,
заключенных с поставщиком;
определять критерии процедуры и приемки;
принимать решения по тем элементам программного обеспечения, которые признаны
непригодными для использования.
Регулярный совместный анализ, проводимый покупателем и поставщиком, должен
планироваться с тем, чтобы охватить следующий круг вопросов:
соответствия программного обеспечения техническому заданию, согласованного с
покупателем;
результаты контроля;
результаты приемочных испытаний.
Результаты такого анализа должны быть согласованы и зарегистрированы.
Поставщик должен разработать и документально оформить систему качества. Система
качества должна представлять собой единый процесс. Проходящий через весь жизненный
цикл продукции, гарантируя тем самым, что качество формируется в ходе разработки, а
не вдруг обнаруживается в конце всего процесса. Упор необходимо делать на
предупреждение появления дефектов, а не на исправление их после возникновения.
Поставщик должен гарантировать эффективную реализацию документально оформленной
системы качества. Все элементы, требования и положения системы качества должны быть
четко представлены документально.
Поставщик обязан подготовить и документально оформить план качества, с тем, чтобы
выполнить мероприятия по обеспечению качества для каждой разработки ПО на базе
системы качества и чтобы обеспечить ее понимание и соблюдение заинтересованными
организациями.
Поставщик должен разработать законченную систему плановых внутренних проверок
качества, чтобы удостовериться в соответствии деятельности по обеспечению качества
запланированным мероприятиям и определить эффективность системы качества.
Проверки должны планироваться исходя из статуса и важности различных видов
деятельности.
Проверки и последующие действия должны проводиться в соответствии с документально
оформленными процедурами.
Результаты проверок должны оформляться документально и доводиться до сведения
персонала, ответственного за проверенный участок работы. Руководящий персонал,
ответственный за этот участок, должен предпринять своевременные меры по устранению
выявленных проверкой недостатков.
Поставщик должен разрабатывать, документально оформлять и выполнять процедуры,
обеспечивающие:
выявление причин несоответствия продукции и корректирующие воздействия,
предупреждающие повторение дефектов;
анализ всех процессов, рабочих операций, отступлений от требований контрактов,
зарегистрированных данных по качеству, отчетов об использовании и рекламаций
пользователей в целях выявления и устранения потенциальных причин несоответствия
продукции;
проведение профилактических действий для решения проблем на уровне,
соответствующем реальному риску;
осуществление контроля, с тем чтобы удостовериться в действительной реализации и
эффективности корректирующих воздействий;
внедрение изменений в процедурах, вызванных корректирующими воздействиями, и их
регистрация.
2. Система качества - жизненный цикл.
Проект разработки ПО должен осуществляться в соответствии с моделью жизненного
цикла. Действия, связанные с обеспечением качества, должны планироваться и
проводиться с учетом особенностей выбранной модели ЖЦ.
Поставщик должен устанавливать и выполнять процедуры, обеспечивающие проведение
анализа контракта и координацию этой деятельности.
Каждый контракт должен быть изучен поставщиком, чтобы гарантировать, что:
область действия контракта, а также требования, определены и оформлены
документально;
вероятные случайности или риск идентифицированы;
информация, являющаяся собственностью фирмы, достаточно защищена;
любые требования, отличные от тех, которые содержаться в заявке на контракт,
нашли необходимое решение;
поставщик имеет возможности выполнить контрактные обязательства;
ответственность поставщика в отношении подрядных работ определена;
терминология согласована обеими сторонами;
покупатель имеет возможность выполнить контрактные обязательства.
Для разработки ПО поставщик должен иметь полный недвусмысленный набор
функциональных требований. Кроме того, эти требования должны отражать все аспекты,
необходимые для удовлетворения потребностей покупателя. Сюда можно отнести, но не
ограничиваться этим, следующие: эксплуатационные качества, безопасность, надежность,
гарантию и приватность.
Эти требования должны быть сформулированы достаточно точно, с тем, чтобы
производить оценку во время приемки продукции.
В техническом задании (ТЗ) эти требования фиксируются. В некоторых случаях этот
документ разрабатывается покупателем. В других случаях он разрабатывается
поставщиком в тесном сотрудничестве с покупателем; при этом поставщик должен
получить согласие покупателя прежде, чем начнется стадия разработки.
Техническое задание покупателя должно быть объектом контроля за документацией и
управления конфигурацией, как часть документации на разработку.
Все интерфейсы между определенной продукцией ПО и другой продукцией ПО или
аппаратных средств должны быть полностью определены либо непосредственно, либо
путем ссылок в техническом задании покупателя.
В процессе разработки ТЗ покупателя рекомендуется обратить внимание на следующие
вопросы:
назначение лиц (с обеих сторон), ответственных за разработку ТЗ покупателя;
методы согласования требований и утверждение изменений;
усилия по предотвращению неправильного понимания, т.е. определение терминов,
объяснение исходных данных в отношении требований;
запись и изучение результатов дискуссий обеими сторонами.
Процесс разработки необходимо планировать. План разработки должен охватывать
следующее:
описание проекта, включая постановку задачи, со ссылкой на связанные с ним проекты
покупателя и поставщика;
организацию ресурсов под конкретный проект, включая состав команды, обязанности,
использование субподрядчиков и материальные затраты;
фазы разработки;
программу работ над проектом, устанавливающую задачи, которые должны быть
решены, ресурсы и время, необходимые для решения каждой задачи и для
промежуточных действий между этими решениями;
идентификацию увязанных между собой планов, таких, как:
а) план качества;
б) план управления конфигурацией;
в) план комплектации;
г) план проведения испытаний.
План разработки должен корректироваться по мере совершенствования разработки, и
каждая фаза должна быть определена до того, как начнутся работы на этой фазе. План
должен быть рассмотрен и утвержден до его реализации.
План разработки должен устанавливать упорядоченный процесс или методологию
преобразования техническое задание покупателя в продукцию программного обеспечения.
Он может включать в себя распределение работ о фазам и идентификацию:
фаз разработки, которые должны быть выполнены;
необходимых затрат для каждой фазы;
требуемых результатов по каждой фазе;
процедур проверки, которые необходимо провести на каждой фазе;
анализа потенциальных проблем, связанных с фазами разработки и с выполнением
установленных требований.
План разработки должен определять, как управлять проектом, и включать
идентификацию:
графика разработки, продукции, выполнения контракта и связанных с ним
поставок;
контроля за ходом выполнения работ;
организационной ответственности, ресурсов и распределения работ;
организационных и технических интерфейсов между различными группами.
План разработки должен устанавливать методы, обеспечивающие правильность
выполнения всех работ. Он может включать правила, практические методы и
накопленный опыт по разработке; средства и технические приемы, используемые для
разработки; управление конфигурацией.
Анализ хода выполнения работ следует планировать, проводить и документально
оформлять, с тем, чтобы обеспечить решение спорных вопросов, касающихся
распределения ресурсов, и гарантировать эффективное выполнение планов проекта.
Необходимые затраты по каждой фазе должны быть определены и документально
оформлены. Каждое требование должно быть определено
таким образом, чтобы его выполнение можно было проверить. Вопрос о неполных,
двусмысленных или противоречивых требованиях должны решать лица, ответственные за
разработку этих требований.
Результаты, требуемые по каждой фазе разработки, должны быть определены и
документально оформлены. Они должны быть проверены и удовлетворять следующим
условиям:
отвечать требованиям, установленным для каждой фазы;
содержать критерии приемки или ссылки на них для перехода к последующей фазе;
соответствовать принятой практике и накопленному опыту по разработке независимо
от того, оговорены ли они во входной информации;
идентифицировать те характеристики продукции, которые являются наиболее
важными для ее безопасности и эффективного функционирования;
соответствовать действующим нормативным требованиям.
Поставщик должен составить план проверки всех результатов разработки в конце каждой
фазы. Проверка разработки должна установить, что результаты разработки отвечают
соответствующим требованиям, установленным в начале фазы. Эти проверки необходимо
проводить, основываясь на выполнение следующих мероприятий по контролю
разработки:
осуществление анализов через установленные интервалы в ходе фаз
разработки;сравнение нового проекта с апробированным аналогичным проектом, если
таковой имеется;
проведение испытаний и демонстрационных показов.
Результаты проверок и последующих действий, необходимых для гарантии того, что
установленные требования выполнены, должны быть запротоколированы и проверены
после того, как соответствующие действия завершатся.
План качества. Поставщик должен подготовить план качества как часть работ по
планированию разработки. План качества должен корректироваться в ходе выполнения
работ, а пункты, касающиеся каждой фазы, должны быть полностью определены к началу
этой фазы.
План качества должен быть официально рассмотрен и согласован со всеми
организациями, заинтересованными в его реализации.
Документ, описывающий план качества, может быть самостоятельным документом
(озаглавленным План качества) или частью другого документа или может быть составлен
из нескольких документов, включая план разработки.
План качества должен определять или давать ссылки на следующие пункты:
цели качества, выраженные в измеряемых показателях, если это возможно;
заданные критерии по затратам и результатам для каждой фазы разработки;
идентификация видов деятельности, связанной с испытаниями, проверками и
оценками, которые должны быть проведены;
подробное планирование испытаний, проверок и оценок, включая графики, ресурсы и
назначенных уполномоченных;
конкретное распределение ответственности за мероприятия по обеспечению качества,
такие, как:
а) анализы и испытания;
б) управление конфигурацией и контроль за изменениями;
в) контроль дефектов и выполнение корректирующих действий.
Проектирование и реализация. Проектирование и реализация - это те виды деятельности,
которые трансформируют ТЗ покупателя в продукцию ПО. Из-за сложности этой
продукции вся деятельность должна осуществляться в строго установленном порядке, с
тем, чтобы производить продукцию в соответствии с заданием, а при обеспечении
качества не следует чрезмерно полагаться на действия, связанные с испытанием и
проверкой.
В дополнение к требованиям, общим для всех фаз разработки, необходимо принять во
внимание следующие аспекты, присущие деятельности по проектированию:
идентификацию конструктивных соображений: в дополнение к требованиям, касающимся
выходных данных и ожидаемых результатов, следует рассмотреть такие аспекты, как
правила проектирования и определения внутреннего интерфейса;
методологию проектирования: должна быть использована методология системного
проектирования, соответствующая виду разрабатываемой продукции программного
обеспечения;
использование прошлого опыта в проектировании: используя уроки, извлеченные из
опыта прошлого проектирования, поставщик должен избегать повторений одних и тех же,
или аналогичных, проблем;
последующие процессы: продукция должна быть спроектирована так, чтобы можно было
без помех проводить испытания, тех. обслуживание и использование.
В дополнение к требованиям, общим для всех видов деятельности, связанных с
разработкой, необходимо рассмотреть следующие аспекты для каждого вида деятельности
по реализации проекта:
правила: следует установить и соблюдать правила программирования, языка
программирования, согласованные правила наименования, кодирования и
соответствующего разъяснения;
методологию реализации: поставщик должен использовать соответствующие методы и
средства реализации, чтобы выполнить требования покупателя.
Поставщик должен проводить анализ с целью гарантии того, что требования
выполняются, и описанные выше методы применяются правильно. Процесс
проектирования или реализации не должен продолжаться до тех пор, пока последствия
всех выявленных недостатков не будут положительно разрешены или пока не будет
известна степень риска в случае продолжения работ другими методами. Следует вести
протоколы таких анализов.
Проведение испытания может быть необходимо на различных уровнях, начиная от
отдельного элемента ПО и кончая готовой продукцией. Существует несколько различных
подходов к испытаниям. В некоторых случаях оценка, испытания на месте и приемочные
испытания могут быть одним и тем же видом деятельности. Документ, описывающий
план испытаний, может быть самостоятельным документом (озаглавленным План
испытаний) или частью другого документа или может быть составлен из нескольких
документов.
3. Система качества - вспомогательные виды деятельности.
Наиболее важными вспомогательными видами деятельности являются управление
конфигурацией и осуществление контроля за документацией.
Управление конфигурацией обеспечивает механизм идентификации, контролирования и
прослеживания вариантов каждого элемента ПО. Во многих случаях более ранние
варианты, которые все еще продолжают использоваться, должны технически
обслуживаться, и находится под контролем.
Система управления конфигурацией должна:
однозначно идентифицировать варианты каждого элемента ПО;
идентифицировать варианты каждого элемента ПО, которые вместе образуют конкретный
вариант готовой продукции;
идентифицировать состояние компоновки продукции ПО, находящейся в разработке или
уже поставленной и смонтированной;
управлять одновременной модернизацией конкретного элемента ПО, проводимой более
чем одним человеком;
обеспечить координацию работ по модернизации многочисленной продукции,
производимой в одном или более местах, по необходимости;
идентифицировать и прослеживать все мероприятия и изменения, вызванные
изменившейся заявкой, начиная от самого зарождения до выпуска продукции.
Поставщик должен разработать и реализовать план управления конфигурацией, который
включает в себя следующее:
организации, занятые в управлении конфигурацией, и ответственность, возложенная на
каждую из них;
виды деятельности по управлению конфигурацией, которые должны быть осуществлены;
технические средства, технологии и методологические принципы, которые должны быть
применены в управлении конфигурацией;
стадия, на которой элементы должны быть подвергнуты управлению конфигурацией.
К видам деятельности, связанной с управлением конфигурацией относятся
идентификация и прослеживаемость конфигурации, контроль изменений, установление
отчета о статусе конфигурации.
Поставщик должен установить и осуществлять процедуры по идентификации элементов
ПО на всех фазах, начиная с составления технических условий, затем разработка и
тиражирование и кончая поставкой. Каждый отдельный элемент ПО должен иметь свою
собственную и отличную от других идентификацию.
Процедуры должны применяться для гарантии того, что для каждого варианта элемента
ПО могут быть идентифицированы:
функциональные и технические требования;
все технические средства, используемые при разработке, которые влияют на
функциональные и технические требования;
все интерфейсы с другими элементами ПО и с аппаратными средствами;
все документы и компьютерные файлы, имеющие отношение к конкретному элементу
ПО.
Для выпущенной продукции необходимо установить процедуры, облегчающие
прослеживаемость элемента или продукции ПО.
Поставщик должен установить и выполнять процедуры по идентификации,
документальному оформлению, анализу и санкционированию любых изменений в
элементах ПО в рамках управления конфигурацией. Все изменения в элементах ПО
должны проводиться в соответствии с этими процедурами.
Поставщик должен установить и обеспечить протоколирования, управления и
предоставления отчетов о статусе ПО, заявок на изменения и реализации утвержденных
изменений.
Поставщик должен установить и обеспечить процедуры по контролю всех документов.
К данным процедурам относится:
определение тех документов, которые должны быть объектом контроля;
утверждение и опубликование;
изменение, включая отмену и, если необходимо, выпуск.
Процедуры контроля за документацией должны применяться к соответствующим
документам, включая следующие:
процедурные документы, описывающие систему качества, которая должна
применяться на протяжение всего ЖЦ ПО;
документы по планированию, описывающие планирование и развитие всех видов
деятельности поставщика, а также взаимодействие с покупателем;
документы на продукцию, описывающие конкретную продукцию ПО, включая:
а) информацию на входе фазы разработки;
б) ожидаемые результаты в конце фазы разработки;
в) планы и результаты проверок и оценок;
г) документацию для покупателя и пользователя;
д) эксплуатационную документацию.
Все документы должны быть изучены и утверждены уполномоченными должностными
лицами до их опубликования. Действующие процедуры должны гарантировать, что:
относящиеся к делу публикации соответствующих документов имеются в наличии на
соответствующих участках там, где выполняются операции, важные для
эффективного функционирования системы качества;
устаревшие документы быстро изымаются из соответствующих мест издания и из
употребления.
Там, где используются компьютерные файлы, особое внимание следует обратить на
соответствующие процедуры утверждения, доступа, распределения и архивного хранения.
К другим вспомогательным видам деятельности, не рассмотренные нами, относятся:
измерение продукции и процесса; правила, практические методы и накопленный опыт;
средства и технические приемы; закупка; поставка ПО третьей стороной; подготовка
кадров.
1.3. Показатели качества ПО в ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126
Показатели качества ПО устанавливают ГОСТ 28195 Оценка качества программных
средств. Общие положения и ГОСТ Р ИСО/МЭК 9126 Информационная технология.
Оценка программной продукции. Характеристика качества и руководства по их
применению. Одновременное существование двух действующих стандартов,
нормирующих одни и те же показатели, ставит вопрос об их гармонизации. Ниже кратко
рассмотрим каждый из перечисленных стандартов.
ГОСТ Р ИСО/МЭК 9126 устанавливает шесть характеристик качества ПО. Под
характеристикой качества ПО, согласно этому стандарту, понимается набор свойств
(атрибутов) программной продукции, по которым ее качество оценивается или
описывается. Определение качества и определенные в этом стандарте характеристики
отражают представление пользователя о качестве ПО. Ниже приводятся существенное для
оценки качества ПО обсуждение этих характеристик.
1. Функциональные возможности. Данная характеристика описывает свойства ПО в
части полноты удовлетворения требований пользователя и в этом смысле является
определяющей для потребительских свойств ПО, в то время как остальные
характеристики носят более технический характер, что не уменьшает их значение при
оценке качества ПО. Кроме того, эти характеристики (такие как надежность,
эффективность и др.) могут входить в число требований пользователя.
Требования пользователя четко обусловлены при наличие контракта и, соответственно,
технического задания (технических требований). В других случаях речь идет о
предполагаемых потребностях, которые должны быть установлены и формально
определены какими-либо нормативными документами (стандартами, техническими
условиями и пр.). Оценка качества ПС должна начинаться с точного и формального
установления предъявляемых требований, которые могут различаться (и различаются) для
различных ПО.
Функциональные возможности - набор атрибутов, относящихся к сути набора функций и
их конкретным свойствам. Функциями являются те, которые реализуют установленные
или предполагаемые потребности. Данный набор атрибутов характеризует то, что ПО
выполняет для удовлетворения потребностей, тогда как другие наборы, главным образом,
характеризуют, когда и как это выполняется.
2. Надежность. Специфика ПО заключается в том, что оно не подвержено старению и
износу, а отказы проявляются из-за ошибок в требованиях, проекте, реализации.
Надежность - набор атрибутов, относящихся к способности ПО сохранять свой уровень
качества функционирования в установленных условиях за определенный период времени.
3. Практичность. При оценке этой характеристики следует исходить из требований
пользователя, так как пользователи разного уровня подготовленности предъявляют
разные (часто взаимоисключающие) требования.
Практичность - набор атрибутов, относящихся к объему работ, требуемых для исполнения
и индивидуальной оценки такого исполнения определенным или предполагаемым кругом
пользователей.
4. Эффективность. Оценка данной характеристики также критически зависит от
требований пользователя. ПО может выглядеть неэффективным не в силу плохого
кодирования, а в силу противоречивости и нереальности исходных требований. Например,
требования к ПО выполнять функции на технических средствах минимальной (по объему
оперативной и дисковой памяти, тактовой частоте и пр.) конфигурации компьютера
противоречит требованиям о высоком быстродействии. Вообще говоря, и теория, и
практика свидетельствует, что быстродействие и объем используемой памяти является
взаимодополняющими характеристиками в том смысле, что увеличение одного приводит
к увеличению другого при прочих равных условиях.
Эффективность - набор атрибутов, относящихся к соотношению между уровнем качества
функционирования ПО и объемом используемых ресурсов при установленных условиях.
5. Сопровождаемость. Мобильность. Для этих двух характеристик следует учитывать,
что в специфических российских условиях им часто не уделялось ранее и не уделяется
сейчас достаточно внимания со стороны пользователя. Эти характеристики связаны с
долгосрочным планированием развития ПО (и эксплуатирующей его организации).
Улучшение сопровождаемости и мобильности может, вообще говоря, повысить стоимость
ПО в настоящий момент времени, что (многократно) окупается лишь через несколько лет.
Сопровождаемость - набор атрибутов, относящихся к объему работ, требуемых для
проведения конкретных изменений (модификаций).
Мобильность - набор атрибутов, относящихся к способности ПО быть перенесенным из
одного окружения в другое.
Все приведенные характеристики являются наборами атрибутов и, следовательно, должны
уточняться на множестве соответствующих подхарактеристик. ГОСТ Р ИСО/МЭК 9126 не
устанавливает соответствующих показателей, но в рекомендуемом приложении А к этому
стандарту дается пример (качественная модель) таких подхарактеристик, называемых
комплексными показателями.
В качестве примера приведем комплексные показатели для некоторых характеристик.
Характеристика Функциональные возможности:
1. Пригодность - атрибут ПО, относящийся к наличию и соответствию набора
функций конкретным задачам.
2. Правильность - атрибуты ПО, относящиеся к обеспечению правильности или
соответствия результатов или эффектов.
3. Способность к взаимодействию - атрибуты ПО, относящиеся к способности его
взаимодействовать с конкретными системами.
4. Согласованность - атрибуты ПО, которые заставляют программу придерживаться
соответствующих стандартов или соглашений, или положений законов, или подобных
рекомендаций.
5. Защищенность - атрибуты ПО, относящиеся к его способности предотвращать
несанкционированный доступ, случайный или преднамеренный, к программам и данным.
Характеристика Эффективность:
1. Характер изменения во времени - атрибуты ПО, относящиеся к временам отклика и
обработки и к скорости выполнения его функций.
2. Характер изменения ресурсов - атрибуты ПО, относящиеся к объему используемых
ресурсов и продолжительности такого использования при выполнении функций.
Приведенные комплексные показатели в свою очередь формируются на основе
показателей нижележащего уровня. ГОСТ Р ИСО/МЭК 9126 не устанавливает этих
показателей, так как современное состояние соответствующих моделей, терминов,
определений не позволяет включить их в рассматриваемый международный стандарт.
В СССР действовал и продолжает действовать в РФ ГОСТ 28195-89. Этот стандарт
устанавливает четырехуровневую модель оценки качества ПС. Характеристики верхних
двух уровней (называемые фактор и критерий) устанавливаются в основном тексте
документа. В таблице 1.1. показаны факторы и критерии качества ПО согласно ГОСТ
28195.
Таблица 1.1
Наименование факторов и
критериев качества ПО и
их обозначение
Характеризуемое свойство
1. Надежность ПО (Н)
Характеризует способность ПО в конкретных областях
применения выполнять заданные функции в
соответствии с программными документами в условиях
возникновения отклонений в среде функционирования,
вызванных сбоями технических средств, ошибками во
входных данных, ошибками обслуживания и другими
дестабилизирующими воздействиями.
1.1. Устойчивость
функционирования (Н1)
Способность обеспечивать продолжение работы ПО
после возникновения отклонений, вызванных сбоями
технических средств, ошибками во входных данных и
ошибками обслуживания.
1.2. Работоспособность
(Н2)
Способность ПО функционировать в заданных режимах
и объемах обрабатываемой информации в соответствии
с программными документами при отсутствии сбоев
технических средств.
2. Сопровождаемость (С)
Характеризует технологические аспекты,
обеспечивающие простоту устранения ошибок в ПО и
программных документах и поддержания ПО в
актуальном состоянии.
2.1. Структурность (С1)
Организация всех взаимосвязанных частей ПО в единое
целое с использованием логических структур
последовательность, выбор, повторение.
2.2. Простота
конструкции (С2)
Построение модульной структуры ПО наиболее
рациональным образом с точки зрения восприятия и
понимания.
2.3. Наглядность (С3)
Наличие и представление в наиболее легко
воспринимаемом виде исходных модулей ПО, полное их
описание в соответствующих программных документах.
2.4. Повторяемость (С4)
Степень использования типовых проектных решений
или компонентов, входящих в ПО.
3. Удобство применения
(У)
Характеризует свойства ПО, способствующие быстрому
освоению, применению и эксплуатации ПО с
минимальными трудозатратами с учетом характера
решаемых задач и требований к квалификации
обслуживающего персонала.
3.1. Легкость освоения
(У1)
Представление программных документов и ПО в виде,
способствующем пониманию логики функционирования
ПО в целом и его частей.
3.2. Доступность
эксплуатационных
программных документов
(У2)
Понятность, наглядность и полнота описания
взаимодействия пользователя с ПО в эксплуатационных
программных документах.
3.3. Удобство
эксплуатации и
обслуживания (У3)
Соответствие процесса обработки данных и форм
представления результатов характеру решаемых задач.
4. Эффективность (Э)
Характеризует степень удовлетворения потребности
пользователя в обработке данных с учетом
экономических, вычислительных и людских ресурсов.
4.1. Уровень
автоматизации (Э1)
Уровень автоматизации функций процесса обработки
данных с учетом рациональности функциональной
структуры ПО с точки зрения взаимодействия с ней
пользователя и использования вычислительных
ресурсов.
4.2. Временная
эффективность (Э2)
Способность ПО выполнять заданные действия в
интервал времени, отвечающий заданным требованиям.
4.3. Ресурсоемкость (Э3)
Минимально необходимые вычислительные ресурсы и
число обслуживающего персонала для эксплуатации ПО.
5. Универсальность (Г)
Характеризует адаптируемость ПО к новым
функциональным требованиям, возникающим
вследствие изменения области применения или других
условий функционирования.
5.1. Гибкость (Г1)
Возможность использования ПО в различных областях
применения.
5.2. Мобильность (Г2)
Возможность применения ПО без существенных
дополнительных трудозатрат на ЭВМ аналогичного
класса.
5.3. Модифицируемость
(Г3)
Обеспечение простоты внесения необходимых
изменений и доработок в ПО в процессе эксплуатации.
6. Корректность (К)
Характеризует степень соответствия ПО требованиям,
установленным в техническом задании, требованиям к
обработке данных и общесистемным требованиям.
6.1. Полнота реализации
(К1)
Полнота реализации заданных функций ПО и
достаточность их описания в программной
документации.
6.2. Согласованность (К2)
Однозначное, непротиворечивое описание и
использование тождественных объектов, функций,
терминов, определений, идентификаторов и т.д. в
различных частях программных документов и текста
программы.
6.3. Логическая
корректность (К3)
Функциональное и программное соответствие процесса
обработки данных при выполнении задания
общесистемным требованиям.
6.4. Проверенность (К4)
Полнота проверки возможных маршрутов выполнения
программы в процессе тестирования.
Характеристики двух нижних уровней (называемых метрика и оценочный элемент)
устанавливаются в справочном приложении 2 к рассматриваемому стандарту. В том же
приложении установлены методы проведения контроля за качеством ПО. Методы
определения качества ПО различаются:
по способу получения информации о ПО - измерительный, регистрационный,
органолептический, расчетный;
по источникам получения информации - традиционный, экспертный,
социологический.
Программно-аппаратные средства проведения контроля зависят от вида
конкретного ПО и должны разрабатываться отдельно.
В качестве примера приведем некоторые метрики следующих критериев фактора
Надежность:
устойчивость функционирования:
а) средства восстановления при ошибках на входе;
б) средства восстановления при сбоях оборудования;
в) реализация управления средствами восстановления;
работоспособность:
а) функционирование в заданных режимах;
б) обеспечение обработки заданного объема информации.
В таблице 1.2. приведены некоторые оценочные элементы факторов Сопровождаемость и
Корректность.
Оценка качества ПО производится в определенной последовательности. На начальных
этапах разработки ПО производится выбор показателей и их базовых значений. Для
показателей качества на всех четырех уровнях принимается единая шкала оценки от 0 до
1. Показатели качества на вышестоящем уровне (кроме уровня оценочных элементов)
определяются показателями качества нижестоящего уровня.
Таблица 1.2.
Код
элемента
Наименование
Метод оценки
Оценка
С0803
Наличие комментариев в
точках входа и выхода
программы
Экспертный
0-1
С0302
Оценка простоты программы
по числу точек входа и
выхода
Расчетный
W = 1/ ((D+1)(F+1))
2
где D - общее число
точек входа в программу,
F - общее число точек
выхода из программы.
С1002
Оценка простоты программы
по числу переходов по
условию
Расчетный
U = (1 - A/B)
где A - общее число
переходов по условию, B
- общее число
исполняемых
операторов.
С0303
Осуществляется ли передача
результатов работы модуля
через вызывающий его
модуль
Экспертный
0-1
С0604
Оценка программы по числу
циклов
Экспертный
0-1
С0901
Соответствие комментариев
принятым соглашениям
Экспертный
0-1
С1001
Используется ли язык
высокого уровня
Экспертный
0-1
К0101
Наличие всех необходимых
документов для понимания и
использования ПО
Экспертный
0-1
К0103
Наличие описания основных
функций
Экспертный
0-1
К0201
Реализация всех основных
функций
Экспертный
0-1
К0701
Комплектность
документации в
соответствии со стандартами
Экспертный
0-1
К1003
Отношение числа модулей,
отработавших в процессе
тестирования и отладки
(Q
T
M
) к общему числу
модулей (Q
О
M
)
Расчетный
(Q
T
M
) / (Q
О
M
)
Коды оценочных элементов составлены из пяти символов следующим образом:
1-ый символ - буква русского алфавита - указывает на принадлежность элемента к тому
или иному фактору;
2-й и 3-й символы - номер метрики, которой принадлежит оценочный элемент;
4-й и 5-й - порядковый номер данного оценочного элемента в метрике.
В процессе оценки качества ПО на каждом уровне (кроме уровня оценочных элементов)
проводятся вычисления показателей качества ПО, т.е. определение количественных
значений абсолютных показателей (P
ij
, где j - порядковый номер показателя для i - го
показателя вышестоящего уровня) и относительных показателей (K
ij
), являющихся
функцией показателя P
ij
, и базового значения P
ij
баз
.
Критерий и метрика характеризуется двумя числовыми параметрами - количественным
значением и весовыми коэффициентами (V
ij
). Сумма весовых коэффициентов показателей
уровня (l) относящихся к i-му показателю вышестоящего уровня (l-1), есть величина
постоянная. Сумма весовых коэффициентов (V
ij
) принимается равной 1.
Общая оценка качества ПО в целом формируется экспертами по набору полученных
значений оценок факторов качества. Для оценки качества ПО различного назначения
методом экспертного опроса составляется таблица базовых показателей качества ПО.
При сопоставление характеристик стандартов ГОСТ Р ИСО/МЭК 9126 и ГОСТ 28195
следует учесть несоответствие используемой терминологии. Например,
подхарактеристика 1.4 ГОСТ Р ИСО/МЭК 9126 называется также, как критерий 6.2 ГОСТ
28195 - согласованность. Однако в первом документе имеется в виду согласованность ПО
со стандартами и другими нормативными документами, а во втором - однозначное,
непротиворечивое описание и использование тождественных объектов, функций,
терминов, определений, идентификаторов и т.д. в различных частях программных
документов и текста программы. Точное сопоставление характеристик и
подхарактеристик первого из обсуждаемых стандартов с факторами и критериями второго
оказывается, как правило, невозможным.
Таким образом, на сегодняшний день действуют два нормативных документа по оценке
качества ПО - ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126. Первый содержит рекомендуемый
(и возможно - неполный) перечень метрик, однако ориентирован на представление
разработчика. Второй - более соответствует взглядам пользователя, но для его
применения требуется разработка модели качества ПС, включающая метрики и методы
оценивания и ранжирования с указанием применимости на стадиях ЖЦ продукта.
1.4. Модели и метрики оценки качества ПО
Современная программная индустрия за полвека исканий накопила внушительную
коллекцию моделей и метрик, оценивающих отдельные производственные и
эксплуатационные свойства ПО. Однако погоня за их универсальностью, неучет области
применения разрабатываемого ПО, игнорирование этапов жизненного цикла
программного обеспечения и, наконец, необоснованное их использование в
разноплановых процедурах принятия производственных решений, существенно
подорвало к ним доверие разработчиков и пользователей ПО.
Тем не менее, анализ технологического опыта лидеров производства ПО показывает,
насколько дорого обходится несовершенство ненаучного прогноза разрешимости и
трудозатрат, сложности программ, негибкость контроля и управления их разработкой и
многое другое, указывающее на отсутствие сквозной методической поддержки и
приводящее в конечном итоге к его несоответствию требованиям пользователя,
требуемому стандарту и к последующей болезненной и трудоемкой его переделке. Эти
обстоятельства, требуют тщательного отбора методик, моделей, методов оценки качества
ПО, учета ограничений их пригодности для различных жизненных циклах и в пределах
жизненного цикла, установления порядка их совместного использования, применения
избыточного разномодельного исследования одних и тех же показателей для повышения
достоверности текущих оценок, накопления и интеграции разнородной метрической
информации для принятия своевременных производственных решений и заключительной
сертификации продукции.Ниже, в таблице 1.3., приведены модели и метрики, хорошо
зарекомендовавшие себя при оценке качества ПО, пригодные для прогнозирования и
констатации различных показателей сложности и надежности программ.
Таблица 1.3.
Название модели
Формула, обозначение
МЕТРИКИ СЛОЖНОСТИ
Метрики Холстеда
-длина программы;
- объем программы
- оценка ее реализации;
- трудность ее понимания;
- трудоемкость кодирования;
- уровень языка выражения;
- информационное содержание;
- оптимальная модульность;
N = n
1
log
1
n
1
+ n
2
log
2
n
2
V = N log
2
n
L
*
= (2n
2
)/ (n
1
N
2
)
E
c
= V/ L
*
D = (n
1
N
2
)(2n
2
) = 1/ L
*
λ
*
= V/ D
2
= V/ L
* 2
I = V / D
M = n
2
*
/6
Метрики Джилба
- количество операторов цикла;
- количество операторов условия;
- число модулей или подсистем;
- отношение числа связей между
модулями к числу модулей;
- отношение числа ненормальных
выходов из множества операторов к
общему числу операторов;
L
1oop
L
IF
L
mod
f = N
4
SV
/ L
mod
f
*
= N
*
SV
/ L
Метрики Мак-Кейба-
цикломатическое число;
- цикломатическая сложность;
λ(G) = m - n + p
ν (G) = λ(G) +1 = m - n + 2
Метрика Чепена
H = 0.5T+P+2M+3C
- мера трудности понимания
программ на основе входных и
выходных данных;
Метрика Шнадевида
- число путей в управляющем графе
S = Σ P
i
C
i
Метрика Майерса
- интервальная мера;
[ν
1 ÷
ν
2
]
Метрика Хансена
- пара (цикломатическое число, число
операторов)
{ν , N}
Метрика Чена
- топологическая мера Чена;
M(G) = (ν (G), N, Q
0
)
Метрика Вудворда
- узловая мера (число узлов передач
управления);
Ψ ξ
Метрика Кулика
- нормальное число (число
простейших циклов в нормальной
схеме программы);
Norm (P)
Метрика Хура
- цикломатическое число сети Петри,
отражающей управляющую
структуру программы;
λ(G
*
р
)
Метрики Витворфа, Зулевского
-мера сложности потока управления
-мера сложности потока данных;
γ (Р)
Ω (Р)
Метрика Петерсона
- число многовходовых циклов;
Nm
1 0 0 p
Метрики Харрисона, Мэйджела
- функциональное число (сумма
приведенных сложностей всех
вершин управляющего графа);
- функциональное отношение
(отношение числа вершин графа к
f
1
= Σ χ
1
f
*
= N χ
1
/ f
1
p(G) = N+L+Sk
функциональному числу);
- регулярные выражения (число
операндов, операторов и скобок в
регулярном выражении
управляющего графа программы);
Метрика Пивоварского
- модифицированная
цикломатическая мера сложности;
N(G) = n
*
(G) + Σ P
i
Метрика Пратта
- тестирующая мера;
Test (Pr)
Метрика Кантоне
- характеристические числа
полиномов, описывающих
управляющий граф программы;
PCN
*
Метрика Мак-Клура
- мера сложности, основанная на
числе возможных путей выполнения
программы, числе управляющих
конструкций и переменных;
C(V) = D(V) × J(V) / N
Метрика Кафура
- мера на основе концепции
информационных потоков;
I(G)
Метрика Схуттса, Моханти
- энтропийные меры;
ε (G)
Метрика Коллофело
- мера логической стабильности
программ;
h (G)
Метрика Зольновского, Симмонса,
Тейера
Взвешенная сумма различных
индикаторов:
- (структура, взаимодействие, объем,
данные);
- (сложность интерфейса,
вычислительная сложность,
сложность ввода/вывода,
читабельность);
∑ (α , β , γ , ν )
∑ (χ , Χ , υ , π )
Метрика Берлингера
- информационная мера;
I(R) = m (F
*
(R) × F
-
(R))
2
Метрика Шумана
- сложность с позиции
статистической теории языка;
Ξ (Ψ )
Метрика Янгера
- логическая сложность с учетом
истории вычислений;
Сложность проектирования
Насыщенность комментариями
Число внешних обращений
Число операторов
Λ (ω )
C
c
= ∑ log
2
(i + 1) [∑
n
Cxy (n)]
X = K/C
C
i
L
1
ПРОГНОЗ МОДЕЛИ
Модели Холстеда
- прогноз системных ресурсов;
- прогноз числа ошибок.
Модель фирмы IBM
Модель общей сложности
Модели связности
Сплайн-модель
P=3/8 (R
a
- 1) × 2
Ra
B = Nlog
2
n / 3000
B = 23M
1
+ M
1 0
B = 21.1 + 0.1 V + COMP (S)
P
ij
= 0.15 (S
i
+ S
j
) + 0.7 C
ij
P
ij
= ½ ∑ λ
i
(∆ Z
ij
2
+ ∆ N
ij
2
) ln (∆ Z
ij
2
+ ∆ N
ij
2
) +
α + β Z
i
+ γ N
1
ОЦЕНОЧНЫЕ МОДЕЛИ
Джелински - Моранды
R(t) = e
- (Т - 1 + 1) Φt
Вейса-Байеса
R
1
(t) = ∫ ∫ e
- l - (i -1) Φ )t
Ψ(λ, F/t
1
, ... , t
i-1
) dλ
dФ
Шика-Волвертона
R
1
(t) = e
- F( N - 1 + 1) t
i
2 / 2
Литтлвуда
R
1
(t) = (b
+
τ /b
+
τ
+
τ)
- Φ(N - i + 1) a
Нельсона
R
j
(t) = exp { ∑ ln (1 - P
j
)}
Халецкого
R
j
(t) = P∝- a(1- γ
nj
) / n
j
Модель отлаженности
R
j
(t) =P∝ - ρ f
j
(τ ,λ ,π )
Мозаичная модель
R
j
(t) = 1 - β ( α - ω
j - 1
)
В таблице представлены разнообразные метрики сложности ПО для различных форм их
представления, модели прогнозирующие ход развития процессов разработки ПО и
вероятностные модели по оценке надежности.
Кратко рассмотрим метрики сложности. Одной из основных целей научно-технической
поддержки является уменьшение сложности ПО. Именно это позволяет снизить
трудоемкость проектирования, разработки, испытаний и сопровождения, обеспечить
простоту и надежность производимого ПО. Целенаправленное снижение сложности ПО
представляет собой многошаговую процедуру и требует предварительного исследования
существующих показателей сложности, проведения их классификации и соотнесения с
типами программ и их местоположением в жизненном цикле.
Теория сложности программ ориентирована на управление качеством ПО и контроль ее
эталонной сложности в период эксплуатации. В настоящее время многообразие
показателей (в той или иной степени описывающих сложность программ) столь велико,
что для их употребления требуется предварительное упорядочение. В ряде случаев
удовлетворяются тремя категориями метрик сложности. Первая категория определяется
как словарная метрика, основанная на метрических соотношениях Холстеда,
цикломатических мерах Мак-Кейба и измерениях Тейера. Вторая категория
ориентирована на метрики связей, отражающих сложность отношений между
компонентами системы - это метрики Уина и Винчестера. Третья категория включает
семантические метрики, связанные с архитектурным построением программ и их
оформлением.
Согласно другой классификации, показатели сложности делятся на две группы: сложность
проектирования и сложность функционирования. Сложность проектирования, которая
определяется размерами программы, количеством обрабатываемых переменных,
трудоемкостью и длительностью разработки и др. факторами, анализируется на основе
трех базовых компонентов: сложность структуры программы, сложность преобразований
(алгоритмов), сложность данных. Во вторую группу показателей отнесены временная,
программная и информационная сложности, характеризующие эксплуатационные
качества ПО.
Существует еще ряд подходов к классификации мер сложности, однако они, фиксируя
частные стороны исследуемых программ, не позволяют (пусть с большим допущением)
отразить общее, то, чьи замеры могут лечь в основу производственных решений.
Общим, инвариантно присущим любому ПО (и связанной с его корректностью), является
его СТРУКТУРА. Важно связать это обстоятельство с определенным значением
структурной сложности в совокупности мер сложности ПО. И более того, при анализе
структурной сложности целесообразно ограничиться только ее топологическими мерами,
т.е. мерами, в основе которых лежат топологические характеристики граф-модели
программы. Эти меры удовлетворяют подавляющему большинству требований,
предъявляемых к показателям: общность применимости, адекватность рассматриваемому
свойству, существенность оценки, состоятельность, количественное выражение,
воспроизводимость измерений, малая трудоемкость вычислений, возможность
автоматизации оценивания.
Именно топологические меры сложности наиболее часто применяются в фазе
исследований, формирующей решения по управлению производством (в процессах
проектирования, разработки и испытаний) и составляют доступный и чувствительный
эталон готовой продукции, контроль которого необходимо регулярно осуществлять в
период ее эксплуатации.
Первой топологической мерой сложности является цикломатическая мера Мак-Кейба. В
ее основе лежит идея оценки сложности ПО по числу базисных путей в ее управляющем
графе, т.е. таких путей, компонуя которые можно получить всевозможные пути из входа
графа в выходы. Цикломатическое число λ (G) орграфа G с n-вершинами, m-дугами и
p-компонентами связности есть величина λ (G) = m - n + p.
Имеет место теорема о том, что число базисных путей в орграфе равно его
цикломатическому числу, увеличенному на единицу. При этом, цикломатической
сложностью ПО Р с управляющим графом G называется величина ν (G) = λ (G) +1 = m - n
+ 2. Практически цикломатическая сложность ПО равна числу предикатов плюс единица,
что позволяет вычислять ее без построения управляющего графа простым подсчетом
предикатов. Данная мера отражает психологическую сложность ПО.
К достоинствам меры относят простоту ее вычисления и повторяемость результата, а
также наглядность и содержательность интерпретации. В качестве недостатков можно
отметить: нечувствительность к размеру ПО, нечувствительность к изменению структуры
ПО, отсутствие корреляции со структурированностью ПО, отсутствие различия между
конструкциями Развилка и Цикл, отсутствие чувствительности к вложенности циклов.
Недостатки цикломатической меры привело к появлению ее модификаций, а также
принципиально иных мер сложности.
Дж. Майерс предложил в качестве меры сложности интервал [ν
1÷
ν
2
], где ν
1
-
цикломатическая мера, а ν
2
- число отдельных условий плюс единица. При этом, оператор
DO считается за одно условие, а CASE c n - исходами за n - 1- условий. Введенная мера
получила название интервальной мерой.
У. Хансену принадлежит идея брать в качестве меры сложности ПО пару
{цикломатической число, число операторов}. Известна топологическая мера Z(G),
чувствительная к структурированности ПО. При этом, она Z(G) = V(G) (равна
цикломатической сложности) для структурированных программ и Z(G) > V(G) для
неструктурированных. К вариантам цикломатической меры сложности относят также
меру М(G) = (V(G),C,Q), где С - количество условий, необходимых для покрытия
управляющего графа минимальным числом маршрутов, а Q - степень связности структуры
графа программы и ее протяженность.
К мерам сложности, учитывающим вложенность управляющих конструкций, относят
тестирующую меру М и меру Харрисона-Мейджела, учитывающих уровень вложенности
и протяженности ПО, меру Пивоварского - цикломатическую сложность и глубину
вложенности, и меру Мак-Клура - сложность схемы разбиения ПО на модули с учетом
вложенности модулей и их внутренней сложности.
Функциональная мера сложности Харрисона-Мейджела предусматривает приписывание
каждой вершине графа своей собственной сложности (первичной) и разбиение графа на
сферы влияния предикатных вершин. Сложность сферы называют приведенной и слагают
ее из первичных сложностей вершин, входящих в сферу ее влияния, плюс первичную
сложность самой предикатной вершины. Первичные сложности вычисляются всеми
возможными способами. Отсюда функциональная мера сложности ПО есть сумма
приведенных сложностей всех вершин управляющего графа.
Мера Пивоварского ставит целью учесть в оценке сложности ПО различия не только
между последовательными и вложенными управляющими конструкциями, но и между
структурированными и неструктурированными программами. Она выражается
отношением N(G) = ν
*
(G) + Σ P
i
, где ν
*
(G) - модифицированная цикломатическая
сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n-
выходами рассматривается как один логический оператор, а не как n - 1 операторов. Р
i
-
глубина вложенности i - той предикатной вершины.
Для подсчета глубины вложенности предикатных вершин используется число сфер
влияния. Под глубиной вложенности понимается число всех сфер влияния предикатов,
которые либо полностью содержаться в сфере рассматриваемой вершины, либо
пересекаются с ней. Глубина вложенности увеличивается за счет вложенности не самих
предикатов, а сфер влияния. Сравнительный анализ цикломатических и функциональных
мер с обсуждаемой для десятка различных управляющих графов программы показывает,
что при нечувствительности прочих мер этого класса, мера Пивоварского возрастает при
переходе от последовательных программ к вложенным и далее к неструктурированным.
Мера Мак-Клура предназначена для управления сложностью структурированных
программ в процессе проектирования. Она применяется к иерархическим схемам
разбиения программ на модули, что позволяет выбрать схему разбиения с меньшей
сложностью задолго до написания программы. Метрикой выступает зависимость
сложности программы от числа возможных путей исполнения, числа управляющих
конструкций и числа переменных (от которых зависит выбор пути). Методика расчета
сложности по Мак-Клуру четко ориентирована на хорошо структурированные программы.
Тестирующей мерой М называется мера сложности, удовлетворяющая следующим
условиям:
1. Мера сложности простого оператора равна 1;
2. М ({F1; F2; ┘;Fn}) = е
i
n
M(Fi);
3. М (IF P THEN F1 ELSE F2) = 2 MAX (M (F1), M (F2));
4. М (WHILE P DO F) = 2 M(F).
Мера возрастает с глубиной вложенности и учитывает протяженность программы. К
тестирующей мере близко примыкает мера на основе регулярных вложений. Идея этой
меры сложности программ состоит в подсчете суммарного числа символов (операндов,
операторов, скобок) в регулярном выражении с минимально необходимым числом скобок,
описывающим управляющий граф программы. Все меры этой группы чувствительны к
вложенности управляющих конструкций и к протяженности программы. Однако
возрастает уровень трудоемкости вычислений.
Рассмотрим меры сложности, учитывающие характер разветвлений. В основе узловой
меры Вудворда, Хедли лежит идея подсчета топологических характеристик потока
управления. При этом, под узловой сложностью понимается число узлов передач
управления. Данная мера отслеживает сложность линеаризации программы и
чувствительна к структуризации (сложность уменьшается). Она применима для сравнения
эквивалентных программ, предпочтительнее меры Холстеда, но по общности уступает
мере Мак-Кейба.
Топологическая мера Чена выражает сложность программы числа пересечений границ
между областями, образуемыми блок - схемой программы. Этот подход применим только
к структурированным программам, допускающим лишь последовательное соединение
управляющих конструкций. Для неструктурированных программ мера Чена существенно
зависит от условных и безусловных переходов. В этом случае можно указать верхнюю и
нижнюю границы меры. Верхняя - есть m+1, где m - число логических операторов при их
гнездовой вложенности. Нижняя - равна 2. Когда управляющий граф программы имеет
только одну компоненту связности, мера Чена совпадает с цикломатической мерой
Мак-Кейба.
Метрики Джилба оценивают сложность графоориентированных модулей программ
отношением числа переходов по условию к общему числу исполняемых операторов.
Хорошо зарекомендовала себя метрика, относящаяся число межмодульных связей к
общему числу модулей. Названные метрики использовались для оценки сложности
эквивалентных схем программ, в особенности схем Янова.
Используются также меры сложности, учитывающие историю вычислений, характер
взаимодействия модулей и комплексные меры.
Совокупность цикломатических мер пригодна для оценивания сложности первичных
формализованных спецификаций, задающих в совокупности исходные данные, цели и
условия построения искомого ПО. Оценка этой первичной программы или сравнение
нескольких альтернативных ее вариантов позволит изначально гармонизировать процесс
разработки ПО и от стартовой точки контролировать и управлять его текущей
результирующей сложностью.
Раздел 2
Стандарты, определяющие жизненный цикл ПО
2.1 Модели жизненного цикла программного обеспечения
Согласно источникам [1,3], в настоящее время просматривается тенденция в сторону
увеличения объема работ, связанных с разработкой программного обеспечения по
сравнению с работами, выполнение которых позволит получить аппаратные средства
ЭВМ. Таким образом, имеет смысл более подробно рассматривать технологический
процесс разработки программных средств, жизненный цикл программного обеспечения,
реализующих специальное математическое, информационное, программное,
лингвистическое обеспечение ЭВМ.
В основе деятельности по созданию и использованию программного обеспечения лежит
понятие жизненного цикла. В общем случае различают понятия жизненного цикла
программного обеспечения и технологического процесса его разработки. Более четко
различия между данными понятиями просматривается в отношении программных
средств. Жизненный цикл является моделью создания и использования программного
обеспечения, отражающей его различные состояния, начиная с момента возникновения
необходимости в данном ПО и заканчивая моментом его полного выхода из употребления
у пользователей.
Существует несколько моделей жизненного цикла. Традиционно выделяют следующие
основные этапы жизненного цикла (рис.2.1):
стратегическое планирование; анализ требований;
проектирование (предварительное и детальное);
кодирование (программирование);
тестирование и отладка;
эксплуатация и сопровождение.
Каждому этапу соответствуют определенный результат и набор документации,
являющейся исходными данными для следующего этапа. В заключение каждого этапа
производится верификация документов и решений с целью проверки их соответствия
первоначальным требованиям заказчика.
Исторически, в ходе эволюционного развития теории проектирования программного
обеспечения и по мере его усложнения, сложились три основные модели жизненного
цикла [4]. Эти модели выражают последовательность этапов ЖЦ ПО. До 80-х годов имела
место каскадная модель ЖЦ, подразумевавшая переход на последующие этапы ЖЦ
только после полного окончания работ на предыдущих этапах. С развитием
вычислительной техники, в середине 80-х, сложность и объемы программного
обеспечения существенно возросли. В связи с этим возникли проблемы с разработкой и
отладкой ПО. Продумать все шаги разработки нового ПО, наметить этапы
проектирования и предусмотреть все варианты поведения при отладке программного
обеспечения стало не под силу одному разработчику. Каскадная модель ЖЦ стала
существенно сдерживать темпы создания сложных программных систем. Процесс
отладки, при этом, затягивался и не давал гарантий безошибочной работы программ.
Рис 2.1 Этапы ЖЦ ПО
На смену каскадной модели, жестко регламентирующей последовательность этапов и
критерии переходов между ними, пришла поэтапная модель с промежуточным
контролем. Это итерационная модель разработки ПО с обратными связями между
этапами. Проверки и корректировки разрабатываемой ИС проводятся на каждом из
этапов, что позволяет существенно снизить трудоемкость отладки по сравнению с
каскадной моделью. Итерационность модели проявляется в обработке ошибок
выявленных промежуточным контролем. Если на каком-либо из этапов в ходе
промежуточной проверки обнаружилась ошибка, допущенная на более ранней стадии
разработки, работы этапа, повлекшего ошибку, необходимо провести повторно. При этом,
анализируются причины ошибки и корректируются, по необходимости, исходные данные
этапа или перечень проводимых работ. Аналогичная ситуация возникает если в ходе
разработки ИС возникают новые требования заказчика или изменяются какие-либо
условия функционирования ИС.
Спиральная модель поддерживает итерации поэтапной модели, но особое внимание
уделяется начальным этапам проектирования: анализу требований, проектированию
спецификаций, предварительному проектированию и детальному проектированию.
Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии
ПО, уточняются цели и требования к ПО, оценивается качество разработанного фрагмента
или версии ПО и планируются работы следующего витка. Таким образом, углубляются и
конкретизируются все детали проектируемого ПО, и в результате получается вариант,
который удовлетворяет всем требованиям заказчика.
Количество, состав и последовательность этапов ЖЦ для каждого конкретного ПО
определяется на ранних стадиях планирования создания ПО. При этом учитываются
особенности эксплуатации, наличие разного рода ограничений, численность и
квалификация персонала разработчиков и эксплуатационников, а также множество других
факторов.
Как было отмечено выше, жизненные циклы систем, процессов их разработки,
эксплуатации и сопровождения регламентированы в стандартах. При этом стандарты,
разрабатываемые международными организациями в той или иной области деятельности,
носят рекомендательный характер и не возведены в ранг закона. Руководящие принципы,
определенные в стандартах, имеют официальную силу тогда, когда приняты
правительством той или иной страны. В настоящее время общепризнанными
международными лидерами в области стандартизации разработки ПО стали следующие
организации: Американский национальный институт по стандартизации - ANSI;
Международная организация по стандартизации - ISO; Министерство обороны США -
DOD, Институт инженеров по электронике и радиотехнике (IEEE).
Далее рассмотрим, какие конкретные жизненные циклы разработки ПО созданы в нашей
стране и за рубежом, а также какими стандартами они регламентированы.
2.2 Стадии разработки ПО, регламентированных ГОСТами.
В нашей стране жизненный цикл разработки ПО установлен стандартом ГОСТ 19.102-77
Стадии разработки программ и программной документации и содержит следующие
стадии и этапы:
1. Техническое задание (ТЗ).
2. Эскизный проект (ЭП).
3. Технический проект (ТП).
4. Рабочий проект (РП).
5. Внедрение.
В табл. 2.1 показаны стадии разработки и этапы, их составляющие.
Неверно предполагать, что жизненный цикл разработки ПО согласно ГОСТ 19.102-77 есть
последовательное выполнение стадий и этапов, определенных в таблице 2. В реальном
жизненном цикле трудно провести четкую и определенную границу между этапами, а сам
процесс создания ПО является итеративным: после завершения некоторого этапа почти
всегда есть необходимость в коррекции уже выполненных этапов и стадий с целью
внесения уточнений. При разработке принципиально нового ПО иногда бывает
необходимо осуществить пробную реализацию с целью получения информации,
требующейся для принятия решения на некоторой стадии.
Таблица 2.1
Стадии разработки
Этапы работ
Техническое задание
1. Обоснование необходимости разработки программ.
2. Выполнение научно-исследовательских работ (НИР).
3. Разработка и утверждение технического задания.
Эскизный проект
1. Разработка эскизного проекта.
2. Утверждение эскизного проекта.
Технический проект
1. Разработка технического проекта.
2. Утверждение технического проекта.
Рабочий проект
1. Разработка программы.
2. Разработка программной документации.
3. Испытание программы.
Внедрение
1. Подготовка и передача программы.
Специалистам в области разработки ПО известно, что наиболее важными стадиями в
жизненном цикле разработки являются начальные, так как ошибки, допущенные на них,
требуют значительных затрат на исправление на конечных стадиях.
Техническое задание. На стадии Техническое задание выполняются следующие работы,
входящие в состав соответствующих этапов.
1. Обоснование необходимости разработки программ:
постановка задачи;
сбор исходных материалов;
выбор и обоснование критериев эффективности и качества;
обоснование необходимости проведения НИР.
2. Выполнение научно-исследовательских работ:
определение структуры входных и выходных данных;
предварительный выбор методов решения задач;
обоснование целесообразности применения ранее разработанных программ;
определение требований к техническим средствам;
обоснование принципиальной возможности решения поставленных задач.
3. Разработка и утверждение технического задания:
определение требований к программе;
разработка технико-экономического обоснования разработки программы;
определение стадий, этапов и сроков разработки программы и документации на нее;
выбор языков программирования;
определение необходимости проведения НИР на последующих стадиях;
согласование и утверждение ТЗ.
Результатом выполнения данной стадии является техническое задание, оформленное в
соответствии с ГОСТ 19.105-78 (изм. 09.1981.) Общие требования к программным
документам и ГОСТ 19.106-78 Общие требования к программным документам,
выполненным печатным способом на листах формата 11 и 12 (по ГОСТ 2.301-68).
Эскизный проект. Основные этапы и содержание работ на стадии Эскизный проект
приведены в таблице 2.2.
Таблица 2.2
Этапы работ
Содержание
Разработка ЭП
1. Предварительная разработка структуры входных и выходных
данных.
2. Уточнение методов решения задач.
3. Разработка общего описания алгоритма решения задачи.
4. Разработка технико-экономического обоснования.
Утверждение ЭП
1. Разработка пояснительной записки.
2. Согласование и утверждение эскизного проекта.
Конкретное содержание работ стадии эскизного проекта и их объем определяет степень
сложности разрабатываемого ПО. Результатом выполнения данной стадии является
полное описание архитектуры ПО. Как правило, это описание делается на нескольких
уровнях иерархии. На верхнем уровне детализации выделяются основные подсистемы,
которым присваиваются имена, устанавливаются связи между подсистемами, их функции,
получаемые путем декомпозиции предполагаемых функций ПО. Затем процедура
декомпозиции выполняется для каждой подсистемы, выделяются модули, составляющие
данную подсистему. В конечном итоге, получается иерархически организованная система,
состоящая из уровней, каждый из которых представляет собой совокупность
взаимосвязанных модулей.
Единицы, выделяемые на различных иерархических уровнях функциональной
архитектуры системы, определяются по усмотрению разработчика. Стандарты ЕСПД
различают программные единицы только с точки зрения их документирования.
Результаты эскизного проекта отображаются в документе Пояснительная записка к
эскизному проекту, оформленному в соответствии с ГОСТ 19.105-78 и ГОСТ 19.404-79.
После утверждения пояснительной записки она становится программным документам,
правила дублирования, учета, хранения которого определяется ГОСТ 19.601-78 Общие
правила дублирования, обращения, учета и хранения и ГОСТ 19.602-78 Правила
дублирования, учета и хранения программных документов, выполненных печатным
способом. Последующие стадии и этапы разработки ПО могут выявить необходимость
внесения изменений в ЭП. Эти изменения должны быть отражены в пояснительной
записке в соответствии с ГОСТ 19.603-78 Общие правила внесения изменений в
программные документы и ГОСТ 19.602-78 Правила внесения изменений в программные
документы, выполненные печатным способом.
В качестве примера, ниже приводится фрагмент расширенного описания работ стадии
эскизного проекта.
1. Разработка эскизного проекта ПО.
разработка плана совместных работ на разработку ПО;
разработка и обоснование математической модели системы на ЭВМ и описание
результатов моделирования;
разработка и обоснование алгоритмов и временных графиков функционирования ПО по
всем режимам работы;
разработка и обоснование ресурсов памяти для реализации алгоритмов;
разработка перечня документов на ПО;
разработка и обоснование структуры БД, внешних входных и выходных данных;
разработка и обоснование алгоритмов информационного обеспечения;
определение взаимосвязей между видами программ;
разработка и обоснование набора тестов для проверки ПО;
разработка и обоснование организации наращивания и развития ПО;
оформление пояснительной записки и ведомости эскизного проекта ПО (в
соответствии с ГОСТ 19.105-78, ГОСТ 19.404-79 и ГОСТ 2.106-68 ЕСКД. Текстовые
документы);
согласование и утверждение ЭП.
Технический проект. Основные этапы и содержание работ на стадии Технический
проект приведены в таблице 2.3.
Содержанием работ на этой стадии является проектирование структуры ПО. Результатом -
реализующий заданный и утвержденный в техническом задании комплекс программ как
иерархическая структура программных модулей, заданных своими функциональными
спецификациями. Форма представления результата - Пояснительная записка к
техническому проекту согласно ГОСТ 19.105-78, ГОСТ 19.404-79.
Разработка структуры ПО заключается в выделении всех программных компонентов по
функциональным признакам, определение функциональных спецификаций модулей и
уточнение внешних функциональных спецификаций, структуры входных и выходных
данных, определении операционной среды, языковых средств и конфигурации
аппаратных средств.
Спецификации модулей являются внешними характеристиками и содержат все сведения,
необходимые вызывающим модулям. На последующих стадиях разработки спецификации
оформляются в виде комментариев в начале текста исходной программы модуля. На
данной стадии спецификации оформляются в виде комментария на принятом в
организации, занимающейся разработкой ПО, языке спецификаций
Таблица 2.3.
Этапы работ
Содержание
Разработка ТП
1. Уточнение структуры входных и выходных данных.
2. Разработка алгоритмов решения задач.
3. Определение формы представления входных и выходных данных.
4. Определение синтаксиса и семантики языка.
5. Разработка структуры программы.
6. Окончательное определение конфигурации технических средств.
Утверждение ТП
1. Разработка плана мероприятий по разработке и внедрению
программ.
2. Разработка пояснительной записки.
3. Согласование и утверждение ТП.
Фрагмент описания работ стадии технического проекта приведен ниже.
1. Разработка технического проекта ПО.
разработка плана совместных работ на разработку ПО;
распараллеливание задач применительно к возможностям ЭВМ и систем обмена
информации и разработка организационной структуры программ;
формализация программно-аппаратных и внутризадачных интерфейсов;
разработка алгоритмов управления вычислительным процессом и процессами обмена, его
исследование и оптимизация;
разработка и комплексное решение вопросов обеспечения устойчивой работы на
программном уровне;
разработка модели и исследование на ней возможности реализации всех функций системы
управления в рамках имеющихся вычислительных ресурсов на основе выбранного
управляющего алгоритма и оптимизация структуры программ до получения
удовлетворяющего результата;
уточнение структуры и определение формы представления БД, внешних входных и
выходных данных;
разработка проекта описания программы для каждого вида программ ПО;
уточнение алгоритмов ПО и алгоритмов информационного обеспечения в процессе
решения задач;
разработка проекта описания текстовых программ ПО;
разработка плана реализации ПО;
разработка проектов технических условий на ПО;
разработка и обоснование решений по надежности функционирования ПО;
разработка программы и правил испытаний ПО;
уточнение временных графиков функционирования программ ПО в процессе решения
задач;
оформление пояснительной записки и ведомости технического проекта ПО (в
соответствии с ГОСТ 19.105-78, ГОСТ 19.404-79 и ГОСТ 2.106-68 ЕСКД. Текстовые
документы);
согласование и утверждение ТП.
Рабочий проект. Основные этапы и содержание работ на стадии Рабочий проект
приведены в таблице 2.4.
Таблица 2.4
Этапы работ
Содержание
Разработка ПО
•
Программирование и отладка программ.
Разработка программной
документации
1. Разработка программных документов в
соответствии с требованиями ГОСТ 19.101-77.
Испытание ПО
1. Разработка, согласование и утверждение программ
и методики испытаний
2. Проведение предварительных государственных,
межведомственных приемо-сдаточных и других
видов испытаний.
3. Корректировка ПО и программной документации
по результатам испытаний.
Содержанием работ на этой стадии является описание ПО на выбранном
проблемно-ориентированном языке (кодирование), отладка, разработка, согласование и
утверждение порядка и методики испытаний, разработка программных документов,
проведение тестирования, корректировка программ и программной документации по
результатам тестирования, проведение приемо-сдаточных испытаний. Результат - ПО в
форме программной документации, в форме документации на ПО или в форме
программного изделия.
На стадии Внедрения осуществляется подготовка и передача ПО и программной
документации для сопровождения и/или изготовления, оформление и утверждение акта о
передаче ПО на сопровождение или изготовление, передача ПО в фонд алгоритмов и
программ.
Кроме рассмотренного выше жизненного цикла программ, установленного 19 - ой
системой стандартов, необходимо иметь в виду, что существует жизненный цикл
автоматизированных систем, установленный ГОСТ 34.601-90. Имеет смысл рассмотреть
стадии и этапы разработки АС, так как 19-я система стандартов в настоящее время
морально устарела и более современным представляется жизненный цикл АС. Анализ
жизненных циклов разработки ПО, установленных ГОСТ 19.102 и ГОСТ 34.601, а также
международных стандартов, регламентирующих данный процесс, будет приведен ниже.
Стандарт ГОСТ 34.601 распространяется на автоматизированные системы (АС),
представляющие собой организационно-технические системы, обеспечивающую
выработку решений на основе автоматизации информационных потоков в различных
видах деятельности (исследование, проектирование, управление и т.п.), включая их
сочетания, создаваемые в организациях, объединениях и на предприятиях. Данный
стандарт устанавливает стадии и этапы создания АС.
В процессе разработки АС создают, в общем случае, следующие виды обеспечения:
техническое, программное, информационное математическое и др. Проектные решения по
программному, техническому и информационному обеспечению реализуют как изделия в
виде взаимоувязанной совокупности компонент и комплексов, входящей в состав АС с
необходимой документацией. Справочное приложение к ГОСТ 34.601 устанавливает, что
программное обеспечение АС - совокупность программ на носителях информации с
программной документацией по ГОСТ 19.101. Таким образом, при разработке
программного обеспечения можно пользоваться как стандартом ГОСТ 19.102, так и ГОСТ
34.601.
Процесс создания АС представляет собой совокупность упорядоченных во времени,
взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых
необходимо и достаточно для создания АС, соответствующей заданным требованиям.
Стадии и этапы создания АС выделяются как части процесса создания по соображениям
рационального планирования и организации работ, заканчивающих заданным
результатом.
Как и в стандарте ГОСТ 19.102, работы по развитию АС осуществляются по стадиям и
этапам, применяемым для создания АС. Состав и правила выполнения работ на
установленных настоящим стандартом стадиях и этапах определяют в соответствующей
документации организаций, участвующих в создании конкретных видов АС.
Стадии и этапы создания АС в общем случае приведены в таблице 2.5.
Стандартом ГОСТ 34.601 допускается исключать стадию Эскизный проект и отдельные
этапы работ на всех стадиях, объединять стадии Технический проект и Рабочая
документация в одну стадию Технорабочий проект. В зависимости от специфики
создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до
завершения предшествующих стадий, параллельное во времени выполнения этапов работ,
включение новых этапов работ.
Рассмотрим этапы, касающиеся разработки программного обеспечения.
При Обследование объекта и обоснование необходимости создания АС проводят: сбор
данных об объекте автоматизации и осуществляемых видах деятельности; оценку
качества функционирования объекта и осуществляемых видов деятельности, выявления
проблем, решение которых возможно средствами автоматизации; оценку
(технико-экономической, социальной и т.п.) целесообразности создания АС.
На этапе Формирование требований пользователя к АС проводят:
подготовку исходных данных для формирования требований к АС (характеристика
объекта автоматизации, описание требований к системе, ограничения допустимых затрат
на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия
создания и функционирования);
формулировку и оформление требований пользователя к АС.
Таблица 2.5.
Стадии
Этапы работ
1. Формирование требований
к АС
1.1. Обследование объекта и обоснование необходимости
создания АС
1.2. Формирование требований пользователя к АС
1.3. Оформление отчета о выполненной работе и заявки на
разработку АС (тактико-технического задания)
2. Разработка концепции АС
2.1. Изучение объекта
2.2. Проведение необходимых научно - исследовательских
работ
2.3. Разработка вариантов концепции АС и выбор варианта
концепции АС, удовлетворяющего требованиям
пользователя
2.4. Оформление отчета о выполненной работе
3. Техническое задание
3.1. Разработка и утверждение технического задания на
создание АС
4. Эскизный проект
4.1. Разработка предварительных проектных решений по
системе и ее частям
4.2. Разработка документации на АС и ее части
5. Технический проект
5.1. Разработка проектных решений по системе и ее частям
5.2. Разработка документации на АС и ее части
5.3. Разработка и оформление документации на поставку
изделий для комплектования АС и/или технических
требований (технических заданий) на их разработку
5.4. Разработка заданий на проектирование в смежных
частях проекта объекта автоматизации
6. Рабочая документация
6.1. Разработка рабочей документации на систему и ее
части
6.2. Разработка или адаптация программ
7. Ввод в действие
7.1. Подготовка объекта автоматизации к вводу АС в
действие
7.2. Подготовка персонала
7.3. Комплектация АС поставляемыми изделиями
(программными и техническими средствами,
программно-техническими комплексами,
информационными изделиями)
7.4. Строительно-монтажные работы
7.5. Пусконаладочные работы
7.6. Проведение предварительных испытаний
7.7. Проведение опытной эксплуатации
7.8. Проведение приемочных испытаний
8. Сопровождение АС
8.1. Выполнение работ в соответствии с гарантийными
обязательствами
8.2. Послегарантийное обслуживание
На этапе Оформление отчета о выполненной работе и заявки на разработку АС
(тактико-технического задания) проводят оформление отчета о выполненных работах на
данной стадии и оформление заявки на разработку АС (тактико-технического задания)
или другого заменяющего ее документа с аналогичным содержанием.
При Изучение объекта и Проведение необходимых НИР организация-разработчик
проводит детальное изучение объекта автоматизации и необходимые НИР, связанные с
поиском путей и оценкой возможности реализации требований пользователя, оформляют
и утверждают отчеты о НИР.
Этап Разработка вариантов концепции АС и выбор варианта концепции АС,
удовлетворяющего требованиям пользователя направлен на разработку альтернативных
вариантов концепции создаваемой АС и планов реализации; оценку необходимых
ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и
недостатков каждого варианта; сопоставление требований пользователя и характеристик
предлагаемой системы и выбор оптимального варианта; определение порядка оценки
качества и условий приемки системы; оценку эффектов, получаемых от системы.
На этапе Оформление отчета о выполненной работе подготавливают и оформляют отчет,
содержащий описание выполненных работ на стадии, описание и обоснование
предлагаемого варианта концепции системы.
На этапе Разработка и утверждение технического задания на создание АС проводят
разработку, оформление, согласование и утверждение технического задания на АС и, при
необходимости, технических заданий на части АС.
Результатом выполнения этапа Разработка предварительных проектных решений по
системе и ее частям является: функции АС; функции подсистем, их цели и эффекты;
состав комплекса задач и отдельных задач; концепции информационной базы, ее
укрупненная структура; функции СУБД; состав вычислительной системы; функции и
параметры основных программных средств.
На этапе Разработка проектных решений по системе и ее частям обеспечивают разработку
общих решений: по системе и ее частям, функционально-алгоритмической структуре
системы; по функциям персонала и организационной структуре; по структуре
технических средств; по алгоритмам решения задач и применяемым языкам; по
организации и ведению информационной базы, системе классификации и кодирования
информации; по программному обеспечению.
На этапах 4.2 и 5.2 Разработка документации на АС и ее части проводят разработку,
оформление, согласование и утверждение документации в объеме, необходимом для
описания полной совокупности принятых проектных решений и достаточном для
дальнейшего выполнения работ по созданию АС.
На этапе Разработка и оформление документации на поставку изделий для комплектации
АС и (или) технических требований (технических заданий) на их разработку проводят:
подготовку и оформление документации на поставку изделий для комплектования АС;
определение технических требований и составление ТЗ на разработку изделий, не
изготавливаемых серийно.
На этапе Разработка заданий на проектирование в смежных частях проекта объекта
автоматизации осуществляют разработку, оформление, согласование и утверждение
заданий на проектирование в смежных частях проекта объекта автоматизации для
проведения строительных, электротехнических, санитарно-технических и других
подготовительных работ, связанных с созданием АС.
При выполнении этапа Разработка рабочей документации на систему и ее части
осуществляют разработку рабочей документации, содержащей все необходимые и
достаточные сведения для обеспечения выполнения работ по вводу АС в действие и ее
эксплуатации, а также для поддерживания уровня эксплуатационных характеристик
(качества) системы в соответствии с принятыми проектными решениями, ее оформление,
согласование и утверждение. Виды документов - по ГОСТ 34.201.
На этапе Разработка и адаптация программ проводят разработку программ и программных
средств системы, выбор, адаптацию и (или) привязку приобретенных программных
средств, разработку программной документации в соответствии с ГОСТ 19.101.
На этапе Подготовка объекта автоматизации к вводу АС в действие проводят работы по
организационной подготовке объекта автоматизации к вводу АС в действие, в том числе:
реализацию проектных решений по организационной структуре АС; обеспечение
подразделений объекта управления инструктивно-методическими материалами;
внедрение классификаторов информации.
Этап Подготовка персонала направлен на обучение персонала и проверку его способности
обеспечить функционирование АС.
На этапе Комплектация АС поставляемыми изделиями обеспечивают получение
комплектующих изделий серийного и единичного производства, материалов и монтажных
изделий. Проводят входной контроль их качества.
На этапе Пусконаладочные работы проводят автономную наладку технических и
программных средств, загрузку информации в БД и проверку системы ее ведения;
комплексную наладку всех средств системы.
На этапе Проведение предварительных испытаний осуществляют: испытание АС на
работоспособность и соответствие ТЗ в соответствии с программой и методикой
предварительных испытаний; устранение неисправностей и внесение изменений в
документацию на АС, в том числе эксплуатационную в соответствии с протоколом
испытаний; оформление акта о приемке АС в опытную эксплуатацию.
На этапе Проведение опытной эксплуатации проводят: опытную эксплуатацию АС;
анализ результатов опытной эксплуатации АС; доработку (при необходимости)
программного обеспечения АС; дополнительную наладку (при необходимости)
технических средств АС; оформление акта о завершении опытной эксплуатации.
На этапе Проведение приемочных испытаний проводят испытания на соответствие ТЗ в
соответствии с программой и методикой приемочных испытаний, анализ результатов
испытаний АС и устранение недостатков, выявленных при испытаниях, а также
оформление акта о приемке АС в постоянную эксплуатацию.
На этапе Выполнение работ в соответствии с гарантийными обязательствами
осуществляются работы по устранению недостатков, выявленных при эксплуатации АС в
течение установленных гарантийных сроков, внесению необходимых изменений в
документацию на АС.
На этапе Послегарантийное обслуживание осуществляются работы по анализу
функционирования системы, выявлению отклонений фактических эксплуатационных
характеристик АС от проектных значений, установлению причин этих отклонений,
устранению выявленных недостатков и обеспечение стабильности эксплуатационных
характеристик АС, внесению необходимых изменений в документацию на АС.
Требования к содержанию документов, разрабатываемых на каждой стадии и этапе,
устанавливает руководящий документ РД-50-34.698-90. Кроме того, необходимо
использовать для из разработки соответствующие стандарты Единой системы
программной документации, Единой системы конструкторской документации и ГОСТ
34.602. Виды и комплектность документов регламентированы в ГОСТ 34.201.
2.3 Жизненный цикл разработки ПО с повышенными требованиями к безопасности
системы
Жизненный цикл разработки ПО, регламентированный документом DO - 178 [5],
заслуживает внимания из следующих соображений. Программное обеспечение,
используемое в бортовых системах и оборудование летательных аппаратах, исполняет
свою функцию с уровнем доверия к безопасности, которая соответствует требованиям
авиационного приложения. Данные требования авиационного приложения отличаются от
аналогичных в других сферах более жесткими требованиями по качеству, надежности, так
как влияют на безопасность пассажиров и характеристики самого летательного аппарата.
Необходимо заметить, что описанные ниже руководящие принципы относительно
жизненного цикла, не возведены в ранг закона, но представляют из себя согласие
авиационного сообщества.
На рис. 2.2. показан краткий обзор аспектов безопасности информационного потока
между этапами жизненного цикла системы и этапами жизненного цикла ПО.
Этап оценки безопасности системы определяет категорию отказа системы. В рамках
данного этапа, анализ проекта системы определяет требования, связанные с
безопасностью, для аппаратных средств ЭВМ и ПО, для устранения и ограничения
влияния ошибок, с ними связанных. Требования, связанные с безопасностью - часть
требований к системе, которые вводятся в этапы жизненного цикла ПО. В целях гарантии
того, что требования связанные с безопасностью, учитываются на всех этапах жизненного
цикла ПО, требования к системе включают:
описание системы и аппаратных средств ЭВМ;
требования сертификации;
требования системы, относящиеся к ПО, включая функциональные и эксплуатационные
требования, а также требования, связанные с безопасностью;
уровни ПО, состояния отказа, их категории и связанные с этим функции, относящиеся
к ПО;
стратегии безопасности и проект разработки;
Рис.2.2 Информационные потоки между системой и этапами жизненного цикла ПО.
Этап оценки безопасности системы определяет воздействия процессов проектирования и
внедрения ПО на безопасность системы путем использования информации, поступающей
от этапов жизненного цикла ПО. Эта информация включает границу распространения
неисправности, требования ПО и его архитектуру, а также источники ошибок, которые
могут быть обнаружены и устранены благодаря ПО или при помощи инструментов и
методов, используемых при разработке ПО.
Имеют место следующие этапы жизненного цикла ПО, установленные данным
документом:
этап планирования разработки, который определяет и координирует действия по
разработке программного обеспечения;
этап разработки, на котором создается ПО и включающий в себя работы по определению
требований, проектированию, кодированию, получению исполняемого кода;
интегрированный этап, обеспечивающий корректировку, проверку и определение
полноты ПО, а также его выпуск и включающий в себя верификацию, контроль за
конфигурацией ПО, оценку качества и проверку взаимодействия этапом друг с другом.
На рис. 2.3. показаны этапы жизненного цикла ПО и их взаимодействие друг с другом.
Проект ПО определяет один или более жизненных циклов посредством выбора действий
на каждом этапе, назначения последовательности этих действий и ответственных за них.
Для разработки конкретного ПО последовательность этапов определяется на основе
анализа таких свойств, как функциональные возможности, сложность, размер,
устойчивость, использование ранее полученных результатов, разрабатываемой стратегией
и аппаратной поддержкой. Обычная последовательность этапов жизненного цикла ПО,
как показано на рис. 2.3, включает определение требований, проектирования, кодирования
и получения исполняемого кода.
Рис. 2.3 Этапы жизненного цикла ПО.
На рис.2.4 показана последовательность этапов жизненного цикла для компонентов
еденичного программного продукта с различными жизненными циклами.
Рис. 2.4 Пример проекта ПО, использующего четыре различных последовательности
разработки.
Компонент W выполняет множество системных требований для разработки программных
требований (R), использует эти требования для проектирования ПО (D), исполняет этот
проект в исходном коде (C) и тогда интегрирует компонент с аппаратурой (I).
Компонент X показывает использование ранее разработанного ПО, которое уже было
сертифицировано.
Компонент Y показывает использование простой отдельной функции, которая может быть
закодирована прямо на основе требований к ПО.Компонент Z показывает использование
прототипной стратегии. Обычно, целями прототипирования является лучшее понимание
требований к ПО и уменьшение технических рисков и рисков разработки. Исходные
требования используются как базис для получения прототипа. Этот прототип
преобразуется в среду, типичную для конкретного использования системы при
разработке. Результатом преобразования является использование уточненных данных.
Этапы жизненного цикла могут носить итерационный характер, т.е. повторяться
несколько раз. Количество этапов и итераций варьируется из-за доработок функций ПО,
сложности, появления новых требований или нового аппаратного обеспечения,
результатов выполнения предыдущих этапов, которые претерпели изменения, а также
других особенностей.Практически все этапы жизненного цикла ПО объединяются с
интегрированным этапом и действиями по верификации.
Для перехода с одного этапа на другой необходимо предусмотреть критерии перехода.
Критерии перехода будут зависеть от запланированной последовательности шагов
разработки и шагов интегрированного этапа, а также от уровня ПО (уровень ПО
определяется на основе анализа вклада, которое оно вносит в набор потенциальных
состояний отказа системы). Например, в качестве критерия перехода можно назвать:
что было выполнено при рецензирование на этапе верификации;
вход определенного элемента конфигурации;
трассировка, проведенная для входа.
Если удовлетворен критерий перехода к последующему этапу, то нет необходимости в
том, чтобы каждый вход этого этапа был сформирован до начала его выполнения.
Руководящий принцип следующий: если этап производит действия над отдельными
входами, последовательность входов должна быть проверена с целью определения того,
что выходы предшествующих шагов этапа разработки и интегрированного этапа еще
имеют силу.
Рассмотрим подробно цели и действия каждого этапа ЖЦ.
На этапе планирования разработки ПО создаются планы и выбираются стандарты,
которые направляют этап разработки и интегрированный этап. Его целью является
определение средств для создания ПО, которое будет удовлетворять требования,
предъявляемые к нему и обеспечивать достаточный уровень надежности. На этом этапе
производиться:
определение действий на этапах разработки и интегрированном этапе, которые будут
посвящены определению системных требований и уровня ПО;
определение ЖЦ ПО, включая взаимодействие между этапами, механизм взаимного
влияния этапов, критерии оценки ПО при переходе от одного этапа к другому;
определение среды ЖЦ, т.е. методы и инструментальные средства, используемые на
каждом этапе;
формирование дополнительных замечаний к ПО;
рассмотрение стандартов разработки ПО, соотношение их с системными целями
безопасности, относящиеся к разрабатываемому ПО;
разработка плана создания ПО;
доработка и проверка плана создания ПО.
Эффективность планирования - определяющий фактор при разработке ПО. Основные
руководящие принципы этого этапа следующие.
1. План разработки ПО должен быть разработан в такой момент ЖЦ, чтобы обеспечить
своевременное управление конкретными действиями на этапе разработки и
интегрированном этапе.
2. Стандарты разработки ПО, используемые в проекте, должны быть строго
определенными и четкими.
3. Выбранные методы и инструментальные средства должны быть такие, чтобы
обеспечили предотвращение ошибок на этапе разработки или свели их к минимуму.
4. Этап планирования разработки ПО должен обеспечить координацию между
остальными этапами с целью согласования их стратегий в плане разработки ПО.
5. Этап планирования разработки ПО должен включать в себя средства проверки плана на
этапе реализации проекта.
6. На завершающей стадии этапа планирования, план и стандарты разработки ПО должны
быть проанализированы на предмет полноты и непротиворечивости.
Другие этапы ЖЦ могут быть начаты до окончания этапа планирования при условии, что
имеются планы и процедуры для действий на этих этапах.
План разработки включает в себя следующие компоненты:
Задачей определения среды план программных аспектов сертификации, служащий
основным средством объединения предлагаемых методов разработки со службами
сертификации;
собственно план разработки, определяющий жизненные циклы и среду разработки;
план верификации ПО, определяющий средства, с помощью которых удовлетворяются
цели этапа верификации;
план управления конфигурацией ПО, определяющий средства, с помощью которых
удовлетворяются цели этапа оценки качества.
ЖЦ является обоснование методов, инструментальных средств, процедур, языков
программирования и аппаратного обеспечения, которые будут использоваться при
разработке, верификации, контроле и выпуске данных этапов жизненного цикла и ПО в
целом. Примером того, как выбор среды оказывает полезное влияние на ПО, может
служить строгое соблюдение стандартов, определение ошибок, предотвращение ошибок
исполнения, методов смягчения последствий сбоев в ПО. Среда ЖЦ является
потенциальным источником ошибок, которые способствуют возникновению сбоев ПО. На
состав среды влияют требования по безопасности, определяемые этапом оценки
безопасности системы.
Цель методов предотвращения ошибок - недопущение ошибок в ходе этапа разработки.
Основной принцип при выборе требований к разработке ПО, методам его проектирования
и программирования заключается в ограничении числа случаев внедрения ошибок и
применение таких методов верификации, которые гарантируют установление факта
внедрения ошибки.
Целью методов смягчения последствий сбоев является включение характеристик
безопасности в проект ПО для гарантии того, что ПО будет корректно реагировать на
ошибки входных данных и предотвращать ошибки выходных данных и ошибки
управления. Необходимость в методах предотвращения ошибок и смягчения последствий
сбоев определяется системными требованиями и этапом оценки безопасности системы.
Среда разработки ПО - определяющий фактор при разработке высококачественного и
надежного ПО. Среда может оказывать также и неблагоприятное влияние на процесс
разработки ПО. Например, компилятор может вносить ошибки в процессе компиляции,
загрузчик может давать сбои при обнаружении ошибок распределения памяти.
Руководящие принципы для выбора методов и инструментальных средств среды
разработки ПО следующие.
1. В ходе этапа планирования среда разработки должна быть выбрана исходя из минимума
потенциального риска для конечного ПО.
2. Использование специализированных инструментальных средств или инструментов и
компонентов среды должно производиться путем достижения необходимого уровня
гарантии того, что ошибки, вносимые одним компонентом, обнаружились бы другим. В
этом случае среда является приемлемой.
3. Действия на этапе верификации и стандарты разработки должны быть определены так,
чтобы свести к минимуму потенциальные ошибки, относящиеся к среде разработки ПО.
4. При поиске определенного уровня доверия к сертификации при использовании
комбинации инструментов, последовательность действий, производимых этими
инструментами, должна быть определена в соответствующем плане.
5. Если определены необязательные характеристики инструментальных средств среды для
использования в проекте, то влияние этих характеристик должно быть проверено и
специфицировано в соответствующем плане. Это особенно важно там, где инструмент
непосредственно создает часть ПО (в этом смысле компиляторы, вероятно, наиболее
важный инструмент).
Назначение стандартов разработки ПО является определение правил и ограничений для
этапа разработки. Эти стандарты включают в себя:
стандарт требований к ПО, который предназначен для определения методики,
правил и средств, используемых при разработке требований высокого уровня, и
включает:
а) методы, используемые при разработке требований к ПО (структурные,
объектно-ориентированные и др.);
б) нотации, используемые для выражения этих требований (диаграммы потоков
данных, спецификации формальных языков и др.);
в) ограничения на использование средств разработки требований;
стандарты проектирования ПО, которые позволяет определить методики, правила и
средства, используемые для создания архитектуры ПО и требований низкого уровня
и включающие:
а) используемые методы описания процесса проектирования;
б) используемые соглашения по именам;
в) условия, налагаемые на разрешенные методы проектирования (например,
использование прерываний и архитектур, управляемых событиями, динамическое
управление задачами и т.д.);
г) ограничения на использование средств проектирования;
д) ограничения на конструкцию (например, исключение, рекурсия, динамические
объекты, ссылки на данные под разными именами и т.д.);
е) ограничения по сложности (например, максимальное число вложенных вызовов
процедур или условных структур, использование безусловных ветвлений и т.д.);
стандарты кодирования ПО, которые позволяют определить языки
программирования, методы, правила и средства, используемые для кодирования ПО
и включающие:
а) используемые языки программирования и/или их подмножества (для языка
необходимо указать данные, которые непротиворечиво определяют синтаксис,
поведение управления, поведение данных и сторонние эффекты языка);
б) стандарты на представление исходного кода (например, ограничения на длину
строки, отступы, использование пустых строк), стандарты на документирование
исходного кода (например, имя автора, дата написания, входные и выходные данные,
используемые глобальные переменные);
в) соглашения по именам для компонентов, подпрограмм, переменных, констант;
г) условия и ограничения, налагаемые на разрешенные соглашения по коду (например,
степень связей между компонентами ПО и сложность логических и числовых
выражений);
д) ограничения на использование средств кодирования.
Этап верификации использует эти стандарты как основу для сравнения выходов этапов с
требуемыми результатами. Руководящие принципы для определения стандартов
включают в себя следующие.
1. Стандарты должны давать возможность компонентам ПО или взаимосвязанному
множеству продуктов разрабатываться единообразно.
2. Стандарты должны обеспечить невозможность использования таких конструкций или
методов, в результате выполнения которых получаются выходы, не соответствующие
требования безопасности.
Как отмечалось выше, составляющими этапа разработки ПО являются:
подэтап разработки требований к ПО;
подэтап проектирования ПО;
подэтап кодирования ПО;
подэтап интеграции ПО.
При разработке ПО вырабатывается один и более уровней требований к ПО. Требования
высокого уровня вытекают непосредственно из анализа требований к системе и ее
архитектуры. Далее они развиваются на подэтапе проектирования ПО, формируя один и
более последующих уровней требований, более низких. Однако если исходный код
генерируется непосредственно из требований высокого уровня (например, компонент Y
на рис. 2.4), то они могут рассматриваться одновременно и как требования низкого
уровня. В этом случае к ним применяются соответствующие основополагающие
принципы формирования.
Разработка архитектуры ПО предполагает принятие решения о структуре ПО. На подэтапе
проектирования ПО определяется как архитектура ПО, так и требования низкого уровня -
такие требования к ПО, исходя из которых, без какой либо дополнительной информации,
может быть непосредственно реализован исходный код.
Каждая из составляющих этапа разработки ПО может порождать производные требования
- требования, которые прямо не сводятся к требования высокого уровня. Например,
необходимость разработки ПО поддержки прерываний для выбранного целевого
компьютера. Требования как высокого (ВУ), так и низкого уровня (НУ) могут включать в
себя производные требования. Влияние последних на требования безопасности
определяется на этапе оценки безопасности системы.
В таблице 2.6 показаны цели каждого подэтапа, составляющих этап разработки, их
входные данные, результаты, основные принципы, применяемые на каждом из них.
Подэтап разработки требований к ПО использует выходные данные жизненного цикла
системы для выработки таких требований высокого уровня, как функциональные
требования, требования производительности, интерфейсные требования и требования
безопасности.
Требования высокого уровня к ПО на подэтапе проектирования перерабатываются в ходе
одной или более итераций в архитектуру ПО и требования низкого уровня, которые в
свою очередь используются для реализации исходного кода.
На подэтапе кодирования, исходя из архитектуры ПО и требований низкого уровня,
вырабатывается исходный код ПО.Целевой компьютер, а также исходный и объектный
код, получаемые из подэтапа кодирования, используются совместно с компоновкой и
загрузкой данных на подэтапе интеграции для создания интегрированной системы.
Подэтап интеграции включает программную и программно-аппаратную интеграцию.
Все подэтапы этапа разработки могут начинаться при удовлетворении планируемого
промежуточного критерия перехода. Подэтапы считаются завершенными, когда их цели и
цели всех связанных с ними подэтапов достигнуты.
Верификация, входящая в состав интегрированного этапа - это техническая оценка
результатов как этапа разработки ПО, так и этапа верификации ПО (последний
применяется согласно этапу планирования разработки ПО и плана верификации ПО).
Верификация не сводиться только к тестированию ПО. Тестирование, в общем случае, не
в состоянии показать отсутствие ошибок, поэтому употребляется термин верификация, а
не тестирование.
Таблица 2.6
Наименование
подэтапа
Цель подэтапа и входные
данные
Результат и основные принципы
Разработка
требований к
ПО
Цель:
- получение требований
ВУ;
- выработка производных
от них требований для
этапа оценки безопасности.
Входные данные:
- требования к системе,
аппаратный интерфейс,
архитектура системы;
- план разработки ПО;
- стандарты на требования
к ПО.
Первичный результат - данные о
требованиях.
Основные принципы:
- интерфейсные и функциональные
требования к системе, реализуемые на
базе ПО, должны быть
проанализированы на предмет
противоречий, несоответствия и
неопределенности;
- неадекватные и некорректные входные
данные должны быть направлены на
выработавшие их подэтапы для
разъяснения или исправления;
- каждое требование к системе,
реализуемое на базе ПО, должно быть
включено в требования ВУ;
- должны быть особо отмечены
требования ВУ, соответствующие
системным требованиям по
предотвращению выхода системы из
строя;
- требования ВУ должны
соответствовать стандартам на
требования к ПО;
- требования ВУ должны
формулироваться в количественных
терминах;
- требования ВУ не должны описывать
детали разработки или тестирования, за
исключением указанных и проверенных
ограничений конструкции;
- каждое системное требование,
реализуемое на базе ПО, должно быть
сводимо к одному или более требованию
ВУ к ПО;
- каждое требование ВУ, за
исключением производных требований,
должно быть сводимо к одному или
нескольким системным требованиям;
- производные требования ВУ должны
быть направлены этапу оценки
безопасности системы.
Проектирование
ПО
Цель:
- создание архитектуры ПО
и требований НУ;
- выработка производных
от них требований для
этапа оценки безопасности.
Входные данные:
- данные о требованиях к
ПО;
- план разработки ПО;
- стандарты
проектирования ПО.
Первичный результат - описание
разработки, включающее архитектуру
ПО и требования НУ.
Основные принципы:
- создаваемые требования НУ и
архитектура ПО должны
соответствовать стандартам разработки
ПО, быть непротиворечивыми и
допускать трассировку и проверку;-
определяемые производные требования
должны быть проанализированы на
предмет соответствия требованиям ВУ;
- на подэтапе проектирования ПО
следует ввести возможные типы сбоев
ПО и наоборот предотвратить
остальные, что может изменить ранее
назначенный программный уровень и
определить дополнительные данные в
качестве производных требований,
передаваемых этапу оценки
безопасности системы;
- потоки данных и управления должны
быть наблюдаемы согласно требованиям
безопасности;
- реакции на условия сбоев должны
соответствовать требованиям
безопасности;
- неадекватные или некорректные
входные данные должны быть переданы
либо этапу оценки жизненного цикла
системы, либо подэтапу разработки
требований, либо этапу планирования
разработки ПО по принципу обратной
связи для разъяснения или исправления.
Кодирование
ПО
Целью является получение
исходного кода, который
должен допускать
трассировку, проверку,
быть непротиворечивым и
корректно реализовывать
требования НУ.
Входные данные:
- требования НУ;
- архитектура ПО;
- план разработки ПО;
- стандарты кодирования
ПО.
Первичный результат - исходный код и
объектный код.
Основные принципы:
- исходный код должен реализовывать
требования НУ и соответствовать
архитектуре ПО;
- исходный код должен соответствовать
стандартам кодирования ПО;
- исходный код должен сводиться к
описанию проекта;
- неадекватные или некорректные
входные данные должны быть переданы
либо подэтапу разработки требований к
ПО, либо подэтапу проектирования ПО,
либо этапу планирования разработки ПО
по принципу обратной связи для
разъяснения или исправления.
Интеграция ПО
Целью является загрузка
исполняемого объектного
кода в аппаратное или
программно-аппаратное
обеспечение.
Входные данные:
- архитектура ПО;
- исходный код;
- объектный код.
Результат - исполняемый объектный
код, а также компонуемые и
загружаемые данные.
Основные принципы:
- исполняемый объектный код должен
быть сгенерирован из исходного кода и
компонуемых и загружаемых данных;
- ПО должно быть загружено в целевой
компьютер для программно-аппаратной
интеграции;
- неадекватные или некорректные
входные данные должны быть переданы
либо подэтапу разработки требований к
ПО, либо подэтапу проектирования ПО,
либо подэтапу кодирования ПО, либо
этапу планирования разработки ПО по
принципу обратной связи для
разъяснения или исправления.
Целью этапа верификации является обнаружение ошибок, которые могли быть внесены в
ПО на этапе его разработки и корректировка таких ошибок должна производиться на этом
же этапе. Основной целью этапа верификации является проверка следующего.
1. Системные требования, реализуемые на базе ПО, были соответствующим образом
воплощены в требования высокого уровня.
2. Требования высокого уровня были соответствующим образом воплощены в
архитектуре ПО и требованиях низкого уровня.
3. Архитектура и требования низкого уровня были соответствующим образом воплощены
в исходном коде.
4. Исполняемый объектный код соответствует требованиям к ПО.
5. Средства, используемые для достижения выше перечисленных целей, являются
технически корректными и функционально законченными для программного уровня.
Методы этапа верификации базируются на комбинации обзоров, анализе, разработке
тестовых событий и процедур и последующего их исполнения. Обзоры и анализ
обеспечивают оценку точности, полноты и проверяемости требований к ПО, архитектуре
ПО и исходного кода Разработка тестовых событий обеспечивает более полную оценку
внутренней состоятельности ПО и полноту требований к нему. Выполнение тестовых
процедур обеспечивает демонстрацию соответствия ПО назначенным требованиям.
Входные данные этапа верификации: требования к системе, требования к ПО и
архитектуре ПО, данные о трассируемости, исходный код, исполняемый объектный код,
план верификации ПО.
Выходные данные этапа верификации ПО фиксируются в Сводке ситуаций и процедур
верификации ПО, а также в Сводке результатов верификации ПО.
Этап верификации обеспечивает проверку соответствия реализации требованиям к ПО и
верификацию этих требований следующими методами.
1. Соответствие между требованиями к ПО и тестовыми ситуациями выполняется путем
анализа области покрытия требований.
2. Соответствие между структурой кода и тестовыми ситуациями выполняется путем
анализа области покрытия структуры.
Основные методы этапа верификации ПО:
необходимо верифицировать требования высокого уровня и сводимость реализации к
этим требованиям;
результаты анализа соответствия реализации, анализа области покрытия требований и
анализа области покрытия структуры должны показывать, что каждое требование к ПО
сводимо к области кода, реализующего это требование, а также к обзорам, анализам и
тестовым ситуациям, проверяющим его;
если нет возможности верифицировать специфические требования к ПО путем
эксплуатации ПО в реальных условиях, должны быть обеспечены иные средства, а в плане
Верификации ПО или сводке результатов верификации ПО должно быть отмечено их
использование в этапе верификации ПО.
К результатам этапов разработки и верификации ПО могут быть применены различные
виды анализа и обзоров. Различия между обзором и анализом заключается в том, что
анализ дает повторяемые доказательства корректности, а обзор обеспечивает
количественную оценку корректности. Обзор может состоять из исследования выходных
данных этапа, выполненного в виде диаграммы. Анализ может исследовать в деталях
функционирование, производительность, трассируемость и вопросы безопасности
компонента ПО.
Обзоры и анализ требований высокого (ВУ), низкого уровней (НУ), архитектуры,
исходного кода показаны в таблице 2.7. Цель таких обзоров и анализов заключается в
обнаружении ошибок в требованиях, которые могли быть внесены в ходе выполнения
подэтапа разработки требований к ПО (подэтапов проектирования, разработки
архитектуры, кодирования).
Цель обзоров и анализа результатов подэтапа интеграции - убедиться в том, что
результаты данного этапа полны и корректны. Это может быть выполнено путем
детального исследования компонуемых и загружаемых данных и карты памяти и
рассмотрения следующих вопросов: некорректность аппаратных адресов, перекрытия
областей памяти, отсутствия отдельных компонентов ПО.
Таблица 2.7.
Требования ВУ Требования НУ Архитектура
ПО
Исходный код
Подчинение
системным
требованиям
/требованиям
ВУ/
требованиям
НУ/
Функции системы,
выполняемые на
базе ПО,
определены;
функциональные
требования,
требования к
производительност
и и безопасности
отражены в
требованиях ВУ;
производные
требования
корректны и
необходимы.
Требования ВУ
отражены в
требованиях
НУ;
производные
требования
корректны и
действительно
необходимы.
Архитектура
ПО не
конфликтует с
требованиями
ВУ, особенно в
функциях
обеспечения
целостности
системы.
Исходный код
корректен и
полноценен по
отношению к
требованиям НУ; не
реализуются
недокументированны
е функции.
Точность и
состоятельност
ь
Каждое требование
ВУ точно,
корректно,
непротиворечиво и
не конфликтует с
другими
требованиями.
Каждое
требование НУ
точно,
корректно,
непротиворечив
о и не
конфликтует с
другими
требованиями.
Между
компонентами
архитектуры
ПО существует
корректные
отношения.
Отношения
выражаются
через потоки
данных и
управления.
Определить
корректность и
состоятельность
исходного кода.
Совместимость
с целевым
компьютером
(ЦК)
Нет конфликтов
между
требованиями ВУ и
возможностями
ЦК.
Нет конфликтов
между
требованиями к
ПО и
возможностями
ЦК.
Нет
конфликтов
между
архитектурой
ПО и
возможностям
и ЦК.
Проверяемость Каждое требование
ВУ может быть
проверено.
каждое
требование НУ
может быть
проверено.
Архитектура
ПО может
быть
проверена.
Исходный код не
содержит операторов
и структур, которые
не могут быть
проверены.
Соответствие
стандартам
На подэтапе
разработки
требований к ПО
соблюдались
стандарты на
требования, а все
отклонения от них
исправлены.
На подэтапе
проектирования
соблюдались
стандарты на
разработку ПО,
а все
отклонения от
них исправлены.
На подэтапе
проектировани
я соблюдались
стандарты на
разработку ПО,
а все
отклонения от
них
исправлены.
На подэтапе
кодирования
соблюдались
стандарты на
кодирования ПО, а
все отклонения от
них исправлены.
Трассируемост Системные
Требования ВУ
низкоуровневые
ь
функциональные
требования,
требования
производительност
и и безопасности,
реализуемые на
базе ПО, были
отражены в
требованиях ВУ.
и производные
от них были
отражены в
требованиях
НУ.
требования были
отражены в исходном
коде.
Аспекты
алгоритмов
Убедиться в
точности и
корректности
поведения
используемых
алгоритмов,
особенно в
областях перехода
от одного
алгоритма к
другому.
Убедиться в
точности и
корректности
поведения
используемых
алгоритмов,
особенно в
областях
перехода от
одного
алгоритма к
другому.
Тестирование ПО имеет две взаимодополняющие цели. Одна из них -
продемонстрировать, что ПО удовлетворяет требованиям к нему; вторая -
продемонстрировать с высокой точностью, что ошибки, приводящие к сбою системы,
согласно этапу оценки безопасности, были удалены. На рис. 2.5. показана диаграмма
тестирования ПО. Целями трех типов тестирования являются:
тестирование программно-аппаратной интеграции - для проверки корректности
выполнения программной операции в среде целевого компьютера;
тестирование программной интеграции - для проверки взаимодействия между
требованиями к ПО и его компонентами, а также правильности реализации требований к
ПО и его компонентов в рамках архитектуры ПО;
низкоуровневое тестирование - для проверки правильности реализации требований
низкого уровня к ПО.
Для достижения целей тестирования необходимо:
тестовые ситуации должны базироваться, главным образом, на требованиях к
ПО;
тестовые ситуации должны быть разработаны для проверки правильности
функционирования и выявления условий, в которых могут быть выявлены
потенциальные ошибки;
анализ покрытия требований к ПО должен определить, какие требования не
тестировались;
Рис. 2.5 Диаграмма тестирования ПО.
анализ покрытия структуры должен определить, какие программные структуры не
исследовались
Этап контроля конфигурацией, работает совместно с другими этапами жизненного цикла
ПО и позволяет достичь следующих целей.
1. Обеспечение определенной управляемой конфигурации ПО в течение жизненного
цикла ПО.
2. Обеспечение возможности размножить полноценный исполняемый объектный код для
выпуска ПО или воспроизвести его в случае необходимости.
3. Обеспечение управления входными и выходными данными этапа в течении ЖЦ ПО,
которое обеспечит состоятельность и воспроизводимость деятельности этапа.
4. Выработка исходных данных для обзоров и оценки статуса: изменение раз за разом
параметров конфигурации до установления базового режима.
5. Обеспечение управления, которое даст возможность уделять внимание проблемам и
записывать, оценивать и реализовывать изменения.
6. Обеспечение открытости информации о ПО путем управления выходными данными
этапов ЖЦ ПО.
7. Помощь в оценке соответствия ПО требованиям на него.
8. Обязательное включение в параметры конфигурации поддержки безопасного
физического архивирования, восстановления и управления.
Этап управления и контроля конфигурации включает в себя идентификацию
конфигурации, управление изменениями, установление базовой конфигурации и
архивацию ПО и данных ЖЦ ПО. Данный этап не останавливается после сертификации
ПО, а продолжает функционировать в течение всего срока службы системы.
На этапе оценки качества ПО оцениваются выходные данные подэтапов жизненного
цикла ПО для принятия решения об удовлетворении поставленных целей, обнаружении,
оценке и устранении ошибок и согласования ПО и данных ЖЦ с требованиями
сертификации. Этот этап применяется согласно этапу планирования разработки ПО и
плана оценки качества ПО. Выходными данными этапа оценки качества формируются в
Реестре оценки качества ПО или других данных жизненного цикла ПО.
Этап оценки качества должен определить, произошла ли в результате выполнения
подэтапов ЖЦ ПО выработка такого ПО, который удовлетворял бы поставленным
требованиям, допуская, что эти подэтапы выполнялись в соответствии с принятыми
планами и стандартами разработки ПО.
Цель этапа оценки качества - убедиться в том, что:
этап разработки ПО удовлетворяет принятым планам и стандартам разработки ПО;
удовлетворен промежуточный критерий для подэтапов ЖЦ ПО;
проведена ревизия программного продукта.
Для достижения целей этапа оценки качества необходимо чтобы этап:
1. Играл активную роль в жизненном цикле ПО.
2. Обеспечивал создание и оценку корректности планов и стандартов разработки
ПО.
3. Обеспечивал протекание этапов жизненного цикла ПО согласно указанным
планам и стандартам.
4. Фиксировал события этапов разработки и интеграции в течение жизненного
цикла ПО с целью определения того, что:
отклонения от планов и стандартов разработки обнаружены, записаны, оценены,
проверены и исправлены (общепринято мнение о том, что, чем раньше обнаружены
такие отклонения, тем более эффективно достигаются цели этапов ЖЦ ПО);
санкционированные отклонения зафиксированы особо;
среда разработки ПО используется согласно планам разработки ПО;
процесс оповещения о проблемах, их исправления и проверки проводиться согласно плану
управления конфигурации ПО;
успешно получены результаты этапа оценки безопасности системы и внесены в
жизненный цикл системы.
5. Этап управления и контроля конфигурации ПО должен контролировать
удовлетворение промежуточных критериев ЖЦ ПО согласно принятого плану
разработки ПО.
6. Этап управления и контроля конфигурации ПО должен проверить
контролируемость данных ЖЦ ПО.
7. Прежде чем рассылать копии ПО для проведения его сертификации, необходимо
выполнить его ревизию.
8. Этап управления и контроля конфигурации ПО должен фиксировать развитие
событий и результаты ревизии ПО для каждого сертифицируемого программного
продукта.
Основная цель ревизии заключается в том, чтобы убедиться, что для сертифицированного
программного продукта этапы ЖЦ ПО завершены, их выходные данные сформированы,
исполняемый объектный код контролируется и может быть воспроизведен.
Целью обеспечения сертификации является установление взаимопонимания между
производителем ПО и службами, осуществляющими сертификацию, в течение всего ЖЦ
ПО, что облегчит этап сертификации. Данный этап применяется согласно этапу
планирования разработки ПО и плана программных аспектов сертификации.
Производитель ПО должен предоставить доказательства того, что жизненный цикл ПО
протекает согласно плану разработки ПО. Служба сертификации может выдавать свои
обзоры для производителя ПО или его поставщика с обсуждением тех или иных аспектов
ЖЦ ПО. Производитель коррелирует замечания с методиками ЖЦ ПО и предоставляет
требуемые данные. Производитель ПО обязан:
рассматривать обзоры служб сертификации;
передавать сводку работ, выполненных над ПО и реестр конфигурации ПО службам
сертификации;
передавать или делать доступными другие данные о соответствии, требующие службам
сертификации.
Кроме того, службам сертификации может быть передан план программных аспектов
сертификации.
Обычно, если не возражают службы сертификации, меры по регулированию данных ЖЦ
ПО, относящиеся к разработке типичного образца, применяются к данным о требованиях
к ПО, описанию проектирования, исходному коду, исполняемому объектному коду,
реестру конфигурации ПО, сводке работ, выполненных над ПО.
Необходимо заметить, что руководящие принципы документа DO - 178 В, в целом,
удовлетворяют целям следующих международных стандартов: ИСО 9000-3-91 Стандарты
в области административного управления качеством и обеспечения качества. Часть 3.
Руководящие положения по применению ИСО 9001 при разработке, поставке и
техническом обслуживании ПО, IEC 65A (Secretariat) 122 (ноябрь 1991) ПО для
компьютеров, используемых в промышленных системах безопасности.
2.4 Процессы жизненного цикла разработки ПО
ИСО/МЭК 12207-95 определяет модель жизненного цикла процессов разработки
программного обеспечения. Данная модель жизненного цикла ПО определяет, на верхнем
уровне, фундаментальные цели, которые являются существенными для разработки
высокоэффективного и надежного программного обеспечения. Цели верхнего уровня
описывают то, что должно быть достигнуто, а не как их достигнуть.
Жизненный цикл, определенный данным стандартом, применим в любой
software-организации, желающей утвердить, а в последствии и улучшить возможности по
поставке, разработке, эксплуатации, развитии и поддержке программного обеспечения.
Модель не предполагает использование специфических организационных структур,
философии управления, технологии или методологии разработки ПО.
Архитектура данной модели организует процессы для помощи персоналу организации в
их понимании и их использования для непрерывного усовершенствования процессов
разработки программного обеспечения. Процессы, определенные в стандарте, образуют
всеобъемлющий набор процессов. Организация, в зависимости от своих целей и для их
реализации, может выбрать соответствующий поднабор. Поэтому стандарт разработан
так, чтобы быть приспособленным как для отдельной организации, так и для конкретного
проекта или приложения. Кроме того, он может использоваться в случаях, когда
программное обеспечение является самостоятельной сущностью, встраивается или
является составной частью общей системы.
ИСО/МЭК 12207 не поддерживает (не устанавливает) какую-либо конкретную модель
жизненного цикла программного обеспечения, управление программным обеспечением,
метод разработки или локальную промышленную технологию. Еще раз повторим, что он
также не предписывает, каким образом исполнять что-либо. Эти моменты очень сильно
зависят от условий конкретного проекта и технологического уровня организации и
остаются в ее компетенции.
Данный стандарт сильно связан со следующими стандартами, которые будут рассмотрены
нами ниже.
ИСО/МЭК 15504, Информационная технология - Оценка процесса разработки
программного обеспечения;
ИСО 9001: 1994, Системы качества - Модель для обеспечения качества при
проектировании, разработке, производстве, монтаже и обслуживании.
Все действия, которые могут осуществляться в процессе жизненного цикла ПО,
рассматриваемый стандарт разбивает на три группы процессов жизненного цикла,
согласно типу действия, которым они направляются. Каждый процесс жизненного цикла
подразделяется на ряд действий. Каждое действие, в свою очередь, подразделяется на ряд
задач. Под задачей понимается действие, преобразующее входы в выходы. Перечень
задач, приведенный ниже, не является исчерпывающим и приведен в качестве примера.
Процессы, действия, и задачи могут выполняться последовательно, параллельно, повторно
и комбинировано.
Основные процессы. Раздел 5 ИСО/МЭК 12207 определяет, что основными процессами
являются:
1. Процесс приобретения. Определяет действия заказчика, организации, приобретающего
систему или программный продукт.
2. Процесс поставки. Определяет действия поставщика, организации, предоставляющей
программный продукт заказчику.
3. Процесс разработки. Определяет действия разработчика, организации, определяющей и
разрабатывающей программный продукт.
4. Процесс эксплуатации. Определяет действия оператора, организации, предоставляющей
для пользователей услуги по эксплуатации компьютерной системы в ее рабочей среде.
5. Процесс сопровождения. Определяет действия сопровождающего, организации,
предоставляющей услуги по сопровождению программного обеспечения; т.е., управлению
изменениями в программном обеспечении для поддержки его в актуальном и
работоспособном состоянии. Этот процесс включает перемещение и отставку
программного обеспечения.
Сопроводительные процессы. Раздел 6 данного стандарта представляет собой
соединение восьми процессов. Сопроводительный процесс поддерживает работу других
процессов как единое целое с четко определенной целью и способствует успеху и
качеству проекта. Сопроводительный процесс используется, как правило, другими
процессами. Сопроводительные процессы:
1. Процесс документирования. Определяет действия для записи информации,
происходящие во время жизненного цикла.
2. Процесс управления конфигурацией. Определяет действия по управлению
конфигурацией.
3. Процесс гарантии качества. Определяет действия, обеспечивающие гарантию
того, что программные продукты соответствуют определенным для них
требованиям и придерживаются установленных планов.
4. Процесс верификации. Определяет действия (для заказчика, поставщиков или
независимой стороны) по верификации программных продуктов различной
глубины, в зависимости от конкретного проекта ПО.
5. Процесс аттестации. Определяет действия (для заказчика, поставщиков или
независимой стороны) для аттестации программных продуктов проекта.
6. Процесс общего обзора. Определяет действия оценки статуса и качества
продуктов. Этот процесс может быть использован любыми из двух сторон, где одна
сторона (проверяющая) проверяет другую сторону (проверяемую).
7. Процесс аудита. Определяет действия для установления согласия с требованиями,
планами и контрактами. Этот процесс может быть использован двумя сторонами,
где одна сторона (аудитор) проводит аудит программных продуктов или действий
другой стороны (подвергающейся аудиту).
8. Процесс разрешения проблем. Определяет действия для анализа и устранения
проблем (включая несогласие), природа или источник которых обнаружены в
течение разработки, эксплуатации, сопровождения или других процессов.
Организационные процессы. Раздел 7 ИСО/МЭК 12207 состоит из четырех процессов.
Они используются организацией на верхнем уровне для установления, выполнения и
усовершенствовании нижележащей структуры, построенной на связи процессов
жизненного цикла и личностей организации. Обычно они используются вне сферы
конкретных проектов и контрактов; однако уроки, извлеченные из этих проектов и
контрактов, способствуют усовершенствованию организации. Организационные
процессы:
1. Процесс управления. Определяет основные действия по управлению, включая
управление проектом, в течение процессов жизненного цикла.
2. Процесс инфраструктуры. Определяет основные действия на установления
нижележащей структуры процесса.
3. Процесс усовершенствования. Определяет основные действия, выполняемые
организацией (заказчиком, поставщиком, разработчиком, эксплуатирующей,
сопровождающей организацией или менеджером другого процесса) для установления,
оценки, проверки и совершенствования процессов жизненного цикла.
4. Процесс обучения. Определяет действия по обеспечению соответственно
подготовленного персонала.
Кратко рассмотрим перечисленные выше процессы.
5.1Приобретение
Процесс приобретения содержит действия и задачи заказчика. Процесс начинается с
определения потребностей в приобретении системы или программных продуктов,
продолжается подготовкой и выпуском заявок на предложение, выбором поставщика и
управлением процесса приобретения посредством принятия программного продукта.
Заказчик управляет процессом приобретения на уровне проекта в соответствии с
процессом управления (7.1), который подтверждается примерами в этом процессе,
закладывает инфраструктуру в процессе согласно процессу инфраструктуры (7.2);
подгоняет процесс для проекта согласно процессу подгонки и управляет процессом на
организационном уровне согласно процессу усовершенствования (7.3).
Перечень действий: Этот процесс содержит следующие действия:
инициализация;
подготовка заявки_для_ предложения;
подготовка контракта и корректировка;
поиск поставщиков;
принятие и заключение.
5.1.1 Инициализация.
Это действие состоит из следующих основных задач:
Заказчик начинает процесс приобретения, выявляя идею или необходимость
приобретения, разработки или усиления системы или программного продукта.
Заказчик должен определить и анализировать системные требования. Системные
требования должны включать безопасность, надежность и другие критичные требования,
касающиеся проектирования, тестирования и согласованными со стандартами и
процедурами. Если заказчик приглашает поставщика для исполнения анализа требований
системы, он должен одобрить проанализированные требования. Заказчик может
выполнить установление требований к программному продукту самостоятельно или
может пригласить поставщика для выполнения этой задачи. Процесс разработки (5.3)
может быть использован для выполнения задач, указанных выше.
Заказчик будет обсуждать варианты приобретения, анализируя риск при каждом варианте.
Варианты включают:
приобретение готового к использованию программного продукта, удовлетворяющего
требованиям;
разработка программного продукта самостоятельно
разработка программного продукта через контракт
комбинация перечисленных выше вариантов.
усовершенствование существующего программного продукта.
Заказчик должен подготовить план приобретения, определяющий соответственно
требования к планируемому использованию системы, тип контракта, который будет
использован, обязанности привлеченных организаций, концепцию поддержки, которая
будет использована, и риски, принимаемые во внимание, также методы управления
рисками. План должен быть зарегистрирован и выполнен.
Аквизитор должен определить и зарегистрировать стратегию приемки и условия
(критерии).
5.1.2 Подготовка заявки для предложения (тендера).
Эта деятельность содержит следующие задачи.
Заказчик должен зарегистрировать требования приобретения (например, заявку на
участие), содержание которых зависит от варианта, выбранного при выполнение
предыдущего действия. Документация должна включать требования системы,
формулировку работы, инструкции для покупателей, перечень программных продуктов,
статьи договора, статьи поддоговора, технические ограничения (например, среда
использования).
Заказчик должен определить, какие процессы, действия и задачи стандарта относятся к
проекту и должны быть соответственно подогнаны. Особо заказчик должен определить
приемлемые сопроводительные процессы (6) и их выполняющие организации, так что
поставщики могут в своих целях определить подход к каждому из определенных
сопроводительных процессов.
Документация также должна определять точки контракта, на которых будут
рассматриваться и проверяться действия поставщика, как часть мониторинга (6.6 и 6.7).
Требования по приобретению должны быть даны организации, выбранной для исполнения
этих действий.
Остальные действия этого процесса касаются требований к подготовке контракта, его
корректировка, выполнению и завершению и здесь не рассматриваются.
5.2 Процесс поставки.
Процесс поставки содержит действия и задачи поставщика. Процесс может быть
инициирован, как принятием решения подготовить предложения в ответ на объявленный
заказчиком тендер, так и подписанием и вступлением в силу контракта с заказчиком по
предоставлению программного продукта. Процесс продолжается идентификацией
процедур и ресурсов, необходимых для управления и обеспечения проекта, включая
разработку планов проекта и выполнение планов поставки программного продукта
аквизитору.
Перечень действий: Этот процесс состоит из следующих действий: введение, подготовка
ответа, контракт, планирование, исполнение и контроль, обзор и оценка, поставка и
заключение.
5.3 Процесс разработки
Процесс разработки содержит действия и задачи разработчика. Процесс содержит
действия для анализа требований, проектирования, программирования, интеграции,
тестирования и инсталляции и приемки, относящейся к программному обеспечению. Он
может содержать системные действия, если это оговаривается в контракте.
Разработчик руководит процессом разработки на уровне проекта согласно процессу
управления (7.1), который сопровождается примерами в этом процессе; представляет
инфраструктуру процесса согласно процессу инфраструктуры (7.2); доводит процесс для
проекта, следуя процессу доводки, и руководит процессом на организационном уровне,
следуя процессу усовершенствования (7.3).
Перечень действий: Этот процесс состоит из следующих видов деятельности.
1. Инструментарий процесс. Это действие состоит из следующих задач:
Если не оговорено в контракте, разработчик должен определить или выбрать модель
жизненного цикла программного обеспечения в соответствии с назначением, значимостью
и сложностью проекта. Действия и задачи этого процесса должны быть выбраны и
отображены в модели жизненного цикла. Эти действия и задачи могут перекрываться или
взаимодействовать и могут быть исполнены итеративно или рекурсивно.
Разработчик должен выполнять следующее:
документировать результаты в соответствии с процессом документирования (раздел 6.1);
разместить результаты (выходы) в процессе конфигурации (6.2) и выполнить контроль
изменений в соответствии с этим;
документировать и разрешить проблемы и несоответствия, найденные в программном
продукте и задачах в соответствии с процессом разрешения проблем (6.8);
другие сопроводительные процессы (6), как определено в контракте.
Разработчик должен выбрать, довести и использовать внутренние стандарты,
методологии, процедуры и языки программирования (если это не оговорено в контракте),
которые должны быть зарегистрированы, соответствуют и установлены организацией для
исполнения действий процесса разработки и процесса поддержки.
Разработчик должен разработать планы управления действиями в процессе разработки.
Планы должны включать особые стандарты, методы, средства, действия и обязанности,
связанные с разработкой и квалификацией всех требований, включая надежность и
безопасность. Эти планы должны быть зарегистрированы и исполнены.
Официально непоставляемые элементы могут быть использованы в разработке или
сопровождении программного обеспечения. Однако должна быть гарантия того, что
эксплуатация и поддержка поставляемого программного обеспечения после его поставки
заказчику не зависит от таких элементов, другими словами, эти элементы становятся
официально поставляемыми.
2. Анализ системных требований. Это действие состоит из следующих задач, которые
разработчик должен исполнить или поддерживать, как требуется по контракту.
Особое предполагаемое использование разрабатываемых систем должно быть
проанализировано для определения системных требований. Спецификация системных
требований должна описывать: функции и возможности системы; надежность, защиту,
разработку, интерфейс требования по эксплуатации и поддержке; ограничения
проектирования и квалификационные требования. Спецификации системных требований
должны быть зарегистрированы.
Системные требования должны быть оценены с позиций следующих критериев:
прослеживаемость потребностей заказчика, согласованность с потребностями заказчика,
тестируемость, выполнимость системного проектирования, осуществимость эксплуатации
и поддержки.
3. Системное проектирование. Это действие состоит из следующих задач, которые
разработчик должен выполнить или поддерживать, как требуется контрактом.
Должна быть представлена архитектура верхнего уровня системы. Архитектура должна
определять элементы аппаратного, программного обеспечения и ручные операции.
Должна быть гарантия того, что все системные требования полностью распределены
среди элементов. Эти элементы должны быть впоследствии определены как элементы
аппаратной конфигурации (ЭАК), элементы конфигурации программного обеспечения
(ЭКПО) и соответственно ручные операции. Архитектура системы и системные
требования, распределенные между элементами аппаратной, конфигурации,
конфигурации ПО и ручными операциями, должны быть зарегистрированы.
Архитектура системы и требования для элементов конфигурации и ручных операций
должны быть оценены в соответствии со следующими критериями:
различимость системных требований;
согласованность с системными требованиями;
соответствие стандартам и используемым методам проектирования;
осуществимость наполнения элементов конфигурации ПО распределенными для них
требованиями;
выполнимость эксплуатации и поддержки.
4. Анализ требований к программному обеспечению. Для каждого ЭКПО это действие
состоит из следующих задач, которые разработчик должен исполнить.
Разработчик должен представить и зарегистрировать требования к программному
обеспечению, включая спецификации характеристик качества, описанных ниже:
спецификации функций и возможности, включая исполнение, физические
характеристики, условия окружающей среды, при которых выполняется программное
обеспечение;
внешний интерфейс ЭКПО;
квалификационные требования;
спецификации безопасности, включая относящиеся к методами эксплуатации и
поддержки, влиянию окружающей среды и повреждению персоналом;
спецификации защиты, включая касающиеся особой информации и материалов;
человеческий фактор и спецификации человеко-машинного взаимодействия, включая
относящиеся к ручным операциям, человеко-машинным взаимодействиям, ограничениям
на персонал и области, требующие концентрации человеческого внимания,
чувствительные с точки зрения ошибок человека и его опыта;
требования определения данных и требования к базам данных;
требования по инсталляции и приемке поставляемого программного обеспечения в
эксплуатацию и сопровождение;
документация пользователя;
требования по эксплуатации пользователя и исполнению;
требования по пользовательскому сопровождению.
Руководство по определению характеристик качества может быть найдено в ИСО/МЭК
9126.
Разработчик должен оценить требования к программному обеспечению, руководствуясь
приведенными ниже критериями:
прослеживаемость системных требований и системного проекта;
внешняя согласованность с системными требованиями;
внутренняя согласованность;
тестовое покрытие требований;
тестируемость;
выполнимость проектирования программного обеспечения;
осуществимость эксплуатации и сопровождения.
Разработчик должен руководить общим обзором в соответствии с 6.6. После успешного
завершения обзора должна быть представлена основа для требований к ЭКПО.
5. Проектирование программного обеспечения. Для каждого ЭКПО это действие состоит
из следующих задач, которые разработчик должен быть выполнить.
Разработчик должен преобразовать требования для ЭКПО в архитектуру, описывающую
структуру его верхнего (высшего) уровня и определяющую главные компоненты. Должна
быть гарантия того, что требования к ЭКПО полностью распределены между его
компонентами и далее уточнены для облегчения детального проектирования.
Разработчик должен разработать и зарегистрировать:
проект высшего уровня для внешнего взаимодействия с ЭКПО и между компонентами
программного обеспечения;
проект высшего уровня для баз данных;
предварительные версии руководства для пользователя;
предварительные тестовые требования и план интеграции программного обеспечения.
Разработчик должен оценить архитектуру ЭКПО и проекты интерфейса и баз данных,
руководствуясь приведенными ниже критериями:
прослеживаемость требований к ЭКПО;
внешняя согласованность с требованиями к ЭКПО;
внутренняя согласованность между компонентами;
соответствие методов проектирования и стандартов, которые были использованы;
выполнимость детализированного проектирования
осуществимость эксплуатации и сопровождения.
Разработчик должен руководить общим обзором в соответствии с 6.6.
6. Детальное проектирование программного обеспечения. Для каждого ЭКПО это
действие состоит из следующих задач, которые разработчик должен выполнить.
Разработчик должен разработать детальный проект для каждого компонента
программного обеспечения ЭКПО. Компоненты программного обеспечения должны быть
уточнены на нижних уровнях, содержащих модули программного обеспечения, которые
могут кодироваться, компилироваться и тестироваться. Должна быть гарантия того, что
требования к программному обеспечению полностью локализованы в модулях
программного обеспечения. Детализированный проект должен быть зарегистрирован.
Разработчик должен разработать и задокументировать детальный проект для внешнего
интерфейса ЭКПО между компонентами программного обеспечения и между модулями
программного обеспечения. Детальный проект интерфейса должен позволять писать код
программы без необходимости в дополнительной информации.
Разработчик должен разработать и зарегистрировать детальный проект базы данных.
Разработчик должен обновить руководство пользователя насколько это необходимо.
Разработчик должен определить и задокументировать тестовые требования и расписание
тестирования блоков программного обеспечения. Тестовые требования должны включать
испытания программного обеспечения на пределе требований.
Разработчик должен обновить тестовые требования и расписание интеграции
программного обеспечения.
Разработчик должен оценить детальный проект программного обеспечения и тестовые
требования с точки зрения критериев, приведенных ниже:
прослеживаемость требований ЭКПО;
внешняя согласованность с архитектурой проекта;
внутренняя согласованность между компонентами и модулями;
соответствие методов проектирования и используемых стандартов;
выполнимость тестирования;
выполнимость эксплуатации и сопровождения.
Разработчик должен руководить объединением согласно 6.6.
7. Программирование и отладка. Для каждого ЭКПО это действие состоит из следующих
задач, которые должен выполнить разработчик.
Разработчик должен разработать и задокументировать следующее:
а) каждый модуль программного обеспечения и базы данных;
б) процедуры тестирования и данные для тестирования каждого модуля и базы данных.
Разработчик должен тестировать каждый модуль ПО и базы данных, убеждаясь в том, что
они удовлетворяют требованиям. Результаты тестирования должны быть
задокументированы.
Разработчик должен обновить руководство пользователя, тестовые требования и
расписание интеграции ПО, оценить код ПО и результаты теста в соответствии с
критериями, приведенными ниже:
прослеживаемость требований ЭКПО и проекта;
внешняя согласованность с требованиями ЭКПО и архитектурой проекта;
внутренняя согласованность между требованиями модулей;
тестирование модулей;
соответствие методов кодирования и используемых стандартов;
выполнимость интеграции ПО и тестирования;
выполнимость эксплуатации и сопровождения.
8. Интеграция программного обеспечения. Для каждого ЭКПО это действие состоит из
следующих задач, которые должен выполнить разработчик.
Разработчик должен разработать план интеграции для объединения модулей ПО и
компонентов в ЭКПО. План должен включать требования, процедуры, данные,
ответственность и расписание.
Разработчик должен объединить модули ПО и компоненты. Должна быть гарантия того,
что каждый компонент удовлетворяет требованиям SCI и что SCI полностью
интегрирован как результат этой деятельности. Интеграция и результаты теста должны
быть задокументированы.
Разработчик должен обновить руководство пользователя, если это требуется.
Разработчик должен разработать и задокументировать для каждого квалификационного
требования ЭКПО полный набор тестов, ситуаций (вход, выход, критерии тестирования) и
процедуры тестирования для управления квалификационным тестированием ПО.
Разработчик должен оценить план интеграции, проект, код, тесты, результаты
тестирования и руководства пользователя с точки зрения критериев, приведенных ниже:
отслеживаемость системных требований;
внешняя согласованность с системными требованиями;
внутренняя согласованность;
тестирование ЭКПО требований;
соответствие используемых стандартов и методов тестирования;
соответствие с ожидаемыми результатами;
выполнимость квалификационного тестирования ПО;
выполнимость эксплуатации и сопровождения.
Разработчик должен руководить общим обзором в соответствии с 6.6.
9. Квалификационное тестирование программного обеспечения. Для каждого ЭКПО это
действие состоит из следующих задач, которые должен выполнить разработчик:
Разработчик должен руководить квалификационным тестированием в соответствии с
квалификационными требованиями, особыми для ЭКПО. Должно быть гарантировано,
что реализация каждого требования к ПО полностью протестирована. Результаты
квалификационного тестирования должны быть зарегистрированы.
Разработчик должен оценить проект, код, тесты, результаты тестирования и руководство
пользователя в соответствии с приведенными ниже критериями:
тестирование требований к ЭКПО;
согласованность с ожидаемыми результатами;
выполнимость системной интеграции и тестирования;
выполнимость эксплуатации и сопровождения.
Разработчик должен поддерживать аудит в соответствии с 6.7. Результаты аудита должны
быть задокументированы. Если разрабатываются или интегрируются ПО и аппаратное
обеспечение, аудит может быть отложен до квалификационного тестирования системы.
После успешного завершения аудита, если предписано, разработчик должен:
а) обновить и подготовить к поставке ПО для системной интеграции, квалификационного
тестирования системы, инсталляции или поддержки приема ПО, как полагается;
б) представить основную линию проектирования и кодирования ЭКПО;
10. Системная интеграция. Это действие состоит из следующих задач, которые должен
выполнить разработчик.
ЭКПО должен быть интегрирован с ЭАК, руководством по эксплуатации и другими
системами в единую систему. Составляющие должны быть протестированы на
соответствие требованиям. Интеграция и результаты тестирования должны быть
задокументированы.
Для каждого квалификационного требования к системе должны быть разработаны и
задокументированы полный набор тестов, ситуаций (входных, выходных, критериев
тестирования), процедур тестирования. Разработчик должен гарантировать, что
интегрированная система готова для квалификационного тестирования.
Интегрированная система должна быть оценена в соответствии с приведенными ниже
критериями:
зона тестирования требований к системе;
приемлемость используемых методов и стандартов тестирования;
согласованность с ожидаемыми результатами;
выполнимость квалификационного тестирования системы;
выполнимость эксплуатации и сопровождения.
11. Квалификационное тестирование системы. Это действие состоит из следующих задач,
выполняемых разработчиком.
Квалификационное тестирование системы должно руководствоваться в соответствии с
квалификационными требованиями, определенными для системы. Должно быть
гарантировано, что выполнение каждого требования к системе протестировано полностью
и система готова к поставке. Результаты квалификационного тестирования должны быть
задокументированы.
Система должна быть оценена в соответствии с приведенными ниже критериями:
зона тестирования требований к системе;
подтверждение ожидаемыми результатами;
выполнимость эксплуатации и сопровождения.
Разработчик должен поддерживать аудит в соответствии с 6.7. Результаты аудита должны
быть задокументированы. Этот пункт не применяется к таким ЭКПО, для которых аудит
был выполнен ранее.
После успешного завершения аудита, если предписано, разработчик должен:
обновить и подготовить к поставке ЭКПО для инсталляции ПО и его приемки;
обосновать основные направления для проектирования и кодирования ЭКПО.
12. Инсталляция ПО. Это действие состоит из следующих задач, выполняемых
разработчиком.
Разработчик должен разработать план инсталляции ПО в намеченную среду. Ресурсы и
информация, необходимые для установки ПО, должны быть определены и доступны.
Разработчик должен помогать поставщику при установке. После того, как ПО установлен
в существующую систему, Разработчик должен поддерживать некоторые параллельно
выполняемые действия. План установки должен быть задокументирован.
Разработчик должен установить ПО в соответствии с планом установки. Должно быть
гарантировано, что ПО и базы данных инициализируются, функционируют и прекращают
работу, как указано в контракте. Процесс установки и результаты должны быть
задокументированы.
12. Поддержка приемки ПО. Это действие состоит из следующих задач, выполняемых
разработчиком.
Разработчик должен поддерживать процесс приемки поставщиком и тестирование ПО.
Приемка и тестирование должны основываться на общем обзоре, аудите,
квалификационном тестировании, квалификационном тестировании системы (если оно
выполнялось). Результаты приемки и тестирования должны быть задокументированы.
5.4 Процесс эксплуатации
Процесс эксплуатации состоит из действий и задач того, кто эксплуатирует разработанное
ПО. Процесс включает эксплуатацию ПО и поддержку пользователей. Поскольку
эксплуатация ПО является интеграционной составляющей эксплуатации системы,
действия и задачи этого процесса относятся и к системе.
Оператор управляет процессом эксплуатации на уровне проекта, следуя процессу
управления (7.1), являющемуся примером; представляет инфраструктуру процесса,
согласно процессу инфраструктура (7.2); подстраивает процесс для проекта согласно
процессу подгонки; руководит процессом на организационном уровне согласно процессу
усовершенствования (7.3).
Перечень действий. Этот процесс состоит следующих задач: выполнения процесса,
тестирование, эксплуатация системы и поддержка пользователей
5.5 Процесс сопровождения
Процесс поддержки состоит из действий и задач лица, выполняющего сопровождение.
Этот процесс начинается, когда необходима модификация из-за допущенных ошибок,
неучтенных проблем, необходимости усовершенствования или адаптации кода ПО и
соответствующей документации. Его цель - модифицировать существующее ПО,
сохранив его целостность. Этот процесс включает распространение и замену ПО. Процесс
завершается заменой ПО.
Действия, обеспечиваемые этим разделом, определены как процесс сопровождения,
однако процесс может использовать другие процессы этого стандарта. Если используется
процесс разработки (5.3), термин разработчик интерпретируется как обеспечивающий
сопровождение. Обеспечивающий сопровождение руководит процессом сопровождении
на уровне проекта, следуя процессу управления (7.3).
Перечень действий. Процесс состоит из следующих действий: процесс реализации, анализ
проблем и модификации, реализация модификации, приемка, распространение, замена
ПО.
В силу ограниченности объема данного учебного пособия, остальные процессы
жизненного цикла ПО, установленные в ИСО/МЭК 12207, рассматривать не будем.
2.5 Сравнительный анализ рассмотренных жизненных циклов ПО
В первую очередь проведем анализ понятия жизненный цикл, употребляемый нами
довольно часто. Согласно ГОСТ 34.003 жизненный цикл АС: совокупность
взаимосвязанных процессов создания и последовательного изменения состояния АС от
формирования исходных требований к ней до окончания эксплуатации и утилизации
комплекса средств автоматизации АС. При рассмотрение жизненного цикла ПО,
регламентированного 34-ой системой стандартов, было приведено такое же определение.
При этом подразумевалось, что под понятием автоматизированная система понимается
программное обеспечение. Тогда, более точным будет следующее определение.
Жизненный цикл ПО - совокупность взаимосвязанных процессов создания и
последовательного изменения состояния ПО от момента формирования исходных
требований к нему до полной его утилизации.
По смыслу и объему это определение полностью согласуется с определением модели
жизненного цикла, данное в проекте стандарта ИСО/МЭК 12207-1. Модель жизненного
цикла ПО - структура, содержащая процессы, действия и задачи, касающиеся разработки,
эксплуатации и поддержки программных продуктов, охватывающая жизнь системы от
определения требований к ней до окончания ее использования.
В документе DO-178B нет четкого определения понятия жизненного цикла программного
обеспечения. Тем не менее, проведя анализ определенных в нем этапов жизненного цикла
ПО, можно сделать вывод, что, по сути, оно аналогично определению, используемому в
ГОСТ 34.003. Однако, жизненный цикл, установленный в DO-178B, не содержит
аналогичных этапов Выполнение работ в соответствии с гарантийными обязательствами и
Послегарантийного обслуживания, определенных в ГОСТ 34.601.
Можно сделать вывод, что современное представление ЖЦ ПО отражено в проекте
стандарта ИСО/МЭК 12207, представляющий ЖЦ не только как процесса разработки ПО,
но и как эксплуатации и сопровождения ПО.
ГОСТ 19.102 и ГОСТ 34.601не охватывают всего жизненного цикла ПО. Кроме того,
ГОСТ 19.102 устарел, его требования не могут быть выполнены в полном объеме
(например, требование обязательной передачи программы в фонд алгоритмов и
программ). Основное отличие ИСО/МЭК 12207 от ГОСТ 19.102, ГОСТ 34.601, DO-178B
заключается также в том, что первый их них устанавливает общий каркас для любого типа
моделей жизненного цикла ПП, а остальные устанавливают более конкретные схемы.
Схема ГОСТ 19.102 не предполагает использование высокопроизводительных моделей
ЖЦ, широко применяемых в современной программотехнике. Из отечественных
стандартов предпочтительнее использовать схему ГОСТ 34.601, которая охватывает
практически все современные модели ЖЦ ПО. DO-178B признает, что приемлемы
различные модели ЖЦ для разработки ПО и подчеркивает, что выбранный жизненный
цикл должен быть определен на этапе планирования проекта.
Кроме того, выполнение требований ГОСТ 19.102 и ГОСТ 34.601 не гарантирует качество
ПО, так как в них явно не определены процессы обеспечения качества разрабатываемого
ПО. В этом отношении более прогрессивны проект стандарта ИСО/МЭК 12207 и
документ DO-178B, руководящие принципы которых удовлетворяют целям стандартов
ИСО 9000-3-91 Стандарты в области административного управления качеством и
обеспечения качества. Часть 3. Руководящие положения по применению стандарта ИСО
9001 при разработке, поставке и обслуживанию ПО и МЭК 65А (Secretariat) 122 (1991 г.)
ПО для компьютеров, используемых в промышленных системах безопасности.
Общая структура процессов ЖЦ во всех рассматриваемых выше стандартах и документах
совпадает, за исключением DO-178B. Структура ИСО/МЭК 12207, ГОСТ 19.102, ГОСТ
34.601 представляет собой иерархию, содержащую три уровня: стадия (процесс), этапы
(действия), содержание работ (задачи). Различия этих стандартов заключается в
наполнении этой структуры. Точки контроля жизненного цикла привязаны к указанным
трем уровням структуры.
DO-178B является преимущественно этапно-ориентированным документом. В нем для
каждого этапа определены цели и способы достижения этих целей. В нем имеется
описание данных этапов жизненного цикла, которые показывают, что цели были
достигнуты. Кроме того, в DO-178B явно определена взаимосвязь между этапами
жизненного цикла системы и этапами жизненного цикла ПО. Условия сбоев, связанных с
функциями, которые выполняют ПО, описаны в ходе выполнения этапа оценки
безопасности системы. Это является основой для установления уровня ПО. Уровень
программного обеспечения основывается на вкладе, вносимом ПО в набор потенциальных
состояний отказов системы.
ГОСТ 34.601 в качестве первой и обязательной стадии создания предусматривает
формирование требований пользователя. В ИСО/МЭК 12207 эта стадия соответствует
двум первым действиям процесса приобретения (5.1). Основным результатом этой стадии
являются формально сформулированные и зарегистрированные требования пользователя
к разрабатываемому ПО. Такой подход позволяет на последующих стадиях проводить
оценку качества ПО ГОСТ 28195 (ГОСТ Р ИСО/МЭК 9126) на основе
идентифицированных требований пользователя.
В ГОСТ 19.102 формулировка требований пользователя опущена до самого нижнего
уровня иерархии (стадия Технический проект, этап 3 Разработка и утверждение
технического задания, работа Определение требований к программе). В недавнем
прошлом эта работа, зачастую, совсем исключалась из проекта, так как этот стандарт
допускает исключать стадии, этапы работ и их содержание.
Стадии Разработка концепции, Техническое задание, Эскизный и технический проект
ГОСТ 34.601 в основном соответствуют процессу разработки (5.3) ИСО/МЭК 12207 и
частично - стадиям Техническое задание, Эскизный и технический проект, Рабочий
проект ГОСТ 19.102. Детализация этапов и содержания работ на этих стадиях по ГОСТ
19.102 представляется на современном уровне недостаточной для оценки качества ПО.
Детализация этапов (действий) и содержания работ (задач) по ГОСТ 34.601 и ИСО/МЭК
12207-1 для этой стадии (процесса) в целом хорошо согласуются между собой, хотя в
первом из этих документов содержание работ в большей мере учитывает реальности РФ, а
во втором дана большая детализация. Так как содержание работ ГОСТ 34.601 вынесено в
справочное приложение к этому стандарту, то, в случае необходимости, в работы можно
включать задачи ИСО/МЭК 12207.
Последние две стадии Ввод в действие и Сопровождение ГОСТ 34.601 связаны с
процессами поставки (5.2), эксплуатации (5.4) и сопровождения (5.5) ИСО/МЭК 12207.
При этом, большинство этапов и работ, выполняемых на этих стадиях, применяются к
автоматизированным системам, а не к программному обеспечению (например, этап 7.4
Строительно-монтажные работы). Содержание работ этапа Внедрение ГОСТ 19.102 не
вполне точно соответствует сегодняшним реальностям, о чем уже говорилось выше.
Что касается сравнения документа DO-178B с ИСО/МЭК 12207, ГОСТ 34.601 в
отношении процессов ЖЦ, то в силу того, что они имеют разную структуры, анализ
несколько затруднен. Можно только сказать, что цели этапа планирования соответствую в
некоторой степени целям стадии 2 ГОСТ 34.601, этап разработки идентичен процессу
разработки ИСО/МЭК 12207, а интегрированный этап - поддерживающим процессам
ИСО/МЭК 12207.
Вопрос, касающийся документации в рассматриваемых выше стандартах будет
рассмотрен нами в разделе 3.
Вопросы обеспечения качества, верификации, подтверждения почти не отражены в ГОСТ
19.102 и ГОСТ 34.601. В проекте ИСО/МЭК 12207 эти вопросы охвачены
поддерживающими процессами обеспечения качества, верификации, подтверждения,
общего обзора, аудита, разрешения проблем. В DO-178B эти вопросы отрабатываются в
процессе выполнения интегрированного этапа. Непосредственное отношение к данным
вопросам имеют работы по тестированию ПО, почти не отраженные в ГОСТ 19.102 и
ГОСТ 34.601, но которым уделяется достаточное внимание в задачах основных процессов
ИСО/МЭК 12207 и DO-178B.
Раздел 3
Документирование в процессах жизненного цикла ПО
3.1 Документация и ее роль в обеспечении качества
Документирование ПО определяется стандартами ГОСТ серии 19, 34, ГОСТ Р ИСО/МЭК
8631, ГОСТ Р ИСО 9127, ГОСТ Р ИСО/МЭК ТО 9294. Полный перечень нормативных
документов на программную документацию приведен в документе Методика экспертизы
программной документации, находящегося на стадии утверждения.
ГОСТ Р ИСО/МЭК ТО 9294-93 ИТ. Руководство по управлению документированием ПО
является одним из основных стандартов в данной области и представляет собой
руководство по документированию ПО для тех руководителей, которые отвечают за
разработку программного обеспечения. Данное руководство предназначено для помощи
руководителям в обеспечении эффективного проведения документирования в
организациях. Данный стандарт направлен на определение стратегий, стандартов,
процедур, ресурсов и планов, которыми должны заниматься сами руководители для того,
чтобы эффективно управлять документированием ПО.
Руководство по управлению документированием ПО предназначено для применения ко
всем типам программного обеспечения - от простейших программ до наиболее сложных
систем программного обеспечения, охватывающих все типы программной документации,
относящейся ко всем стадиям жизненного цикла ПО.
Принципы управления документированием программного обеспечения одинаковы для
любого объема проекта. Для небольших проектов значительную часть положений,
приведенных в данном стандарте, можно не применять, но принципы остаются теми же.
Руководители могут адаптировать данные рекомендации для своих конкретных
потребностей.
Эффективность выполнения руководящей роли можно рассматривать как основанную на
следующих трех элементах.
1. Руководящая обязанность по документированию - требует признания того, что
программная документация важна и что ее следует планировать, описывать, проверять,
утверждать, выпускать, распространять и сопровождать.
2. Руководящая поддержка обязанностей персонала по документированию - требует
руководство и стимулирование персонала при проведение требуемого документирования
и обеспечение его ресурсами для содействия в данной работе.
3. Признаки руководящих обязанностей и поддержки - требует обеспечить:
а) опубликованные официальные отчеты о стратегии документирования;
б) стандарты и руководства, определяющие все аспекты документирования ПО;
в) опубликованные процедуры документирования;
г) выделение соответствующих ресурсов для документирования;
д) планирование документирования, осуществляемое как неотъемлемая часть процесса
разработки ПО;
е) постоянную проверку, осуществляемую для обеспечения соответствия со
стратегией, стандартами, процедурами и планами по документированию.
В ГОСТ Р ИСО/МЭК ТО 9294-93 программная документация рассматривается как
имеющая следующие шесть основных функций.
1. Информация для управления. Во время разработки ПО администрации необходимо
оценивать ход работы, возникающие проблемы и вероятности развития процесса
разработки ПО. Периодические отчеты, согласно которым проверяют ход работ по
графику и представляют планы на следующий период, обеспечивают контрольные
механизмы и обзор проекта.
2. Связь между задачами. Большинство проектов разработки ПО разделяется на задачи,
выполняемые различными группами: специалисты в предметной области, аналитики,
проектировщики, специалисты по обеспечению качества и др. Этим группам, а также
персоналу в пределах группы, необходимы средства общения друг с другом,
обеспечивающие информацию, которую можно воспроизводить, распространять и на
которую можно ссылаться. Большинство методологий разработки ПО устанавливают
официальные документы для связи между задачами. Например, аналитики представляют
официальные спецификации требований проектировщикам, а они, в свою очередь,
официальные проектные спецификации программистам.
3. Обеспечение качества. Требуется документация разработки и документация продукции
для выполнения задач, связанных с обязанностями по обеспечению качества ПО.
4. Инструкции и справки. Документация, требующаяся операторам, пользователям,
руководителям и другим заинтересованным лицам для того, чтобы понимать и
использовать ПО.
5. Сопровождение ПО. Специалистам, сопровождающим ПО, требуется детальное
описание ПО, такое, чтобы они могли локализовать и корректировать ошибки и
модернизировать или изменять ПО соответствующим образом.
6. Исторические справки. Документация, требуемая в качестве исторической справки по
проекту. Данная документация может помочь в переносе и переводе ПО в новое
окружение.
Рассмотрим стратегии документирования. Стратегии документирования, подготовленные
и контролируемые руководителем организации, обеспечивают руководящими
положениями ответственных лиц, принимающих решения на всех нижних уровнях.
Стратегия обеспечивает главное направление, но не дает рекомендаций, что делать и как
это делать. Из-за существенной роли, которую играет документация на всех стадиях ЖЦ
ПО, стратегия должна быть официально утверждена, доведена до каждого исполнителя
проекта. Официальная стратегия устанавливает дисциплину, требуемую для
эффективного документирования ПО.
Стратегия должна поддерживать основные элементы эффективного документирования:
требования документации охватывают весь жизненный цикл ПО;
документирование должно быть управляемым;
документация должна соответствовать ее читательской аудитории;
работы по документированию должны быть объединены в общий процесс разработки
ПО;
должны быть определены и использованы стандарты по документированию;
должны быть определены средства поддержки.
Внутри организации, помимо стратегии, должны быть приняты стандарты и руководства
для:
модели жизненного цикла ПО;
типов и взаимосвязей документов;
содержания документа;
качества документа;
форматов документа;
обозначение документа.
Данные стандарты и руководства будут определять, как следует выполнять задачи
документирования, и будут обеспечивать критерии для оценки полноты, полезности и
соответствия программной документации, создаваемой в организации.
Большинство стандартов и руководств выдают рекомендации, которые применимы на
общем уровне. Зачастую будут требоваться управленческие решения для адаптации
общих рекомендаций к конкретным проектам. Применение стандартов,
распространяющихся на организацию документирования, облегчит руководителям
проекта определение следующих вопросов:
какие типы документов требуются?
каков объем представляемой документации?
что документы содержат?
какой уровень качества будет достигнут?
где документы будут созданы?
как документы будут хранить, сопровождать и обращать?
В организации должны быть установлены процедуры для применяемых стратегий
документирования. Процедуры определяют последовательность документирования:
планирование, подготовка, конфигурационное управление, проверка, утверждение,
производство, хранение, дублирование, распространение и модернизация, продажа. Кроме
того, процедуры должны определять контрольные пункты и методы обеспечения качества.
Основными ресурсами, требуемыми для документирования, являются следующие:
персонал, средства, финансирование.
Персонал. Для процесса разработки ПО необходимы люди со знанием программирования,
сути предмета, документирования, проектировщики, специалисты в предметной области и
другие. Важно, чтобы все специалисты, участвующие в разработке проекта были обучены
методам документирования и полностью понимали и выполняли свою роль в
документировании.
Средства. Важно предусмотреть обеспечение задач документирования соответствующими
и подходящими средствами. Инструментальные средства полезны для подготовки и
контроля документации. Они могут быть применены для повышения эффективности
многих процессов документирования и использования стандартов данной организации,
распространяющихся на документирование.
Финансирование. Важно, чтобы стоимость документирования определяли как отдельные
статьи бюджета, так как она нередко составляет значительную часть стоимости
разработки ПО.
Процесс документирования, как уже отмечалось выше, должен планироваться. План
документирования определяет, что должно быть сделано, как это должно быть сделано,
когда это должно быть сделано и кто это должен делать.
План документирования может быть как частью общего плана проекта, так и как
отдельным документом. Он должен быть доведен до всех участников проекта. План
документирования включает в себя изложение общей структуры документации, типов,
содержания, качества, форматов, обозначения, комплектности и хранения документов, их
обращения и графика документирования.
График документирования должен распределять время для:
планирования документов;
проверки плана и принципов документирования;
подготовки проектов и проверки их на техническую точность, полноту и
соответствие;
редактирование при внесение комментариев, появившихся при проверке;
проведения согласования;
перевода;
распространения.
Планирование документирования следует начинать заранее, и план необходимо проверять
на всем протяжении проекта. Подобно любому плану, план документирования отражает
намечаемые действия и является объектом для необходимых изменений. В проекте
должны быть предусмотрены регулярные проверки результативности изменений в плане.
Более подробно рассмотрим стандарты и руководства, принимаемые в организации.
1. Выбор модели жизненного цикла ПО.
Как уже отмечалось выше, существует ряд моделей жизненного цикла ПО с
отличающейся терминологией для различных стадий. С точки зрения программной
документации, не имеет значения, какая модель выбрана, до тех пор, пока стадии и
соответствующая им документация четко определены, спланированы и выполнимы для
любого конкретного программного проекта. Руководители должны выбрать
соответствующую модель ЖЦ и гарантировать, чтобы ее применяли в данной
организации. При этом руководители должны убедиться, что выбранные стадии и
соответствующие задачи помогут им в контроле за ходом разработки ПО.
Проведем краткий анализ жизненных циклов программного обеспечения, описанных нами
выше.
В рамках ИСО/МЭК 12207 документирования решаются при вызове каким-либо
процессом ЖЦ процесса документирования.
Процесс документирования - это процесс записи информации, получаемой в процессе
жизненного цикла или деятельности. Процесс состоит из набора действий, таких как
планирование, проектирование, производство, редактирование, распространение и
сопровождение документов, необходимых всем заинтересованным лицам проекта:
менеджерам, инженерам и пользователям системы или ПО.
Процесс документирования состоит из следующих действий: реализации, проектирование
и разработка, производство и сопровождение.
Реализация. Это действие состоит из следующих задач.
1 Планирование, определяющее, какие документы должны быть выпущены во время
жизненного цикла ПО, что должно быть разработано, задокументировано и реализовано.
Для каждого установленного документа должно быть указано следующее:
а) название или имя;
б) цель;
в) назначение;
г) процедуры и ответственность по вводу, разработке, осмотру, модификации,
утверждению, производству, хранению, распространению, сопровождению и
конфигурированию;
д) расписание промежуточной и конечной версий.
Проектирование и разработка. Это действие состоит из следующих задач.
1. Каждый документ должен быть спроектирован в соответствии с применяемыми
стандартами по формату, содержанию, нумерации страниц, размещению рисунков/таблиц,
отметке о приоритете/секретности, упаковке и другим пунктам.
2. Источник и соответствие входных данных для документов должны быть
гарантированы. Должны быть использованы автоматические средства документирования.
3. Подготовленные документы должны быть просмотрены и отредактированы с точки
зрения формата, технического содержания и стиля представления в соответствии со
стандартами по документации. Они должны быть утверждены ответственным за их
выпуск.
Производство. Это действие состоит из следующих задач.
1. Документы должны быть произведены и упакованы. В соответствии с планом, ими
должны быть обеспечены все заинтересованные стороны. Производство и
распространение документов может быть выполнено в бумажном, электронном виде.
Исходные материалы должны храниться в соответствии с условиями записи, секретности,
сопровождения и резервных копий проекта.
2. Контроль должен быть представлен в соответствии с процессом управления
конфигурированием.
Сопровождение. Это действие состоит из следующих задач.
1. Задачи, необходимые для выполнения при модификации существующего ПО, должны
быть исполнены.
Стадия Рабочая документация ГОСТ 34.601 частично соответствует привлечению
процесса документирования процессов разработки по ИСО/МЭК 12207. Название данной
стадии не точно отражает ее содержание, так как она содержит этап 6.2 - Разработка или
адаптация программ. Кроме того, процесс документирования выполняется на стадиях
эскизного и технического проекта. По ГОСТ 19.102 этап разработки программной
документации появляется только на стадии Рабочий проект. Такое позднее начало
документирования процессов ЖЦ не в состоянии обеспечить ни требуемого качества
документации, ни требуемого качества ПО.
Таким образом, терминология и концепция в области документирования ИСО/МЭК 12207
представляются более удачными. Можно рекомендовать при использование ГОСТ 34.601
для этапов 4.2, 5.2, 5.3, 6.1 учитывать в содержании работ задачи, определенные в
ИСО/МЭК 12207 для процесса документирования
2. Определение типов и содержания документов.
Программные документы можно представить разделенными на три категории:
документация разработки;
документация продукции;
документация управления проектом.
Данная схема не является исчерпывающей и окончательной, но служит контрольной
таблицей основных типов программных документов, которые руководители должны
предусмотреть, когда определяют стандартные типы своих документов.
1. Документация разработки. Документы, описывающие процесс разработки ПО,
определяют требования, которым должно удовлетворять ПО, определяют проект
программного обеспечения, определяют, как его контролируют и как обеспечивают его
качество. Документация разработки также включает в себя подробное описание ПО
(программную логику, программные взаимосвязи, форматы и хранения данных и т.д.).
Разработка документов преследует пять целей:
а) они являются средством связи между всеми участниками проекта и описывают
подробности решений, принятых относительно требований к ПО, проекту,
программированию и тестированию;
б) они описывают обязанности группы разработки и определяют, кто, что и когда
делает, учитывая роль программного обеспечения, предмета работ, документации,
персонала, обеспечивающего качество, и каждого вовлеченного в процесс разработки;
в) они выступают, как контрольные пункты, которые позволяют руководителям
оценивать ход разработки (если документы разработки отсутствуют, неполны или
устарели, то руководители проекта теряют важное средство для отслеживания и
контроля проекта);
г) они образуют основу документации сопровождения ПО, требуемой лицам,
сопровождающим ПО, как часть документации продукции;
д) они описывают историю разработки ПО.
Типовыми документами разработки являются:
анализы осуществимости и исходные заявки;
спецификации требований и функций;
проектные спецификации, включая спецификации программ и данных;
планы разработки, сборки и тестирования ПО;
планы обеспечения качества, стандарты и графики;
защитная и текстовая информация.
2. Документация продукции. Документация продукции обеспечивает информацию,
необходимую для эксплуатации, сопровождения, модернизации, преобразования и
передачи программной продукции.
Документация продукции преследует три цели:
обеспечение учебной и справочной информацией для любого, использующего или
эксплуатирующего ПО;
облегчение сопровождения и модернизации ПО программистам, не разрабатывавших
ПО;
помощь при продаже или приемке ПО.
Документация продукции должна включать в себя материалы для следующих типов
читателей: пользователей, операторов, сопровождающих программистов. Кроме того,
данная документация может включать в себя руководства и материалы для
руководителей, вспомогательные материалы, общую информацию.
Типовые документы продукции включают в себя:
учебные руководства;
справочные руководства и руководства пользователя;
руководства по сопровождению ПО;
брошюры и информационные листки, посвященные продукции.
ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и
информация на упаковке для потребительских пакетов вводит определение документации
пользователя, как документации, которая обеспечивает пользователей информацией,
необходимой для установки и прогона ПО и является обязательной в поставке
(документация пользователя выполняется в виде одного или нескольких руководств и
вкладывается вместе с программным продуктом внутрь упаковки).
Данный стандарт определяет три категории информации:
- обязательная - информация, поставляемая с каждым пакетом;-
- условная - информация, поставляемая с каждым пакетом, для которого она
необходима;
- факультативная - информация, поставляемая с каждым пакетом, по усмотрению
изготовителя или торгующей организации.
Назначением документации пользователя является обеспечение конечного пользователя
достаточной информацией для ясного понимания:
цели, функций и характеристик ПО;
того, как ввести в действие и использовать ПО;
договорных прав и обязанностей.
Документация пользователя должна включать в себя справочную документацию для
повседневного использования программы. Дополнительно может быть выполнена учебная
документация. В качестве справочной документации выступают обозначение пакета,
компоненты пакета, функциональное описание ПО, ввод в действие ПО, использование
ПО, техническая информация о ПО, тестирование, договорная информация, словарь,
указатель, замечания конечных пользователей.
Таким образом, ГОСТ Р ИСО 9127, не имея формальных ссылок на ГОСТ Р ИСО/МЭК ТО
9294, фактически дополняет введенное в нем понятие документации продукции.
3. Документация управления проектом. Документы создаются на основе информации
управления проектом, такой как:
графики для каждой стадии процесса разработки и отчеты об изменениях графиков;
отчеты о согласованных изменениях ПО;
отчеты о решениях, связанных с разработкой;
распределение обязанностей.
Данная документация обеспечивает информацию, относящуюся, с точки зрения
руководства, к долговечности продукции.
3. Определение качества документов.
Руководители должны выбирать стандарты, распространяющиеся на уровень качества,
соответственно различным типам документов и различным типам проектов и должны
определять, как это качество будет достигнуто и поддержано.
Понятия качества, применимые к содержанию, структуре и представлению документации:
1. качество содержания можно измерять в элементах точности, полноты и ясности;
2. качество структуры, можно измерять легкостью, с которой читатель имеет
возможность определить местоположение информации;
3. качество представления должно соответствовать типу проекта.
4. Определение форматов документов.
Стандартизованные форматы документов важны для контроля качества документов, для
читаемости документов и для облегчения их сопровождения.
Информация может быть представлена в различных форматах, причем форматы могут
меняться от проекта к проекту. Форматы зависят от таких факторов, как объем проекта,
аудитория, для которой предназначены документы, количество стадий разработки и
бюджет документирования. Кроме того, должно быть учтено соображение о том, будут ли
документы переводить для международного распространения.
Стандарты и руководства организации, распространяющие на форматы документов,
должны быть установлены таким образом, чтобы допускать гибкость для руководителей в
выборе форматов, подходящих для их проектов.
5. Определение системы обозначения документов.
Стандартные обозначения документов необходимы для эффективного контроля
документации. Обозначающая информация может включать в себя: заглавие документа;
ссылочный номер документа; номер версии документа; дату выпуска и пересмотра;
реквизиты автора; реквизиты утвердившего лица; обозначение защищенности (авторских
прав); обозначение организации.
Если документы выпускаются в виде разрозненных листов, каждая страница должна
иметь индивидуальное обозначение (например, со ссылочным номером документа,
номером страницы и номером издания).
В части требований 2 - 5 отечественные стандарты 19-ой, 34-ой серии, ГОСТ 28195-89
обеспечивают решение задачи формирования комплекта документации, что будет нами
рассмотрено ниже.
3.2. Требования стандартов к программной документации
Как уже было отмечено, качество программного обеспечения, наряду с другими
факторами, определяется полнотой и качеством пакета документов, сопровождающих ПО.
К программным документам относятся документы, содержащие сведения, необходимые
для разработки, изготовления, сопровождения программ и эксплуатации.
19-я система стандартов (Единая система программной документации - ЕСПД)
устанавливает следующие виды программной документации.
1. Спецификация. Состав программы и документация на нее.
2. Ведомость держателей подлинников. Перечень предприятий, на которых хранят
подлинники программных документов.
3. Текст программы. Запись программы с необходимыми комментариями.
4. Описание программы. Сведения о логической структуре и функционировании
программ.
5. Программа и методика испытаний. Требования, подлежащие проверке при испытании
программы, а также порядок и методы контроля.
6. Техническое задание. Назначение и область применения программы, технические,
технико-экономические и специальные требования, предъявляемые к программе,
необходимые стадии и сроки разработки, виды испытаний.
7. Пояснительная записка. Схема алгоритма, общее описание алгоритма и
функционирования программы, а также обоснование принятых технических и
технико-экономических решений.
8. Эксплуатационные документы. Сведения для обеспечения функционирования и
эксплуатации программы. Перечень эксплуатационных документов представлен в таблице
3.1.
Таблица 3.1
Вид эксплуатационного
документа
Содержание эксплуатационного
документа
Регламентирующие
стандарты
Ведомость
эксплуатационных
документов
Перечень эксплуатационных
документов на программу.
ГОСТ 19.507-79.
Формуляр
Основные характеристики
программы, комплектность и
сведения об эксплуатации
программы.
ГОСТ 19.501-78.
Описание применения
Сведения о назначении
программы, области применения,
классе решаемых задач,
применяемых методах,
ограничениях для применения,
минимальной конфигурации
технических средств.
ГОСТ 19.502-78.
Руководство системного
программиста
Сведения для проверки,
обеспечения функционирования
и настройки программы на
условия конкретного
применения.
ГОСТ 19.503-79.
Руководство
программиста
Сведения для эксплуатации
программы.
ГОСТ 19.504-79.
Руководство оператора
Сведения, необходимые для
осуществления действий,
связанных с выполнением
программы вычислительной
системой.
ГОСТ 19.505-79.
Описание языка
Описание синтаксиса и
семантики языка.
ГОСТ 19.506-79.
Руководство по
техническому
обслуживанию
Сведения для применения
текстовых и диагностических
программ при обслуживание
технических средств.
ГОСТ 19.508-79.
Полный пакет документов, разрабатываемых при создание автоматизированной системы
и, в частности, программного обеспечения, установленный в отечественных стандартах,
включает:
ГОСТ 34.602-89 - техническое задание на создание АС;
ГОСТ 34.201-90 - виды и комплектность документов;
РД 50-34.698-90 - пояснительная записка, схема функциональной структуры, общее
описание системы, описание постановки задачи, описание информационного обеспечения
системы, описание организации информационной базы, перечень входных сигналов и
данных, перечень выходных сигналов/документов, описание программного обеспечения;
ГОСТ 19.201-78 - техническое задание;
ГОСТ 19.402-78 - описание программы;
ГОСТ 19.404-79 - пояснительная записка;
ГОСТ 19.301-79 - программа и методика испытаний.
Техническое задание. Содержание технического задания на разработку программных
продуктов должно соответствовать ГОСТ 19.201-78 Техническое задание. Требования к
содержанию и оформлению. Помимо разработки технического задания на все ПО могут
разрабатываться технические задания на этапы, например, техническое задание на
выполнение НИР.
Согласно ГОСТ 19.201-78 техническое задание на разработку ПО должно включать
следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
приложения.
В зависимости от особенностей разрабатываемого ПО стандарт допускает уточнение
содержания разделов, введение новых разделов или их объединение.
В разделе Введение указывается наименование, краткая характеристика области
применения ПО.
В разделе Основания для разработки указывается:
документ (документы), на основание которых ведется разработка;
организация, утвердившая документ, и дата утверждения;
наименование (условное обозначение) темы разработки.
В разделе Назначение разработки должно быть указано функциональное и
эксплуатационное назначение ПО.
В раздел Требования к программе включаются следующие подразделы.
1. Требования к функциональным характеристикам, в котором указываются требования к
составу выполняемых функций, организации входных и выходных данных, временным
характеристикам и т.д. В данном подразделе описывается поведение ПО с точки зрения
соотношения входа и выхода, без конкретизации его внутренней структуры. Описание
выполняемых функций делается либо в текстовом виде, либо на специальном
графическом языке. Описание входа заключается в фиксации синтаксиса и семантики всех
входных данных. Описание выхода должно содержать точное описание всех возможных
выходных данных в тесной взаимосвязи с входными.
2. Требования к надежности, где указываются требования к обеспечению надежного
функционирования ПО, его защите (контроль входной и выходной информации, описание
последствий отказов ПО и т.д.).
3. Условия эксплуатации, в котором должны быть указаны характеристики операционной
среды, вид обслуживания, необходимое количество и квалификация персонала и др., а
также допустимые параметры окружающей среды (относительная влажность, температура
и др.).
4. Требования к составу и параметрам технических средств - необходимый состав
технических средств (конфигурация) с указанием их основных технических
характеристик.
5. Требования к информационной и программной совместимости, в котором указываются
требования к информационным структурам на входе и выходе и методам решения,
исходным кодам, языкам программирования и программным средствам, используемым
ПО. Кроме того, могут указываться протоколы межмашинного сетевого обмена данными,
стандарты протоколов формализации данных и управления терминалами, стандарты и
форматы сообщений, протоколы транзакций, протоколы запросов данных, стандарты
представления данных, требования к СУБД и операционным системам.
6. Требования к маркировке и упаковке.
7. Требования к транспортированию и хранению.
В разделе Требования к программной документации должен быть указан
предварительный состав программной документации и, при необходимости, специальные
требования к ней.
В разделе Технико-экономические показатели указывается: ориентировочная
экономическая эффективность, предполагаемая годовая потребность, экономические
преимущества разработки по сравнению с лучшими отечественными и зарубежными
образцами или аналогами.
В разделе Стадии и этапы разработки устанавливают необходимые стадии разработки,
этапы и содержание работ (перечень документов, которые должны быть разработаны,
согласованы и утверждены), а также сроки разработки и исполнителей.
В разделе Порядок контроля и приемки должны быть указаны виды испытаний и общие
требования к приемке ПО. Здесь фиксируют важнейшие характеристики ПО в некоторой
количественной или иной достаточно простой форме, с тем, чтобы можно было
установить степень соответствия готового ПО принятым техническим условиям.
В приложениях к техническому заданию при необходимости приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы,
которые могут быть использованы при разработке;
другие источники разработки.
Техническое задание на создание АС разрабатывается в соответствии с ГОСТ 34.602-89.
Данный стандарт устанавливает следующие разделы, включаемые в техническое задание.
1. Общие сведения, включающие полное наименование системы, условное обозначение
системы, шифр темы (шифр (номер) договора), наименование предприятий разработчика
и заказчика системы и их реквизиты, перечень документов, на основании которых
создается система, плановые сроки начала и окончания работ по созданию АС, сведения
об источниках и порядке финансирования работ.
2. Назначение и цели создания АС, в котором указывают назначение системы и цели ее
создания..
3. Характеристика объекта автоматизации.
4. Требования к системе. Данный раздел состоит из следующих подразделов.
а) Требования к системе в целом. Здесь указывают перечень подсистем, их назначение и
основные характеристики, требования к числу уровней иерархии и степени централизации
системы, требования к способам и средствам связи для информационного обмена между
компонентами системы, требования к характеристикам взаимосвязей АС со смежными
системами, требования к ее совместимости, способы обмена информации. Кроме того,
требования к численности и квалификации персонала и режиму его работы, к надежности,
безопасности и т.д..
б) Требования к функциям.
в) Требования к видам обеспечения (математическому, информационному,
лингвистическому программному , техническому организационному и т.д.).
5. Состав и содержание работ по созданию (развитию) АС.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к
вводу в действие.
8. Требования к документированию.
9. Источники разработки.
Основное внимание уделим руководящему документу РД 50-34.698-90, устанавливающий
требования к содержанию документов на автоматизированные системы. Структура РД
50-34.698-90 приведена в таблице 3.2.
Содержание документов, разрабатываемых на предпроектных стадиях (Формирование
требований к АС и Разработка концепции АС), приведено в рекомендуемом приложении к
РД 50-34.698-90. На первой стадии разрабатывается отчет (согласно ГОСТ 7.32) и заявка
на разработку АС. На второй - отчет согласно ГОСТ 7.32.
Содержание организационно-распорядительных документов установлено также в
рекомендуемом приложении. К организационно-распорядительным документам
относятся:
акт завершения работы;
акты приемки в опытную и промышленную эксплуатацию;
план-график работ;
приказы о проведении работ и составе приемочной комиссии;
протоколы испытаний и согласования.
Документ Описание программного обеспечения содержит вводную часть и разделы:
структура ПО, функции частей ПО, методы и средства разработки ПО, операционная
система, средства, расширяющие возможности операционной системы.
Во вводной части приводят основные сведения о техническом, информационном и других
видах обеспечения АС, необходимые для разработки ПО или ссылку на соответствующие
документы проекта АС.
В разделе Структура ПО приводят перечень частей ПО с указанием их взаимосвязей и
обоснованием выделения каждой из них. В разделе Функции частей ПО приводят
назначение и описание основных функций для каждой части ПО.
В разделе Методы и средства разработки ПО приводят перечень методов
программирования и средства разработки ПО АС с указанием частей ПО, при разработке
которых следует использовать соответствующие средства и методы.
В разделе Операционная система указывают следующее.
1. Наименование, обозначение и краткую характеристику выбранной операционной
системы и ее версии, в рамках которой будут выполнять разрабатываемые программы, с
обоснованием выбора и указанием источников, где дано подробное описание выбранной
версии.
2. Наименование руководства, в соответствие с которым должна осуществляться
генерация выбранного варианта операционной системы.
3. Требования к варианту генерации выбранной версии операционной системы.
Раздел Средства, расширяющие возможности операционной системы содержит
подразделы, в которых для каждого используемого средства, расширяющего возможности
операционной системы, указывают:
наименование, обозначение и краткую характеристику средства, с обоснованием
необходимости его применения и указанием источников, где дано подробное описание
выбранного средства;
наименование руководства, в соответствие с которым следует настраивать используемое
средство на конкретное применение;
требования к настройке используемого средства.
Таблица 3.2.
Область
Документы
Содержание
Документы по
общесистемные решения
1. Ведомость эскизного
(технического) проекта
2. Пояснительные записки к
эскизному, техническому
проектам
Выполняется по ГОСТ 2.106
Согласно РД 50-34.698-90
3. Схема функциональной
структуры
4. Ведомость покупных изделий
Согласно РД 50-34.698-90
Выполняется по ГОСТ 2.106
5. Описание автоматизируемых
функций
6. Описание постановки задачи
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
7. Паспорт
Согласно РД 50-34.698-90
8. Проектная оценка надежности
системы
9. Общее описание системы
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
10. Программа и методика
испытаний
Согласно РД 50-34.698-90
11. Схема орг. структуры
Согласно РД 50-34.698-90
Документы с решениями
по организационному
обеспечению
1. Описание организационной
структуры
2. Методика
автоматизированного
проектирования
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
3. Технологическая инструкция
4. Руководство пользователя
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
5. Описание технологического
процесса обработки данных
Согласно РД 50-34.698-90
Документы с решениями
по техническому
обеспечению (основные)
1. Схема автоматизации
2. Описание комплекса
технических средств
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
3. ТЗ на разработку
специализированных
технических средств
4. Схема структурная комплекса
технических средств (КТС)
Согласно ГОСТ 15.001
Согласно РД 50-34.698-90
Документы с решениями
по информационному
обеспечению (основные)
1. Перечень входных сигналов и
данных
2. Перечень выходных сигналов
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
3. Описание ИО системы
Согласно РД 50-34.698-90
5. Описание организации
информационной базы
Согласно РД 50-34.698-90
6. Описание системы
классификации и кодирования
7. Описание массива
информации
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
8. Массив входных данных
9. Каталог БД
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
10. Состав выходных данных
11. Инструкция по
формированию и ведению БД
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Д
окументы с решениями по
техническому
обеспечению
1. Описание программного
обеспечения
Согласно РД 50-34.698-90
Документы с решениями
по математическому
обеспечению
1. Описание алгоритма
(проектной процедуры)
Согласно РД 50-34.698-90
Пояснительная записка к эскизному (техническому) проекту содержит следующие
разделы (согласно РД 50-34.698-90): общие положения; описание процесса деятельности;
основные технические решения; мероприятия по подготовке объекта автоматизации к
вводу системы в действие.
В разделе Общие положения приводят:
наименование проектируемой АС и наименование документов, их номера и дату
утверждения, на основании которых ведут проектирование АС;
перечень организаций, участвующих в разработке системы, сроки выполнения стадий;
цели, назначение и область использования АС;
подтверждение соответствия проектных решений действующим нормам и правилам
техники безопасности и т.п.;
сведения об использованных при проектирование нормативно-технических документах;
сведения о НИР, передовом опыте, изобретениях, использованных при разработке
проекта.
В разделе Описание процесса деятельности отражают состав процедур (операций) с
учетом обеспечения взаимосвязи и совместимости процессов автоматизированной и
неавтоматизированной деятельности, формируют требования к организации работ в
условиях функционирования АС.
В разделе Основные технические решения приводят:
решения по структуре системы, подсистем, средствам и способам связи для
информационного обмена между компонентами системы, подсистем;
решения по взаимосвязям АС со смежными системами, обеспечению их
совместимости;
решения по режимам функционирования, диагностированию работы АС;
решения по численности, квалификации и функциям персонала АС, режимам его
работы, порядку взаимодействия;
сведения об обеспечении заданных в техническом задании потребительских
характеристик системы (подсистем), определяющих ее качество;
состав функций, комплексов задач, реализуемых системой (подсистемой);
решения по комплексу технических средств, его размещению на объекте;
решения по составу информации, объему, способам ее организации, видам машинных
носителей, входным и выходным документам и сообщениям, последовательности
обработки информации и другим компонентам;
решения по составу программных средств, языкам деятельности, алгоритмам процедур
и операций и методам их реализации.
В разделе приводят в виде иллюстраций другие документы, которые допускается
включать по ГОСТ 34.201.
В разделе Мероприятия по подготовке объекта автоматизации к вводу системы в действие
приводят:
мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ;
мероприятия по обучению и проверке квалификации персонала;
мероприятия по созданию необходимых подразделений и рабочих мест;
мероприятия по изменению объекта автоматизации;
другие мероприятия, исходящие из специфических особенностей создаваемых АС.
Рассмотрим содержание ряда документов, определенных в стандарте DO - 178B.
Некоторые документы, именуемые в данном стандарте как данные жизненного цикла ПО,
уже рассматривались нами в разделе 2.
В DO - 178B определено, что данные жизненного цикла могут принадлежать к одной из
двух категорий: Категории Управления 1 и Категории Управления 2. Эти категории
связаны с элементами управления конфигурацией. Данное разделение позволяет иметь
средства управления затратами на разработку там, где может применяться менее строгий
контроль без снижения степени защищенности данных. В приложении А к документу DO
- 178B приведены минимальные категории управления, назначенному каждому виду
данных и их вариации в зависимости от уровня ПО (А, В, С, D, Е). Ниже, в таблице 3.3,
представлены некоторые фрагменты целей этапов жизненного цикла и их выходы -
данные жизненного цикла.
Документ DO - 178B устанавливает, что приложение А не предназначено для
представления всех данных, необходимых для создания ПО, и не предусматривает
какого-либо определенного способа хранения этих данных или их организации внутри
структур хранения. В дополнении к указанным документам могут вырабатываться другие,
необходимые для сертификации ПО.
Характеристики данных жизненного цикла ПО следующие:
непротиворечивость: информация непротиворечива, если она записана в терминах,
допускающих единственное толкование и дополненная, по необходимости,
определениями;
полнота: информация полна, если она включает все необходимые требования и/или
описательные материалы; все используемые диаграммы имеют комментарии, единицы
измерения и термины полностью определены;
проверяемость: информация проверяема, если она может быть проконтролирована на
предмет корректности;
состоятельность; информация состоятельна, если внутри нее нет конфликтов;
модифицируемость: информация модифицируема, если она структурирована и
стилизована таким образом, что вносимые изменения полноценны, непротиворечивы и
корректны;
Таблица 3.3
╧ п/п
Цели
Применяемость, в
зависимости от
уровня ПО
Выходы
Категория
управления,
обуславливаемая
уровнем ПО
Описание
А
В С D
А В С D
Этап планирования ПО
1. Определение действий на
этапе разработки и
интегрированном этапе
* * * * План программных
аспектов
сертификации
1
1 1 1
2.
Определение критериев
перехода, взаимосвязей и
согласованности между
этапами
* * *
План разработки ПО
План верификации
ПО
1
1
1
1
1
1
2
2
2
2
2
2
План управления
конфигурацией ПО
3.
Определение среды ЖЦ
ПО
* * * * План определения
качества ПО
1
1 2 2
5.
Определение стандартов
разработки ПО
* * *
Стандарты
требований к ПО
Стандарты
проектирования ПО
Стандарты
кодирования ПО
1
1
1
1
1
1
2
2
2
Этап разработки ПО
1.
Разработка ВУ
требований
* * * * Данные требований
к ПО
1
1 1 1
2.
Определение
установленных ВУ
требований
* * * * Данные требований
к ПО
1
1 1 1
3.
Разработка архитектуры
ПО
* * * * Описание
проектирования
1
1 2 2
6.
Разработка исходного
кода
* * * * Исходный код
1
1 1 1
Верификация выходов подэтапа определения требований к ПО
1.
ВУ требований к ПО
подчиняются
требованиям к системе
-
-
* * Результаты
верификации ПО
2
2 2 2
2.
ВУ требований точны и
согласованы
-
-
* * Результаты
верификации ПО
2
2 2 2
7.
Алгоритмы точны
-
-
*
Результаты
верификации ПО
2
2 2
Тестирование выходов подэтапа интеграции
1.
Исполняемый объектный
код подчиняются ВУ
требованиям
* * * * Варианты и
процедуры
верификации ПО
Результаты
верификации ПО
1
2
1
2
2
2
2
2
4.
Исполняемый объектный
код точно соответствует
НУ требованиям
-
* *
Варианты и
процедуры
верификации ПО
Результаты
верификации ПО
1
2
1
2
2
2
- - цели должны быть удовлетворены независимо; * - цели должны быть удовлетворены; 1
- данные удовлетворяют Категории Управления 1; 2 - данные удовлетворяют Категории
Управления 2.
трассируемость: информация трассируема, если могут быть определены источники ее
компонентов;
форма; форма должна обеспечить возможность эффективно получать доступ к данным
жизненного цикла По в течение всего срока службы системы;
управление; если предназначены для использования с этой целью, то данные должны
быть определены в плане ПО, который регламентирует этап, для которого
вырабатываются эти данные.
Дадим краткую характеристику основных данных жизненного цикла ПО.
План программных аспектов сертификации - первичное средство из используемых
службами сертификации для определения, предлагает ли разработчик такой жизненный
цикл ПО, который удовлетворяет уровню разрабатываемого ПО. Данный план должен
включать следующие разделы.
1. Обзор системы. Этот раздел содержит обзор системы, включая описание ее функций и
их распределение между аппаратной и программной частями, архитектуры,
программно-аппаратных интерфейсов, возможностей по обеспечению безопасности и т.д.
2. Обзор ПО. Здесь коротко описывают функции ПО с акцентом на предлагаемый уровень
концепции безопасности.
3. Аспекты сертификации. Этот раздел содержит сводку базиса сертификации, включая
средства обеспечения соответствия по отношению к программным аспектам
сертификации. Здесь также устанавливается предлагаемый уровень ПО и приводятся
выводы этапа оценки безопасности системы, включая потенциальную возможность
работы ПО в неблагоприятных условиях.
4. Жизненный цикл ПО. В данном разделе описан используемый жизненный цикл и
приводятся резюме по каждому его этапу и подэтапу, для которых детальная информация
определяется в соответствующих планах на разработку ПО. Резюме определяет, какие
цели каждого этапа и подэтапа ЖЦ ПО должны быть достигнуты, вовлекаемые структуры
для их достижения и т.д.
5. Данные жизненного цикла ПО. Этот раздел определяет данные, которые будут
выработаны и управляемы подэтапами ЖЦ ПО. Здесь также описывается отношение
данных друг к другу и другим данным, определяющим систему, данные, требуемые для
сертификации, форма данных и т.д.
6. Планировка. Этот раздел описывает средства, которые будут использованы
разработчиком для предоставления отчетности по деятельности в течение жизненного
цикла ПО при сертификации.
7. Дополнительные аспекты. Здесь приводятся специфические возможности, которые
могут повлиять на этап сертификации: например, альтернативные методы обеспечения
соответствия, оценка качества инструментальных средств, ранее разработанное ПО и т.д.
План оценки качества ПО. Устанавливает используемые методы для достижения целей
этапа оценки качества ПО (ОКПО). План ОКПО может включать описание методов
улучшения и прогрессивного управления этапом и может состоять из следующих
разделов.
1. Среда. Описание среды оценки качества ПО, включая структуру, организационные
ответственности и интерфейсы, стандарты, процедуры, средства, методы и метрики.
2. Полномочия. Характеристика полномочий, ответственности и независимости оценки
качества ПО.
3. Методы. Методы оценки качества ПО, которые должны использоваться для каждого
подэтапа жизненного цикла ПО на всем его протяжении, включая:
методы ОКПО, такие, как обзоры, ведение протоколов, отчеты, проверки и наблюдение за
этапами ЖЦ ПО;
методы, относящиеся к оповещению о проблемах и их исправлению;
методы описания проверки ПО.
4. Промежуточный критерий. Устанавливает промежуточный критерий для перехода к
этапу оценки качества ПО.
5. Временные требования. Временные требования методик этапа ОКПО по отношению к
методикам подэтапов ЖЦ ПО.
6. Результаты оценки качества ПО. Описание результатов, выработанных этапом оценки
качества ПО.
7. Управление поставщиками. Описание средств оценки соответствия действий
поставщиков нижнего уровня плану оценки качества ПО.
Документ Требования к ПО определяет требования высокого уровня, включая и
производные требования, если это необходимо. Этот документ должен включать
следующее (но не ограничиваться этим).
1. Описание приведения системных требований к программным, с особым акцентом на
требования безопасности и потенциальные условия возникновения сбойных ситуаций.
2. Функциональные и операционные требования для каждого режима работы.
3. Критерии функционирования, например, точность.
4. Временные требования и ограничения.
5. Ограничения по размеру памяти.
6. Программные и аппаратные интерфейсы, например, протоколы обмена, форматы
данных, частота входных и выходных сигналов.
7. Требования на обнаружение сбоев и мониторинг за безопасностью функционирования.
8. Требования к расчленению ПО на отдельные компоненты и на их взаимодействие друг
с другом (например, при реализации в виде распределенной системы).
Таким образом, хотя стандарт DO - 178B и не устанавливает явно процессы
документирования в своем жизненном цикле, ясно видно, что документации в нем
уделено большое внимание.
В заключение данного раздела кратко остановимся на документах, разрабатываемых в
ходе процесса создания ПО согласно [2]. В процессе разработки ПО появляются
следующие документы, перечисленные ниже в хронологическом порядке:
Соглашение о требованиях;
Внешняя спецификация;
Внутренняя спецификация.
Документ Соглашение о требованиях должен содержать первое письменное соглашение
между заказчиком и разработчиком о том, что будет сделано, и что не будет делаться при
разработке и выпуске программного обеспечения. В отличие от него спецификация
предполагает наличие более точных и исчерпывающих формулировок и определений. При
этом, первые два документа содержат информацию о том, что представляет собой ПО; а
третий должен объяснять, как ПО устроено и как достигаются установленные для него
цели и требования. Все документы имеют схожую структуру для облегчения контроля над
проектом, а также для обеспечения прослеживаемости всех технических решений от
требований до их реализации. По мере продвижения проекта разделы документа либо
просто копируются в соответствующие разделы следующего создаваемого документа,
либо расширяются описаниями технических решений текущего этапа.
Ниже приведена общая структура документа Внешняя спецификация, с развернутыми
комментариями в тех пунктах, которые касаются технической стороны дела (документ
также включает экономические, управленческие и другие аспекты, которые не
рассматриваются здесь):
1. ОПИСАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ
1.1. Наименование и шифры ПО (полное наименование, сокращенные наименования,
шифры ПО и проекта).
1.2. Краткое описание ПО (включая сведения об авторском праве, иерархию документов, с
указанием документов вышестоящих уровней).
1.3. Результирующие компоненты ПО (оформляется в виде таблицы или другой формы и
включает в себя, перечень спецификаций, другой документации и компонентов
программного обеспечения).
2. ЦЕЛИ
Этот раздел содержит причины выпуска ПО с указанием различного типа заявок, планов и
т.п. и носит полностью управленческий характер.
3. СТРАТЕГИЯ
3.1. Соглашения относительно представления материала.
3.1.1. Обозначения (определяются все обозначения, используемые в требованиях:
например, если применяются индексы, то дается пример их использования и определяется
принцип индексации).
3.1.2. Терминология (особенно специфическая для данного изделия).
3.1.3. Синтаксис (приводятся, если необходимо, синтаксические правила для дальнейшего
описания требований).
3.2. Генерируемое программное обеспечение (классифицируется как вспомогательное и
порождаемое описываемым изделием).
3.3. Системное программное обеспечение (все остальное ПО, включая ОС, утилиты,
пакеты прикладных программ, которое классифицируется как основное, поскольку оно
генерирует ПО предыдущего пункта).
Примечание. Причина такой расстановки пунктов состоит в том, что при правильном
проектировании сверху вниз генерируемое программное обеспечение является основной
целью проектирования и должно быть описано раньше, чем его генератор. Другими
словами, структура генерируемых программ должна определять структуру генератора, а
не наоборот. Если все ПО является основным, то в п.3.2. делается пометка не
используется и опускаются все его подпункты. Структура подпунктов п.п. 3.2 и 3.3
полностью дублируется и далее для простоты используется нумерация только п.п. 3.3.
3.3.n. Общие характеристики функции n. Если технически затруднительно и
неестественно рассматривать ПО как один большой функциональный модуль, то следует
привести его функциональную декомпозицию, показав связи между функциями
(функциональными модулями) и присвоив каждой функции некоторое уникальное имя n.
Затем для каждой функции отводится подраздел раздела 3.3 (т.е. 3.3.1, 3.3.2 и т.д.), в
заглавии которого используется слово функция с последующим именем функционального
модуля. Отметим, что такая функциональная декомпозиция не указывает, как именно ПО
будет фактически разбито на программные модули (это составляет содержание документа
Внутренняя спецификация). Для удобства работы, конечно, полезно иметь некоторое
соответствие функционального и фактического разбиения, но это не является требованием
и не должно уводить с правильного пути проектирования изделия.
3.3.n.1. Внешние ограничения.
3.3.n.1.1. Стандарты (список используемых промышленных стандартов и собственных
стандартов предприятия).
3.3.n.1.2. Ограничения на совместимость. Необходимо рассматривать несколько аспектов
совместимости:
исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов,
форматы листингов и т.п. Специально должна оговариваться совместимость со
следующими программными изделиями:
изделиями-предшественниками (т.е. такими, которые пользователь может заменить новым
изделием; если число функций при такой замене уменьшается, то следует привести
обоснование этому);
изделиями-компаньонами (т.е. относящимися к той же группе средств и являющимися
альтернативой);
подобными изделиями (т.е. выполняющих похожие функции в других программных
изделиях); конкурирующими изделиями (других организаций).
3.3.n.1.3. Программные ограничения. Описываются программное окружение
разрабатываемого ПО, включая указание средств для его загрузки и запуска. Также
отмечаются все действующие программные ограничения, например использование
вычислений с удвоенной точностью для некоторых функций.
3.3.n.1.4. Аппаратные ограничения. Приводится перечень устройств, необходимых для
работы ПО (с указанием минимальной, оптимальной и максимальной конфигурации).
Указываются все действующие ограничения на оборудование, например, физические
характеристики терминала или требование запрещения использования звукового
сигнального устройства.
3.3.n.2. Внешние характеристики.
Примечание. Если разрабатываемое ПО является расширением уже существующего, то
описываются, главным образом, его дополнительные характеристики. В любом случае
наибольшее внимание должно уделяться самым важным для конечного пользователя
вопросам. Эти разделы являются основой документа и содержат полное и окончательное
описание всех свойств программного изделия.
3.3.n.2.1. Результаты. Описываются все выходные данные ПО с точки зрения их
функционального содержания и назначения (например, файлы, сообщения, программно
устанавливаемые сигналы и прерывания). При этом должны быть рассмотрены все
возможные в системе носители и средства отображения информации. Указываются тип,
структура, формат, объем, расположение и диапазон изменения. Для всех выходных
данных, читаемых людьми (сообщения и отчеты) должны быть приведены образцы.
3.3.n.2.2. Процессы обработки. Описываются операции, выполняемые ПО в целом или
функциональными модулями, рассматриваемыми как черный ящик. Если обсуждение
идет на уровне модулей или этапов разработки, указываются также модули или этапы,
требуемые для получения определенной выходной информации. Точно определяются все
возможные ошибки, потенциальные условия их возникновения и способы рестарта и
восстановления. Подраздел должен описывать инициацию, преобразование данных, все
варианты завершения работы (нормального и аварийного).
3.3.n.2.3. Входы. Описание подобно п. 3.3.2.1
3.3.n.3. Эргономические характеристики.
Примечание. Этот раздел описывает свойства, обеспечивающие надежность, комфорт и
продуктивность работы пользователей и операторов, а также вопросы безопасности,
секретности, восстанавливаемости после сбоев, мобильности ПО. Остановимся более
подробно на двух подразделах: Надежность и Рабочие характеристики.
В разделе Надежность (это свойство программы понимается здесь как способность к
восстановлению нормальной работы при ошибках и сбоях в работе оборудования)
рассматриваются следующие вопросы:
защита данных пользователя;
степень защиты программ от ошибок, возникающих в других частях системы (например,
работающих одновременно с данной программой в другой области памяти). Следует
рассмотреть, как могут повлиять на работу предлагаемых программных средств такие
ошибки, учитывая следующие моменты: распределение ресурсов памяти (указать, если
предусмотрено обеспечение изоляции отводимых областей памяти); связь программ через
общие аппаратные ресурсы.
Раздел Рабочие характеристики описывает основные параметры или принципы, по
которым должна оцениваться эффективность работы программы, по возможности в
количественном виде с указанием возможных допусков. Все параметры должны быть
измеряемыми, к их числу могут относиться быстродействие, пропускная способность,
скорость передачи данных, расход машинных ресурсов, время реакции (или задержки) и
т.д.
3.3.n.4. Внутренние характеристики (этот раздел полностью расширяется в документе
Внутренняя Спецификация, однако частично может быть заполнен с целью полного
описания соответствующих внешних свойств).
3.4. Внутренние ограничения (здесь речь идет о тех свойствах, которые пользователю
логично ожидать, но которые по тем или иным причинам будут исключены из
программного изделия или потенциально оставлены на усмотрение разработчика:
например, неполная взаимозаменяемость носителей, отсутствие поддержки каких-либо
возможностей оборудования, и т.п.).
4. ИСПОЛЬЗУЕМЫЕ МАТЕРИАЛЫ (в т.ч. справочные)
5. ПЕРЕДАЧА ЗАКАЗЧИКУ И ВВОД В ДЕЙСТВИЕ.
Раздел 4
Оценка процесса разработки программного обеспечения
В июне 1991, четвертое полное заседание ИСО/МЭК JTC1/SC7 одобрило программу
(решение 144) в исследование потребностей и требований для стандарта оценки процесса
разработки ПО.
Стандарт первоначально должен быть издан как Технический Отчет, чтобы дать
возможность развивающемуся стандарту стабилизироваться в течение периода испытания
у пользователей, до преобразования его в Международный стандарт.
Директивы ИСО/МЭК JTC1 устанавливают, что опубликованный Технический Отчет, как
ожидаемый стандарт, может использоваться для временного пользования с целью сбора
информации и опыта его практического использования.
Новые вопросы работы над стандартом были впоследствии, в январе 1993, одобрены
JTC1.
В июне 1993 мандатом от JTC1/SC7 был предложен проект SPICE, чтобы:
помочь проекту стандартизации в его подготовительной стадии разрабатывать
начальные рабочие проекты;
провести испытания у пользователя в порядке приобретения опыта, который
формирует основу для изменения изданного стандарта до преобразования его в полный
Международный стандарт;
сформировать понимание рынка и принять стандарт развития.
Проект SPICE завершил первую из этих задач. Рабочая группа ИСО/МЭК (ИСО/МЭК
SC7/WG10), которая является ответственной за развитие Технического Отчета,
впоследствии, в июне 1995, распространила рабочие проекты через SC7 для PDTR
регистрационного бюллетеня. В настоящее время продолжаются предприниматься
поэтапные испытания у пользователей, чтобы обеспечить своевременную обработку
отчетов об опыте использования. Изданный Технический Отчет в данный момент
называется проектом стандарта ИСО/МЭК 15504.
Проект ИСО/МЭК 15504 является дополнением к другим Международным стандартам и
другим моделям для оценки возможности и эффективности организаций и их процессов.
ИСО/МЭК 15504 включает намерения стандартов серии ИСО 9000 обеспечить
уверенность в управлении качеством у поставщиков, обеспечивая пользователей
руководством (каркасом) для независимой оценки возможности потенциальных
поставщиков удовлетворить их потребности. Оценка процесса обеспечивает
пользователей способностью оценить возможность процесса по непрерывной шкале
простым и сравнимым способом, не используя характеристики выполнено/не выполнено
аудита качества, базирующегося на ИСО 9001. Кроме того, руководство, описанное в
проекте стандарта ИСО/МЭК 15504, предоставляет возможность регулировать сферу
оценки для покрытия конкретных процессов, представляющих интерес, а не всех
процессов, используемых в организации.
ИСО/МЭК 15504 связан со следующими стандартами серии ИСО 9000, ранее
упоминаемыми нами:
ИСО 9001 - 1994 Системы качества. Модель для обеспечения качества при
проектирование, разработке, производстве, монтаже и обслуживании;
ИСО 9000-3 - 1997 Стандарты в области административного управления качеством и
обеспечения качества. Часть 3. Руководящие положения по применению ИСО 9001:1994
при разработке, поставке и техническом обслуживании ПО;
ИСО 9004-4 - 1993 Административное управление качеством и элементы системы
качества. Часть 4. Руководящие положения по повышению качества.
Часть 2 ИСО/МЭК 15504 особенно сильно связана с ИСО/МЭК 12207 - 1995,
Информационная технология. Жизненный цикл процессов ПО, также рассмотренный
нами в разделе 2 данного учебного пособия.
Проект стандарта ИСО/МЭК 15504 состоит из следующих частей, под общим названием
Оценка процесса разработки ПО
Часть 1: Понятия и вводное руководство (информативная)
Часть 2: Эталонная модель процессов и возможности процесса (нормативная)
Часть 3: Выполнение оценки (нормативная)
Часть 4: Руководство по выполнению оценки (информативная)
Часть 5: Модель оценки и показательное руководство (информативная)
Часть 6: Руководство по компетенции эксперта-консультанта (информативная)
Часть 7: Руководство для использования в улучшение процесса (информативная)
Часть 8: Руководство для использования в определении возможности процесса
поставщика (информативная)
Часть 9: Словарь (информативная)
4.1 Основные положения
ИСО/МЭК 15504 обеспечивает руководство для оценки процесса разработки
программного обеспечения. Оно может использоваться организациями для планирования,
менеджмента, текущего контроля, управления и совершенствования приобретения,
поставки, разработки, функционирования, развития и поддержки программного
обеспечения.
ИСО/МЭК 15504 обеспечивает структурированный подход к оценке процесса разработки
ПО для следующих целей:
организацией или от ее имени с целью понимания состояния собственных процессов для
совершенствования (улучшения) процесса разработки ПО
организацией или от ее имени с целью определения пригодности собственных процессов
для удовлетворения специфического требования или класса требований
организацией или от ее имени с целью определения пригодности процессов другой
организации для специфического контракта или класса контрактов.
Руководство оценки поощряет самостоятельную оценку, определяет управление для
оцениваемых процессов, принимает во внимание контекст, в котором оцениваемые
процессы функционируют, вырабатывает набор рейтингов процесса (профиля процесса),
соответствует всем предметным областям и размерам организаций.
Использование оценки процесса разработки ПО внутри организации должно утвердить
:
культуру постоянного улучшения и учреждения соответствующих механизмов для
поддержки и сопровождения этой культуры;
инжиниринг процессов, с целью удовлетворения деловых требований;
оптимальное использование ресурсов.
Пользователи извлекут выгоду из использования оценки, определенной в данном
стандарте. Ее использование в определения возможности процесса позволит:
уменьшить неопределенность и риск в выборе поставщика программных систем при
заключении контракта;
поместить соответствующие средства управления в наиболее рискованные места
жизненного цикла проекта;
обеспечить определенную количественную основу для выбора финансовых
потребностей, требований и оценить стоимость проекта относительно
возможностей конкурирующих поставщиков.
Основные преимущества стандартизированного подхода к оценке процесса разработки
заключаются в том, что:
общественности представлена общедоступная модель;
достигнуто общее понимание в использовании оценки для улучшения процесса и
определения его возможности;
облегчена процедура определения возможности поставки оборудования;
процесс разработки ПО управляется и регулярно просматривается в свете опыта
использования;
подход может быть изменен только с международного согласия;
способствует гармонизации существующих моделей и схем оценки.
Подход к оценке процесса, определенный в ИСО/МЭК 15504, предоставляет основу для
общего подхода к описанию результатов оценки, принимая во внимание некоторую
степень сравнения оценок, базирующих на других, но совместимых, моделях и методах.
Связь ИСО/МЭК 15504 с другими моделями и методами показана на рис. 4.1.
Рис. 4.1 Источники SPICE.
Оценка имеет два принципиальных контекста для ее использования, как показано рис. 4.2.
В границах контекста улучшения процесса, результаты оценки характеризуют текущую
деятельность внутри организации в понятиях возможности выбранных процессов. Анализ
результатов оценки в свете деловых потребностей организации позволяет определить
достоинства, недостатки и риски, свойственные ее процессам. Это, в свою очередь,
приводит к ответу на вопрос, когда процессы эффективны в достижении своих целей, и
определить причины низкого качества, перерасхода времени и стоимости.
Определение возможности процесса достигать поставленной цели связано с анализом
предлагаемой возможности процесса, выбранного для оценки, относительно целевого
профиля возможности процесса. Это необходимо для того, чтобы определять риски,
включаемые в реализацию проекта, использующего данный процесс. Предлагаемая
возможность может базироваться как на основе результатов предыдущих оценок, так и на
основе оценки, выполненной с целью установления предлагаемой возможности.
ИСО/МЭК 15504 разрабатывается для удовлетворения потребностей пользователей,
поставщиков и экспертов-консультантов, и их индивидуальных требований.
Преимущества использования этого блока документов заключаются в следующем:
для пользователей: в способности определить текущую и потенциальную
возможность процессов разработки организации-поставщика ПО;
для поставщиков: в способности определить текущую и потенциальную возможность
своих собственных процессов разработки ПО; в способности определить области и
приоритеты в улучшении процессов организации; определена схема, которая указывает
маршрут для улучшения процессов разработки ПО;
для экспертов-консультантов: как руководство для проведения оценки процесса
разработки ПО.
Верхний уровень связей между оценкой процесса, усовершенствованием процесса и
определением возможности процессов показан на рис. 4.3 с указанием мест различных
компонентов ИСО/МЭК 15504.
Рис. 4.3 Обзор связей элементов проекта стандарта ИСО/МЭК 15504.
Данный стандарт разрабатывается с целью получения результатов оценки, которые
являются объективными, сравнимыми, способными использоваться как для улучшения
процесса, так и для определения его возможности. Надежные результаты оценки
достигаются через определение руководства для проведения оценки. Руководство
включает архитектуру для рейтинга процесса и для представления оценок рейтинга.
Каркас оценки.
Контекст оценки процесса обобщен на рис. 4.4. ИСО/МЭК 15504-2 определяет эталонную
модель, которая обеспечивает основу для рейтингов возможности процессов,
базирующуюся на достижении определенных атрибутов процесса. Часть 3 ИСО/МЭК
15504 определяет требования для выполнения оценки и устанавливает обстоятельства, в
которых может быть произведено сравнение результатов оценки. ИСО/МЭК 15504-4
обеспечивает руководящие положения в выполнении оценки и интерпретации требований
части 3. Эти руководящие положения являются общими, чтобы быть применимыми всеми
организациями, а также для проведения оценок, использующих различные методы,
технологии и инструментальные средства.
Рис. 4.4 Контекст оценки процесса.
Оценка процесса выполняется как для улучшения процесса, как описано в ИСО/МЭК
15504 -7, так и как часть процедуры определения возможности процесса, как указано
ИСО/МЭК 15504-8. В каждом случае, формальный вход в оценку происходит с
определения: цели оценки (почему это выполняется), сферы оценки (процессы, которые
должны быть оценены) и ограничений, если имеются, относящиеся к оценке. Входы
оценки определяют также обязанности для выполнения оценки и другую дополнительную
информацию.
Оценка выполняется над выбранными процессами на основе модели оценки. Эта модель
оценки процессов должна быть совместима с эталонной моделью. Эталонная модель - это
двухмерная модель, состоящая из набора процессов и набора атрибутов процесса.
Атрибуты процесса применяются ко всем процессам. Они группируются в уровни
возможности, которые могут использоваться для определения того, как процесс
управляется. Выходы оценки включают набор профилей процессов и дополнительный
рейтинг уровня возможности для каждого оцениваемого процесса.
Оценка содержит, по крайней мере, пять специфических действий: планирование, сбор
данных, верификацию данных, ранжирование процессов и документирование. Процесс
оценки должен быть документирован. Кроме того, эксперты-консультанты должны
записать объективные показатели выполнения или использованной возможности, чтобы
доказать достижение рейтингов. Оценка процесса выполняется как группой, по крайней
мере, с одним компетентным экспертом-консультантом, компетенция которого описана в
ИСО/МЭК 15504-6, так и на непрерывной основе, с использованием пригодных
инструментальных средств для сбора данных, подтвержденных компетентным
экспертом-консультантом.
Эталонная модель процессов и возможности процесса формирует основу для любой
модели, используемой для целей оценки процесса. Эталонная модель включает
двумерный подход к оценке возможности процесса - одно измерение определяет
оцениваемые процессы, второе - описывает шкалу для измерения возможности. Любая
модель, совместимая с эталонной моделью, может использоваться для оценки, и
результаты любых совместимых оценок могут переноситься в общую базу.
Контекст улучшения процесса.
Успешное улучшение процесса разработки ПО происходит в деловом контексте,
учитывающем специфические потребности и бизнес - цели организации, ключевые
ограничения, такие как, например, ресурсы, культура и т.п. Это отражено на рис. 4.5.
Часть 7 стандарта ИСО/МЭК 15504 обеспечивает руководящими положениями в
использование оценки процесса разработки ПО как метода для выполнения улучшения
процесса ПО в непрерывном цикле. Руководящие положения определяют:
введение оценки процесса разработки ПО;
использование результатов оценки процесса разработки ПО;
измерение эффективности процесса ПО и улучшение этой эффективности;
установление действий улучшения в соответствии с бизнес - целями;
использование эталонной модели, определенной в ИСО/МЭК 15504-2 как маршрутной
карты для улучшения;
вопросы культуры в контексте улучшения процесса разработки ПО;
вопросы управления улучшением данного процесса.
Рис. 4.5 Улучшение процесса.
Предусмотренные руководящие положения непосредственно строятся на ИСО 9004-4.
Они не предполагают специфические организационные структуры, философию
управления, жизненный цикл процессов ПО или методы разработки ПО. Понятия и
принципы подходят для области различных деловых потребностей, предметных областей
и размеров организаций, так что они могут использоваться всеми типами организациями
ПО для проведения улучшения их процессов.
Контекст определения возможности.
Процедура определения возможности процесса описана в ИСО/МЭК 15504-8.
Определение возможности процесса строится, главным образом, на оценке процесса.
Процессы ранжируются, а затем сравниваются с процессами эталонной модели, используя
измерение и структуру рейтингов, описанных в ИСО/МЭК 15504-2. Контекст определения
возможности процесса показан на рис.4.6.
Рис.4.6 Определение возможности процесса.
Пользователь программных продуктов или услуг имеет технические и другие
потребности, что выражается в специфических требованиях. Прежде, чем заключить
контракт, пользователь должен определить возможность процесса ожидаемого
контрагента, или поставщик может захотеть установить свою собственную возможность
процесса прежде, чем ответить на предложение пользователя. Технические и другие
потребности в определении возможности процесса подтверждаются в специфических
требованиях.
Специфические требования переводятся в целевую возможность, которая представляет
вход в оценку процесса. Поставщик может выдвинуть предлагаемую возможность
процесса как набор процесс - процесс рейтингов уровня возможности, который должен
предлагаться заинтересованным организациям. В простой ситуации, предлагаемая
возможность процесса может базироваться на последней самооценке или на других
средствах. В более сложных случаях, поставщик может предложить возможность
процесса, которая может быть достигнута в будущем, базируясь на текущем профиле
поставщика и уместных планах улучшения.
Доверие к предлагаемой возможности процесса анализируется вместе с рисками,
включенными и описанными в отчете о возможности процесса.
ИСО/МЭК 15504-8 обеспечивает руководящие положения об использовании результатов
оценки для целей определения возможности процесса поставщиков. Руководящие
положения особо адресуются определению возможности процесса, как для использования
в пределах организации с целью определения рисков, связанных с новым проектом, так и
для использования пользователем для оценки внешних поставщиков.
4.2 Эталонная модель
Архитектура эталонной модели искусственно включает два измерения:
измерение процесса, которое характеризует результаты процесса, являющиеся
существенными измеримыми целями процесса;
измерение возможности процесса, которое характеризует набор атрибутов процесса,
применимых к любому процессу и представляющие собой измеримые характеристики,
которые необходимы для управления процессом и улучшающие возможность его
выполнения.
Эталонная модель группирует процессы, при измерение процесса, в три группы процессов
жизненного цикла, которые содержат пять категорий процесса, согласно типу
деятельности, к которым он обращен.
Начальные процессы жизненного цикла состоят из категорий процессов поставщик -
заказчик и инжиниринга.
Категория процесса поставщик - заказчик состоит из процессов, на которые
непосредственно воздействует заказчик, разработка поддержки и перехода ПО заказчику,
и предусматривают корректное функционирование и использование программного
продукта и/или услуг.
Категория процесса инжиниринга состоит из процессов, которые непосредственно
определяют, осуществляют или поддерживают программный продукт, его отношение к
системе и его документации потребителя (заказчика).
Поддерживающие процессы жизненного цикла состоят из категории процесса
поддержки.
Категория процесса поддержки состоит из процессов, которые могут использоваться
любым из других процессов (включая другие поддерживающие процессы ) в различных
точках жизненного цикла ПО.
Организационные процессы жизненного цикла состоят из категорий процессов
управления и организации.
Категория процесса управления состоит из процессов, которые содержат методы общего
характера, которые могут использоваться любым, кто управляет любым типом проекта
или процессом внутри жизненного цикла программного обеспечения.
Категория процесса организации состоит из процессов, которые устанавливают бизнес -
цели организации и разрабатывают (развивают) процесс, продукт и активные ресурсы,
которые, когда используется проектами в организации, помогут организации достигнуть
ее бизнес - целей.
Категории процессов и процессы обеспечивают группирование типов деятельности.
Каждый процесс в эталонной модели описан в терминах утверждения цели. Эти
утверждения включают в себя уникальные функциональные цели процесса, которые
подтверждаются в конкретной среде. Утверждение цели включает дополнительный
материал, определяющий выходы успешной реализации процесса. Соответствие цели
процесса представляет первый шаг в формирование возможности процесса.
Эталонная модель не определяет как, или в каком порядке, элементы утверждений цели
процесса должны быть достигнуты. Цели процесса будут достигнуты в организации через
различные действия более низкого уровня, задачи и методики, выполняемые, чтобы
произвести рабочий продукт. Эти выполняемые задачи, действия и методики, а также
характеристики произведенных рабочих продуктов, являются показателями, которые
демонстрируют, достигнута ли цель конкретного процесса.
Развитие возможности процесса характеризуется в терминах атрибутов процесса,
сгруппированных в уровни возможности. Атрибуты процесса являются признаками
процесса, которые могут быть оценены по шкале достижения, обеспечивая меру
возможности процесса. Атрибуты применимы ко всем процессам. Каждый атрибут
процесса описывает аспект полной возможности управления и улучшения эффективности
процесса в достижении его целей и содействующего бизнес - целям организации.
Уровень возможности характеризуется набором атрибутов, которые работают вместе.
Каждый уровень обеспечивает главное расширение возможности выполнения процесса.
Уровни составляют рациональный путь развития через усовершенствование возможности
любого процесса.
Есть шесть уровней возможности в эталонной модели.
Уровень 0: Незавершенный. Общая неудача в достижении цели процесса. Имеются
нелегко идентифицированные рабочий продукт или выходы процесса.
Уровень 1: Выполняемый. Цель процесса, в общем, достигнута. Достижение не может
строго планироваться и отслеживаться. Персонал организации осознает, что процесс
должен выполняться, и имеется общее согласие, что этот процесс выполняется, как
требуется и когда требуется. Имеются определенные рабочие продукты процесса, и они
свидетельствуют в пользу достижения цели.
Уровень 2: Управляемый. Процесс вырабатывает рабочие продукты согласно
определенным процедурам, планируется и отслеживается. Рабочие продукты
соответствуют конкретным стандартам и требованиям. Основное различие от
Выполняемого уровня в том, что при выполнении процесса теперь вырабатываются
рабочие продукты, которые полностью требования к качеству в пределах определенного
промежутка времени и выделенного ресурса.
Уровень 3: Установленный. Процесс выполняется и управляется, используя
определенный процесс, основанный на хороших принципах инжиниринга программного
обеспечения. Индивидуальные реализации процесса используют документирующие
процессы, утвержденные, приспособленные версии стандарта в достижении выходов
определенного процесса. Ресурсы, необходимые для установления определения процесса -
также на месте. Основное отличие от Управляемого уровня в том, что процесс
Установленного уровня использует определенный процесс, который способен достигнуть
своих выходов.
Уровень 4: Предсказуемый. Определенный процесс, на практике, последовательно
выполняется в пределах определенных ограничений и достигает определенных целей.
Подробные меры выполнения процесса собраны и проанализированы. Это ведет к
количественному пониманию возможности процесса и улучшенной способности
предсказать выполнение. Выполнение процесса объективно управляется. Качество
рабочих продуктов количественно известно. Основное отличие от Установленного уровня
в том, что определенный процесс теперь выполняется последовательно внутри
определенных ограничений, чтобы достигнуть своих определенных выходов.
Уровень 5: Оптимизирующий. Выполнение процесса оптимизируется, чтобы достичь
текущие и будущие деловые потребности. Процесс достигает повторяемости при
достижении определенных бизнес - целей. Количественная эффективность процесса и
цели эффективности для выполнения установлены, базируются на бизнес - целях
организации. Непрерывный процесс, контролирующий эти цели, позволяет получать
количественную обратную связь, и усовершенствование достигнуто анализом
результатов. Основное отличие от Предсказуемого уровня в том, что определенные и
стандартные процессы теперь динамически изменяются и адаптируются, чтобы
эффективно достичь текущие (актуальные) и будущие бизнес - цели.
Естественно, эталонная модель не может использоваться как основа для проведения
надежных и непротиворечивых оценок возможности процесса, так как уровень
детализации не достаточен. Описания цели процесса и атрибутов возможности в
эталонной модели необходимо поддерживать исчерпывающим набором показателей
выполнения процесса и его возможности. Таким образом, будет возможен
непротиворечивый рейтинг возможности процесса.
Измерение процесса
В этом подразделе приводиться классификация процессов, принятых в организациях,
занимающихся разработкой, эксплуатацией, приобретением, поставкой и поддержкой
функционирования ПО. Классификация распознает пять категорий процессов, которые
содержат все процессы. Категории и их процессы сопоставимы с теми процессами,
которые определены в проекте стандарта ИСО/МЭК 12207, Информационная технология -
Жизненный цикл процесса ПО, рассмотренного нами в разделе 2.
Как было отмечено выше, в эталонной модели процессы объединяются в три группы и
пять категорий процессов:
начальные процессы жизненного цикла включают категории процесса инжиниринга и
поставщик - заказчик;
поддерживающие процессы жизненного цикла включают категории процесса
поддержки;
организационные процессы жизненного цикла включают категории процесса
управления и организации.
Описание каждой категории процессов включает характеристику процессов, которые он
содержит, сопровождающееся списком имен процессов.
Индивидуальные процессы описаны в терминах шести компонентов.
Идентификатор процесса. Идентифицирует категорию и последовательный номер
внутри этой категории. Схема нумерации различается между процессами верхнего уровня
и процессами второго уровня. Идентификатор состоит из двух частей: сокращения
категории (например, ENG для категории процесса инжиниринга) и номер (например,
CUS. 1 обозначает Процесс Приобретения и CUS. 1.2 обозначает процесс второго уровня,
Процесс Выбора Поставщика, который является составляющим (компонентным)
процессом Процесса Приобретения).
Имя процесса. Описательная фраза, которая выделяет принципиальное свойство процесса
(например, Выбор Поставщика).
Тип процесса. Имеется 3 типа процессов верхнего уровня (базисный, расширенный,
новый) и 2 процесса второго уровня (компонентный, расширенный), которые имеют
следующее отношение к процессам ИСО/МЭК 12207. Новые процессы дополнительны к
тем, что определены в ИСО/МЭК 12207. Базисные процессы идентичны в предназначении
процессам ИСО/МЭК 12207. Расширенные процессы дополняются на существующем
процессе ИСО/МЭК 12207. Компонентные процессы группирует одно или большее
количество действий ИСО/МЭК 12207 из того же самого процесса. Расширенные
компонентные процессы группируют одно или большее количество действий ИСО/МЭК
12207 из того же самого процесса и включают дополнительный материал.
Цель процесса. Материал, который указывает цель процесса, устанавливающего общие
цели выполнения процесса на верхнем уровне. Необязательный дополнительный материал
может быть включен, чтобы далее определить утверждение цели.
Результаты процесса. Список описаний результатов процесса.
Примечания процесса. Необязательный список информативных примечаний
относительно процесса и его отношения к другим процессам.
Для примера, приведем несколько процессов из каждой категории процесса.
CUS.1 Процесс Приобретения
Базисный процесс
Цель Процесса Приобретения состоит в том, чтобы получить продукт и/или услугу,
которое удовлетворяет потребность, выраженную заказчиком (клиентом). Процесс
начинается с определения потребности заказчика и требуемых результатов с принятием
продукта и/или услуги, необходимого заказчиком. В результате успешной реализации
процесса:
- будет разработан контракт, который ясно выражает ожидания, обязанности и
обязательства, как заказчика, так и поставщика;
- будет произведен продукт и/или услуга, что удовлетворит установленную потребность
заказчика;
- приобретение будет проверено таким образом, чтобы определенные ограничения как,
например, стоимость, план и качество были выполнены.
CUS.1.1 Процесс Подготовки Приобретения
Компонентный процесс CUS.1 - Процесса Приобретения
Цель Процесса Подготовки Приобретения состоит в том, чтобы установить потребности
и цели приобретения. В результате успешной реализации процесса:
- будет установлена потребность в приобретении, разработке или расширении системы,
программного продукта или процесса разработки ПО;
- будут сформулированы системные требования;
- будет разработана стратегия приобретения;
- будут определены приемочные критерии.
ENG.1 Процесс Разработки
Базисный процесс
Цель процесса Разработки состоит в том, чтобы трансформировать согласованный набор
требований в функциональный программный продукт или программную систему, которые
удовлетворяют установленным потребностям заказчика. В результате успешной
реализации процесса:
- будет разработан программный продукт или программная система;
- будут разработаны промежуточные рабочие продукты, что показывает, что
конечное изделие основывается на согласованных требованиях;
- будет установлена непротиворечивость между требованиями программного
обеспечения и проектами программного обеспечения;
- данные тестирования будут показывать, что конечный продукт встречает
согласованные требования;
- конечный продукт будет установлен в целевую среду и принят заказчиками.
ПРИМЕЧАНИЕ: Согласованные требования можно обеспечивать операцией процесса
Приобретения (CUS. 1) или Процесса Установления Требований (CUS. 3).
ENG.1.1 Процесс Разработки и Анализа Системных Требований
Компонентный процесс ENG.1 - Процесса Разработки
Цель Процесса Разработки и Анализа Системных Требований состоит в том, чтобы
установить системные требования (функциональные и нефункциональные) и архитектуру,
идентифицируя, какие системные требования должны быть распределены к каким
элементам системы и в какой версии. В результате успешной реализации процесса:
- будут разработаны системные требования, что соответствует установленным
потребностям заказчика;
- будет предложено решение, идентифицирующее основные элементы системы;
- согласованные требования будут распределены каждому из основных элементов
системы;
- будет разработана стратегия версии, определяющая приоритет для выполнения
системных требований;
- системные требования будут одобрены и модифицированы, как и требуется;
- требования, предложенное решение и их связи будут сообщены всем
заинтересованным сторонам.
SUP.1 Процесс Документирования
Расширенный Процесс
Цель Процесса Разработки ALIGN="JUSTIFY"Документации состоит в том, чтобы
разработать и поддержать документы, которые записывают информацию, произведенную
процессом или действием. В результате успешной реализации процесса:
- будет разработана стратегия, идентифицирующая документы, которые будут
произведены в течение жизненного цикла программного продукта;
- будут определены стандарты, к которые должны обращаться за разработка
документов;
- все документы, которые будут произведены процессом или проектом будут
идентифицированы;
- содержание и цель всех документов будет определена, рассмотрена и одобрена;
- все документы будут разрабатываться и издаваться в соответствии с
определенными стандартами;
- все документы будут поддерживаться в соответствии с определенными критериями.
ПРИМЕЧАНИЕ - процесс поддерживает исполнение атрибута процесса 2.2 в тех
примерах, где он введен.
MAN.1.1 Процесс Управления Проектом
Компонентный процесс MAN.1 - процесса Управления
Цель Процесса Управления Проектом состоит в том, чтобы идентифицировать,
устанавливать, координировать и контролировать действия, задачи и ресурсы,
необходимые для проекта создания продукта и/или встречи услуги согласованным
требованиям. В результате успешной реализации процесса:
- будет определена область работ проекта;
- будет оценена выполнимость достижения целей проекта с доступными ресурсами и
ограничениями;
- будут измерены и оценены задачи и ресурсы, необходимые для завершения работы;
- будут идентифицированы и проверяться интерфейсы между элементами проекта и
другими проектами и организационными модулями;
- будут разработаны и выполняться планы выполнения проекта;
- будет проверен и сообщаться прогресс проекта;
- действия, чтобы исправить отклонения от плана и предотвращать рекуррентное
соотношение проблем, идентифицированных в проекте, будут приниматься, когда цели
проекта не достигнуты.
ПРИМЕЧАНИЕ - Этот процесс поддерживает исполнение атрибута процесса 2.1 в тех
примерах, где он введен.
ORG.2 Процесс Усовершенствования
Базисный Процесс
Процесс Усовершенствования - процесс для установления, оценки, измерения, управления
и улучшения процесса жизненного цикла программного обеспечения. В результате
успешной реализации этого процесса:
- набор организационных активов процесса будет разработан и сделан доступным;
- возможность процесса организации будет периодически оценена, чтобы определить
степень, в какой реализация процесса является эффективной в достижении целей
организации;
Измерение возможности
Измерение возможности эталонной модели определяет шкалу измерения для оценки
возможности процесса любого процесса. Возможность процесса определена на шести
пунктах порядковой шкалы, которая позволяет оценить возможность из нижней части
шкалы, незавершенного уровня, к верхнему концу шкалы, оптимизирующему уровню.
Шкала определяет повышение возможности выполняемого процесса от эффективности,
которая не способна к достижению определенных результатов вплоть до эффективности,
которая является способной к достижению бизнес - цели и поддержке непрерывного
улучшения процесса. Следовательно, шкала определяет четкий маршрут улучшения для
каждого индивидуального процесса.
Внутри модели возможности, мера возможности основана на наборе из девяти атрибутов
процесса (АП) (см. таблицу 4.1). Атрибуты процесса используются, чтобы определить,
достиг ли процесс данной возможности. Каждый атрибут измеряет специфический аспект
возможности процесса. Атрибуты самостоятельно измеряются в шкале процентов и,
следовательно, обеспечивают более подробное понимание специфических аспектов
возможности процесса, требуемой, чтобы поддерживать усовершенствование процесса и
определение возможности.
Для примера, приведем один из атрибутов третьего уровня возможности.
AП 3.1 Атрибут определение и преобразование процесса
До какой степени ведется выполнение процесса в виде преобразованного экземпляра
стандартного определения процесса. Стандартный процесс отвечает определенным бизнес
- целям организации. Преобразование выполняется для соответствия специфическим
целям экземпляра процесса. В результате полного достижения этого атрибута:
- документация процесса, вместе с соответствующим руководством на подгонку
стандартной документации процесса, будет определена, что способно обеспечить
нормальную область выполнения процесса и функциональные и нефункциональные
требования к рабочему продукту;
- выполнение процесса будет проводиться в соответствии с выбранной и/или
приспособленной стандартной документацией процесса;
- исторические данные выполнения процесса будут собраны, во-первых, чтобы
устанавливать и совершенствовать понимание поведения процесса, во-вторых, чтобы
оценить потребности ресурса выполнения процесса;
- опыты использования документации процесса будут использоваться, чтобы
совершенствовать стандартный процесс
Таблица 4.1.
Номер
Название
Уровень 1
Выполняемый процесс
АП 1.1
Атрибут выполнения процесса
Уровень 2
Управляемый процесс
AП 2.1
Атрибут управления выполнением
AП 2.2
Атрибут управления рабочим продуктом
Уровень 3
Установленный процесс
АП 3.1
Атрибут определения и преобразования процесса
АП 3.2
Атрибут ресурса процесса
Уровень 4
Предсказуемый процесс
AП 4.1
Атрибут измерения процесса
AП 4.2
Атрибут контроля процесса
Уровень 5
Оптимизирующий процесс
AП 5.1
Атрибут изменения (верификации) процесса
AП 5.2
Атрибут возможности дальнейшего улучшения
Атрибут процесса представляет измеримую характеристику любого процесса, как
определено выше.
Шкала рейтинга - шкала в процентах, от ноля до ста, которая представляет степень
достижения атрибута.
Порядковая шкала рейтинга, определенная ниже, должна использоваться, чтобы
откалибровать уровни достижения определенной возможности атрибутов процесса.
N Не достигнутый:
0 % - 15 % - есть маленькое или нет вообще подтверждения достижения определенного
атрибута.
P Частично достигнутый:
16 % - 50 % - есть подтверждение надежного систематического метода к достижению
определенного атрибута. Некоторые аспекты достижения могут быть непредсказуемы.
L В значительной степени достигнутый:
51 % - 85 % - есть подтверждение надежного систематического метода к значительному
достижению определенного атрибута. Выполнение процесса может измениться в
некоторых областях.
F Полностью достигнутый:
86 % - 100 % - есть подтверждение полного и систематического метода к полному
достижению определенного атрибута. Никаких значительных недостатков не существуют
в пределах определенной части организации.
Каждый атрибут процесса, оцененный в любой части организации, включая самый
высокий уровень возможности, определенный в сфере оценки, должен быть согласован с
рейтингом, использующего шкалу атрибута, определенную выше. Набор рейтингов
атрибута для процесса формирует профиль для этого процесса. Выход оценки включает
набор профилей для всех оцененных процессов.
Каждый рейтинг атрибута процесса должен иметь ссылку, которая записывает имя
процесса и оцененный атрибут процесса.
Используемый идентификатор должен давать объективное подтверждение
использованию, чтобы определить рейтинг, который должен извлекаться. Рейтинги могут
представляться в любом формате, как, например, матрицы или как часть базы данных, при
условии, что представление допустит идентификацию индивидуальных рейтингов
согласно этой схемы ссылки.
Уровень возможности, достигнутый процессом, должен быть получен из рейтинга
атрибута для этого процесса, согласно модели уровня возможности процесса,
определенной в таблице 4.2. Цель этого требования состоит в том, чтобы гарантировать
единообразие значений, когда уровень возможности процесса ссылается для процесса.
Ниже приведены таблицы, содержащие итоговые списки процессов, которые включены в
эталонная модель (таблица 4.3) и соответствие процессов эталонной модели и процессов,
определенные в проекте стандарта ИСО/МЭК 12207 (таблица 4.4).
Таблица 4.2
Шкала
Атрибуты процесса
Оценка
Уровень 1
Выполнение процесса
В основном или полностью
Уровень 2
Выполнение процесса
Управление выполнением
Управление рабочим продуктом
Полностью
В основном или полностью
В основном или полностью
Уровень 3
Выполнение процесса
Управление выполнением
Управление рабочим продуктом
Определение и преобразование процесса
Ресурс процесса
Полностью
Полностью
Полностью
В основном или полностью
В основном или полностью
Уровень 4
Выполнение процесса
Управление выполнением
Управление рабочим продуктом
Определение и преобразование процесса
Ресурс процесса
Измерение процесса
Контроль процесса
Полностью
Полностью
Полностью
Полностью
Полностью
В основном или полностью
В основном или полностью
Уровень 5
Выполнение процесса
Управление выполнением
Управление рабочим продуктом
Определение и преобразование процесса
Ресурс процесса
Полностью
Полностью
Полностью
Полностью
Полностью
Измерение процесса
Контроль процесса
Изменение процесса
Возможность дальнейшего улучшения
Полностью
Полностью
В основном или полностью
В основном или полностью
Таблица 4.3.
Категория
процесса
Процесс
Номер Название Номер
Название
Начальные процессы жизненного цикла
CUS
Категория процесса поставщик - заказчик
CUS.1
Приобретение (базисный)
CUS.1.1
Подготовка приобретения (компонентный)
CUS.1.2
Выбор поставщика (компонентный)
CUS.1.3
Проверка поставщика (компонентный)
CUS.1.4
Одобрение заказчика (компонентный)
CUS.2
Поддержка (базисный)
CUS.3
Установление требований (новый)
CUS.4
Функционирование (расширенный)
CUS.4.1
Функциональное использование (расширенный
компонентный)
CUS.4.2
Поддержка пользователя (расширенный
компонентный)
ENG
Категория процесса инжиниринга
ENG.1
Разработка (базисный)
ENG.1.1
Анализ и разработка системный требований
(компонентный)
ENG.1.2
Анализ требований ПО (компонентный)
ENG.1.3
Разработка ПО (компонентный)
ENG.1.4
Конструкция ПО (компонентный)
ENG.1.5
Интеграция ПО (компонентный)
ENG.1.6
Тестирование ПО (компонентный)
ENG.1.7
Тестирование и интеграция системы
(компонентный)
ENG.2
Эксплуатация системы и ПО (базисный)
Поддерживающие процессы жизненного цикла
SUP
Категория процесса поддержки
SUP.1
Документирование (расширенный)
SUP.2
Управление конфигурацией (базисный)
SUP.3
Гарантия качества (базисный)
SUP.4
Верификация (базисный)
SUP.5
Проверка правильности (базисный)
SUP.6
Совместный обзор (базисный)
SUP.7
Проверка (базисный)
SUP.8
Решение проблем (базисный)
SUP.9
Измерение (новый)
SUP.10
Повторного использования (новый)
Организационные процессы жизненного цикла
MAN
Категория процесса управления
MAN.1
Управление (базисный)
MAN.1.1
Управление проектом (компонентный)
MAN.2
Управление качеством (новый)
MAN.3
Управление риском (новый)
ORG
Категория процесс организации
ORG.1
Организационное выравнивание (новый)
ORG.2
Процесс усовершенствования (базисный)
ORG.2.1
Создание процесса (компонентный)
ORG.2.2
Оценка процесса (компонентный)
ORG.2.3
Усовершенствование процесса (компонентный)
ORG.3
Управление человеческими ресурсами
(расширенный)
ORG.4
Инфраструктура (базисный)
4.3 Выполнение оценки
Этот подраздел определяет набор минимальных требований для выполнения оценки. Они
увеличат вероятность того, что результаты оценки процессов будут являются целевыми,
беспристрастными, непротиворечивыми, повторимыми и представительными, и определят
обстоятельства, при которых результаты оценки являются сравнимыми.
Требования формируют часть структуры оценки процесса, который:
поощряет самооценку;
принимает во внимание контекст, в котором оцененные процессы функционируют;
производит наборы рейтингов процесса (профили процесса);
через атрибуты процесса, применимые ко всем процессам, направляют возможность
процессов, чтобы достигнуть их целей;
является соответствующим всем предметным областям и размерам организации.
Чтобы увеличить непротиворечивость оценок для оцениваемых процессов, необходимо
обеспечить требования для проведения оценок. Требования помогают гарантировать, что
выход оценки непротиворечив, обеспечивает подтверждение, чтобы доказать
обоснованность оценки и проверять согласие с требованиями.
Вход должен быть определен до оценки и одобрен заказчиком оценки. Вход оценки, как
минимум, должен определять следующее.
1. Личность заказчика оценки и его отношение к оцениваемой организации.
2. Цель оценки.
3. Сферу оценки, включая:
а) процессы, которые будут исследованы внутри организации;
б) самый верхний уровень возможности, который должен исследоваться;
в) часть организации, которая разворачивает эти процессы;
г) контекст процесса, который, как минимум, включает: размер организации;
демографию организации; предметную область продукта или услуг организации;
размер, уязвимость и сложность изделий или услуг; качественные характеристики
изделий (см., например, ИСО/МЭК 9126-91 Характеристики качества ПО).
4. Ограничения целостности оценки, которые могут включать:
а) доступность ключевых ресурсов;
б) максимальное количество времени, которое должно использоваться для оценки;
в) специфические процессы, которые должны быть исключены из оценки;
г) минимальный, максимальный или специфический типовой размер или покрытие,
которое желательно для оценки;
д) собственность на выполнение оценки и любые ограничения на их использование;
е) средства управления на информацию, следующей из соглашения
конфиденциальности.
5. Подлинность модели, используемой в пределах оценки, которая должна быть
совместима с хорошей модель инжиниринга ПО, и встречающая требования,
рассмотренные в подразделе 4.2.
6. Личности экспертов-консультантов, включая компетентного эксперта-консультанта,
ответственного за оценку.
7. Личности экспертов-консультантов и персонала поддержки со специфическими
обязанностями для оценки.
8. Любая дополнительная информация, которая будет собрана в течение оценки, чтобы
поддерживать улучшение процесса или определение возможности процесса.
Любые изменения во входах оценки должны быть согласованными с заказчиком и
зарегистрироваться в записи оценки. Заказчик оценки должен проверять, что
эксперт-консультант, который должен брать ответственность за оценку и наблюдать за
ней (компетентный эксперт-консультант), имеет необходимую компетентность и умения.
Эксперт-консультант должен подтвердить требования заказчика, чтобы приступить к
оценке.
Компетентный эксперт-консультант должен гарантировать, что оценка проводится в
соответствии с определенными требованиями и принимает во внимание релевантные
руководства в других частях ИСО/МЭК 15504.
Эксперт-консультант должен гарантировать, что все другие участники оценки
проинформированы о целях, сфере и методе оценки. По завершение оценки,
компетентный эксперт-консультант должен подтвердить, что требования были
выполнены.
Оценка должна проводиться согласно зарегистрированному процессу, который является
способным удовлетворить цель оценки.
Оценка процесса, в минимуме, должен содержать следующие действия.
1. Планирование. План оценки должен быть разработан и зарегистрирован, определяя, в
минимуме: требуемые входы; действия, которые нужно выполнить для проведения
оценки; ресурсы и план, назначенный этим действиям; выбор и определенные
обязанности экспертов-консультантов и участников организации оценки; критерии для
проверки исполнения требований.
2. Сбор данных. Данные, требуемые для оценки процессов в пределах области оценки,
должны быть собраны систематическим и упорядоченным способом, применяя, в
минимуме, следующие принципы:
должны быть явно идентифицированы стратегия и методы сбора и анализа данных;
должно быть установлено соответствие между процессами организации,
определенные в сфере оценки через совместимую модель, используемую для оценки, и
процессами, определенными в эталонной модели;
каждый процесс, идентифицированный в области оценки, должен быть оценен на
основе целевого доказательства;
целевое доказательство, собранное для каждого атрибута оцененного процесса, должно
быть достаточным для удовлетворения цели оценки и ее сферы;
цель - утвержденное доказательство, основанное на показателях оценок атрибута
процесса, которые поддерживают решения эксперта-консультанта, должна быть
зарегистрирована, чтобы обеспечить основу для проверки оценок.
Эти записи должны включать:
а) методы и исследованные рабочие продукты;
б) имена личностей, обеспечивающих информацию;
в) обсуждение оценок;
3. Проверка правильности данных. Собранные данные должны быть утверждены,
гарантируя, что утвержденные данные достаточно покрывают область оценки.
4. Ранжирование процесса. Оценка должна быть назначена и утверждаться для каждого
атрибута процесса, до, и включая, самый высокий уровень возможности, определенный в
области оценки, для определенной части организации.
Набор рейтингов атрибута процесса должен быть зарегистрирован как профиль процесса
для определенной части организации.
Чтобы обеспечивать основу для повторяемости оценки, определенный набор показателей
оценки в совместимой модели должен использоваться в течение оценки, чтобы
поддерживать суждения эксперта-консультанта в рейтинге атрибутов процесса.
5. Результаты. Результаты оценки, включая, как минимум, выходы, определенные ниже
(запись оценки), должны быть зарегистрированы и сообщаться заказчику оценки.
Критерии для квалификации компетентного эксперта-консультанта должны быть
зарегистрированы.
Эксперты-консультанты, участвующие в оценке, должны иметь доступ к
соответствующим материалам, описывающим как выполнить оценки, и необходимую
компетентность, использовать любые приборы или инструментальные средства,
выбранные, чтобы поддерживать оценку.
Запись оценки, как минимум, должна содержать:
дату оценки;
вход оценки (исходные данные);
используемый метод оценки и инструментальные средства;
имена экспертов-консультантов, которые провели оценку, включая компетентного
эксперта-консультанта, ответственного за оценку;
набор профилей процесса, следующих из рейтингов (т. е. один профиль для каждого
оцененного процесса),
расположение записей объективного доказательства, обеспечивающего оценки
атрибута процесса в профилях процесса, и эксперт-консультант (-ов), ответственных
за решение оценки,
любая дополнительная информация, собранная в течение оценки, которая была
идентифицирована в начале оценки, чтобы поддерживать улучшение процесса или
определение возможности процесса,
время, потраченное экспертом-консультантом, и уровень возможности процесса или
уровни, как определено в эталонной модели.
З
апись должна содержать следующее утверждение : эта оценка провелась в
соответствии с требованиями ISO 15504. Оценка процесса разработки программного
обеспечения.
4.4. Модель оценки
Эталонная модель, определенная выше, обеспечивает общую основу для выполнения
оценок возможности процесса разработки ПО, принимая во внимание результаты,
использующие общую шкалу оценки. Эталонная модель определяет двухмерную модель
возможности процесса. Одно измерение, измерение процесса, определяет и
классифицирует процессы, связанные с ПО, в пять категорий процесса. Другое измерение,
измерение возможности, определяет серию атрибутов процесса, сгруппированных в
уровни возможности. Атрибуты процесса представляют собой измеряемые
характеристики возможности процесса.
Эталонная модель, как указывалось выше, не может быть использована как основа для
проведения надежной и последовательной оценки возможности процесса, так как
предусмотренный уровень детализации не является достаточным. Описания цели и
атрибутов процесса в эталонной модели должны поддерживаться исчерпывающим
набором показателей исполнения процесса и возможности. В этом подразделе
представляет примерная модель оценки, включая эти показатели.
Полная модель оценки основывается на эталонной модели и является совместимой с ней,
и может использоваться в качестве основы для проведения оценки возможности процесса
разработки ПО (рис. 4.7). Чтобы выполнить оценку, нужна дополнительная информация о
методах. Описание примерного метода не входит в цели данного учебного пособия.
Рис. 4.7 Отношения между эталонной моделью, моделью оценки и методами оценки.
Структура и принципы модели оценки
Основная структура модели оценка идентична эталонной модели, определенной выше.
Существует связь один к одному между категориями процессов, процессами, целями
процесса, уровнями возможностей процессов и атрибутами процессов эталонной модели и
такой же моделью оценки.
Модель оценки расширяет эталонная модель, добавляя определение и использование
показателей оценки (см. рис.4.8). Показатели оценки - объективные атрибуты или
характеристики метода или рабочего продукта, которые поддерживают решения асессора
о выполнение и возможности оцениваемого процесса.
Рис. 4.8 Связь между эталонной моделью и моделью оценки.
Базовый метод и характеристики рабочего продукта имеют отношение к измерению
процесса эталонной модели и выбираются, чтобы явно направлять достижение целей для
определенных процессов. Базовые методы и рабочие продукты являются показателями
исполнения процесса. Базовые методы являются функциональной декомпозицией
процесса и демонстрируют исполнение процессов. Они определены для поддержки
решения достижения цели процесса и результатов. Процессы также используют и выдают
(входы и выходы) рабочие продукты со специфическими характеристиками.
Метод управления имеет отношение к атрибутам процесса, определенным при измерение
возможности процесса эталонной модели. Подтверждение их эффективного исполнения
поддерживает решение о степени достижения атрибута. Метод управления со связанными
вспомогательными атрибутами - показатели возможности процесса. Методы управления
являются средствами достижения возможностей, направляемых атрибутами процесса.
Данные методы связываются со вспомогательными показателями, такими как:
характеристики исполнения метода, которые обеспечивают управление в реализации
метода;
ресурсы и характеристики инфраструктуры, которые обеспечивают механизмы для
помощи управления процессом;
процессы, связанные с измерением процесса, которые поддерживают метод управления.
Специфические методы управления связываются с каждым атрибутом процесса.
Вспомогательные атрибуты помогают устанавливать объективные подтверждения, что
методы управления, связанные с атрибутом процесса, выполняются.
Модель оценки основана на следующем принципе: возможность процесса может быть
оценена, показывая достижение атрибутов процесса. Каждый процесс при измерении
процесса имеет набор связанных базовых методов, эффективность которых обеспечивает
индикацию относительно степени достижения цели процесса. Аналогично, каждый
атрибут процесса при измерении возможности имеет набор связанных методов
управления, эффективность которых обеспечивает индикацию относительно степени
достижения предписанного атрибута в процессе.
Показатели, определенные в модели оценки - не требуемые характеристики процесса. Они
представляют доказательство, которое могло бы быть найдено в экземпляре процесса и,
следовательно, может использоваться, чтобы судить достижение возможности. Набор
показателей обеспечивает набор подробных отличий, которые могут использоваться,
чтобы оценить, способствует ли конкретный экземпляр метода к цели процесса или
достижению атрибута процесса.
Модель оценки группирует процессы при измерении процесса в пять категорий, согласно
типу деятельности, к которому они обращены. Группировки идентичны тем, что
определены в эталонной модели.
Базовый метод - деятельность управления проектом, которое направляет цель
специфического процесса. Последовательное выполнение базовых методов, связанных с
процессом, поможет достигнуть цели процесса. Последовательный набор базовых
методов связан с каждым процессом при измерении процесса.
Базовые методы описаны на абстрактном уровне, идентифицируя "что" должно быть
выполнено без того, чтобы определить "как". Они характеризуют выполнение процесса.
Выполнение только базовых методов процесса представляет только первый шаг в
формирование возможности процесса, но они представляют уникальные, функциональные
действия процесса, если даже это выполнение не систематическое. Выполнение базовых
методов может быть специальным, непредсказуемым, противоречивым, плохо
запланированным, и/или результат проявляется в продуктах низкого качества.
Выполнение процесса, однако, производит рабочие продукты, которые являются, по
крайней мере, незначительно пригодными для использования в достижении цели
процесса. В модели оценки, каждый рабочий продукт имеет определенный набор
характеристик, которые могут использоваться, чтобы оценить эффективную реализацию
процесса.
Развитие возможности процесса выражено в модели оценки в терминах атрибутов
процесса, сгруппированных в уровни возможности. Атрибуты и уровни возможности
идентичны тем, которые определены в эталонной модели.
Атрибуты процесса - характеристики, которые могут быть оценены по шкале достижения,
обеспечивая меру возможности процесса. Они применимы ко всем процессам. Каждый
атрибут процесса описывает аспект полной возможности управления и улучшения
эффективности процесса в достижении цели и содействующих бизнес - целям
организации.
Уровень возможности - набор атрибутов, которые работают вместе, чтобы обеспечить
главное расширение в возможности выполнить процесс. Каждый уровень обеспечивает
главное расширение возможности в эффективности процесса. Уровни составляют
рациональный путь развития через усовершенствование возможности любого процесса.
В пределах модели оценки, измерение потенциальных возможностей основано на наборе
из девяти атрибутов процесса эталонной модели. Атрибуты процесса использованы для
определения достижения заданных потенциальных возможностей. Каждый атрибут
измеряет конкретный аспект возможности процесса. Атрибуты эволюционируют по
четырехточечной порядковой шкале рейтингов. Поэтому они обеспечивают
проникновение в суть специфических аспектов процесса потенциальных возможностей,
требуемое для поддержки процесса совершенствования и определения потенциальных
возможностей.
Следуя определению атрибутов каждого процесса, модель оценки обеспечивает такой
набор методов управления, который, если адекватно исполненный в процессе создания
экземпляров, достигнет характеристик атрибута. Методы - действия управления родового
типа и применимы ко всем процессам. Они разрабатываются для достижения
принципиальных функций управления планирования, организации, распределения
ресурсов и управления. Имеется обычно, но не обязательно, четыре метода для каждого
атрибута.
Связанные с каждым методом управления, набор показателей предоставляет типовое
подтверждение, доказывающее степень, в которой метод управления выполняется. Эти
показатели включают характеристики выполнения метода, связанные ресурсы и
характеристики инфраструктуры, связанные процессы.
Выход из оценки процесса - набор профилей процесса, один для каждого образца каждого
процесса внутри области применения оценки. Каждый профиль процесса состоит из
набора девяти оценок атрибута для оцененного процесса. Каждая оценка атрибута
представляет экспертное суждение степени, в которой атрибут достигнут.
Эта модель оценки представляет набор показателей, чтобы формировать основу такого
набора зарегистрированного доказательства. Показатель определен как целевой атрибут
или характеристика метода или рабочего продукта, которое поддерживает решение
исполнения или возможности, осуществленного процессом. Из этой области определения,
два различных класса показателей могут быть идентифицированы: показатели
выполнения процесса и показатели возможности процесса. Внутри контекста этой модели,
эти типы показателей касаются, соответственно, базовых методов, определенных при
измерении процесса, и методов управления при измерении возможности. Классы и типы
показателей, их отношение к выходу оценки, показаны на рис. 4. 9.
Рис. 4.9 Связь между показателями и оценками атрибута процесса.
Показатели - атрибуты или характеристики, существование которых подтверждает, что
некоторые процессы выполняются и для которых возможно собрать целевое
доказательство в течение оценки. Такие подтверждения приходят или из исследования
рабочего продукта оцененных процессов, или из утверждений, сделанных исполнителями
и администраторами процессов. Существование рабочего продукта и их характеристик
обеспечивает доказательство исполнения процессов, связанных с ними. Аналогично,
подтверждение, полученное от исполнителей процесса, обеспечивает доказательство
относительно выполнения процесса и способа, которым они выполняются.
Показатели в модели включают списки предложенного подтверждения, которое асессор
мог получить, или наблюдать, в ходе оценки. Они не предназначены, чтобы быть
расцененными как обязательный набор контрольных списков, которые должны
сопровождаться, но довольны как руководство для асессора в накоплении необходимого
объективного подтверждения, чтобы поддерживать их суждения возможности.
Полученное подтверждение должно быть зарегистрировано в форме, которая ясно
идентифицирует типы показателей и классы, так, чтобы поддержка для суждений асессора
могла быть легко подтверждена или проверена.
В модели оценки, полное описание каждого процесса включает:
сфера цели процесса, принимаемая из эталонной модели;
примечания, усиливающие эту сферу, где необходимо;
набор базовых методов для процесса, представляя область определения задач и
действий, необходимых для выполнения цели процесса;
число входных и выходных рабочих продуктов, связанных с каждым процессом;
характеристики, связанные с каждым рабочим продуктом.
Для примера приведем описание по одному процессу из каждой категории.
CUS.1 Приобретение ПО
Целью процесса приобретения ПО является получение продукта и/или услуги, которая
удовлетворит потребность, выраженную клиентом. Процесс начинается с идентификации
потребности клиента и результатов с принятием продукта и/или услуги, необходимых
клиенту. В результате успешной реализации процесса:
будет разработан контракт, в котором ясно выражено ожидание, обязанности и
ответственность, как поставщика, так и клиента;
продукт и/или услуга, которые будут произведены, удовлетворят потребность
клиента;
процесс приобретения будет управляемым, чтобы выполнить установленные
ограничения (например, такие как стоимость, график и качество).
Базовые методы:
CUS.1.1 Определение потребности. Определите потребность приобретения, разработки
или усовершенствования программного продукта.
Примечание. Потребность может требоваться рядом обстоятельств, включая бизнес,
исследование, безопасность или надежность.
CUS.1.2 Определение требований. Определите требования для системы и/или
программного продукта, которые удовлетворят потребность в новом продукте и/или
услуге.
Примечание. Это определение требований может быть выполнено полностью или
частично поставщиком. См. ENG.1 и ENG.2. Также см. CUS.2. CUS.1 фокусируется на
определение требований, когда программная организация выступает в качестве клиента.
CUS.2 фокусируется на определение требований, когда программная организация
выступает в качестве поставщика. Первичное различие - одна из перспектив, в
зависимости от выполняемой роли.
CUS.1.3 Подготовка стратегии приобретения. Подготовьте стратегию приобретения
продукта.
Примечание. Посмотрите характеристики для Стратегии Приобретения (45) относительно
деталей, которые должны покрываться.
CUS.1.4 Подготовка заявки для предложений. Подготовьте заявки для предложений,
включая требования приобретения и график проекта.
CUS.1.5 Выбор поставщика программного продукта. Выберите поставщика для
приобретаемого программного продукта и/или услуги, основанных на оценке
предложений поставщика, возможности и другие показатели, которые могут быть
характерными для продукта.
CUS.1.6 Определение интерфейсов с независимыми агентам и субподрядчикам.
Определите интерфейсы клиента с независимым агентом, включаемым в проведении
проекта, и любых других сторон, типа субподрядчиков, которые будут включаться в
работу, описанную в контракте, или чья работа будет влиять на успех, и документируйте
это в контракте.
CUS.1.7 Заключение контракта. Заключите контракт с поставщиком.
CUS.1.8 Поддержка контракта. Установите и обеспечьте поддержку, требующуюся
контрагентом.
Примечание. Эта поддержка может быть, например, в форме документированных
исходных данных, обеспечение участия персонала в деятельности как, например,
подтверждение правильности требований или обеспечение возможностей таких, как,
например, доступ к оборудованию, связывающее разрабатываемое оборудование.
CUS.1.9 Приемка поставленного продукта. Установите и согласуйте критерии приемки
и средства оценки, которые должны использоваться. Выполните оценки продукта или
услуг в соответствии с согласованными критериями.
Примечание. Приемка программных продуктов проходит, обычно, на основе прохождения
согласованного комплекта тестов, но и другие критерии и методы оценки, такие, как
проверка и аудит, могут быть использованы. Приемочные оценки могут быть сделаны
пользователем, поставщиком (обычно при участие пользователя) или третьей стороной.
ENG.2 Разработка требований к ПО
Цель процесса Разработки программных требований - формулировка требований к
программному обеспечению системы. Как результат успешной реализации этого
процесса:
будут определены требования, предъявляемые к различным программным компонентам
системы и их интерфейсам, соответствующие настоящим и предполагаемым
потребностям клиента;
должны быть разработаны проанализированные, корректные и подающиеся проверке
требования к программному обеспечению;
должно быть понято влияние программных требований на операционную среду;
должна быть разработана соответствующая стратегия выпуска, определяющая
приоритет в реализации требований к системе;
программные требования должны быть проверены и откорректированы, если
необходимо;
требования к программному обеспечению должны быть переданы всем
задействованным сторонам.
Базовые методы:
ENG.2.1 Выявление требований к ПО. Определите и проанализируйте требования к
компонентам программной системы и зафиксируйте их в спецификациях.
ENG.2.2 Определение влияния операционной среды. Определите интерфейс между
требованиями к программному обеспечению и компонентами операционной среды, и то
воздействие, которое будут оказывать требования к ПО на операционную среду.
Примечание. Операционная среда включает в себя: задачи, выполняемые в ней самой;
системы пользователей данного программного продукта.
ENG.2.3 Оценка требований вместе с заказчиком (клиентом). Свяжитесь с заказчиком
и обсудите с ним требования к ПО и, при необходимости, внесите коррективы.
Примечание. Должна использоваться подходящая форма такого взаимодействия.
Исследование суждений клиента дает лучшую информацию, но является дорогим.
Испытания лучше, чем демонстрация. Бумажных спецификаций обзоров не должно быть.
См. также процесс CUS.2, Управление требованиями клиента.
ENG.2.4 Определение стратегии выпуска версии ПО. Определите приоритетность
требований к ПО и отобразите их в будущих версиях.
ENG.2.5 Изменение требований для следующей итерации. После завершения цикла,
включающего анализ требований, проектирования, кодирование и тестирования,
используете механизм обратной связи, чтобы модифицировать требования для следующей
итерации.
ENG.2.6 Связь с требованиями к ПО. Определите связывающий механизм для
распределения информации о требованиях к ПО (и изменениях в них).
SUP.3 Выполнение гарантии качества
Целью процесса Гарантия качества является обеспечение гарантии того, что рабочие
продукты и действия процесса или проекта согласуются со всеми применяемыми
стандартами, процедурами и требованиями. Результат успешной реализации процесса:
должны быть определены, спланированы и расписаны действия по гарантии качества
процессов и проекта;
должны быть определены стандарты качества, методологии, процедуры и средства
для выполнения действий по обеспечению гарантии качества;
должны быть установлены ресурсы и ответственность для выполнения действий по
обеспечению гарантии качества;
должна быть установлена и гарантироваться независимость ответственных лиц за
выполнение действий по гарантии качества;
должны быть выполнены определенные действия по гарантии качества в
соответствии с планами и графиками.
Базовые методы:
SUP.3.1 Выбор критериев качества. Определите роли, сферу и степени гарантии
качества и выберите приемлемые стандарты и процедуры.
SUP.3.2 Определение записей качества. Определите записи качества, которые будут
демонстрировать соответствие критериям качества и определять период их действия.
SUP.3.3 Гарантия качества действий инжиниринга ПО. Выполните серию действий
для обеспечения требуемого уровня уверенности, что действия инжиниринга
программного обеспечения выполняются в соответствии с планами и выбранными
стандартами и процедурами.
SUP.3.4 Гарантия качества рабочих продуктов. Выполните серии действий для
обеспечения требуемого уровня уверенности, что рабочие продукты удовлетворяют
стандартам качества.
SUP.3.5 Сообщение о результатах. Сообщите результаты вышеперечисленных действий,
в частности, отклонения, на соответствующих уровнях управления и штата.
SUP.3.6 Обработка отклонений. Направьте отклонения на соответствующий уровень
управления, передавая их на следующий более высокий уровень, до тех пор, пока они не
будут разрешены.
SUP.3.7 Обеспечение независимости ресурсов и организации по гарантии качества.
Обеспечьте квалифицированным персоналом, средствами и возможностями для
выполнения действий по гарантии качества. Создайте организационную структуру,
гарантирующую независимость персонала, занимающегося гарантией качества.
MAN.2 Управление качеством
Целью процесса управления качеством является управление качеством продукта и услуг
проекта и гарантия того, что они удовлетворяют клиента. Процесс включает установление
фокуса на управление качеством продукта и процесса, как проекта, так и
организационного уровня. В результате успешной реализации процесса:
будут установлены цели качества, основанные на требованиях качества заказчика, для
различных контрольных точек внутри жизненного цикла ПО;
будут определены и использоваться метрики, которые измеряют результаты
действий проекта в контрольных точках жизненного цикла проекта, и оценивать,
были ли цели качества достигнуты;
будут идентифицированы и интегрированы в модель жизненного цикла ПО действия,
которые помогут достигать целей качества,;
будут выполнены идентифицированные действия качества;
будут приниматься корректирующие действия, когда цели качества не достигнуты.
Базовые методы:
MAN.2.1 Установление целей качества. Установите цели качества для продукта и
процесса, основанные на требованиях качества клиента, которые могут быть оценены в
проекте.
MAN.2.2 Определение метрик качества. Определите метрики, которые измеряют
результаты действий проекта и оцените, были ли релевантные цели качества достигнуты.
MAN.2.3 Определение действий качества. Для каждой цели качества, определите
действия, которые помогут достигать этой цели качества и интегрируйте эти действия в
жизненный цикл программного обеспечения.
MAN.2.4 Выполнение действий качества. Выполните идентифицированные действия
для обеспечения качества.
MAN.2.5 Оценка качества. В определенных контрольных точках жизненного цикла
программного обеспечения проекта, примените определенную метрику качества, чтобы
оценить, были ли релевантные целик качества достигнуты.
MAN.2.6 Применение корректировочного действия. Когда определенные цели качества
не достигнуты, возьмите корректирующее или профилактическое действие.
Примечание. Корректирующее действие может включать фиксирование продукта,
сгенерированное специфическим действием проекта или заменять (изменять)
запланированный набор действий, чтобы лучше достигнуть качественных целей или оба.
Профилактическое действие может включать модификацию спецификации продукта или
области определения процесса, или оба, чтобы предотвращать повторное недостижение.
ORG.2 Определение процесса
Цель Определения процесса - сформировать библиотеку многократно используемых
определений процесса (включая стандарты, процедуры и модели), которая будет
поддерживать исполнение устойчивых и повторяющих процессов управления и
инжиниринга ПО (все процессы, включенные в это руководство). В результате успешной
реализации процесса:
будет существовать хорошо определенный и поддерживающий стандарты комплект
процессов, вместе с индикацией применимости каждого процесса;
будут определены подробные задачи, действия и связанные рабочие продукты для
каждого стандартного процесса, вместе с ожидаемыми характеристиками
выполнения;
будет существовать развернутый конкретный процесс для каждого проекта,
приспособленный из стандартного процесса в соответствии с потребностями
проекта;
будет существова
Информация о работе Стрелковое оружие