Неверно что в результате успешного осуществления процесса конструирования программных средств
Процессы реализации программных средств
Процессы реализации программных средств используются для создания конкретного элемента системы (составной части), выполненного в виде программного средства. Эти процессы преобразуют заданные характеристики поведения, интерфейсы и ограничения на реализацию в действия, результатом которых становится системный элемент, удовлетворяющий требованиям, вытекающим из системных требований. [ГОСТ Р ИСО/МЭК 12207-2010].
Примечание. В курсе «Технология разработки программного обеспечения» программное средство рассматривается ни как составная часть системы, а как независимое автономное программное обеспечение, состоящее из программных модулей [17].
Процесс реализации
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса реализации программных средств:
1) Если не оговорено в контракте, разработчик должен определить или выбрать модель жизненного цикла, соответствующую области применения, размерам и сложности проекта. Модель жизненного цикла должна содержать стадии, цели и выходы каждой стадии. Виды деятельности и задачи процесса реализации программных средств должны быть выбраны и отражены в модели жизненного цикла. Подробно существующие модели и методологии будут рассмотрены во второй теме текущего документа. Эти виды деятельности и задачи могут пересекаться или взаимодействовать друг с другом, могут выполняться итеративно или рекурсивно. В идеальном случае рассматриваемые виды деятельности и задачи выполняются и решаются с использованием определенной организационной модели жизненного цикла.
2) Исполнитель должен:
— документировать результаты в соответствии с процессом менеджмента программной документации;
— передавать результаты в процесс менеджмента конфигурации программных средств и выполнять управление изменениями в соответствии с ним;
— документировать, решать проблемы и снимать несоответствия, найденные в программных продуктах и задачах в соответствии с процессом решения проблем в программных средствах;
— выполнять поддержку процессов в соответствии с контрактом;
— устанавливать базовые линии и соединять элементы конфигурации в сроки, определенные приобретающей стороной и поставщиком.
3) Исполнитель должен выбирать, адаптировать и применять те стандарты, методы, инструментарий и языки программирования (если не оговорено в контракте), которые документально оформлены, являются подходящими и установлены организацией для выполнения деятельности в рамках процесса реализации программных средств и поддерживающих процессов.
4) Исполнитель должен разрабатывать планы проведения действий процесса реализации программных средств. Планы должны включать в себя конкретные стандарты, методы, инструментарий, действия и обязанности, связанные с разработкой и квалификацией всех требований, включая безопасность и защиту. При необходимости могут разрабатываться отдельные планы. Эти планы должны документироваться и выполняться.
5) При разработке или сопровождении программных продуктов могут применяться не поставляемые элементы. Однако должно гарантироваться, что функционирование и сопровождение поставляемых программных продуктов после поставки приобретающей стороне не зависит от таких элементов; другими словами, эти элементы следует также рассматривать как поставляемые.
Результатом процесса является создание программной составной части, удовлетворяющей как требованиям к архитектурным решениям, что подтверждается посредством верификации, так и требованиям правообладателей, что подтверждается посредством валидации.
В результате успешного осуществления процесса реализации программных средств:
1) определяется стратегия реализации;
2) определяются ограничения по технологии реализации проекта;
3) изготавливается программная составная часть;
4) программная составная часть упаковывается и хранится в соответствии с соглашением о ее поставке.
Процесс реализации программных средств включает в себя несколько специальных процессов более низкого уровня:
1) процесс анализа требований к программным средствам;
2) процесс проектирования архитектуры программных средств;
3) процесс детального проектирования программных средств;
4) процесс конструирования программных средств;
5) процесс комплексирования программных средств;
6) процесс квалификационного тестирования программных средств.
Цель процесса конструирования программных средств заключается в …
Создании заданных элементов системы, выполненных в виде программных продуктов или услуг
Обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно требований
Создании исполняемых программных блоков, которые должным образом отражают проектирование программных средств
Объединении программных блоков и программных компонентов, создании интегрированных программных элементов, согласованных с проектом программных средств
Объединении программных блоков и программных компонентов, создании интегрированных программы элементов, согласованных с проектом программных средств
При разработке или сопровождении программных продуктов непоставляемые элементы …
Применяться не могут
Могут применяться без каких либо ограничений
Могут применяться при условии, что функционирование и сопровождение поставляемых программных продуктов после поставки приобретающей стороне не зависит от таких элементов
Могут применяться при условии, что разработчик снимает с себя обязательства по сопровождению и/или поддержке программного продукта
Процесс менеджмента рисков жизненного цикла информационной системы или программного продукта применим к рискам, связанным с …
Изменением экономической ситуации
Возникновением природных или техногенных катастроф
Изменением статуса компании (реорганизация, смена собственника)
Приобретением, разработкой, сопровождением или применением программного продукта
Цель процесса менеджмента конфигурации состоит …
В определении состояния проекта и гарантии того, что проект выполняется в соответствии с планами и графиками работ в пределах бюджета и удовлетворяет техническим параметрам
В составлении и доведении до заинтересованных сторон эффективного и выполнимого плана
В выборе из существующих альтернатив наиболее предпочтительного направления проектных действий
В установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны
Оценка процесса менеджмента рисков подразумевает …
Сбор информации в течении всего жизненного цикла проекта для целей улучшения процесса менеджмента рисков и извлечения практических уроков
Определение политики менеджмента рисков, описывающие руководящие указания, регламентирующие выполнение менеджмента рисков
Описание перспектив правообладателей, категорий риска, а также описание технических и управленческих целей, допущений и ограничений
Предоставление рекомендованных альтернатив обработки риска в требованиях на действия по отношению к риску
Неверно, что одним их элементов планов для выполнения проекта является …
Распределение задач
Стратегия принятия решений
Распределение обязанностей
Разработка графиков работ для своевременного завершения задач
В процессе приобретения программного продукта заключается договор/соглашение между …
Приобретающей стороной и разработчиком
Разработчиком и поставщиком
Приобретающей стороной и поставщиком
Приобретающей стороной, поставщиком и разработчиком
При получении заказа на программный продукт разработчик обязан …
Усовершенствовать имеющийся продукт
Разработать или приобрести новый продукт
Найти сторону для осуществления поставки
Определение требований инициируемого проекта включает в себя …
Список имеющего, аппаратного обеспечения
Список имеющего, программного обеспечения
Идентификацию целей, мотиваций и ограничений проекта
Техническое задание на разработку программного продукта
После доставки продукта приобретающей стороне, заказчик обязан …
Приготовиться к приему продукта, принять его ответственность
Сообщить о появлении нового продукта
Встретиться с поставщиком
Провести оплату труда
Роли и обязанности сторон должны быть изложены в форме …
Контракта/соглашения
Устной договоренности
Заявки об обязанностях
Регламента взаимодействия сторон
Приобретая готовый программный продукт, приобретающая сторона должна гарантировать, что
Будет написана необходимая документация по продукту
Будут соблюдены права собственности
Будет заключен договор о требованиях к продукту
Продукт будет использоваться строго по назначению
В документацию по требованиям к приобретению программного продукта следует включить …
Перечень имеющейся техники
Список имеющихся программных продуктов
Технические требования к программному продукту
Название фирмы поставщика и производителя
Список требований к программному продукту следует составить как только …
Приобретающая сторона найдет разработчика
Приобретающая сторона найдет поставщика
Приобретающая сторона выявит потребность
Разработчик заявит о продукте
За тем, что заказанный продукт соответствует установленным требованиям должна следить …
Сторона заказчика
Сторона поставщика
Сторона, поставщика и разработчика
Сторона заказчика и разработчика
Цель процесса реализации программных средств заключается в …
Создании заданных элементов системы, выполненных в виде программных продуктов или услуг
Обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно требований
Создании исполняемых программных блоков которые должны образом отражают проектирование программных средств
Объединении программных блоков и программных компонентов, создании интегрированных программных элементов, согласованных с проектом программных средств
Планирование менеджмента рисков подразумевает …
Описание перспектив правообладателей, категорий риска, а также описание технических и управленческих целей, допущений и ограничений
Определение политика менеджмента рисков, описывающие руководящие указания, регламентирующие выполнение менеджмента рисков
Предоставление рекомендованных альтернатив обработки риска в требованиях на действия по отношению к риску
Сбор информации в течение всего жизненного цикла проекта для целей улучшения процесса менеджмента рисков и извлечения практических уроков
Перед объявлением тендера на продукт государственной структурой обязан быть осуществлен этап …
Формирование списка потенциальных поставщиков
Формулирование первичных требований и выбор спроса
Подача заявления об участии в тендере
Объявления тендера является первым этапом
Цель процесса проектирования архитектуры программных средств заключается в …
Создании заданных элементов системы выполненных в виде программных продуктов или услуг
Обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно требований
Создании исполняемых программных блоков, которые должны образом отражают проектирование программных элементов, согласованных с проектом программных средств
Цель оценки проекта и процесса управления заключается …
В определении состояния проекта и гарантии того, что проект выполняется в соответствии с планами и графиками работ в пределах бюджета и удовлетворяет техническим параметрам
В составлении и доведении до заинтересованных сторон эффективного и выполнимого плана
В выборе из существующих альтернатив наиболее предпочтительного направления проектных действий
В установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованный стороны
Неверно, что одним из результатов успешного осуществления процесса менеджмента конфигурации является …
Определение стратегии менеджмента конфигурации
Определение рисков по мере их выявления и в течение проведения проекта
Определение составных частей, нуждающиеся в менеджменте конфигурации
Установление базовой линии конфигурации
Проведение ревизий программного средства осуществляется в процессе …
Квалификационного тестирования программных средств
Комплексирования программных средств
Анализа требований к программным средствам
Конструирования программных средств
Обработка рисков подразумевает …
Определение политики менеджмента рисков, описывающие руководящие указания, регламентирующие выполнение менеджмента рисков
Описание перспектив правообладатели, категорий риска, а также описание технических и управленческих целей, допущений и ограничений
Предоставление регламентированных альтернатив обработки риска в требованиях на действия по отношению к риску
Сбор информации в течение всего жизненного цикла проекта для целей улучшения процесса менеджмента рисков и извлечения практических уроков
Заключительным этапом процесса поставки является …
Подтверждение поставщика о доставке
Подтверждения о расчете с заказчиком
Установление сроков доставки и места получения
Выполнение условий соглашения по поставке продукта
После выбора поставщика, приобретающей стороне следует …
Найти альтернативный вариант поставки
Составить список требований по продукту
Составить и заключить договор
Найти альтернативный вариант продукта
Процесс менеджмента решений обусловлен …
Возникающим в течение жизненного цикла системы запросами на приянтие решений, направленных на достижение заданных, желаемых или оптимальных результатов
Возникающими разногласиями между поставщиком и приобретающей стороной
Ошибками в формулировании требований к программному продукту
Внесением изменений и дополнений в договор/соглашение о поставке программного продукта
Приобретающая сторона до заключения контракта с поставщиком о закупке товара имеет максимальные права …
Вести переговоры, привлекать другие стороны
Запросить требования производителя товара
Установить и использовать демо-версию приобретаемого продукта
Заявить о желании заявить контракт
Для активации проекта менеджер должен представить …
Заявки на необходимые ресурсы для выполнения проекта
План проекта
График работ по задачам проекта
Техническо-экономическое обоснование проекта
Цель процесса менеджмента решений заключается …
В установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны
В выборе из существующих альтернатив наиболее предпочтительного направления проектных действий
В определении состояния проекта и гарантии того, что проект выполняется в соответствии с планами и графиками работ в пределах бюджета и удовлетворяет техническим параметрам
В составлении и доведении до заинтересованных сторон эффективного и выполнимого плана
«ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ. ГОСТ Р ИСО/МЭК 12207-2010» (утв. Приказом Ростехрегулирования от 30.11.2010 N 631-ст)
7.1 Процессы реализации программных средств
7.1.1 Процесс реализации
Цель процесса реализации программных средств заключается в создании заданных элементов системы, выполненных в виде программных продуктов или услуг.
В ходе этого процесса происходит преобразование заданных поведенческих, интерфейсных и производственных ограничений в действия, которые создают системный элемент, выполненный в виде программного продукта или услуги, известный как «программный элемент».
Результатом процесса является создание программной составной части, удовлетворяющей как требованиям к архитектурным решениям, что подтверждается посредством верификации, так и требованиям правообладателей, что подтверждается посредством валидации.
В результате успешного осуществления процесса реализации программных средств:
a) определяется стратегия реализации;
b) определяются ограничения по технологии реализации проекта;
c) изготавливается программная составная часть;
d) программная составная часть упаковывается и хранится в соответствии с соглашением о ее поставке.
В дополнение к этим действиям процесс реализации программных средств имеет следующие процессы более низкого уровня:
— процесс анализа требований к программным средствам*;
— процесс проектирования архитектуры программных средств*;
— процесс детального проектирования программных средств;
— процесс конструирования программных средств;
— процесс комплексирования программных средств*;
— процесс квалификационного тестирования программных средств*.
7.1.1.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса реализации программных средств.
7.1.1.3.1 Стратегия реализации программных средств
Данный вид деятельности состоит из решения следующих задач:
7.1.1.3.1.1 Если не оговорено в контракте, разработчик должен определить или выбрать модель жизненного цикла, соответствующую области применения, размерам и сложности проекта. Модель жизненного цикла должна содержать стадии, цели и выходы каждой стадии. Виды деятельности и задачи процесса реализации программных средств должны быть выбраны и отражены в модели жизненного цикла. Эти виды деятельности и задачи могут пересекаться или взаимодействовать друг с другом, могут выполняться итеративно или рекурсивно.
7.1.1.3.1.2 Исполнитель должен:
a) документировать результаты в соответствии с процессом менеджмента программной документации (см. 7.2.1);
b) передавать результаты в процесс менеджмента конфигурации программных средств (см. 7.2.2) и выполнять управление изменениями в соответствии с ним;
c) документировать, решать проблемы и снимать несоответствия, найденные в программных продуктах и задачах в соответствии с процессом решения проблем в программных средствах (см. 7.2.8);
d) выполнять поддержку процессов в соответствии с контрактом;
e) устанавливать базовые линии и соединять элементы конфигурации в сроки, определенные приобретающей стороной и поставщиком.
7.1.1.3.1.3 Исполнитель должен выбирать, адаптировать и применять те стандарты, методы, инструментарий и языки программирования (если не оговорено в контракте), которые документально оформлены, являются подходящими и установлены организацией для выполнения деятельности в рамках процесса реализации программных средств и поддерживающих процессов.
7.1.1.3.1.4 Исполнитель должен разрабатывать планы проведения действий процесса реализации программных средств. Планы должны включать в себя конкретные стандарты, методы, инструментарий, действия и обязанности, связанные с разработкой и квалификацией всех требований, включая безопасность и защиту. При необходимости могут разрабатываться отдельные планы. Эти планы должны документироваться и выполняться.
7.1.1.3.1.5 При разработке или сопровождении программных продуктов могут применяться непоставляемые элементы. Однако должно гарантироваться, что функционирование и сопровождение поставляемых программных продуктов после поставки приобретающей стороне не зависит от таких элементов; другими словами, эти элементы следует также рассматривать как поставляемые.
7.1.2 Процесс анализа требований к программным средствам
Цель процесса анализа требований к программным средствам заключается в установлении требований к программным элементам системы.
В результате успешного осуществления процесса анализа требований к программным средствам:
a) определяются требования к программным элементам системы и их интерфейсам;
b) требования к программным средствам анализируются на корректность и тестируемость;
c) осознается воздействие требований к программным средствам на среду функционирования;
d) устанавливается совместимость и прослеживаемость между требованиями к программным средствам и требованиями к системе;
e) определяются приоритеты реализации требований к программным средствам;
f) требования к программным средствам принимаются и обновляются по мере необходимости;
g) оцениваются изменения в требованиях к программным средствам по стоимости, графикам работ и техническим воздействиям;
h) требования к программным средствам воплощаются в виде базовых линий и доводятся до сведения заинтересованных сторон.
7.1.2.3 Виды деятельности и задачи
При реализации проекта необходимо выполнять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса анализа требований к программным средствам.
7.1.2.3.1 Анализ требований к программным средствам
Для каждого программного элемента (или элемента конфигурации, если он определен) данный вид деятельности состоит из решения следующих задач:
7.1.2.3.1.1 Исполнитель должен установить и документально оформить следующие требования к программным средствам (включая спецификации характеристик качества):
a) спецификации функциональных характеристик и возможностей, включая эксплуатационные, физические характеристики и условия окружающей среды, при которых будет применяться программная составная часть;
b) внешние интерфейсы к программной составной части;
c) квалификационные требования;
d) спецификации по безопасности, включая те спецификации, которые относятся к методам функционирования и сопровождения, влиянию окружающей среды и ущербу для персонала;
e) спецификации по защите, включая спецификации, связанные с угрозами для чувствительной информации;
f) спецификации эргономических факторов, включая спецификации, связанные с ручными операциями, взаимодействием человека с оборудованием, ограничениями по персоналу и областям, требующим концентрации внимания и чувствительным к ошибкам человека и уровню его обученности;
g) описание данных и требования к базам данных;
h) инсталляция и требования к приемке поставляемого программного продукта в местах функционирования и сопровождения;
i) требования к документации пользователя;
j) операции пользователя и требования к их выполнению;
k) пользовательские требования к сопровождению.
7.1.2.3.1.2 Исполнитель должен оценить требования к программным средствам, учитывая критерии, перечисленные ниже. Результаты оценок должны быть документально оформлены.
a) прослеживаемость к системным требованиям и к системному проекту;
b) внешняя согласованность с системными требованиями;
с) внутренняя согласованность;
е) осуществимость программного проекта;
f) осуществимость функционирования и сопровождения.
7.1.2.3.1.3 Исполнитель должен проводить ревизии в соответствии с 7.2.6.
7.1.3 Процесс проектирования архитектуры программных средств
Цель процесса проектирования архитектуры программных средств заключается в обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно требований.
В результате успешной реализации процесса проектирования архитектуры программных средств:
a) разрабатывается проект архитектуры программных средств и устанавливается базовая линия, описывающая программные составные части, которые будут реализовывать требования к программным средствам;
b) определяются внутренние и внешние интерфейсы каждой программной составной части;
c) устанавливаются согласованность и прослеживаемость между требованиями к программным средствам и программным проектом.
7.1.3.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса проектирования архитектуры программных средств.
7.1.3.3.1 Проектирование архитектуры программных средств
Для каждого программного элемента (или элемента конфигурации, если он определен) данный вид деятельности состоит из решения следующих задач:
7.1.3.3.1.1 Исполнитель должен преобразовать требования к программным составным частям в архитектуру, которая описывает верхний уровень его структуры и идентифицирует программные компоненты. Необходимо гарантировать, что все требования к программным составным частям распределяются по программным компонентам и в дальнейшем уточняются для облегчения детального проектирования. Архитектуру программной составной части необходимо документировать.
7.1.3.3.1.2 Исполнитель должен разработать и документально оформить проект верхнего уровня для внешних интерфейсов программной составной части и интерфейсов между ней и программными компонентами.
7.1.3.3.1.3 Исполнитель должен разработать и документально оформить проект верхнего уровня для базы данных.
7.1.3.3.1.4 Исполнитель должен разработать и документально оформить предварительные версии пользовательской документации.
7.1.3.3.1.5 Исполнитель должен определить и документировать требования к предварительному тестированию и график работ по комплексированию программных средств.
7.1.3.3.1.6 Исполнитель должен оценить архитектуру программной составной части, проекты по интерфейсам и базе данных, учитывая следующие критерии:
a) прослеживаемость к требованиям программной составной части;
b) внешняя согласованность с требованиями программной составной части;
c) внутренняя согласованность между программными компонентами;
d) приспособленность методов проектирования и используемых стандартов;
e) осуществимость детального проектирования;
f) осуществимость функционирования и сопровождения.
Результаты оценок следует оформлять документально.
7.1.3.3.1.7 Исполнитель должен проводить ревизии в соответствии с 7.2.6.
7.1.4 Процесс детального проектирования программных средств
Цель процесса детального проектирования программных средств заключается в обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно установленных требований и архитектуры программных средств, а также существенным образом детализируются для последующего кодирования и тестирования.
В результате успешного осуществления процесса детального проектирования программных средств:
а) разрабатывается детальный проект каждого программного компонента, описывающий создаваемые программные модули;
b) определяются внешние интерфейсы каждого программного модуля и
c) устанавливается совместимость и прослеживаемость между детальным проектированием, требованиями и проектированием архитектуры.
7.1.4.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса детального проектирования программных средств.
7.1.4.3.1 Детальное проектирование программных средств
Для каждой программной составной части (или составной части конфигурации, если она определена) данный вид деятельности состоит из решения следующих задач:
7.1.4.3.1.1 Исполнитель должен разработать детальный проект для каждого программного компонента программной составной части. Программные компоненты должны быть детализированы на более низком уровне, включающем программные блоки, которые могут быть закодированы, откомпилированы и проверены. Следует гарантировать, что все требования к программным средствам распределяются от программных компонентов к программным блокам. Детальный проект должен быть документально оформлен.
7.1.4.3.1.2 Исполнитель должен разработать и документально оформить детальный проект для внешних интерфейсов к программным составным частям, между программными компонентами и между программными блоками. Необходимо, чтобы детальный проект для интерфейсов позволял проводить кодирование без потребности в получении дополнительной информации.
7.1.4.3.1.3 Исполнитель должен разработать и документально оформить детальный проект базы данных.
7.1.4.3.1.4 Исполнитель должен совершенствовать пользовательскую документацию по мере необходимости.
7.1.4.3.1.5 Исполнитель должен определять и документировать требования к тестированию и графики работ по тестированию программных блоков. Необходимо, чтобы требования к тестированию включали в себя проведение проверок программных блоков при граничных значениях параметров, установленных в требованиях.
7.1.4.3.1.6 Исполнитель должен обновлять требования к тестированию и графики работ по комплексированию программных средств.
7.1.4.3.1.7 Исполнитель должен оценивать детальный проект для программных средств и требования к тестированию по следующим критериям:
a) прослеживаемость к требованиям программной составной части;
b) внешняя согласованность с архитектурным проектом;
c) внутренняя согласованность между программными компонентами и программными блоками;
d) соответствие методов проектирования и используемых стандартов;
e) осуществимость тестирования;
f) осуществимость функционирования и сопровождения.
Результаты оценки должны быть документально оформлены.
7.1.4.3.1.8 Исполнитель должен проводить ревизии в соответствии с 7.2.6.
7.1.5 Процесс конструирования программных средств
Цель процесса конструирования программных средств заключается в создании исполняемых программных блоков, которые должным образом отражают проектирование программных средств.
В результате успешного осуществления процесса конструирования программных средств:
a) определяются критерии верификации для всех программных блоков относительно требований;
b) изготавливаются программные блоки, определенные проектом;
c) устанавливается совместимость и прослеживаемость между программными блоками, требованиями и проектом;
d) завершается верификация программных блоков относительно требований и проекта.
7.1.5.3 Виды деятельности и задачи
При реализации проекта необходимо выполнять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса конструирования программных средств.
7.1.5.3.1 Конструирование программных средств
Для каждой программной составной части (или составной части конфигурации, если она определена) данный вид деятельности состоит из решения следующих задач:
7.1.5.3.1.1 Исполнитель должен разработать и документально оформить:
a) каждый программный блок и базу данных;
b) процедуры тестирования и данные для тестирования каждого программного блока и базы данных.
7.1.5.3.1.2 Исполнитель должен тестировать каждый программный блок и базу данных, гарантируя, что они удовлетворяют требованиям. Результаты тестирования должны быть документально оформлены.
7.1.5.3.1.3 Исполнитель должен улучшать документацию пользователя при необходимости.
7.1.5.3.1.4 Исполнитель должен совершенствовать требования к тестированию и графики работ по комплексированию программных средств.
7.1.5.3.1.5 Исполнитель должен оценивать программный код и результаты испытаний, учитывая следующие критерии:
a) прослеживаемость к требованиям и проекту программных элементов;
b) внешнюю согласованность с требованиями и проектом для программных составных частей;
c) внутреннюю согласованность между требованиями к блокам;
d) тестовое покрытие блоков;
e) соответствие методов кодирования и используемых стандартов;
f) осуществимость комплексирования и тестирования программных средств;
g) осуществимость функционирования и сопровождения.
Результаты оценки должны быть документально оформлены.
7.1.6 Процесс комплексирования программных средств
Цель процесса комплексирования программных средств заключается в объединении программных блоков и программных компонентов, создании интегрированных программных элементов, согласованных с проектом программных средств, которые демонстрируют, что функциональные и нефункциональные требования к программным средствам удовлетворяются на полностью укомплектованной или эквивалентной ей операционной платформе.
В результате успешного осуществления процесса комплексирования программных средств:
a) разрабатывается стратегия комплексирования для программных блоков, согласованная с программным проектом и расположенными по приоритетам требованиями к программным средствам;
b) разрабатываются критерии верификации для программных составных частей, которые гарантируют соответствие с требованиями к программным средствам, связанными с этими составными частями;
c) программные составные части верифицируются с использованием определенных критериев;
d) программные составные части, определенные стратегией комплексирования, изготавливаются;
е) регистрируются результаты комплексного тестирования;
f) устанавливаются согласованность и прослеживаемость между программным проектом и программными составными частями;
g) разрабатывается и применяется стратегия регрессии для повторной верификации программных составных частей при возникновении изменений в программных блоках (в том числе в соответствующих требованиях, проекте и кодах).
7.1.6.3 Виды деятельности и задачи
При реализации проекта необходимо выполнять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса комплексирования программных средств.
7.1.6.3.1 Комплексирование программных средств
Для каждой программной составной части (или составной части конфигурации, если она определена) данный вид деятельности состоит из решения следующих задач:
7.1.6.3.1.1 Исполнитель должен разработать план комплексирования для объединения программных блоков и программных компонентов в программную составную часть. План должен включать в себя требования к тестированию, процедуры, данные, обязанности и графики работ. План должен быть оформлен документально.
7.1.6.3.1.2 Исполнитель должен объединить программные блоки, программные компоненты и тесты, поскольку они разрабатываются в соответствии с планом комплексирования. Должны быть гарантии в том, что каждое такое объединение удовлетворяет требованиям к программной составной части и что составная часть комплексируется при завершении выполнения данной задачи. Результаты комплексирования и тестирования должны быть оформлены документально.
7.1.6.3.1.3 Исполнитель должен обновлять пользовательскую документацию номере необходимости.
7.1.6.3.1.4 Исполнитель должен разработать и документально оформить для каждого квалификационного требования к программной составной части комплект тестов, тестовых примеров (входов, результатов, критериев тестирования) и процедур тестирования для проведения квалификационного тестирования программных средств. Разработчик должен гарантировать, что после комплексирования программная составная часть будет готова к квалификационному тестированию.
7.1.6.3.1.5 Исполнитель должен оценить план комплексирования, проект, код, тесты, результаты тестирования и пользовательскую документацию, учитывая:
a) прослеживаемость к системным требованиям;
b) внешнюю согласованность с системными требованиями;
c) внутреннюю согласованность;
d) тестовое покрытие требований к программной составной части;
e) приспособленность используемых методов и стандартов тестирования;
f) соответствие ожидаемым результатам;
g) осуществимость квалификационного тестирования программных средств;
h) осуществимость функционирования и сопровождения.
Результаты оценки должны быть оформлены документально.
7.1.6.3.1.6 Исполнитель должен проводить ревизии в соответствии с 7.2.6.
7.1.7 Процесс квалификационного тестирования программных средств
Цель процесса квалификационного тестирования программных средств заключается в подтверждении того, что комплектованный программный продукт удовлетворяет установленным требованиям.
В результате успешного осуществления процесса квалификационного тестирования программных средств:
a) определяются критерии для комплектованных программных средств с целью демонстрации соответствия с требованиями к программным средствам;
b) комплектованные программные средства верифицируются с использованием определенных критериев;
c) записываются результаты тестирования;
d) разрабатывается и применяется стратегия регрессии для повторного тестирования комплектованного программного средства при проведении изменений в программных составных частях.
7.1.7.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса квалификационного тестирования программных средств.
7.1.7.3.1 Квалификационное тестирование программных средств
Для каждой программной составной части (или составной части конфигурации, если она определена) данный вид деятельности состоит из решения следующих задач:
7.1.7.3.1.1 Исполнитель должен проводить квалификационное тестирование в соответствии с квалификационными требованиями к программному элементу. Должна обеспечиваться гарантия того, что реализация каждого требования к программным средствам тестируется на соответствие. Результаты квалификационного тестирования должны быть документально оформлены.
7.1.7.3.1.2 Исполнитель должен обновлять пользовательскую документацию по мере необходимости.
7.1.7.3.1.3 Исполнитель должен оценивать проект, код, тесты, результаты тестирования и пользовательскую документацию, учитывая следующие критерии:
a) тестовое покрытие требований к программной составной части;
b) соответствие с ожидаемыми результатами;
c) осуществимость системного комплексирования и тестирования, если они проводятся;
d) осуществимость функционирования и сопровождения.
Результаты оценки должны быть документально оформлены.
7.1.7.3.1.4 Исполнитель должен поддерживать проведение аудитов в соответствии с 7.2.7. Результаты аудитов должны быть документально оформлены. Если и технические, и программные средства разрабатываются или комплексируются, то аудиты могут быть отсрочены до тех пор, пока не будет выполнено системное квалификационное тестирование.
7.1.7.3.1.5 После успешного завершения аудитов (если они проводились) исполнитель должен обновить и подготовить поставляемый программный продукт для системного комплексирования, системного квалификационного тестирования, инсталляции программных средств или поддержки приемки программных средств.