Процессы реализации программных средств

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

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

В результате выполнения процесса:

• — определяется стратегия реализации;
• — устанавливаются ограничения по технологии реализации проекта;
• — изготавливается программная часть проекта, упаковывается и хранится в соответствии с соглашением о ее поставке.

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

• — процесс анализа требований к ПС*^[1][2];
• — процесс проектирования архитектуры ПС*;
• — процесс детального проектирования ПС;
• — процесс конструирования ПС;
• — процесс комплексирования ПС*;
• — процесс квалификационного тестирования ПС*.

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

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

2. Процесс анализа требований к ПС (7.1.2) является процессом более низкого уровня, чем предыдущий процесс реализации программных средств. Его цель — установление требований к программным элементам системы.

В ходе осуществления процесса:

• — определяются требования к программным блокам и модулям системы и их интерфейсам, выполняется их анализ на корректность и тестируемость;
• — выявляется уровень воздействия требований к программным блокам и модулям системы на среду функционирования;
• — устанавливается совместимость, взаимосвязь и корреляция¹ между требованиями к программным элементам и требованиями к системе в целом;
• — определяются приоритеты реализации установленных требований;
• — устанавливается в случае необходимости порядок предъявления и обновления требований к ПС;
• — оценивается влияние изменений в требованиях к ПС на стоимость и сроки работ, графики их выполнения, характеристики технических средств и т. п.;
• — требования к программным средствам документируются «в виде базовых линий и доводятся до сведения заинтересованных сторон»^[3][4].

В ходе анализа требований к ПС для каждого элемента (составной части) устанавливаются и фиксируются в виде документа:

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

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

3. Процесс проектирования архитектуры ПС (7.1.3) обеспечивает процесс реализации программных средств.

В результате реализации процесса:

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

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

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

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

4. Процесс детального проектирования ПС (7.1.4) обеспечивает осуществление процесса реализации относительно установленных требований и архитектуры ПС.

В ходе реализации процесса:

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

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

Оценка детального проекта должна осуществляться по следующим критериям:

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

Результаты оценки должны быть документально оформлены.

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

В ходе процесса:

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

Конструирование ПС предполагает:

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

Оценка ПС осуществляется с учетом множества критериев:

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

В ходе процесса:

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

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

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

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

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

В ходе процесса:

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

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

Проводится общая оценка проекта по критериям:

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

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

По завершению системного квалификационного тестирования программных средств ИС стандарт ГОСТ Р ИСО/МЭК 12 207—2010 рекомендует проводить аудит проекта. Разработчик (исполнитель) проекта должен поддерживать его проведение.

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

• [1] Во избежание недоразумения, поскольку в стандарте и группа процессов и первыйиз процессов группы именуются одинаково, учитывая содержание, целесообразнее было быназвать данную группу процессами разработки программных средств (см. табл. 3.3).
• [2] Отмеченные звездочкой (*) процессы рекурсивно применяются для программныхсредств и их элементов (по мере необходимости, в случае внесения изменений и т. п.); ихсодержание приведено ниже.
• [3] В стандарте ГОСТ Р ИСО/МЭК 12 207—2010 вместо слов «взаимосвязь и корреляция"приведен термин «прослеживаемость».
• [4] См.: ГОСТ Р ИСО/МЭК 12 207—2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.