Перечень объектов, подлежащих сертификации и их характеристики

Объектами, подлежащими добровольной сертификации, являются:

- программное обеспечение средств измерений как автономное, так и встроенное;

- программное обеспечение измерительных и информационно-измерительных систем;

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

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

- описание структуры ПО (ПП) и выполняемых функций, в том числе последовательность обработки данных;

- описание функций и параметров ПО (ПП), подлежащих метрологическому контролю;

- описание реализованных в ПО (ПП) расчетных алгоритмов, а также их блок-схемы;

- описание модулей ПО (ПП);

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

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

- описание реализованной методики идентификации ПО (ПП);

- описание реализованных методов защиты ПО (ПП) и данных;

- описание интерфейсов пользователя, всех меню и диалогов;

- описание хранимых или передаваемых наборов данных;

- руководство пользователя;

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

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

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

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

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

б) требований к идентификации;

в) требований к защите измерительной и иной хранимой и передаваемой информации;

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

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

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

6. Извлечение программных требований

6.1.1. Программные требования

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

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

Требование – условие или особенность, которой должна удовлетворять система.

Требованием может быть:

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

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

– ограничение, наложенное заинтересованным лицом.

6.1.2. Функциональные и нефункциональные требования

Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

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

• Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы.

• Группа функциональных требований

- Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.

- Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).

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

• Группа нефункциональных требований (Non-Functional Requirements)

- Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д.

- Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.

- Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.

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

• Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Требования с количественной оценкой

Требования с количественной оценкой – требования, поддающиеся количественному измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием.

При этом, например, требование “система должна вести журнал подключений пользователей” может и должно детализироваться с точки зрения описания информации, которую необходимо сохранять в журнале, однако, такое требование уже не будет являться количественным требованием. А требование с формулировкой “система должна обладать интуитивно-понятным пользовательским интерфейсом” - непроверяем. В определенных случаях, по мнению автора книги, это может выглядеть просто издевкой, даже не являясь изначально таковой – все зависит от точки зрения: например, в устах “целевого” пользователя специализированного программного обеспечения – системного администратора, привыкшего работать в kshell (популярной командной оболочке Unix/Linux), объясняющего свои потребности аналитику, фиксирующему запросы пользователя и привыкшего оперировать Microsoft Office; ) Может ли такое требование быть переформулировано и/или детализировано для адекватности интерпретации? Да. Например, так – средний показатель ошибок оператора не должен превышать 2% от объема вводимой информации и 85% пользователей должны дать положительную оценку прототипу пользовательского интерфейса на этапе опытной эксплуатации.

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

Большинство требований с количественной оценкой относится к атрибутам качества.

В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту: “Система должна производить поиск документов < определенного вида> за время, не превышающее 5 секунд”. Это типичное требование с количественной оценкой, в котором определена верхняя граница диапазона времени, за которое должен быть осуществлен поиск документов. Несомненно, этот атрибут качества системы существует в контексте определенного функционального требования о возможности поиска документов по определенным критериям. И этот контекст или связь должна быть определена либо явно, в рамках иерархии требований, либо посредством трассировки, между требованиями разных видов (функционального и атрибута качества). Примечательно, что Вигерс в своей книге выделяет требования по производительности системы в отдельный вид требований, тем не менее входящих в понятие нефункциональных требований или атрибутов качества.

6.1.4. Системные требования и программные требования

Системные требования и программные требования (System Requirements and Software Requirements) – данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов < созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, что система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности. Часто в литературе по управлению требованиями встречается описание системных требований как “пользовательских требований” (user requirements), SWEBOK ограничивает применение понятия “пользовательское требование” требованиями к системе конечных пользователей/заказчиков. Системные требования по SWEBOK, в свою очередь, окружают пользовательские требования (или требования других заинтересованных лиц – stakeholders, например, регулирование полномочий) без указания идентифицируемого источника-человека.

6.1.5. Характеристики программных требований

Перечислим основные характеристики программных требований:

Недвусмысленность

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

Пример:

Треб.1: Система не должна принимать пароли более 15-ти символов.

Не совсем ясно, что система должна делать:

– Система не должна позволять пользователю вводить более чем 15 символов.

– Система должна отсекать введенную строку до 15-ти символов.

– Система не должна отображать сообщение об ошибке, если пользователь вводит более чем 15 символов.

Исправленное требование содержит пояснение:

Треб.1: Система не должна принимать пароли более 15-ти символов. Если пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.

⇐ Предыдущая 1 2 3 4 567 8 9 10 Следующая ⇒