<<
>>

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


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




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

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

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

  1. Липаев В.В.. Экономика производства программных продуктов., 2011
  2. Программная реализация
  3. 1. ПРОГРАММНЫЕ ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К АСПИРАНТАМ И СОИСКАТЕЛЯМ ГУМАНИТАРНЫХ И ЕСТЕСТВЕННОНАУЧНЫХ СПЕЦИАЛЬНОСТЕЙ, СДАЮЩИМ КАНДИДАТСКИЙ ЭКЗАМЕН ПО ФИЛОСОФИИ И МЕТОДОЛОГИИ НАУКИ
  4. Лекция 13. ПРИОРИТЕТНЫЕ ПУТИ РАЗВИТИЯ И РЕАЛИЗАЦИИ НОВЫХ ТЕХНОЛОГИЙ, ОТВЕЧАЮЩИХ ТРЕБОВАНИЯМ ПРОМЫШЛЕННОЙ ЭКОЛОГИИ
  5. ПРИЛОЖЕНИЕ № 9 ТРЕБОВАНИЯ к передвижному пункту (автомобилю) для проведения медицинского освидетельствования на состояние опьянения лиц, которые управляют транспортным средством
  6. Разработка программного обеспечения. Затраты, связанные с качеством программного обеспечения, в группе компаний Raytheon’s Electronic Systems
  7. Приложение 1 ТРЕБОВАНИЯ К УРОВНЮ ПОДГОТОВКИ И К ГОСУДАРСТВЕННОЙ АТТЕСТАЦИИ ВЫПУСКНИКОВ СПЕЦИАЛЬНОСТИ 030500.18 - ПРОФЕССИОНАЛЬНОЕ ОБУЧЕНИЕ (ЭКОНОМИКА И УПРАВЛЕНИЕ)
  8. 4.7. ПРОДУКТ КАК РЕЗУЛЬТАТ ПРОИЗВОДСТВА. СВОЙСТВА ПРОДУКТА
  9. Статья 982. Последствия одобрения заинтересованным лицом действий в его интересе
  10. 20.3. ВАЛОВОЙ ВНУТРЕННИЙ ПРОДУКТ И ВАЛОВОЙ НАЦИОНАЛЬНЫЙ ПРОДУКТ. СОСТАВ и СПОСОБЫ РАСЧЕТА
  11. Приложение 3 МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ПОДГОТОВКЕ И ОФОРМЛЕНИЮ КУРСОВЫХ И ДИПЛОМНЫХ РАБОТ ПО ПЕДАГОГИКЕ ОПРОСА1 I. Требования к курсовым работам по педагогике
  12. Статья 1103. Соотношение требований о возврате неосновательного обогащения с другими требованиями о защите гражданских прав