67176

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

Лекция

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

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

Русский

2014-09-04

139 KB

4 чел.

PAGE  1

Лекция 6. Разработка требований к программным средствам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          

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

         

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     

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

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

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

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

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

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

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

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

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

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

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

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

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


 

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

26756. Судово-психологічна експертиза 56.25 KB
  Судово-слідчій практиці відомі випадки проведення судово-психологічної експертизи у відсутності людини, наприклад, коли підекспертного вмирає до суду. Посмертна експертиза здійснюється лише за матеріалами справи...
26757. лассификация организационных структур государственного управления 33.5 KB
  Организационная структура государственного управления это особое государственноправовое явление обусловленное общественнополитической природой социальнофункциональной ролью целями и содержанием государственного управления в обществе. В качестве системообразующего элемента организационной структуры государственного управления выступает государственный орган связанный с формированием и реализацией государственноуправляющих воздействий. Основу организационной структуры государственного управления составляют органы исполнительной власти.
26758. Этапы принятия управленческих решений: содержание и сущностные особенности 26 KB
  Это подготовка принятие и реализация решения. Построение взаимоотношений в организации для решения проблемы формирование команды для подготовки решения. Принятие решения руководителем. Конкретизация решения его дезагрегирование для более низких уровней управления.
26760. Управленческая процедура и ее виды 26.5 KB
  Под процедурой понимается набор действий операций с помощью кот. Управленческая процедура документально зафиксированная последовательность выполнения элементов управленческого процесса определяющая состав очередность содержание составляющих его операций. Понятие процедура отражает порядок подготовки рассмотрения обсуждения выполнения ряда последовательных и параллельных операций в процессе управления предписание о порядке выполнения какойлибо работы в аппарате управления. Понятие технология управления тесно связано с процессом...