«В.В. Липаев ТЕСТИРОВАНИЕ КОМПОНЕНТОВ И КОМПЛЕКСОВ ПРОГРАММ УЧЕБНИК СИНТЕГ® Москва - 2010 УДК 004.41(075.8) ББК 32.973.26-018я73 Л61 Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. – М.: СИНТЕГ, ...»

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

В.В. Липаев. Тестирование компонентов и комплексов программ Эталоны и требования при проектировании и производстве комплексов и компонентов программ должны включать:

- системные основы разработки требований к сложному комплексу программ:

функции, задачи и методы создания сложных систем;

процесс определения и формирования требований заказчика к системам;

определения особенностей внешней среды систем;

процессы проектирования архитектуры систем;

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

- формализацию эталонов требований и характеристик к комплексу программ:

эталонный – базовый масштаб проекта комплекса программ;

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

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

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

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

- формирование требований компонентов и модулей путем декомпозиции функций комплексов программ:

функциональную декомпозицию комплексов программ;

требования структурирования архитектуры комплексов, компонентов и модулей программ;

унификацию архитектуры и интерфейсов модулей, компонентов и комплексов программ;

общие свойства взаимодействия компонентов иерархических систем;

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

распределение и установление ответственности специалистов за качество и сроки создания модулей и компонентов.

Лекция 1.2. Эталоны и требования при проектировании и производстве… В соответствии с принятой политикой предприятия и/или проекта для определения требований к системе должны осуществляться следующие базовые действия:

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

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

установление масштаба и требуемых ресурсов для реализации системы;

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

определение взаимодействия между пользователями и системой;

анализ полноты и корректности множества установленных требований к системе;

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

разрешение проблем и конфликтов, возникающих в связи с определением требований к системе;

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

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

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

архитектуры и ресурсов аппаратуры вычислительной системы;

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

нормальных, необычных и чрезвычайных ситуаций функционирования системы;

набора, обучения и развития операторов и пользователей;

физических, умственных и научных способностей пользователей.

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

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

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

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

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

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

основа для верификации комплекса системных требований.

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

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

устанавливаться порядок, в соответствии с которым выполняется проектирование архитектуры;

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

определяться требования к интерфейсам компонентов и с внешней средой при проектировании архитектуры системы;

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

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

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

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

ограниченные возможности человека;

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

интеграция человеческих возможностей в систему и ее функционирование.

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

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

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

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

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

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

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

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

архитектурой комплекса программ и базы данных;

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ предполагаемым тиражом производства и применения комплекса программ;

степенью необходимой документированности программного продукта.

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

требования к входной информации:

источники информации и их идентификаторы;

перечень и описание входных данных (идентификаторы, формы представления, регламент, сроки и частота поступления);

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

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

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

общие требования к структуре, составу компонентов и интерфейсам с внешней средой.

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

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

проекта следующими характеристиками (см. рис. 1.4):

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

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

временем, которое может быть выделено на создание комплекса программ.

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

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

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

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

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

Лекция 1.2. Эталоны и требования при проектировании и производстве… После того как базовый, эталонный уровень масштаба согласован и задан, он представляет собой основу, вокруг которой концентрируется множество разнообразных видов деятельности проектирования. Функции базового уровня могут использоваться для того, чтобы реалистически оценивать прогресс в развитии проекта. Исходя из достигнутого соглашения по отношению к базовому уровню, можно манипулировать ресурсами. Базовые функции нужно разрабатывать наиболее детально, тем самым подготавливая их к разработке кода. Полезно применять трассировку потребностей пользователя к функциям эталонного уровня требований. Трассировку можно затем продолжить от функций к дополнительным спецификациям и реализации компонентов.

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

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

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

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

Функции в документе – концепции представляют собой описания желательного и полезного поведения комплекса программ на языке заказчика и пользователей. Если ресурсы фиксированы и график изменить нельзя, команда проекта должна привлечь заказчика к процессу принятия решения о приоритете новой функции по отношению к другим функциям, определенным для реализации в данной версии. Если новая функция является критической, она должна быть включена в реализацию. Заказчик совместно с командой проекта должен определить, какие функции следует исключить из реализации или, по крайней мере, как понизить их приоритеты с соответствующим уменьшением ожиданий. Но если функция является важной, а не критической, команда может исходить из того, что в проВ.В. Липаев. Тестирование компонентов и комплексов программ цессе разработки будет ясно, можно ли данную функцию реализовать в версии.

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

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

экономические финансовые или бюджетные ограничения;

себестоимость и ценообразование; проблемы лицензирования;

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

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

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

