<<
>>

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


В самом начале и в процессе проектирования, необходимо проверять качество и корректность требований они должны быть верифицируемыми. Принято считать, что требования описаны не полностью, если для них не заданы правила - проверки и аттестации, то есть, не определены способы контроля корректности и утверждения.
Преимущества такого подхода состоят в том, что сводятся к минимуму дорогие переделки за счет уменьшения числа дефектов требований, которые можно обнаружить или предотвратить на ранних этапах жизненного цикла проекта. Определение требований напрямую связано с процедурами проверки и утверждения (аттестации), как это сформулировано в стандарте ISO12207:2007.
Определения качества требований позволяют выявить и прояснить нечеткие, неоднозначные требования. Такое неоднозначное требование целесообразно заменить несколькими требованиями, каждое из которых будет иметь свой собственный критерий качества. Не каждое требование может иметь четкий критерий качества, который можно использовать для проверки того, удовлетворяет ли какое- либо решение этому требованию. Добавив разъяснения в критерий качества для каждого требования, можно сделать их осязаемыми и понятными. Это первый шаг по определению критериев для измерения качества решений.
Когда формулируются требования помимо тех, которые уместны для конкретного проекта, есть вероятность, прихватить и несущественные требования, которые часто появляются в результате непонимания заинтересованной стороной целей проекта. Уровень конкретизации и неоднозначности требований взаимосвязаны, и руководителям-менеджерам проекта необходимо стремиться установить баланс «золотую середину» между ними.
Необходимо уметь проверять, что разрабатываемый комплекс программ удовлетворяет каждому из зафиксированных и утвержден - ных требований. Нужно выделять каждое такое требование, чтобы проследить его развитие в ходе подробного анализа, проектирования и, наконец, производства программ. Каждый этап разработки комплекса программ формирует, уточняет и реорганизует требования, чтобы сделать их как можно ближе к назначению нового программного продукта. Каждое требование должно иметь уникальный идентификатор, требование должно отражать отдельно распознаваемую, измеряемую сущность. В проектах сложных комплексов программ нужно применять способ работы с большим числом требований и сложными связями между ними. Следует учитывать, что наряду с существованием некоторого числа требований, связанных с одним основным событием и/или сценарием использования, любое требование может быть связано с другими событиями и/или сценариями использования.
Спецификация требований должна содержать все требования, которым обязан удовлетворять программный продукт. В спецификации необходимо объективно определить все, что он должен делать, а также те условия внешней среды, при которых он должен применяться и функционировать. Наиболее ответственный аспект формирования требований - общение со специалистами, которые вносят и изменяют требования. При наличии согласованного способа формирования требований все заинтересованные стороны могут принимать участие в процессе проектирования требований. Как только сформулировано хотя бы одно требование, можно приступать к его тестированию на корректность и задавать заинтересованным сторонам подробные вопросы для уточнения и конкретизации.
Можно применять различные тесты для проверки того, что требование существенно и что все ответственные участники проекта понимают его смысл одинаково. Целесообразно заказчику определять относительную значимость, приоритеты требований, задавать критерий качества для каждого требования и использовать этот критерий для тестирования корректности возможных решений.
Системная эффективность - функциональная пригодность при проектировании комплекса программ может быть описана количественно или качественно, в виде набора полезных свойств и характеристик программного средства, их отличий от имеющихся у других комплексов программ, а также источников возможной эффективности. Она определяет назначение, основные функции и требования за - казчика, какие задачи должны обязательно решаться для удовлетворения пользователей, а дополнительные, конструктивные характеристики качества - как и при каких условиях заданные функции могут выполняться с требуемым качеством. В результате может быть формализована цель использования и набор главных характеристик, требований заказчика и пользователей при заказе или приобретении программного продукта, а также предполагаемая его сфера назначения и применения. Полнота и точность представления этих характеристик является исходной для прослеживания реализации всех последующих, производных свойств и качества функциональной пригодности комплексов программ (см. рис. 1.5).
Функциональная пригодность - это набор и описания атрибутов, определяющих назначение, основные, необходимые и достаточные функции программного комплекса, заданные техническим заданием и спецификациями требований заказчика или потенциального пользователя. Номенклатура и значения всех остальных показателей качества непосредственно определяются требуемыми функциями программного комплекса и, в той или иной степени, влияют на выполнение этих функций. Данное требование связано с тем, какие основные функции и задачи должен решать программный продукт для удовлетворения потребностей пользователей, в то время как, конструктивные требования связаны с тем, как и при каких условиях, заданные функции могут выполняться с требуемым качеством. Поэтому выбор функциональной пригодности, подробное и корректное описание ее свойств, являются основными исходными данными для установления требуемых значений всех остальных стандартизированных показателей качества. Атрибутами этой характеристики могут быть функциональная полнота решения заданного комплекса задач, степень покрытия функциональных требований спецификациями и их стабильность при совершенствовании, число и полнота реали - зуемых требований заказчика. Такими атрибутами могут быть: функциональная адекватность программ документам и декларированным требованиям, утвержденным заказчиком; степень покрытия тестами исходных требований; полнота и законченность реализации этих требований; точность выполнения требований детальных спецификаций на функциональные компоненты.
Выбор требований к характеристикам при проектировании программных комплексов начинается с определения исходных данных. Для корректного выбора и установления требований к характеристикам качества, прежде всего, необходимо определить основные особенности применения системы. На основе этих данных должен формироваться общий набор требуемых характеристик, свойств, их мер и значений качества для определенных потребителей в жизненном цикле программного комплекса.
Если масштаб проекта и сопутствующие требования заказчика превышают реальные доступные ресурсы, в любом случае придется ограничиваться в функциях и качестве комплекса программ. Поэтому следует определять, что обязательно должно быть сделано в первой или очередной версии системы и программного продукта при имеющихся ресурсах проекта. Для этого приходится вести переговоры. Привлечение заказчика к итерационному проектированию и управлению масштабом и функциями, повышает взаимные обязательства сторон, способствует росту взаимопонимания и доверия между заказчиком и разработчиками. Имея достаточное определение функций продукта (концепцию) и сократив масштаб проекта до ра - зумного уровня, можно надеяться на успех проектирования программного продукта.
<< | >>
Источник: Липаев В.В.. Экономика производства программных продуктов.. 2011

Еще по теме Функциональная пригодность сложных заказныхкомплексов программ:

  1. § 3. ДИАГНОСТИКА ПРОФЕССИОНАЛЬНОЙ ПРИГОДНОСТИ
  2. Поиск глины и проверка ее на пригодность
  3. Бодров В.А.. Психология профессиональной пригодности. Учебное пособие для вузов – М.. ПЕР СЭ – 511 с – (Современное образование)., 2001
  4. Письмо г-на ЛІейбница] о всеобщем принципе, пригодном для объяснения законов природы с точки зрения божественной мудрости, служащее отзывом на ответ преподобного отца Мальбранша 10
  5. 55. Сложные эфиры
  6. Сложные эфиры
  7. 10.5. Сложные (органические) противоречия
  8. «Сложный объект»
  9. 5.1.11. Сложно ли применять ? '*
  10. Сложная цепь
  11. СЛОЖНЫЕ КОММУНАЛЬНЫЕ ИНДИВИДЫ
  12. НЕКОТОРЫЕ СЛОЖНЫЕ, НО ПОЛЕЗНЫЕ ТЕРМИНЫ
  13. СОКРАЩЁННЫЕ И СЛОЖНЫЕ СИЛЯОГИЗМЫ