<<
>>

Общие требования к проектированию сложных программных продуктов


Команда проектирования заказного программного продукта должна понять проблемы заказчика до начала производства программного продукта. Для этого следует использовать анализ, выявление и освоение его профессиональных проблем и интересов - рис.
1.5. Программный менеджер и/или системный инженер должен быть знаком с основными способами проектирования сложных систем, знать, как перевести расплывчатые требования и пожелания заказчика системы в четкое техническое задание, уметь разговаривать с заказчиком и потенциальными пользователями системы на языке предметной области. Понимание потребностей заказчика и пользователей необходимый организационный этап, так как разра- ботчики редко получают совершенные спецификации требований к создаваемой системе, они должны сами добывать у заказчика информацию, необходимую им для успешной работы. Термин выявление требований точно отражает данный процесс, в котором проекти- ровщики должны играть активную роль. В соответствии с принятой политикой предприятия для определения требований к системе и продукту должны осуществляться следующие действия заинтересованных специалистов проектирования [1, 5, 14]: идентификация заинтересованных лиц или групп, имеющих законный интерес к системе и программному продукту в течение жизненного цикла; определение ограничений системных решений, которые яв- ляются неизбежным следствием существующих соглашений, управленческих или технических решений специалистов;



установление масштаба и требуемых ресурсов для реализации системы и программного продукта; определение представительного набора последовательных действий специалистов для идентификации всех требуемых функциональных возможностей, которые отвечают предполагаемым сценариям и внешней среде применения, функционирования и сопровождения системы и КП; анализ полноты и корректности множества установленных требований к системе и КП; специфицирование безопасности и других требований заказчика, имеющих отношение к критическим показателям применения системы; разрешение проблем и конфликтов, возникающих в связи с определением требований к системе; документирование требований заказчика в форме, приемлемой для управления требованиями в течение проектирования и жизненного цикла системы и КП.
Цель анализа требований состоит в преобразовании потребностей заказчика, выраженных в виде пользовательского представления о системе и КП, в формализованные функциональные возможности. В ходе этого процесса должно создаваться четкое представление о будущей системе, которая будет удовлетворять требованиям заказчика и не потребует специальных мероприятий в связи с ее практическим применением. В результате определяется комплекс оцениваемых требований, какими функциями и характеристиками должна обладать система и какими должны быть их значения, чтобы удовлетворить требованиям заказчика.
Определения и формирования требований заказчика состоит в формулировании требований к системе, выполнение которых должно обеспечить функциональные возможности, необходимые пользователям системы и иным заинтересованным лицам, в заданной эксплуа - тационной среде.
Должны быть определены цели создания и назначения компонентов системы, а также функции и область ее применения. Эти данные анализируются и преобразуются в общий набор требований заказчика, они описывают необходимое поведение системы в процессе взаимодействия с эксплуатационной средой, и совокупность образцовых показателей, проверка на соответствие которым является целью процесса аттестации и позволяет подтвердить, что система и КП отвечает заявленным требованиям.
Проектирование процессов производства сложных комплексов программ является фундаментом для обеспечения функциональной адекватности требованиям всего жизненного цикла ПК.
От полноты и тщательности проектирования зависит эффективность реализации функций системы и степень удовлетворения ожиданий и требований заказчика и пользователей. В последовательности выработки и подготовки к реализации этих требований далее учитываются три крупных этапа.
• системное проектирование - обследование, системный анализ существующей системы и КП, выявление их свойств и недостатков; предварительное проектирование - обобщение результатов системного анализа и создание предварительной концепции новой или модернизированной системы и её программного комплекса; детальное проектирование - разработка системного проекта производства комплекса программ и базы данных, определяю - щего и конкретизирующего цель, назначение, методы дальнейшего производства и всего жизненного цикла КП.
Поэтапное проектирование требований к производству способно остановить нерентабельное развитие системы и КП и избежать крупных затрат заказчикам и разработчикам. В то же время, на базе рекомендуемых при проектировании методов, инструментальных средств и стандартов может и должен быть подготовлен и обеспечен длительный, эффективный жизненный цикл производства и совершенствование версий высококачественных программных продуктов и их компонентов.
Требования заказчика при проектировании могут выражаться в форме потребностей, пожеланий и ограничений. Сценарии применения системы должны использоваться для анализа ее функционирования в заданной среде, с целью выявления требований, которые формально могли быть не заданы заказчиком. Также следует анализировать социальное воздействие организации на пользователей, которые могут повлиять на использование системы или сдерживать процесс ее проектирования. Стандарты и правила должны использоваться для определения особенностей внешней среды системы.
Анализ корректности сформированных требований к системе и программному продукту включает выявление и идентификацию противоречивых, пропущенных, неполных, неоднозначных, нелогичных или непроверяемых требований; расстановку приоритетов и разрешение проблем, возникающие в связи с определением требований (см. рис. 1.5). Сюда же относятся требования, которые не могут быть реализованы или которые нецелесообразно реализовывать. Необходимо достигать соглашения совместно с заинтересованными ли - цами, по решениям, касающимся противоречивых, нецелесообразных и неосуществимых требований, устанавливать, чтобы их требования были корректно откорректированы.
Исходные данные и требования к проектированию программного продукта, включая установленные законодательные и регламентирующие нормативные требования, должны быть, оформлены документально, а их выбор проанализирован поставщиком на адекватность. Спецификацию требований должен представить потребитель - заказчик. Однако по взаимному согласию ее может подготовить поставщик - разработчик, в тесном сотрудничестве с потребителем для предупреждений разногласий путем, уточнения определений терминов, объяснения предпосылок и обоснования требований. Неполные, двусмысленные или противоречивые требования должны быть предметом урегулирования с заказчиком и заинтересованными лицами, ответственными за их предъявление.
Для конкретного комплекса программ доминирующие требования выделяются и определяются его функциональным назначением. Программы для компьютеров как объекты проектирования, производства, испытаний и оценки качества характеризуются в жизненном цикле следующими обобщенными характеристиками. проблемно - ориентированной областью применения, техни - ческим и социальным назначением программного комплекса; конкретным классом и назначением решаемых функциональных задач с достаточно определенной областью применения квали - фицированными пользователями; масштабом и сложностью комплекса программ и базы данных, решающих единую целевую задачу системы; архитектурой комплекса программ и базы данных; необходимыми составом и требуемыми значениями характеристик качества функционирования программ и величиной допусти - мого ущерба - риска из-за недостаточного их качества или ресурсов; составом потребителей характеристик комплекса программ, для которых важны соответствующие атрибуты качества; комплектом стандартов и их содержания, которые целесообразно использовать при выборе технологии и характеристик комплекса программ; реальными ограничениями всех видов ресурсов проекта; степенью связи решаемых задач с реальным масштабом времени или допустимой длительностью ожидания результатов решения задач; прогнозируемыми значениями длительности эксплуатации и перспективой создания, множества версий программного продукта; предполагаемым тиражом производства и применения программного продукта; степенью необходимой документированности программного продукта.
Исходные требования к комплексу программ могут быть представлены и согласованы в составе спецификации всей системы. Если программный продукт нуждается во взаимодействии с другими программными или аппаратными продуктами, то в спецификации требований должны быть оговорены непосредственно или при помощи ссылок интерфейсы между разрабатываемыми и другими применяемыми продуктами. В этом случае должны быть разработаны процедуры, обеспечивающие четкое распределение системных требований между аппаратными и программными компонентами, а также соответствующие спецификации интерфейсов с внешней средой. При заключении контракта спецификация требований может быть оп- ределена не полностью, она может быть доработана в ходе реализа - ции проекта.
В соответствии с принципиальными особенностями конкретного комплекса программ при проектировании должны выбираться номенклатура и значения показателей качества, необходимых для его эффективного применения пользователями, которые отражаются в технической документации и в спецификациях требований на конечный программный продукт. При проектировании рекомендуется набор критериев качества требований к комплексам программ, который включает: корректность - отсутствуют дефекты и ошибки в формули - ровках требований к комплексу программ; недвусмысленность - каждое требование должно быть однозначно и не допускать различного понимания и толкования специалистами; полнота - состав и содержание требований должны быть достаточны для производства и применения корректного комплекса программ и компонентов; непротиворечивость - между разными требованиями к компонентам и комплексу программ отсутствуют конфликты и противоречия; модифицируемость - каждое требование допускает возможность его простого и согласованного изменения и развития при производстве комплекса программ; трассируемость - требование имеет однозначный идентификатор и возможность детализации и перехода к производству компонента или комплекса программ.
Системная эффективность применения программных продуктов в стандартах ISO 9126, ISO 25000 определяется степенью удовлетворения потребностей заинтересованных лиц - заказчиков и/или пользователей, которые, в ряде случаев, желательно измерять экономическими категориями: прибылью, стоимостью, трудоемкостью, предотвращенным ущербом, длительностью применения и т.п. В стандартах эта эффективность отражается основной, обобщенной характеристикой качества - функциональной пригодностью. В связи с тем, что ее абсолютную величину обычно трудно измерить непосредственно и количественно, то по ряду показателей необходима и возможна качественная оценка свойств и достоинств при применении программного продукта [13, 21, 29].
Улучшение каждой, нефункциональной - конструктивной характеристики качества, требует некоторых затрат ресурсов, которые в той или иной степени должны отражаться на улучшении основной характеристике качества - на функциональной пригодности. Требования к конструктивным характеристикам имеют значение для проекта постольку, поскольку они обеспечивают требуемое качество реализации основного назначения и функций комплекса программ. Поэтому для каждого проекта необходимо ранжировать характери - стики и их атрибуты (приоритеты) и выделять, прежде всего, те требования, которые могут в наибольшей степени улучшить функциональную пригодность для конкретных целей.
Ограниченные ресурсы для реализации требований функциональной пригодности, могут негативно отражаться на конструктивных характеристиках: на надежности, безопасности, пропускной способности, качестве взаимодействия с внешней средой и с пользователями, качестве документации и других эксплуатационных факторах. Наиболее общим видом ресурсов, используемых в жизненном цикле комплексов программ, являются допустимые финансово-экономические, бюджетные затраты. При анализе требований качества этот показатель может применяться или как вид ресурсных ограничений, или как оптимизируемый критерий. При этом необходимо также учитывать затраты на разработку, закупку и эксплуатацию системы обеспечения качества, технологии и комплекса средств автоматизации разработки программ и баз данных, которые могут составлять существенную часть совокупной стоимости программного продукта.
Каждое требование к характеристикам качества и к затратам ресурсов при проектировании первоначально обычно анализируются независимо, что может использоваться в качестве исходных данных для их сопоставления с отдельными характеристиками аналогичных комплексов программ, или для представления, как составляющей вектора в многомерном пространстве требований стандартизированных характеристик качества. Обычно заказчики и разработчики первоначально устанавливают требования к каждой характеристике без учета относительных затрат на их достижение, а также без детального анализа их совместного влияния на полную функциональную при - годность у потребителей. Это может приводить к несбалансированным значениям требований к отдельным, взаимосвязанным характеристикам качества, на которые не рационально используются огра - ниченные ресурсы проекта, или к не адекватно низким их значениям. Требования к характеристикам комплексов программ, определяющие их функциональную пригодность, принципиально различаются на две группы. требования к количественным, измеряемым, функциональным характеристикам, непосредственно влияющим на опера - тивное функционирование и возможность применения программного продукта в системе, в которые входят требования к надежности, безопасности, производительности, допустимым рискам применения; требования к структурным характеристикам, определяющим архитектуру комплекса программ, влияющие на возможности его модификации и сопровождения версий, на мобильность и переносимость на различные платформы, на документированность, удобство практического освоения и применения программного продукта вне оперативного функционирования.
Общие требования к заказным системам и комплексам программ реального времени для автоматизации управления и обработки информации о динамических объектах состоят в следующем: в процессах управления решением задач и вычислениями на компьютерах должно использоваться единое глобальное реальное время систем управления и обработки информации динамических объектов, а также внешней среды; для обработки потоки данных из внешней среды могут быть независимыми, несинхронными, различными по интенсивности, содержанию, реальному времени формирования и поступления для обработки; информация в сообщениях от источников и объектов внешней среды должна содержать реальное время, к которому относятся сообщения, их координаты и характеристики состояния; реальное время решения различных функциональных задач должно эффективно упорядочиваться в соответствии с установленной дисциплиной диспетчеризации, определенной при производстве системы, и реальным временем приема информации из внешней среды; алгоритмы и программы функциональных задач системы могут различаться по длительности решения и важности для пользователей, должны включать и использовать текущее и расчетное реальное время результатов решения и исходной информации; для эффективного использования ограниченных ресурсов производительности и оперативной памяти компьютеров целесообразно применять приоритеты и прерывания исполнения программ в соответствии с выбранными дисциплинами решения различных функциональных задач; информация и сообщения для потребителей и внешней среды могут выдаваться асинхронно, в соответствии с установленной дисциплиной и содержать значения реального время, которому соответствуют данные в сообщениях.
Приступая к проектированию сложного комплекса программ, необходимо произвести реалистичную оценку ресурсов проекта, выделенного времени и поставленных целей. Эти факторы совместно определяют базовый масштаб проекта. Однако не всегда увеличение ресурсов позволяет сократить время создания сложного комплекса программ. Для решения этой проблемы необходимо управление масштабом проекта комплекса программ и согласование всех изменений разработчиков и заказчиков.
Время или допустимая длительность разработки является невосполнимым ресурсом. Этот ресурс все больше определяет требования к качеству комплексов программ в процессе их производства и сопровождения. Жесткие требования заказчиков к срокам реализации проектов, естественно, ограничивают разработчиков и испытателей. Увеличение числа привлекаемых для этого специалистов только в некоторых пределах позволяет ускорять разработку. Радикальный способ увеличения реальных затрат на разработку и испытания в ограниченное время состоит в систематизации, планировании и автоматизации на всех этапах жизненного цикла комплекса программ. Сокращение масштаба комплекса до размеров, соответствующего имеющимся времени и ресурсам, может привести к конфликтам между командой разработчиков и заказчиками, потребности которых необходимо удовлетворить. 
<< | >>
Источник: Липаев В.В.. Экономика производства программных продуктов.. 2011

Еще по теме Общие требования к проектированию сложных программных продуктов:

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