Методологические основы

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

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

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

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