Лекция 1.2. Эталоны и требования при проектировании и производстве… эксплуатационные ограничения информационной среды;

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

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

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

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

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

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

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

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

определять функциональные границы компонента или комплекса в терминах его поведения и предусмотренных свойств внешней среды;

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

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

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

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

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

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

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

Программные компоненты и модули для производства сложных комплексов программ могут создаваться двумя методами:

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

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

Декомпозиция функций комплекса программ и выявление особенностей при создании, программировании и тестировании его конкретных компонентов основывается на разбиении общей цели и функций проекта на несколько промежуточных целей и этапов, каждый из которых также можно разделить. Этот процесс можно повторять до тех пор, пока каждая цель и функция не станет достаточно мелкой для ее полного представления и разработки в виде программного модуля или компонента. Разбиение общей цели проекта декомпозиция производственных работ может начинаться с построения символического дерева, корень которого помечен основной целью и функцией проекта. Каждый узел такого дерева можно разЛекция 1.2. Эталоны и требования при проектировании и производстве… бить на более мелкие производственные компоненты. Такую декомпозицию можно повторять до тех пор, пока каждый компонент не будет представлять часть работы, которую руководитель сможет оценить по размеру, сложности выполнения и необходимым ресурсам.

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

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

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

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

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

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

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

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

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

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

стандартизированную структуру (архитектуру) целостного построения комплекса программ определенного класса;

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

Лекция 1.2. Эталоны и требования при проектировании и производстве… стандартизированную структуру баз данных, обрабатываемых программами;

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

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

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

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

Структурное проектирование программных комплексов должно быть основано на модульном принципе. Многоуровневое, иерархическое построение сложных программных комплексов позволяет ограничивать и локализовать на каждом из уровней сложности соответствующие ему компоненты. Нижнему иерархическому уровню представления программ соответствуют программные и информационные модули (модули данных). Эти компоненты (например, 10 100 модулей) объединяются в группы на среднем уровне компонентов программ определенного функционального назначения с автономной целевой задачей. Несколько групп функциональных программ образует целостный функциональный комплекс программ высокого уровня определенной системы. В сложных случаях возможно создание программного продукта из нескольких взаимодействующих функциональных комплексов программ высокого уровня. Всем иерархическим системам (в частности, программным комплексам) присущ ряд свойств и требований, важнейшими из которых являются:

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

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

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

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

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

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

При организации структуры сложного комплекса программ, создаваемого большим коллективом специалистов, естественно возникает проблема оценки и упорядочивания целесообразных размеров модулей и компонентов на разных иерархических уровнях. Рациональные размеры программных модулей (ПМ) могут быть ограничены удобством и обозримостью разработки текстов программ и их тестирования отдельными специалистами. Хотя у некоторых программистов «виртуозов» есть тенденция писать монолитные модули размером во многие сотни строк, однако при этом возникают трудности тестирования и обеспечения высокой корректности таких программ. Экспериментально установлено, что во многих программах управления и обработки информации – линейные участки программ между предикатами – узлами с ветвлением в среднем составляют около 5 – 10 строк. Поэтому число маршрутов исполнения программ и соответствующее число тестов, необходимых для их проверки, возрастает не пропорционально числу строк в программе, а значительно быстрее (почти квадратично, см. лекцию 2.1). Уже при ста строках в программе (10 – 20 предикатов – узлов ветвления) для ее тестирования может потребоваться более 100 тестов. Таким образом, при разработке ПМ целесообразно учитывать рациональное ограничение размеров модулей на уровне трехсот строк текста, что соответствует приблизительно тридцати альтернативам в таких программах.

При этом для полного покрытия таких ПМ тестами необходимо задавать до 1000 условий в тестах, что обычно достаточно трудно или невозможно реализовать практически в ограниченное время. В среднем полное тестирование программ с 30-ю вершинами ветвления производится тестами с суммарной сложностью около 300 – 500 узлов – предикатов.

Программные компоненты высокой сложности целесообразно делить на более простые и легче тестируемые модули, что во многих В.В. Липаев. Тестирование компонентов и комплексов программ случаях делается программистами интуитивно. Анализ числа тестов для большой реальной выборки программных модулей в комплексе программ, создаваемом коллективом специалистов, показал, что основная часть модулей содержала около 200 строк (до 20 – 30 узлов ветвления). Это обычно устанавливалось средними специалистами вследствие психологической сложности разработки и тестирования более крупных модулей. Поэтому в ряде предприятий при разработке ПМ был рекомендован рациональный размер программ модулей в пределах 100 – 300 строк текста, для полного тестирования которых достаточно использовать 10 – 50 тестов с суммарным числом условий ветвления до 100. При превышении рекомендуемых размеров ПМ их трудно протестировать полностью и целесообразно делить программистам на более мелкие компоненты – модули, доступные для практически полного покрытия тестами, размеры которых регламентировать инструкциями проекта.

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

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

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

