Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Надежность и функциональная безопасность комплексов программ реального времени (для магистров)
.pdf
Проектирование общих требований к компонентам и ком-
плексам программ включает:
общие требования к проектированию сложных программных
продуктов;
анализ, выявление и освоение профессиональных проблем за-
казчика;
этапы проектирования производства сложных программных
продуктов;
особенности внешней среды системы;
распределение системных требований между аппаратными и
программными компонентами, интерфейсов с внешней средой;
учет ограниченных ресурсов для реализации требований
функциональной пригодности, времени и допустимой длительно-
сти проектирования;
общие требования и ограничения системы и комплекса про-
грамм реального времени;
три пространства функций и характеристик программного
продукта – заказчика, проектировщика, пользователя;
функциональные требования к проектированию сложных за-
казных комплексов программ;
выявление и прояснение не четких, неоднозначных требова-
ний к программному продукту;
формирование требований компонентов и модулей путем декомпо-
зиции функций комплексов программ:
унификацию архитектуры и интерфейсов модулей, компонентов
и комплексов программ;
нисходящее - восходящее проектирование модулей и
программных компонентов;
распределение и установление ответственности специалистов
за качество и сроки создания модулей и компонентов.
повторное использование модулей и компонентов в комплексах
программ:
цели и требования создания и повторного применения
программных компонентов и модулей;
подготовку возможности многократного использования
компонентов в различном операционном и внешнем окружении;
оценивание затрат на применение готовых компонентов при
проектировании комплексов программ;
изменения трудоемкости и длительности создания комплексов
программ при проектировании из готовых компонентов.
Рис. 2.1.
61
Поэтапное проектирование требований к производству спо-
собно остановить нерентабельное развитие системы и ПП и избе-
жать крупных затрат заказчикам и разработчикам. В то же время, на
базе рекомендуемых при проектировании методов, инструменталь-
ных средств и стандартов, может быть подготовлен и обеспечен, эф-
фективный жизненный цикл производства версий высококачественных программных продуктов и их компонентов. Требования заказчика при проектировании могут выражаться в форме потребностей,
пожеланий и ограничений. Сценарии применения системы должны
использоваться для анализа ее функционирования в заданной среде, с
целью выявления требований, которые формально могли быть не за-
даны заказчиком. Также следует анализировать социальное воздей-
ствие организации на пользователей, которые могут повлиять на использование системы или сдерживать процесс ее проектирования.
Стандарты и правила должны использоваться для определения осо-
бенностей внешней среды системы.
Анализ корректности сформированных требований к системе
и программному продукту включает выявление и идентификацию
противоречивых, пропущенных, неполных, неоднозначных, нелогичных или непроверяемых требований; расстановку приоритетов и раз-
решение проблем, возникающие в связи с определением требований.
Сюда же относятся требования, которые не могут быть реализованы
или которые нецелесообразно реализовывать.
Исходные данные и требования к проектированию программно-
го продукта, включая установленные законодательные и регламентирующие нормативные требования, должны быть, оформлены документально, а их выбор проанализирован поставщиком на адекватность. Спецификацию требований должен представить потреби-
тель – заказчик. Однако по взаимному согласию ее может подготовить поставщик – разработчик, в тесном сотрудничестве с потреби-
телем для предупреждений разногласий путем, уточнения определе-
ний терминов, объяснения предпосылок и обоснования требований.
Неполные, двусмысленные или противоречивые требования должны
быть предметом урегулирования с заказчиком и заинтересованными
лицами, ответственными за их предъявление.
Для конкретного комплекса программ доминирующие требова-
ния выделяются и определяются его функциональным назначением.
Программы для компьютеров как объекты проектирования, произ-
62
водства, испытаний и оценки качества характеризуются в жизненном
цикле следующими обобщенными характеристиками:
– проблемно – ориентированной областью применения, техни-
ческим и социальным назначением программного комплекса;
– конкретным классом и назначением решаемых функциональ-
ных задач с достаточно определенной областью применения квали-
фицированными пользователями;
– масштабом и сложностью комплекса программ и базы данных,
решающих единую целевую задачу системы;
– архитектурой комплекса программ и базы данных;
– необходимыми составом и требуемыми значениями характе-
ристик качества и безопасности функционирования программ и вели-
чиной допустимого ущерба – риска из-за недостаточного их качества
или ресурсов;
– составом потребителей характеристик комплекса программ,
для которых важны соответствующие атрибуты качества;
– комплектом стандартов и их содержания, которые целесооб-
разно использовать при выборе технологии и характеристик комплекса программ;
– реальными ограничениями всех видов ресурсов проекта;
– степенью связи решаемых задач с реальным масштабом вре-
мени или допустимой длительностью ожидания результатов решения
задач;
– прогнозируемыми значениями длительности эксплуатации и
перспективой создания множества версий программного продукта;
– предполагаемым тиражом производства и применения про-
граммного продукта;
– степенью необходимой документированности программного
продукта.
В соответствии с принципиальными особенностями конкретного
комплекса программ при проектировании должны выбираться номенклатура и значения показателей качества, необходимых для его эффективного применения пользователями, которые отражаются в технической документации и в спецификациях требований на конечный
программный продукт. При проектировании рекомендуется набор
критериев качества требований к комплексам программ, который
включает:
63
− корректность – отсутствуют дефекты и ошибки в формули-
ровках требований к комплексу программ;
− недвусмысленность – каждое требование должно быть одно-
значно и не допускать различного понимания и толкования специали-
стами;
− полнота – состав и содержание требований должны быть до-
статочны для производства и применения корректного комплекса
программ и компонентов;
− непротиворечивость – между разными требованиями к компо-
нентам и комплексу программ отсутствуют конфликты и противоре-
чия;
− модифицируемость – каждое требование допускает возмож-
ность его согласованного изменения и развития при производстве
комплекса программ.
Системная эффективность применения программных продуктов в стандартах ISO 9126:1-4, ISO 25000 определяется степенью
удовлетворения потребностей заинтересованных лиц – заказчиков
и/или пользователей, которые, в ряде случаев, желательно измерять
экономическими категориями: прибылью, стоимостью, трудоемко-
стью, предотвращенным ущербом, длительностью применения и т.п.
В стандартах эта эффективность отражается основной, обобщенной
характеристикой качества – функциональной пригодностью В связи
с тем, что ее абсолютную величину обычно трудно измерить непосредственно и количественно, то по ряду показателей необходима и
возможна качественная оценка свойств и достоинств при применении
программного продукта [4,14].
Улучшение каждой, нефункциональной – конструктивной ха-
рактеристики качества, требует некоторых затрат ресурсов, которые в той или иной степени должны отражаться на улучшении основной характеристике качества – на функциональной пригодности. Тре-
бования к конструктивным характеристикам имеют значение для
проекта постольку, поскольку они обеспечивают требуемое качество
реализации основного назначения и функций комплекса программ.
Поэтому для каждого проекта необходимо ранжировать характери-
стики и их атрибуты (приоритеты) и выделять, прежде всего, те тре-
бования, которые могут в наибольшей степени улучшить функцио-
нальную пригодность для конкретных целей.
64
Ограниченные ресурсы для реализации требований функцио-
нальной пригодности, могут негативно отражаться на конструктивных характеристиках: на надежности, безопасности, пропускной спо-
собности, качестве взаимодействия с внешней средой и с пользователями, качестве документации и других эксплуатационных факторах
(см. рис 2.1). Наиболее общим видом ресурсов, используемых в жизненном цикле комплексов программ, являются допустимые финансово-
экономические, бюджетные затраты. При анализе требований качества
этот показатель может применяться или как вид ресурсных ограничений,
или как оптимизируемый критерий. При этом необходимо также учитывать затраты на разработку, закупку и эксплуатацию системы обеспечения
качества, технологии и комплекса средств автоматизации разработки программ и баз данных, которые могут составлять существенную часть сово-
купной стоимости программного продукта.
Обычно заказчики и разработчики первоначально устанавливают
требования к каждой характеристике без учета относительных затрат
на их достижение, а также без детального анализа их совместного
влияния на полную функциональную пригодность у потребителей.
Это может приводить к несбалансированным значениям требова-
ний к отдельным, взаимосвязанным характеристикам качества, на которые не рационально используются ограниченные ресурсы проекта,
или к не адекватно низким их значениям.
Общие требования к сложным системам и комплексам про-
грамм реального времени для автоматизации управления и обработки
информации о динамических объектах состоят в следующем:
− для обработки потоки данных из внешней среды могут быть
независимыми, несинхронными, различными по интенсивности, содержанию, реальному времени формирования и поступления для об-
работки;
− информация в сообщениях от источников и объектов внешней
среды должна содержать реальное время, к которому относятся со-
общения, их координаты и характеристики состояния;
− реальное время решения различных функциональных задач
должно эффективно упорядочиваться в соответствии с установленной
дисциплиной диспетчеризации, определенной при производстве си-
стемы, и реальным временем приема информации из внешней среды;
− алгоритмы и программы функциональных задач системы мо-
гут различаться по длительности решения и важности для пользова-
65
телей, должны включать и использовать текущее и расчетное реаль-
ное время результатов решения и исходной информации;
− для эффективного использования ограниченных ресурсов про-
изводительности и оперативной памяти компьютеров целесообразно
применять приоритеты и прерывания исполнения программ в соот-
ветствии с выбранными дисциплинами решения различных функциональных задач;
− информация и сообщения для потребителей и внешней среды
могут выдаваться асинхронно, в соответствии с установленной дис-
циплиной и содержать значения реального время, которому соответствуют данные в сообщениях.
Требования к программному продукту при проектировании
должны детализировать и конкретизировать описания функций до
уровня, позволяющего разработчикам вести производство модулей,
компонентов и всего комплекса, которые могут быть проверены на
корректность их реализации. Функции и основные характеристики
сложных комплексов программ условно можно отразить многомер-
ными пространствами свойств и значений, контроля и обеспечения
их реализации. Особенности, соответствие и покрытие этих много-
мерных пространств, их взаимодействия при различных задачах применения упрощенно можно представить как три пространства,
функции и характеристики которых, используются и взаимодей-
ствуют в следующих целях:
− исходные, утвержденные требования к функциям и характе-
ристикам программного комплекса, согласованные с разработчиками
в виде конкретных документов, в соответствии с которыми разработчики обязаны создать и обеспечить применение программного про-
дукта пользователями или в составе системы;
− реализованные разработчиками функции и характеристики
программного комплекса, которые обычно не могут полностью и аб-
солютно точно соответствовать исходным эталонным требованиям,
достоверно не известны заказчику, разработчикам и пользователям,
и не полностью отражены документами;
− реальные функции и характеристики программного продукта,
которые практически используются пользователями и/или системой
в соответствии с эксплуатационной документацией, и могут не совпа-
дать с исходными реализованными требованиями, вследствие превышения их значений или не полного их использования.
66
Требуется удостоверять, что требования являются, с одной стороны, необходимыми и достаточными для удовлетворения при при-
менении компонента, а с другой необходимыми и достаточными
входными данными для других процессов и компонентов, в частности
для проектирования функций и архитектуры комплекса программ. Для этого при производстве в общем случае должны быть вы-
делены руководители и коллективы специалистов, которые должны
планировать, утверждать, выпускать, распространять и сопровождать
комплекты достоверных документов на программный продукт.
Они должны стимулировать разработчиков компонентов, программных комплексов и их корректировок, осуществлять непрерывное, регламентированное документирование процессов и результатов своей
деятельности, а также контролировать полноту и качество документов.
Техническое задание на проект и исходные требования к производству программного продукта целесообразно формировать при
проектировании на основе общих положений программной инженерии, и должны содержать поэтапно уточняющиеся, детализирующиеся и дополняющиеся при детальном и рабочем проектировании раз-
делы:
− общие технические требования, перечень стандартов и базо-
вых нормативных документов для выполнения проекта;
− общие требования к программному комплексу; требования к
функциям и основным характеристикам качества;
− требования к внешней среде применения комплекса программ;
− специальные требования к аппаратной и операционной плат-
формам для реализации программного комплекса;
− требования к структуре, оформлению и содержанию эксплуа-
тационной и технологической документации;
− этапы и график выполнения основных работ проекта;
− ожидаемые результаты проекта и форма их представления;
− порядок контроля исполнения проекта и приемки результатов
работы.
Выходные проектные данные для производства программного
комплекса должны быть документально оформлены и выражены в
требованиях заказчика так, чтобы их можно было проверить, и под-
твердить соответствие входным проектным требованиям. Эти данные
должны содержать критерии приемки программного продукта за-
казчиком или ссылки на них, а также идентифицировать те характе-
67
ристики, которые являются критическими для его надежного и без-
опасного функционирования и применения. Для разработчиков осо-
бенно важно формализовать требования в документах и согласовать
их с заказчиком при утверждении контракта и технического задания
на проект. Требования к характеристикам, утвержденные после предварительного проектирования, могут быть закреплены в техническом
задании как обязательные для детального проектирования и про-
изводства.
В процессе проектирования, необходимо проверять качество и
корректность требований они должны быть верифицируемыми.
Определение требований напрямую связано с процедурами проверки
и утверждения аттестации (стандарт ISO12207:2008). Определения
качества требований позволяют выявить и прояснить нечеткие,
неоднозначные требования. Такое неоднозначное требование целе-
сообразно заменить несколькими требованиями, каждое из которых
будет иметь свой собственный критерий качества. Не каждое требование может иметь четкий критерий качества, который можно ис-
пользовать для проверки того, удовлетворяет ли какое-либо реше-
ние этому требованию. Добавив разъяснения в критерий качества для
каждого требования, можно сделать их осязаемыми и понятными. Это
первый шаг по определению критериев для измерения качества реше-
ний.
Каждый этап разработки комплекса программ формирует, уточняет и реорганизует требования, чтобы сделать их как можно ближе к
назначению нового программного продукта. Каждое требование
должно иметь уникальный идентификатор, требование должно от-
ражать отдельно распознаваемую, измеряемую сущность. В проек-
тах сложных комплексов программ нужно применять способ работы с
большим числом требований и сложными связями между ними. Следует учитывать, что наряду с существованием некоторого числа тре-
бований, связанных с одним основным событием и/или сценарием ис-
пользования, любое требование может быть связано с другими собы-
тиями и/или сценариями использования.
Системная эффективность – функциональная пригодность
при проектировании комплекса программ может быть описана количественно или качественно, в виде набора полезных свойств и харак-
теристик программного продукта, их отличий от имеющихся у других
комплексов программ, а также источники возможной эффективности.
68
Она определяет назначение, основные функции и требования заказ-
чика, какие задачи должны обязательно решаться для удовлетворе-
ния пользователей, а дополнительные, конструктивные характеристи-
ки качества – как, и при каких условиях, заданные функции могут
выполняться с требуемым качеством. В результате может быть формализована цель использования и набор главных характеристик, тре-
бований заказчика и пользователей при заказе или приобретении про-
граммного продукта, а также предполагаемая его сфера назначения и
применения. Полнота и точность представления этих характеристик
является исходной для прослеживания реализации всех последующих, производных свойств и качества функциональной пригодности
комплексов программ.
Если масштаб проекта и сопутствующие требования заказ-
чика превышают реальные доступные ресурсы, в любом случае
придется ограничиваться в функциях и качестве комплекса программ.
Поэтому следует определять, что обязательно должно быть сделано
в первой или очередной версии системы и программного продукта
при имеющихся ресурсах проекта. Для этого приходится вести переговоры. Привлечение заказчика к итерационному проектированию и
управлению масштабом и функциями, повышает взаимные обязательства сторон, способствует росту взаимопонимания и доверия между
заказчиком и разработчиками.
Декомпозиция требований, функций, процессов проектирования компонентов и комплексов программ весьма сильно влияет на
возможность использования апробированного задела из предыдущих
реализованных проектов. Результаты системного анализа,
применение функциональных и информационных моделей предметной области, формализация спецификаций требований, функциональная декомпозиция программных комплексов и последо-
вательная детализация проектов позволяют применять готовые
технические решения в различных формах и сочетаниях. Для этого
необходимо проектирование функционально законченных
программных компонентов и модулей, потенциально готовых, к
многократному применению в различной внешней и операционной
среде, а также в различных сочетаниях их взаимодействия в
комплексах программ. Программные компоненты и модули для производства сложных комплексов программ могут создаваться двумя
методами:
69
− в процессе системного проектирования конкретного комплек-
са программ и его последовательной декомпозиции на функцио-
нальные задачи и далее на небольшие уникальные программные компоненты и модули, которые могут иметь произвольную архитектуру и
интерфейсы для определенного проекта;
− путем поиска, подбора и повторного использования готовых
апробированных компонентов и модулей, созданных для предшествовавших проектов, с учетом возможности их эффективного ис-
пользования в других комплексах программ за счет унифицирован-
ной архитектуры и интерфейсов.
Декомпозиция требований и процессов проектирования при
создании конкретных компонентов и программных продуктов осно-
вывается на разбиении общей цели проекта, на несколько промежуточных целей и этапов, каждый из которых также можно разделить.
Этот процесс можно повторять до тех пор, пока каждая цель не станет достаточно четкой для ее полного функционального, представ-
ления и оценивания характеристик, которую руководитель сможет определить по размеру, сложности выполнения и необходимым
ресурсам.
Декомпозиция работ обеспечивает руководителей базой для разбиения крупных проектировочных задач на достаточно обозримые,
управляемые компоненты. После того, как последние определены, их
можно использовать для распределения между специалистами с учетом их квалификации, запланированной продолжительностью выпол-
нения, датой начала и окончания работы. Декомпозицию работ также
можно использовать как исходную информацию в процессе кален-
дарного планирования проекта. При этом производится упорядочи-
вание технологических процессов для обеспечения своевременного и
скоординированного решения всего комплекса задач проектирова-
ния.
Унификация и структурирование процессов декомпозиции
комплексов программ оправданы, если они обеспечивают экономию
времени производства и/или применения продукта. Разработка унифицированной структуры компонентов особенно целесообразна для
версий программных комплексов, когда затраты могут эффективно
окупаться при проектировании множества последовательных вариан-
тов – версий продуктов. Для обеспечения эффективного проектирования и сокращения затрат целесообразно формулировать и
70
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]