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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждое требование должно иметь уникальный идентификатор.

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

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

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

Лекция 1.4. Требования к повторному использованию готовых компон.

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

ИСПОЛЬЗОВАНИЮ ГОТОВЫХ КОМПОНЕНТОВ

ПРИ ПРОИЗВОДСТВЕ ПРОГРАММНЫХ

КОМПЛЕКСОВ

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

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

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

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

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

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

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

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

проектные спецификации требований на этапе разработки комплекса программ;

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

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

Требования повторного использования текстов и тестов компонентов и комплексов программ охватывают (рис. 1.6):

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

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

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

Для этого следует создавать методологию и технологию, а также применять стандарты, поддерживающие требования и разработку повторно используемых и/или переносимых (мобильных) программ и данных (см. стандарт ISO 14764). Основные особенности требований к компонентам и комплексам программ для повторного использования в системах определяют две группы задач:

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

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

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

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

затраты на процессы переноса программ и данных на иные платформы;

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

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

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

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

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

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

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

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

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

программных компонентов;

- применение стандартов интерфейсов Открытых систем при производстве компонентов для повторного использования в программных комплексах:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ реализации самого процесса переноса и интеграции компонентов и/или программного продукта с операционной и внешней средой на новой аппаратной платформе или в существующей среде;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для успешного проектирования и разработки комплексов с повторным использованием компонентов должны выполняться следующие основные условия:

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

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

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

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

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

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

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

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

Формирование повторно используемых компонентов при производстве комплексов программ может осуществляться использованием стандартов и руководств, обязательных для оформления и производства основной массы программных компонентов (80 90%) с возможностью их применения как повторяющихся в определенном семействе комплексов программ, однако допускающем однократное применение (10 20%) уникальных компонентов с произвольным оформлением. Особенно полное тестирование и оформление документации целесообразно проводить для тех компонентов, которые в перспективе будут использоваться многократно различными специалистами и в разных проектах. При анализе характеристик производства конкретных комплексов трудно предвидеть кратность повторного использования определенных компонентов в будущих проектах.

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

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

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

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

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

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

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

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

Производству комплексов программ с ПИК присущ ряд недостатков и проблем, которые препятствуют запланированному сокращению расходов на разработку комплекса:

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

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

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

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

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

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

При анализе экономических характеристик и рентабельности производства комплексов программ на базе готовых ПИК и/или путем их переноса с другой аппаратной и операционной платформы необходимо учитывать:

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

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

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

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

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

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

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

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

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

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

Оценка изменения полной трудоемкости производства программного продукта за счет повторного использования компонентов зависит oт доли готовых ПИК из полного состава программных компонентов в комплексе. Эти оценки могут быть проведены для простейшего случая, когда применяются все 100% готовых ПИК при некоторых частных предположениях о значениях затрат на последующих этапах производства. Предельный выигрыш в трудоемкости производства комплекса, собираемого из полного набора готовых ПИК, когда отсутствует необходимость разработки дополнительных программных компонентов, можно оценить на основе распределения затрат по этапам разработки следующим образом. Трудоемкость сокращается только за счет исключения этапов программирования и автономного тестирования новых программных компонентов и модулей в процессе производства. Трудоемкость этих этапов для программных комплексов реального времени (СРВ) составляет около 50% от полной трудоемкости при отсутствии ПИК. Таким образом, суммарная трудоемкость в данном варианте уменьшается для этого класса комплексов программ соответственно почти в 2 раза.

В процессе совершенствования «сборочного» программирования с применением ПИК возможно некоторое дополнительное снижение затрат при детальном проектировании и комплексной отладке.

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

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

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

программирования, соответственно, повысится.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

стандартизация аппаратных и операционных платформ;

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

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

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

Технология Открытых систем для повторного использования компонентов и переноса комплексов программ на иные платформы наиболее сильно отражается на сокращении затрат ресурсов при создании крупных «коммерческих» административных систем обработки информации. При этом возможно снижение трудоемкости в 10 15 раз, длительности разработки в 5 8 раз и числа необходимых специалистов почти вдвое относительно значений при полной разработке без применения современной технологии переноса и ПИК.