лекцию 2.7).

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

В.В. Липаев. Тестирование компонентов и комплексов программ

ТРЕБОВАНИЯ К ФУНКЦИЯМ И

ХАРАКТЕРИСТИКАМ КАЧЕСТВА

КОМПЛЕКСОВ ПРОГРАММ

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

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

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

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

специалистов сопровождающих и модифицирующих комплекс программ, которые отдают приоритет характеристикам, поддерживающим сопровождение и конфигурационное управление версиями комплекса и его компонентов;

Лекция 1.3. Требования к функциям и характеристикам качества… Требования к функциям и характеристикам качества - требований заинтересованных лиц к функциям и характеристикам комплексов программ;

- функциональные требования к сложному комплексу программ:

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

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

требования к архитектуре и качеству программного комплекса в составе системы;

ограничения ресурсов проектирования, производства и применения программного комплекса;

- общие требования к качеству функционирования программных комплексов:

функциональная пригодность и конструктивные характеристики комплексов программ;

внутреннее качество проектирования и производства и внешнее качество функционирования и применения;

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

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

- требования к эффективности использования ресурсов ЭВМ программным комплексом в реальном времени;

- проверку корректности функциональных требований к комплексам программ.

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

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

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

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

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

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

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

Лекция 1.3. Требования к функциям и характеристикам качества… определить, где приблизительно находятся область и границы возможных решений проблем;

понять ограничения, которые будут наложены на проект, команду и решения проблем.

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

интервьюирования и анкетирования создание структурированного интервью возможных требований;

проведение интервью с несколькими пользователями и/или заинтересованными лицами;

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

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

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

по возможности выявление или создание временных прототипов на основе первичных требований.

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

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

функциональную пригодность (функциональность) конкретного проекта программного комплекса;

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

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

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

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

Так, например, при проектировании:

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

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

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

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

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

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

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

Функциональные требования – определяют поведение программного комплекса, который должен быть создан разработчиками для предоставления возможности выполнения заказчиком и/или пользователями своих обязанностей в контексте пользовательских требований. Выбор требований к характеристикам при проектировании программных комплексов начинается с определения исходных Лекция 1.3. Требования к функциям и характеристикам качества… данных. Для корректного выбора и установления требований к характеристикам качества, прежде всего, необходимо определить основные особенности программной системы. На основе этих данных должен формироваться общий набор требуемых характеристик, свойств, их мер и значений качества для определенных потребителей в жизненном цикле программного комплекса:

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

общие требования к функциям и характеристикам задач программного комплекса;

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

периодичность и продолжительность решения комплекса задач;

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

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

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

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

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

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

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

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

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

Формализация требований к качеству программных продуктов могут проводиться с двух позиций: с позиции положительной обеспечения эффективности и непосредственной адекватности их характеристик качества – назначению, целям создания и применения программного продукта, а также с негативной позиции возможного при этом ущерба – допустимого риска от дефектов и недостатков качества при применении комплекса программ или системы. Характеристики качества и риски объектов и процессов обычно тесно связаны, на них влияют подобные внутренние и внешние факторы, которые с разных сторон отражаются на свойствах систем или комплексов программ. Требуемые и реальные характеристики качества влияют на риски, а остающиеся риски влияют на характеристики качества программного продукта. Повышению требований к характеристикам качества проекта обычно сопутствует снижение его рисков и наоборот, сокращение рисков способствует улучшению характеристик качества и повышению функциональной пригодности. Их сбалансированное взаимовлияние должно обеспечивать требуемую функциональную пригодность программного продукта. Методы и системы управления качеством близки к методам анализа и управления рисками проектов комплексов программ, они должны их дополнять и совместно способствовать совершенствованию функциональной пригодности программных продуктов и систем на их основе.

Системная эффективность целевого применения программных продуктов в стандарте ISO 9126 определяется степенью удовлетворения потребностей определенных лиц – заказчиков и/или пользователей, которые, в ряде случаев, желательно измерять экономическими категориями: прибылью, стоимостью, трудоемкостью, предотвращенным ущербом, длительностью применения и т.п. В стандартах эта эффективность отражается основной, обобщенной характеристикой качества – функциональная пригодность. В связи с тем, что ее абсолютную величину обычно трудно измерить непосредственно и количественно, то по ряду показателей необходима и возможна качеВ.В. Липаев. Тестирование компонентов и комплексов программ ственная оценка свойств и достоинств при применении программного продукта.

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

