Процессы разработки требований к характеристикам сложных программных средств

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

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

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

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

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

Разработку и утверждение требований к характеристикам и атрибутам качества без учета рисков, целесообразно проводить итерационно на этапах системного и детального проектирования ПС. Полная и однократная формализация требований к характеристикам качества в начале жизненного цикла сложного ПС обычно невозможна, прежде всего, из-за разных представлений заказчика и разработчиков о деталях его назначения, функций и возможностей реализации при доступных ресурсах. Чем крупнее и сложней проект ПС и соответственно выше его стоимость, тем тщательнее следует разрабатывать требования к его характеристикам качества и распределять ресурсы на их реализацию (см. лекцию 12). Поэтому при средней и относительно невысокой сложности ПС, во многих случаях, можно удовлетвориться подготовкой требований к качеству с подробностью анализа, соответствующей системному проектированию. Для крупномасштабных и особо сложных проектов необходим более детальный анализ факторов при разработке требований и их оптимизация по критерию качество/затраты. Поэтому на этапах проектирования последовательно должны определяться требования:

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

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

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

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

Выбор требований к характеристикам и атрибутам качества при проектировании программных средствначинается с определения исходных данных. Для корректного выбора и установления требований к характеристикам качества, прежде всего, необходимо определить особенности проекта:

- класс, назначение и основные функции создаваемого ПС;

- комплект стандартов и их содержание, которые целесообразно использовать при выборе характеристик качества ПС;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- спецификация структурного проектирования;

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

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

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

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

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

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

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

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