Эффективность переноса программных продуктов систем реального времени значительно ниже, чем в предыдущем случае, вследствие высокой доли затрат на перепрограммирование некоторых компонентов и интерфейсов, а также на постановку и освоение технологии на новой платформе. Для этого класса комплексов программ при переносе трудоемкость может уменьшаться в 4 5 раз, длительность в 2 3 раза, а необходимое число специалистов почти в два раза относительно полной разработки «с нуля» без применения ПИК.

Рядом зарубежных организаций и промышленных фирм под руководством IEEE с 1990 года ведется активная разработка и модернизация последовательных версий стандартов интерфейсов Открытых систем POSIX (Portable operating system interfaces). В результате подготовлена группа международных стандартов из четырех крупных частей ISO 9945:1-4:2003 (IEEE 1003.1 – 2003). Цель документов – стандартизация обеспечения переносимости программных компонентов на уровне исходных текстов. В них определены основные интерфейсы операционных систем и окружения, интерфейсы командного интерпретатора, а также программы общих утилит. Три отдельных крупных тома включают: базовые определения; системные интерфейсы; команды управления и сервисные программы (утилиты).

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

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

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

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

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

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

ТРЕБОВАНИЯ К ДОПУСТИМЫМ

РИСКАМ И К ДОКУМЕНТИРОВАНИЮ

ТРЕБОВАНИЙ К КОМПЛЕКСАМ ПРОГРАММ

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

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

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

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ Требования к допустимым рискам и документам требований - риски при формировании требований к характеристикам компонентов и сложных программных комплексов:

риски оценки масштабов комплексов программ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На этапе концепции проекта ошибки оценки размера уменьшаются приблизительно до 40%. Это вполне объяснимо, поскольку еще не уточнены структура и многие детали проекта. Эти вопросы могут быть разрешены во время разработки структуры и спецификаций требований к комплексу программ, и тогда можно оценить его размер с точностью до 15 – 20%.

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

Если при оценке масштаба проекта его величина в договоре определена недостаточной – заниженной, то основной ущерб – риски достаются разработчикам. Они вынуждены принимать жесткие меры для выполнения плановых сроков, выделенного бюджета работ при относительно малом числе специалистов, что угрожает рисками срыва сроков и нарушения стоимости проекта. Недооценка размера комплекса программ и ресурсов для его реализации может резко увеличивать число дефектов в программах. Кроме того, ограниченные ресурсы для реализации в полном объеме функциональной пригодЛекция 1.5. Требования к допустимым рискам и к документированию… ности, могут отражаться на ее качестве и удобстве применения, а также на конструктивных характеристиках: на безопасности, надежности, качестве взаимодействия с внешней средой и с пользователями, качестве документации и других эксплуатационных факторах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документирование требований к программным Общие требования к документации сложных комплексов программ и компонентов определены в стандарте ISO 9126 в разделе практичность. Требования к практичности комплекса, функциям, характеристикам и документам, включают их понятность и простоту использования, зависят от его назначения и функций. Они могут формализоваться заказчиками набором свойств, необходимых для обеспечения удобной и комфортной эксплуатации программного комплекса достаточно квалифицированными пользователями. Для обеспечения полноценного изучения процессов применения комплекса специалистами Лекция 1.5. Требования к допустимым рискам и к документированию… необходима эксплуатационная и технологическая документация, требования к которой должны устанавливаться заказчиком и входить в состав основных требований к программному комплексу. Ее объем существенно зависит от назначения и функций продукта и может быть задан на основе анализа прецедентов подобных успешных проектов. Для некоторых программных комплексов, подлежащих широкому тиражированию, могут быть желательны адекватные по содержанию электронные учебники, требования к объему и функциям которых также целесообразно оценивать по прецедентам. Следует учитывать, что малый объем эксплуатационной документации может снизить качество и полноту использования функций сложного комплекса программ, а очень большой объем – также может ухудшить эксплуатацию из-за трудности выделения из множества второстепенных деталей и освоения наиболее существенных свойств и особенностей применения комплекса.

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

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

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

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

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

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

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

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

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

полное наименование проекта программного комплекса;

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

основание для выполнения и финансирования проекта;

организация заказчик проекта;

предприятие головной исполнитель и соисполнители проекта;

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

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

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

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

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

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

этапы и график выполнения основных работ проекта;

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

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

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

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

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

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

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

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

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

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