10649

Разработка требований к программным средствам

Реферат

Информатика, кибернетика и программирование

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

Русский

2013-03-30

196 KB

142 чел.

Тема: Разработка требований к программным средствам

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

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

3. Структура основных документов, отражающих требования к программным средствам

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

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

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

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

- неполные, некорректные требования,

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

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

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

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

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

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

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

  1.  достигнуть соглашения между заказчиком и разработчиком по определению проблемы, целей и задач проекта;
  2.  выделить основные причины — проблемы, являющиеся ее источниками и стоящие за основной проблемой проекта системы и ПС;
  3.  выявить заинтересованных лиц и пользователей, чьи коллективное мнение и оценка в конечном итоге определяют успех или неудачу проекта;
  4.  определить, где приблизительно находятся область и границы возможных решений проблем;
  5.   понять ограничения, которые будут наложены на проект, команду и решения проблем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С помощью трассировки можно удостовериться в том, что:

— все элементы требований проекта учтены;

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

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

Методы проверки корректности требований призваны гарантировать, что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функциональные возможности

Надежность

Эффективность

Практичность

Сопровож-даемость

Мобильность

Заказчики

Высокая

Высокая

Высокая

Высокая

Средняя

Средняя

Пользователи

Высокая

Высокая

Высокая

Высокая

Низкая

Низкая

Разработчики

Высокая

Высокая

Средняя

Средняя

Средняя

Средняя

Сопровождающие

Средняя

Средняя

Средняя

Высокая

Высокая

Низкая

Специалисты по переносу

Высокая

Средняя

Высокая

Средняя

Низкая

Высокая

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Структура основных документов, отражающих требования к программным средствам

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

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

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

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

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

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

— общие требования к характеристикам комплекса задач ПС:

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

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

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

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

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

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

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

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

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

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

- потребители и назначение выходной информации;

- перечень и описание выходных сообщений;

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

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

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

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

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

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

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

ориентировочный план реализации выбранного варианта требований концепции ПС;

общие требования к составу и содержанию документации проекта

ПС;

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

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

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

Спецификация требований к системе и к комплексу программ на этапе детального проектирования:

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

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

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

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

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

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

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

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

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

- к режимам работы;

- к производительности системы;

- к внешнему и пользовательскому интерфейсу системы;

- к внутреннему интерфейсу компонентов и к внутренним данным системы;

- по возможности адаптации ПС к внешней среде;

- по обеспечению безопасности системы, ПС и внешней среды;

- по обеспечению защиты, безопасности и секретности данных;

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

- по обучению и уровню квалификации персонала;

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

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


 

А также другие работы, которые могут Вас заинтересовать

27556. Юридическая ответственность государства 30.5 KB
  Государство как субъект ответственности. Всякий раз когда государство становится участником какоголибо правоотношения оно может быть привлечено к ответственности за нарушение прав и охраняемых законом интересов другого участника этих отношений и наоборот. Это общее правило касающееся юридической ответственности. Однако говоря о государстве как субъекте ответственности нужно вести речь об ином об особых случаях внедоговорной ответственности государства за вред причиненный в определенных ситуациях.
27557. Юридическая техника. Понятие и основные приемы 31 KB
  Способы закрепления приёмов ЮТ: 1 НПА; 2 правовые обычаи; 3 научнометодические разработки. Юридическая технология – это боле широкое понятие – это основанная на определенных принципах планах прогнозах протекающих в определенно установленных процессуальных формах деятельность по созданию НПА и иных актов в ходе которой используются средства и способы ЮТ. 2 юридические способы – пути достижения намеченных целей с помощью конкретных юр. способы структуризации; способы логического изложения; способы языкового изложения; способы...
27558. Юридическая типология: основные правовые системы современности 35.5 KB
  Юридическая типология права это его специфическая классификация. Основополагающим объектом юридической типологии выступает категория правовая система тесно связанная с такими исходными концептуальными понятиями как правовая карта мира исторический тип права семья правовых систем национальная правовая система. При этом понятие правовая система не синоним понятия система права так как последнее понятие институционное раскрывающее взаимосвязь соотношение и строение отраслей права что предопределяется факторами как...
27559. Юридические факты 30.5 KB
  Юридические факты – конкретные жизненные обстоятельства события действия вызывающие в соответствии с нормами права наступление определенных правовых последствий – возникновение изменение или прекращение правовых отношений. Юридические факты имеют ряд признаков: по своему содержанию это реальные жизненные обстоятельства явления; данные жизненные обстоятельства предусмотрены нормами права; они вызывают наступление определенных юридических последствий; юридический факт несет в себе информацию о состоянии общественных отношений; ...
27560. Позитивный и ретроспективный аспект юридической ответственности 27.5 KB
  Юридическая ответственность – возникшее в результате лично совершенного правонарушения и предусмотренное юридической нормой политикоправовое состояние когда компетентный орган должностное лицо или гражданин на основе закона или в специальной форме требует от правонарушителя отчет в совершенном деянии возлагает на него определенную меру лишений а правонарушитель претерпевает неблагоприятные последствия нарушения юридической нормы. 1 Положительная позитивная ответственность – одна из характеристик правомерного поведения. Все несут...
27561. Политика и право: назначение и соотношение 28 KB
  В этой связи теория государства и права носит политический характер. Право воздействует на политику по нескольким направлениям: 1 посредством публичной власти закрепляются политический строй общества механизм функционирования политической системы политические свободы граждан 2 в результате воздействия права на политику все виды политической деятельности осуществляются как права субъектов а не как проявление их силы авторитета иных качеств 3 право придает легитимность политическим решениям и органам государственной власти 4 право...
27562. Субъекты права в России. Правосубъектность 29 KB
  Субъекты правоотношений – это участники правовых отношений имеющие субъективные права и юридические обязанности. Традиционно все многочисленные субъекты права подразделяются в юридической литературе на два вида: индивиды физические лица и организации юридические лица. Виды коллективных субъектов права: 1.
27563. Сущность права. Классовое и общечеловеческое в праве 28 KB
  Сущность права – это главная внутренняя относительно устойчивая качественная основа права которая отражает его истинную природу и назначение в обществе Основные подходы к пониманию сущности права: 1 сущность права – это возведенная в закон воля той социальной группы которая обладает реальной государственной властью марксистколенинская теория. 2 сущность права – это социальная свобода соединенная с социальной ответственностью. 3 сущность права – это реальное общественное отношение которое складывается в социальнонеоднородном обществе.
27564. Теория государства и права в системе юриспруденции. Место в системе других социальных наук 30 KB
  В свою очередь юридические науки можно условно поделить на четыре основные группы: – общая теория государства и права; – историкоправовые науки; – отраслевые науки; – прикладные науки криминалистика судебная медицина психиатрия. Особенность теории государства и права как науки состоит в том что она является: – гуманитарной наукой предметом изучения которой составляют общественные явления – право и государство. Этой особенностью она отличается от других наук – естественных и технических; – политикоюридической наукой изучающей такие...