Стандарты описывают метрики качества комплексов программ на основе их внутренних атрибутов и внешнего поведения системы.

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

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

внешнее качество, заданное требованиями заказчика;

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

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

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

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

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

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

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

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

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

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

Общие требования к системам и комплексам программ реального времени для автоматизации управления и обработки информации о динамических объектах состоят в следующем:

в процессах управления решением задач и вычислениями в ЭВМ должно использоваться единое глобальное реальное время систем управления и обработки информации динамических объектов, а также внешней среды;

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

информация в сообщениях от источников и объектов внешней среды должна содержать реальное время, к которому относятся сообщения, их координаты и характеристики состояния;

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

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

для эффективного использования ограниченных ресурсов производительности и оперативной памяти ЭВМ целесообразно применять приоритеты и прерывания исполнения программ в соответствии с выбранными дисциплинами решения различных функциональных задач;

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

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

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

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

Непредсказуемость вида, места и времени проявления дефектов в процессе эксплуатации приводит к необходимости создания специальных, дополнительных систем оперативной защиты от непредумышленных, случайных искажений вычислительного процесса, программ и данных. Системы оперативной защиты предназначены для выявления и блокирования распространения негативных последствий проявления дефектов и уменьшения их влияния на надежность функционирования комплекса программ до устранения их первичных источников. Для этого в комплекс программ должна вводиться временная, программная и информационная избыточность, осуществляющая оперативное обнаружение дефектов функционирования, их идентиЛекция 1.3. Требования к функциям и характеристикам качества… фикацию и автоматическое восстановление (рестарт) нормального функционирования. Эффективность такой защиты зависит от используемых методов, координации их применения и выделяемых вычислительных ресурсов на их реализацию.

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

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

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

Основным требованием к процессу восстановления является длительность восстановления и ее вероятностные характеристики.

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

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

Непредусмотренные при проектировании ситуации и ошибки функционирования программ и данных могут быть потенциальными источниками катастроф при применении таких программных комплексов, влияющими на безопасность их функционирования и применения. Наиболее полно функциональная безопасность комплексов программ характеризуется величиной ущерба, возможного при проявлении дестабилизирующих факторов и реализации конкретных угроз – рисков, а также средним временем между проявлениями непредумышленных угроз, нарушающих надежность и безопасность. Однако описать и измерить в общем виде возможный ущерб при нарушении безопасности для критических комплексах программ разных классов практически невозможно. Поэтому реализации угроз целесообразно характеризовать интервалами времени между их проявлениями, нарушающими безопасность применения программ, или наработкой на отказы, отражающиеся на безопасности. Это сближает понятия и требования безопасности с показателями надежности комплексов программ. Различие состоит в том, что в показателях надежности учитываются все реализации отказов, а в характеристиках функциональной безопасности следует регистрировать только те случайные катастрофические отказы, которые Лекция 1.3. Требования к функциям и характеристикам качества… отразились на безопасности. Статистически таких отказов может быть в несколько раз меньше, чем учитываемых в значениях надежности. Однако методы, влияющие факторы и реальные значения показателей надежности, могут служить ориентирами при оценке функциональной безопасности критических программных комплексов.

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

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

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

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

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

Степень использования ограниченной производительности ЭВМ в некоторых пределах не влияет на качество решения функциональных задач комплексом программ. При излишне высокой интенсивности поступления исходных данных может нарушаться временной баланс между длительностью решения полной совокупности задач комплексом программ в реальном времени, и производительностью ЭВМ при решении этих задач. Для формирования требований к программному продукту при подготовке технического задания и спецификаций следует согласовывать с заказчиком динамическую модель и характеристики внешней среды, в которой будет применяться комплекс программ, а также динамику приема и передачи данных пользователям или системе. Оценивание величины производительности рекомендуется для определения: загрузки операторов-пользователей, пропускной способности по числу задач в единицу времени, временной шкалы событий обработки заданий и данных в системе. Эти реЛекция 1.3. Требования к функциям и характеристикам качества… зультаты предлагается сравнивать с требованиями заказчика и пользователей для оценивания рабочих нагрузок и достаточности производительности программного комплекса в конкретной системе и внешней среде.

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

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

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

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

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

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

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

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

В стандарте IEEE 830 рекомендуется набор критериев качества формулировки требований к комплексам программ, который включает:

корректность – отсутствуют дефекты и ошибки в формулировках требований к комплексу программ;

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

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

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

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

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