ГОСТ Р ИСО-МЭК 12207-2010 Процессы ЖЦ ПС. Процессы жизненного цикла программных средств
 Скачать 457.34 Kb.
|
|
b) создается и поддерживается свидетельство гарантии качества; c) идентифицируются и регистрируются проблемы и (или) несоответствия с требованиями; d) верифицируется соблюдение продукцией, процессами и действиями соответствующих стандартов, процедур и требований. 7.2.3.3 Виды деятельности и задачи При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса гарантии качества программных средств. 7.2.3.3.1 Реализация процесса Данный вид деятельности состоит из решения следующих задач: 7.2.3.3.1.1 Должен быть создан процесс обеспечения гарантии качества, удовлетворяющий условиям проекта. Цели процесса гарантии качества должны предусматривать, что программные продукты и процессы, используемые для обеспечения этих программных продуктов, соответствуют установленным требованиям и планам. 7.2.3.3.1.2 Процесс гарантии качества следует скоординировать со связными с ним процессами верификации программных средств (см. 7.2.4), валидации программных средств (см. 7.2.5), ревизии (см. 7.2.6) и аудита программных средств (см. 7.2.7). 7.2.3.3.1.3 План проведения действий и задач процесса гарантии качества должен разрабатываться, документально оформляться, реализовываться и сопровождаться в течение срока жизни контракта. План должен включать в себя: a) стандарты качества, методологии, процедуры и инструментарий для выполнения действий по обеспечению гарантии качества (или ссылки на официальную документацию организации); b) процедуры пересмотра контракта и их координацию; c) процедуры идентификации, сбора, регистрации, сопровождения и распространения записей о качестве; d) ресурсы, графики работ и ответственность за проведение действий по обеспечению гарантии качества; e) выбранные действия и задачи из поддерживающих процессов, такие как верификация программных средств (см. 7.2.4), валидация программных средств (см. 7.2.5), ревизии программных средств (см. 7.2.6), аудит (см. 7.2.7) и решение проблем в программных средствах (см. 7.2.8). 7.2.3.3.1.4 Планируемые и осуществляемые виды деятельности и задачи обеспечения гарантии качества должны быть выполнены. Если обнаруживаются проблемы или несоответствия с требованиями контракта, то они должны быть документированы и переданы в качестве исходных данных в процесс решения проблем (см. 7.2.8). Записи этих действий и задач, их выполнение, проблемы и решения проблем должны быть подготовлены и поддержаны. 7.2.3.3.1.5 Записи действий и задач гарантии качества должны быть доступны приобретающей стороне, как определено в контракте. 7.2.3.3.1.6 Должна обеспечиваться гарантия того, что лица, отвечающие за соответствие требованиям контракта, располагают организационной свободой, ресурсами и полномочиями для решения и верификации решаемых проблем. 7.2.3.3.2 Гарантии на продукты Данный вид деятельности состоит из решения следующих задач: 7.2.3.3.2.1 Должны предоставляться гарантии того, что все планы, требуемые по контракту, документированы, соответствуют условиям контракта, взаимно согласованы и выполняются надлежащим образом. 7.2.3.3.2.2 Должны обеспечиваться гарантии того, что программные продукты и связанная с ними документация соответствуют условиям контракта и реализуются в соответствии с планами. 7.2.3.3.2.3 При подготовке к поставке программных продуктов, должно гарантироваться, что они полностью удовлетворяют требованиям контракта и являются приемлемыми для приобретающей стороны. 7.2.3.3.3 Гарантии процесса Данный вид деятельности состоит из решения следующих задач: 7.2.3.3.3.1 Должна обеспечиваться гарантия того, что процессы жизненного цикла программных средств (поставки, разработки, функционирования, сопровождения и поддержки, включая гарантии качества), используемые для проекта, соответствуют условиям контракта и реализуются в соответствии с планами. 7.2.3.3.3.2 Должны обеспечиваться гарантии того, что внутренняя практика программной инженерии, среда разработки, среда тестирования и библиотеки соответствуют условиям контракта. 7.2.3.3.3.3 Должна обеспечиваться гарантия того, что требования главного контракта передаются вниз подрядчику и что программные продукты подрядчика удовлетворяют требованиям главного контракта. 7.2.3.3.3.4 Должна обеспечиваться гарантия того, что приобретающая сторона и другие стороны обеспечены требуемой поддержкой и кооперацией в соответствии с условиями контракта, договоренностями и планами. 7.2.3.3.3.5 Должна обеспечиваться гарантия того, что программный продукт и процесс измерений находятся в соответствии с установленными стандартами и процедурами. 7.2.3.3.3.6 Должна обеспечиваться гарантия того, что назначенный штатный персонал имеет навыки и знания, необходимые для удовлетворения требований проекта, и получает надлежащее обучение. 7.2.3.3.4 Гарантии качества систем Данный вид деятельности состоит из решения следующей задачи: 7.2.3.3.4.1 Дополнительные действия менеджмента качества могут быть обеспечены в соответствии с положениями [4]. 7.2.4 Процесс верификации программных средств 7.2.4.1 Цель Цель процесса верификации программных средств заключается в подтверждении того, что каждые программный рабочий продукт и (или) услуга процесса или проекта должным образом отражают заданные требования. 7.2.4.2 Выходы В результате успешного осуществления процесса верификации программных средств: a) разрабатывается и осуществляется стратегия верификации; b) определяются критерии верификации всех необходимых программных рабочих продуктов; c) выполняются требуемые действия по верификации; d) определяются и регистрируются дефекты; e) результаты верификации становятся доступными заказчику и другим заинтересованным сторонам. 7.2.4.3 Виды деятельности и задачи При реализации проекта необходимо осуществлять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса верификации программных средств. 7.2.4.3.1 Реализация процесса Данный вид деятельности состоит из решения следующих задач: 7.2.4.3.1.1 Должны быть определены условия реализации процесса, если проектом предусматриваются работы по верификации и необходима определенная степень организационной независимости этих работ. Требования проекта должны быть проанализированы на критичность. Критичность может быть оценена в терминах: a) потенциального наличия необнаруженной ошибки в требованиях к системе или программным средствам, приводящей к гибели или травматизму персонала, невыполнению задания, финансовому ущербу катастрофической утрате или повреждению оборудования; b) степени отработки технологии программных средств и рисков, связанных с ее применением; c) доступности фондов и ресурсов. 7.2.4.3.1.2 Если проектом предусматриваются работы по верификации, то должен быть установлен процесс верификации для проверки программного продукта. 7.2.4.3.1.3 Если проектом предусматриваются работы по независимой верификации, то должна быть выбрана квалифицированная организация, ответственная за проведение верификации. Данной организацией должны гарантироваться независимость и полномочия для проведения работ по верификации. 7.2.4.3.1.4 Должны быть определены программные продукты, требующие верификации, и конечные цели действий в течение жизненного цикла, основанные на области их применения, размерах, сложности и анализе критичности. Виды деятельности и задачи верификации, определенные в 7.2.4.3.2, включая соответствующие методы, технические приемы и инструментарий для выполнения задач, должны быть выбраны в зависимости от конечных целей действий в течение жизненного цикла и программных продуктов. 7.2.4.3.1.5 Должен быть разработан и документально оформлен план проведения верификации на основе установленных задач верификации. План должен содержать действия в течение жизненного цикла и предмет верификации программных продуктов, необходимые задачи по верификации для каждого действия в течение жизненного цикла и программного продукта, связанные с ними ресурсы, ответственность и графики проведения работ. План должен предусматривать процедуры направления отчетов о верификации приобретающей стороне и другим заинтересованным организациям. 7.2.4.3.1.6 Должен быть реализован план проведения верификации. Проблемы и несоответствия, обнаруженные при проведении верификации, должны служить входами в процесс решения проблем (см. 7.2.8). Все возникшие проблемы должны быть решены, а обнаруженные несоответствия устранены. Результаты действий по верификации должны быть доступны приобретающей стороне и другим заинтересованным организациям. 7.2.4.3.2 Верификация Данный вид деятельности состоит из решения следующих задач: 7.2.4.3.2.1 Верификация требований. Требования должны быть верифицированы с учетом следующих критериев: a) системные требования являются согласованными, выполнимыми и тестируемыми; b) системные требования соответственно распределены по техническим, программным элементам и ручным операциям согласно критериям проекта; c) требования к программным средствам согласованы, выполнимы, проверяемы и точно отражают системные требования; d) требования к программным средствам, связанные с безопасностью, защитой и критичностью, являются корректными, что показано соответствующими строгими методами. 7.2.4.3.2.2 Верификация проекта Проект должен быть верифицирован с учетом следующих критериев: a) проект корректируется, согласуется с требованиями и обеспечивает прослеживаемость к ним; b) проект осуществляет надлежащую последовательность событий, входы, выходы, интерфейсы, логические связи, назначение сроков и размеров финансирования, а также обнаружение ошибок, локализацию и восстановление; c) выбранный проект может быть выведен из требований; d) проект корректно реализует требования по безопасности, защищенности и другим критическим свойствам, как показано соответствующими строгими методами. 7.2.4.3.2.3 Верификация кода Код должен быть верифицирован с учетом следующих критериев: a) код является следствием проекта и требований тестируемости, правильности и соответствует установленным требованиям и стандартам, относящимся к кодированию; b) код осуществляет надлежащую последовательность событий, согласованные интерфейсы, корректные данные и поток команд управления, завершений, адекватного распределения времени и размеров финансирования, а также определение ошибок, локализацию и восстановление; c) выбранный код может следовать из проекта или требований; d) код корректно реализует требования по безопасности, защищенности и другим критическим свойствам, как показано соответствующими строгими методами. 7.2.4.3.2.4 Верификация комплексирования Комплексирование должно быть верифицировано с учетом перечисленных ниже критериев: a) программные компоненты и модули каждого программного элемента полностью и корректно комплектуются в программный элемент. b) технические и программные элементы, а также ручные операции системы комплексируются в систему; c) задачи комплексирования выполняются в соответствии с планом комплексирования. 7.2.4.3.2.5 Верификация документации Документация должна быть верифицирована с учетом перечисленных ниже критериев: a) документация является адекватной, полной и согласованной; b) подготовка документации осуществляется своевременно; c) менеджмент конфигурации документов следует установленным процедурам. 7.2.5 Процесс валидации программных средств 7.2.5.1 Цель Цель процесса валидации программных средств заключается в подтверждении того, что требования выполняются для конкретного применения рабочего программного продукта. 7.2.5.2 Выходы В результате успешного осуществления процесса валидации программных средств: a) разрабатывается и реализуется стратегия валидации; b) определяются критерии валидации для всей требуемой рабочей продукции; c) выполняются требуемые действия по валидации; d) идентифицируются и регистрируются проблемы; e) обеспечиваются свидетельства того, что созданные рабочие программные продукты пригодны для применения по назначению; f) результаты действий по валидации делаются доступными заказчику и другим заинтересованным сторонам. 7.2.5.3 Виды деятельности и задачи При реализации проекта необходимо выполнять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса валидации программных средств. 7.2.5.3.1 Реализация процесса Данный вид деятельности состоит из решения следующих задач: 7.2.5.3.1.1 Должны быть определены условия реализации процесса, если проектом предусматриваются работы по валидации и необходима определенная степень организационной независимости этих работ. 7.2.5.3.1.2 Если проект предусматривает работы по валидации, то должен быть установлен процесс валидации для подтверждающей проверки системного или программного продукта. Должны быть выбраны задачи валидации, определенные ниже, в том числе связанные с ними методы, технологии и инструментарий. 7.2.5.3.1.3 Если проект предусматривает независимые работы по валидации, то должна быть выбрана квалифицированная организация, ответственная за проведение работ. Эта организация должна гарантировать независимость и полномочия при выполнении задач валидации. 7.2.5.3.1.4 Должен быть разработан и документально оформлен план валидации. План должен включать в себя, по крайней мере: a) элементы, подвергаемые валидации; b) задачи валидации, которые будут выполняться; c) ресурсы, ответственности и графики выполнения работ по валидации; d) процедуры передачи отчетов приобретающей стороне и другим сторонам. 7.2.5.3.1.5 План валидации должен быть выполнен. Проблемы и несоответствия, обнаруженные в процессе работ по валидации, должны быть переданы процессу решения проблем в программных средствах (см. 7.2.8). Все проблемы и несоответствия должны быть устранены. Результаты действий по валидации должны быть доступны приобретающей стороне и другим заинтересованным организациям. 7.2.5.3.2 Валидация Данный вид деятельности состоит из решения следующих задач: Примечание - Для валидации помимо тестирования могут использоваться другие средства, такие как анализ, моделирование, имитация и т.п. 7.2.5.3.2.1 Готовить выбранные требования к тестированию, тестовые примеры и спецификации для анализа результатов тестирования. 7.2.5.3.2.2 Гарантировать, что требования к тестированию, тестовые примеры и спецификации отражают частные требования для конкретного применения. 7.2.5.3.2.3 Провести проверки выполнения 7.2.5.3.2.1 и 7.2.5.3.2.2, включая: a) тестирование в условиях повышенной нагрузки, граничных значений параметров и необычных входов; b) тестирование программного продукта на его способность изолировать и минимизировать влияние ошибок; то есть осуществлять плавную деградация после отказов, обращение к оператору за помощью в условиях повышенной нагрузки, граничных значений параметров и необычных входов; c) тестирование того, что основные пользователи могут успешно решать намеченные задачи, используя данный программный продукт. 7.2.5.3.2.4 Подтвердить, что программный продукт удовлетворяет своему назначению. 7.2.5.3.2.5 Провести тестирование программного продукта в выбранных областях заданной среды применения по назначению. 7.2.6 Процесс ревизии программных средств 7.2.6.1 Цель Цель процесса ревизии программных средств заключается в поддержке общего понимания с правообладателями прогресса относительно целей соглашения и того, что именно необходимо сделать для помощи в обеспечении разработки продукта, удовлетворяющего правообладателей. Ревизии программных средств применяются как на уровне менеджмента проекта, так и на техническом уровне и проводятся в течение всей жизни проекта. 7.2.6.2 Выходы В результате успешного осуществления процесса ревизии программных средств: a) выполняются технические ревизии и ревизии менеджмента на основе потребностей проекта; b) оцениваются состояние и результаты действий процесса посредством ревизии деятельности; c) объявляются результаты ревизии всем участвующим сторонам; d) отслеживаются для закрытия позиции, по которым необходимо предпринимать активные действия, выявленные в результате ревизии; e) идентифицируются и регистрируются риски и проблемы. 7.2.6.3 Виды деятельности и задачи При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса ревизии программных средств. 7.2.6.3.1 Реализация процесса Данный вид деятельности состоит из решения следующих задач: 7.2.6.3.1.1 Периодические ревизии должны проводиться в предварительно определенные сроки, указанные в плане (планах) проекта. Правообладателям следует определять потребность в проведении каких-либо целевых ревизий, в которых по согласованию могут принимать участие другие стороны. 7.2.6.3.1.2 Должны обеспечиваться все ресурсы, необходимые для проведения ревизий. Эти ресурсы включают в себя персонал, местоположение, средства обслуживания, технические средства, программные средства и инструментарий. 7.2.6.3.1.3 Стороны, участвующие в ревизии, должны договариваться о следующих позициях для каждой ревизии: повестке дня заседания, составе программных продуктов (результатов деятельности) и проблемах, подлежащих обсуждению; области применения и процедурах; исходных и итоговых критериях для ревизии. 7.2.6.3.1.4 Проблемы, выявленные при проведении ревизии, должны регистрироваться и, как и требуется, служить входом в процесс решения проблем в программных средствах (см. 7.2.8). 7.2.6.3.1.5 Результаты ревизии должны документироваться, включая оценку адекватности ревизии (например, принятие, непринятие или условное принятие результатов ревизии), и затем распространяться. 7.2.6.3.1.6 Участвующие стороны должны согласовывать итоговый результат ревизии, ответственность за позиции, требующие действий, и критерии завершения. 7.2.6.3.2 Ревизии менеджмента проекта Данный вид деятельности состоит из решения следующей задачи: 7.2.6.3.2.1 Состояние проекта должно быть оценено по отношению к планам проекта, графикам работ, стандартам и руководящим указаниям. Итоговые результаты ревизии необходимо представлять на рассмотрение соответствующему руководству, предусматривая: a) активизацию работ в соответствии с планом, основанную на оценке деятельности или состояния программного продукта; b) поддержание глобального управления проектом посредством соответствующего распределения ресурсов; c) изменение направления развития проекта или определение потребности в дополнительном планировании; d) оценку и руководство решением вопросов, связанных с риском, которые могут угрожать успеху проекта. 7.2.6.3.3 Технические ревизии Данный вид деятельности состоит из решения следующей задачи: 7.2.6.3.3.1 Технические ревизии должны проводиться для оценки программных продуктов или услуг с позиции рассмотрения и представления свидетельств того, что: а) они полностью укомплектованы; b) они соответствуют принятым стандартам и спецификациям; c) изменения к ним выполнены должным образом и влияют только на те области, которые определены процессом менеджмента конфигурации (см. 7.2.2); d) они полностью придерживаются установленных графиков работ; e) они готовы к выполнению последующих запланированных работ; f) их разработка, эксплуатация или сопровождение проводится в соответствии с планами, графиками, стандартами и руководящими указаниями проекта. 7.2.7 Процесс аудита программных средств 7.2.7.1 Цель Цель процесса аудита программных средств заключается в независимом определении соответствия выбранных продуктов и процессов требованиям, планам и соглашениям. 7.2.7.2 Выходы В результате успешного осуществления процесса аудита программных средств: a) разрабатывается и осуществляется стратегия аудита; b) согласно стратегии аудита определяется соответствие отобранных рабочих программных продуктов и (или) услуг или процессов требованиям, планам и соглашениям; c) аудиты проводятся соответствующими независимыми сторонами; d) проблемы, выявленные в процессе аудита, идентифицируются, доводятся до сведения ответственных за корректирующие действия и затем решаются. 7.2.7.3 Виды деятельности и задачи При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса аудита программных средств. 7.2.7.3.1 Реализация процесса Данный вид деятельности состоит из решения следующих задач: 7.2.7.3.1.1 Аудиторские проверки должны проводиться в предварительно установленные контрольные сроки, указанные в плане (планах) проекта. 7.2.7.3.1.2 Аудиторский персонал не должен нести какой-либо прямой ответственности за проверяемые программные продукты и действия. 7.2.7.3.1.3 Все ресурсы, необходимые для проведения аудитов, должны быть согласованы участвующими сторонами. Эти ресурсы включают в себя обеспечивающий персонал, место проведения, условия проведения, технические, программные и инструментальные средства. 7.2.7.3.1.4 Участвующим сторонам необходимо согласовывать следующие вопросы по каждому аудиту: повестку дня; состав проверяемых программных продуктов (и результаты деятельности); область распространения и процедуры аудита; а также исходные и итоговые критерии проведения аудита. 7.2.7.3.1.5 Проблемы, выявленные при проведении аудитов, должны регистрироваться и, как установлено, должны предаваться процессу решения проблем в программных средствах (см. 7.2.8). 7.2.7.3.1.6 Результаты аудита после его завершения должны быть документально оформлены и представлены проверяемой стороне. Проверяемая сторона должна подтвердить проверяющей стороне согласие с наличием проблем, обнаруженных при проведении аудита, и сообщить о планируемых решениях соответствующих проблем. 7.2.7.3.1.7 Стороны должны согласовывать результат аудиторской проверки, любые обязательства по позициям, требующим активных действий, и критерии их закрытия. 7.2.7.3.2 Аудит программных средств Данный вид деятельности состоит из решения следующей задачи: 7.2.7.3.2.1 Аудиторские проверки программных средств должны проводиться для гарантии того, что: a) когда кодирование выполнено, программные продукты (такие как программный элемент) отражают проектную документацию; b) обзор условий приемки и требования к тестированию, изложенные в документации, пригодны для приемки программной продукции; c) тестовые данные соответствуют спецификациям; d) программные продукты успешно протестированы и удовлетворяют спецификациям; e) отчеты об испытаниях правильны и расхождения между фактическими и ожидаемыми результатами устранены; f) документация пользователя соответствует стандартам; g) действия проведены в соответствии с утвержденными требованиями, планами и контрактом; h) затраты и графики работ согласуются с утвержденными планами. 7.2.8 Процесс решения проблем в программных средствах 7.2.8.1 Цель Цель процесса решения проблем в программных средствах заключается в обеспечении гарантии того, что все выявленные проблемы идентифицируются, анализируются, контролируются и подвергаются менеджменту для осуществления их решения. 7.2.8.2 Выходы В результате успешной реализации процесса решения проблем в программных средствах: a) разрабатывается стратегия менеджмента проблем; b) проблемы регистрируются, идентифицируются и классифицируются; c) проблемы анализируются и оцениваются для определения приемлемого решения (решений); d) выполняется решение проблем; e) проблемы отслеживаются вплоть до их закрытия; f) известно текущее состояние всех зафиксированных проблем. Примечание - Процесс решения проблем в программных средствах может использоваться или легко адаптироваться для менеджмента, отслеживания и управления заявками на изменения в программных средствах. 7.2.8.3 Виды деятельности и задачи При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми политиками организации и процедурами, относящимися к процессу решения проблем в программных средствах. 7.2.8.3.1 Реализация процесса Данный вид деятельности состоит из решения следующей задачи: 7.2.8.3.1.1 Должен быть создан процесс решения проблем для обработки всех проблем (в том числе несоответствий), обнаруженных в программных продуктах и действиях. Процесс должен соответствовать следующим требованиям: a) процесс должен образовывать замкнутую петлю, гарантируя что: - обо всех обнаруженных проблемах немедленно сообщается и они вводятся в процесс решения проблем, - по этим проблемам инициируются необходимые действия, - соответствующие стороны, как принято, информируются о существовании проблем, - причины устанавливаются, анализируются и, если возможно, устраняются, - решения и их распространение достигаются, - состояние проблемы отслеживается и отражается в отчетах, - отчеты о проблемах сопровождаются, как оговорено в контракте; b) в рамки процесса следует включать схему категоризации и расстановки проблем по приоритетам. Каждую проблему следует классифицировать по категории и приоритету для облегчения анализа тенденций и решения проблем; c) для обнаружения тенденций в известных проблемах должен проводиться соответствующий анализ; d) решения проблем и распространение решений должны оцениваться для того, чтобы определить, какие проблемы решены, неблагоприятные тенденции устранены, изменения корректно реализованы в соответствующих программных продуктах и действиях, а также были ли созданы дополнительные проблемы. 7.2.8.3.2 Решение проблем Данный вид деятельности состоит из решения следующей задачи: 7.2.8.3.2.1 При обнаружении проблемы (в том числе несоответствия) в программном продукте или действии должен быть подготовлен отчет, описывающий каждую обнаруженную проблему. Отчет о проблемах должен использоваться как часть приведенного выше процесса, образующего замкнутую петлю: от обнаружения проблем, через исследование, анализ, решение проблем и устранение их причин до обнаружения тенденций в рамках возникших проблем. 7.3 Процессы повторного применения программных средств Примечание - Пользователи настоящего стандарта, которые желают принять организационные методы повторного применения программных средств, могут захотеть дополнить условия настоящего стандарта требованиями из [1]. 7.3.1 Процесс проектирования доменов 7.3.1.1 Цель Цель процесса проектирования доменов заключается в разработке и сопровождении моделей доменов, архитектуры доменов и активов для доменов. 7.3.1.2 Выходы В результате успешного осуществления процесса проектирования доменов: a) выбираются формы представления модели и архитектуры домена; b) определяются границы домена и его взаимосвязи с другими доменами; c) разрабатывается модель домена, которая объединяет в себе существенные общие и различные свойства, возможности, концепции и функции в этом домене; d) разрабатывается архитектура домена, описывающая семейство систем в пределах домена, включая их общность и изменчивость; e) специфицируются активы, относящиеся к домену; f) соответствующие активы приобретаются или разрабатываются и поддерживаются в течение всего жизненного цикла; g) модели и архитектуры домена поддерживаются в течении всего их жизненного цикла. Примечание 1 - Проектирование доменов основано на повторном применении подхода к определению области применения (то есть определению домена), спецификации структуры (то есть архитектуры домена) и созданию активов (например, требований, конструкции, программного кода, документации) для класса систем, подсистем или приложений. Примечание 2 - Процесс, относящийся к проектированию доменов, может перекрываться с процессами разработки и сопровождения, использующими активы, созданные процессом проектирования доменов. 7.3.1.3 Виды деятельности и задачи При реализации проекта необходимо выполнять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами, относящимися к процессу проектирования доменов. Примечание - Более детальное множество действий и задач, согласующихся с видами деятельности и задачами, приведенными ниже, представлено в [1]. 7.3.1.3.1 Реализация процесса Данный вид деятельности состоит из решения следующих задач: 7.3.1.3.1.1 Разработчик доменов должен создавать и выполнять план проектирования доменов. 7.3.1.3.1.2 Разработчик доменов должен выбирать формы представления, которые будут использоваться для архитектур и моделей доменов. 7.3.1.3.1.3 Разработчик доменов должен определять процедуры получения, выработки решений и обеспечения обратной связи с менеджером активов каждый раз, когда возникают проблемы или заявки на изменения разработанных им активов. 7.3.1.3.2 Анализ доменов Данный вид деятельности состоит из решения следующих задач: 7.3.1.3.2.1 Разработчик доменов должен определять границы каждого домена и взаимосвязи между конкретным доменом и другими доменами. 7.3.1.3.2.2 Разработчик доменов должен идентифицировать текущие и предполагаемые потребности правообладателей программных продуктов в пределах этого домена. 7.3.1.3.2.3 Разработчик доменов должен создавать модели домена, используя формы представления, выбранные в действиях процесса реализации данного процесса. 7.3.1.3.2.4 Разработчик доменов должен составлять словарь, охватывающий терминологию для описания важных понятий доменов и взаимоотношений между сходными или общими активами домена. 7.3.1.3.2.5 Разработчик доменов должен классифицировать и документировать модели домена. 7.3.1.3.2.6 Разработчик доменов должен оценивать модели и словарь домена в соответствии с условиями выбранной техники моделирования и процедурами приемки и сертификации активов организации. 7.3.1.3.2.7 Разработчик доменов должен проводить анализ ревизий домена. Разработчики программных средств, менеджеры активов, эксперты домена и пользователи должны принимать участие в ревизиях. 7.3.1.3.2.8 Разработчик доменов должен представлять модели домена менеджеру активов. 7.3.1.3.3 Проектирование доменов Данный вид деятельности состоит из решения следующих задач: 7.3.1.3.3.1 Разработчик доменов должен создавать и документально оформлять архитектуру домена, согласовывать ее с моделью домена и следовать стандартам организации. 7.3.1.3.3.2 Архитектура домена должна оцениваться в соответствии с условиями выбранной техники проектирования архитектуры и процедурами приемки и сертификации активов организации. 7.3.1.3.3.3 Для каждого выбранного объекта, предназначенного для повторного применения, разработчик доменов должен разрабатывать и документально оформлять спецификацию активов. 7.3.1.3.3.4 Для каждого определенного актива спецификация должна оцениваться в соответствии с процедурами приемки и сертификации активов организации. 7.3.1.3.3.5 Разработчик доменов должен проводить ревизии проекта домена. Разработчики программных средств, эксперты домена и менеджеры активов должны участвовать в проведении этих ревизий. 7.3.1.3.3.6 Разработчик доменов должен предоставлять архитектуру домена менеджеру активов. 7.3.1.3.4 Обеспечение активов Для каждого разработанного или приобретенного актива данный вид деятельности состоит из решения следующих задач: 7.3.1.3.4.1 Разработчик доменов должен получать активы через приобретение или разработку. 7.3.1.3.4.2 Разработчик доменов должен документально оформлять и классифицировать активы. 7.3.1.3.4.3 Разработчик доменов должен оценивать активы в соответствии с процедурами приемки и сертификации активов организации. 7.3.1.3.4.4 Разработчик доменов должен проводить ревизии активов. Разработчики программных средств и менеджеры активов должны принимать участие в этих ревизиях. 7.3.1.3.4.5 Разработчик доменов должен представлять активы менеджеру активов. 7.3.1.3.5 Сопровождение активов Следующая задача, относящаяся к повторному применению, добавляется к процессу сопровождения программных средств, когда она применяется к сопровождению активов. 7.3.1.3.5.1 При анализе заявок на модификацию и выборе вариантов реализации активов разработчик доменов должен рассматривать: a) соответствие с моделями и архитектурой домена; b) воздействия на системы и программные продукты, которые используют активы; c) воздействия на будущих пользователей активов; d) воздействия на возможность повторного использования активов. 7.3.2 Процесс менеджмента повторного применения активов 7.3.2.1 Цель Цель процесса менеджмента повторного применения активов заключается в управлении жизненным циклом повторно применяемых активов от концепции до отмены применения. 7.3.2.2 Выходы В результате успешного осуществления процесса менеджмента повторного применения активов: a) документируется стратегия менеджмента активов; b) формируется схема классификации активов; c) определяются критерии приемки активов, сертификации и прекращения применения; d) приводится в действие механизм хранения и поиска активов; e) регистрируется использование активов; f) контролируются изменения в активах; g) пользователи активов оповещаются о выявленных проблемах, выполненных модификациях, созданных новых версиях и удалениях активов из мест хранения и механизмов поиска. 7.3.2.3 Виды деятельности и задачи При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента повторного применения активов. 7.3.2.3.1 Реализация процесса Данный вид деятельности состоит из решения следующих задач: 7.3.2.3.1.1 Менеджер активов должен разрабатывать план менеджмента активов с целью определения ресурсов и процедур для осуществления менеджмента активов. 7.3.2.3.1.2 Менеджер активов должен выполнять этот план. 7.3.2.3.1.3 План менеджмента активов должен пересматриваться в соответствии с процессом проведения ревизий. Инженеры домена и администраторы повторного применения программ должны принимать участие в ревизиях. 7.3.2.3.2 Определение условий хранения и поиска активов Данный вид деятельности состоит из решения следующих задач: 7.3.2.3.2.1 Менеджер активов должен осуществлять и поддерживать механизм хранения и поиска активов. 7.3.2.3.2.2 Менеджер активов должен разрабатывать, документально оформлять и сопровождать схему классификации, используемую для классификации активов. 7.3.2.3.2.3 Менеджер активов должен проводить ревизии механизма хранения и поиска активов в соответствии с процессом проведения ревизий. Администраторы повторного применения программ и инженеры доменов должны принимать участие в этих ревизиях. 7.3.2.3.3 Менеджмент и управление активами Для каждого актива данный вид деятельности состоит из решения следующих задач: 7.3.2.3.3.1 Каждый актив, принадлежащий менеджеру актива, должен быть оценен на основе критериев приемки и сертификации актива. 7.3.2.3.3.2 Каждый принятый актив должен быть доступен для повторного использования через механизм хранения и поиска активов. 7.3.2.3.3.3 Актив должен быть классифицирован в соответствии со схемой классификации повторного использования (при ее наличии). 7.3.2.3.3.4 Менеджер активов должен выполнять менеджмент конфигурации для активов, используя процесс менеджмента конфигурации программных средств. 7.3.2.3.3.5 Менеджер активов должен отслеживать каждое повторное применение актива и сообщать информацию разработчику доменов о текущих повторных использованиях актива. 7.3.2.3.3.6 Менеджер активов должен направлять заявки на модификации активов и отчеты о проблемах, полученных разработчиком доменов от пользователей повторно применяемых активов, для анализа и корректировки (модификации) планов и действий. 7.3.2.3.3.7 Менеджер активов должен непрерывно отслеживать и регистрировать эти заявки (отчеты) об активах и предпринимать последующие действия. 7.3.2.3.3.8 Менеджер активов должен оповещать всех пользователей повторно применяемого актива и разработчика доменов об обнаруженных в активе проблемах, сделанных модификациях в активе, новых версиях актива, а также об удалении актива из механизма хранения и поиска активов. 7.3.2.3.3.9 Менеджер активов должен удалять активы из механизма хранения и поиска активов согласно процедурам и критериям прекращения применения активов. 7.3.3 Процесс менеджмента повторного применения программ 7.3.3.1 Цель Цель процесса менеджмента повторного применения программ заключается в планировании, создании, руководстве, управлении и мониторинге повторного применения программ в организации при систематическом использовании возможностей повторного применения. 7.3.3.2 Выходы В результате успешного осуществления процесса менеджмента повторного применения программ: a) определяется стратегия повторного применения программ в организации, в том числе назначение, область применения, конечные и промежуточные цели; b) идентифицируются домены для потенциальных возможностей повторного применения; c) оценивается возможность систематического повторного применения организацией; d) оцениваются потенциальные возможности повторного применения каждого домена; e) оцениваются предложения повторного применения для гарантии того, что повторно используемый продукт пригоден для предложенного приложения; f) реализуется стратегия повторного применения в организации; g) устанавливаются обратная связь, коммуникации и механизмы оповещения, которые функционируют между взаимодействующими сторонами; h) контролируется и оценивается повторное применение программ. Примечание - Взаимодействующие стороны могут включать в себя администраторов повторного применения программ, менеджеров активов, инженеров доменов, разработчиков, операторов и сопровожденцев. 7.3.3.3 Виды деятельности и задачи При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента повторного применения программ. 7.3.3.3.1 Инициация Данный вид деятельности состоит из решения следующих задач: 7.3.3.3.1.1 Повторное применение программ в организации должно быть инициировано установлением стратегии организации в части повторного применения, которая включает в себя конечные цели, назначение, промежуточные цели и область применения. 7.3.3.3.1.2 Должен быть назван спонсор повторного применения. 7.3.3.3.1.3 Должны быть идентифицированы участники повторного применения программ и обозначены их роли. 7.3.3.3.1.4 Должна быть установлена функция, регулирующая повторное применение, для принятия полномочий и обязанностей по повторному применению программ в организации. 7.3.3.3.1.5 Должна быть установлена функция поддержки повторного применения программ. 7.3.3.3.2 Идентификация домена Данный вид деятельности состоит из решения следующих задач: 7.3.3.3.2.1 Администратор повторного применения программ, которому помогают соответствующий менеджер, разработчики доменов, пользователи и разработчики программных средств, должен идентифицировать и документировать домены для исследования возможностей повторного применения или для осуществления намерения организации практиковать повторное применение. 7.3.3.3.2.2 Администратор повторного применения программ, которому помогают соответствующие менеджеры, разработчики доменов, пользователи и разработчики программных средств, должен оценить домены для гарантии точного отражения стратегии повторного применения в организации. 7.3.3.3.2.3 Администратор повторного применения программ должен проводить ревизии в соответствии с процессом ревизий. Разработчики программных средств, разработчики доменов и пользователи должны принимать участие в этих ревизиях. 7.3.3.3.2.4 Когда получение более обширной информации о доменах и планах организации относительно будущих программных продуктов становится доступным или когда проводится анализ доменов, сами домены могут быть уточнены, а область их распространения пересмотрена администратором повторного применения программ. 7.3.3.3.3 Оценки повторного применения Данный вид деятельности состоит из решения следующих задач: 7.3.3.3.3.1 Администратор повторного применения программ должен оценивать возможности систематического повторного применения в организации. 7.3.3.3.3.2 Администратор повторного применения программ должен оценивать каждый домен, подлежащий рассмотрению, для определения потенциального успеха повторного применения в домене. 7.3.3.3.3.3 Администратор повторного применения программ должен выдавать рекомендации по уточнению стратегии и плана реализации повторного применения программ в организации, основанному на результатах оценок повторного применения. 7.3.3.3.3.4 Администратор повторного применения программ совместно с соответствующими приобретающими сторонами, поставщиками, разработчиками, операторами, сопровождающими сторонами, менеджерами активов, разработчиками доменов должен с приращением улучшать навыки, технологии, процессы повторного применения, структуру организации, а также показатели, которые вместе включают в себя инфраструктуру повторного применения. 7.3.3.3.4 Планирование Данный вид деятельности состоит из решения следующих задач: 7.3.3.3.4.1 Должен быть создан, документально оформлен и поддерживаться план реализации повторного применения программ для определения ресурсов и процедур по осуществлению повторного применения программ. 7.3.3.3.4.2 План должен анализироваться и оцениваться на полноту, осуществимость выполнения, а также на способность реализовать стратегию повторного применения в организации. К проведению оценки плана следует привлекать представителей, осуществляющих функцию регулирования повторного применения. 7.3.3.3.4.3 Принятие и поддержка плана реализации повторного применения программ должны вытекать из функции регулирования повторного применения и функций соответствующих менеджеров. 7.3.3.3.4.4 Администратор повторного применения программ должен проводить ревизии в соответствии с процессом ревизий. Представители от функции регулирования повторного применения и соответствующие менеджеры должны принимать участие в этих ревизиях. 7.3.3.3.5 Выполнение и управление Данный вид деятельности состоит из решения следующих задач: 7.3.3.3.5.1 Действия, предусмотренные планом реализации повторного применения программ, должны выполняться в соответствии с планом. 7.3.3.3.5.2 Администратор повторного применения программ должен осуществлять мониторинг процесса продвижения повторного применения программ в соответствии со стратегией повторного применения программ в организации, а также проводить необходимые корректировки плана для реализации этой стратегии. 7.3.3.3.5.3 Проблемы и несоответствия, которые возникают в процессе выполнения плана реализации повторного применения программ, должны быть зарегистрированы и устранены. 7.3.3.3.5.4 Администратор повторного применения программ должен периодически подтверждать финансовую поддержку менеджмента, поддержку и обязательства по программе повторного применения. 7.3.3.3.6 Ревизии и оценивание Данный вид деятельности состоит из решения следующих задач: 7.3.3.3.6.1 Администратор повторного применения программ должен периодически оценивать повторно применяемые программы для достижения стратегии повторного применения в организации, продолжающейся пригодности и результативности повторного применения программ. 7.3.3.3.6.2 Администратор повторного применения программ должен представлять результаты оценок и информацию об извлеченных уроках для реализации функции регулирования повторного применения и соответствующим менеджерам. 7.3.3.3.6.3 Администратор повторного применения программ должен давать рекомендации и проводить изменения в повторно применяемых программах, соответственно расширяя и улучшая эти программы. Приложение А (обязательное). Процесс адаптации Приложение А (обязательное) А.1 Введение В данном приложении сформулированы требования к адаптации настоящего стандарта. Примечание - Адаптация не является требованием соответствия стандарту. Фактически адаптация не разрешается, если сделано заявление о "полном соответствии". Если же сделано заявление об "адаптированном соответствии", то адаптация должна выполняться в соответствии с изложенным ниже процессом. А.2 Процесс адаптации А.2.1 Цель процесса адаптации Цель процесса адаптации состоит в приспособлении процессов, представленных в настоящем стандарте, для удовлетворения требований, отражающих специфические обстоятельства или факторы: a) воздействующие извне на организацию, которая использует настоящий стандарт в соответствии с соглашением; b) влияющие на проект, который должен соответствовать соглашению, ссылающемуся на настоящий стандарт; c) отражающие потребности организации в поставке продукции и услуг. А.2.2 Результаты процесса адаптации В результате успешной реализации процесса адаптации а) определяются модифицированные процессы жизненного цикла для достижения целей и результатов модели жизненного цикла. А.2.3 Деятельность в процессе адаптации При адаптации настоящего стандарта в интересах организации или проекта должны быть выполнены следующие задачи в соответствии с применяемыми политиками и процедурами в отношении процесса адаптации. А.2.3.1 Идентифицировать и документировать обстоятельства, влияющие на адаптацию. Эти влияния включают (но не ограничиваются только перечисленными ниже): a) стабильность и разнообразие среды функционирования; b) коммерческие и эксплуатационные риски, касающиеся заинтересованных сторон; c) новизну, размеры и сложность; d) дату начала и продолжительность применения; e) вопросы целостности, такие как безопасность, защищенность, секретность, удобство применения, доступность; f) вновь возникающие технологические возможности; g) профиль бюджета и доступные организационные ресурсы; h) готовность предоставления услуг обеспечивающими системами; i) роли и обязанности в полном жизненном цикле системы; j) необходимость соответствия с другими стандартами. А.2.3.2 При наличии свойств, критичных по отношению к системе, принимать во внимание структуры жизненного цикла, рекомендованные или установленные в качестве обязательных стандартами, соответствующими области критичности. А.2.3.3 Получать исходные данные от всех сторон, затрагиваемых решениями по адаптации, что включает в себя, по меньшей мере: a) правообладателей системы; b) заинтересованные стороны соглашения, заключенного организацией; c) добавление нового качества в организационные функции. А.2.3.4 Принимать решения по адаптации в соответствии с процессом менеджмента решений для достижения целей и выходов выбранной модели жизненного цикла. Примечание 1 - Организации устанавливают стандартные модели жизненного цикла как часть процесса менеджмента моделей жизненного цикла. Для организации может быть приемлемым адаптировать процессы, представленные в настоящем стандарте, для достижения целей и выходов стадий жизненного цикла в модели, выбранной организацией. Примечание 2 - В рамках проектов выбирается как часть процесса планирования проектов организационно установленная модель жизненного цикла для конкретного проекта. Может быть приемлемым адаптировать организационно принятые процессы для достижения целей и выходов стадий жизненного цикла выбранной модели. Примечание 3 - В случаях, когда проекты непосредственно используют настоящий стандарт, может быть приемлемым адаптировать процессы, представленные в настоящем стандарте, для достижения целей и выходов стадий подходящей модели жизненного цикла. А.2.3.5 Отбирать процессы жизненного цикла, требующие адаптации, и удалять отдельные выходы, виды деятельности или задачи. Примечание 1 - Независимо от адаптации организации и проекты всегда позволяют осуществлять процессы, которые достигают дополнительных выходов или реализуют дополнительные виды деятельности и задачи, помимо тех, которые требуются для соответствия настоящему стандарту. Примечание 2 - Организация или проект могут столкнуться с ситуацией, когда возникает желание модифицировать некоторые условия настоящего стандарта. Таких изменений следует избегать, поскольку они могут иметь непредсказуемые последствия для других процессов, выходов, видов деятельности или задач. Если необходимо, то модификация проводится посредством исключения определенных условий и тщательного рассмотрения последствий таких исключений. Выдвигается требование адаптированного соответствия, при этом реализуется процесс, с помощью которого достигаются дополнительные результаты или выполняются дополнительные виды деятельности и задачи в адаптированном варианте. Приложение В (обязательное). Эталонная модель процессов для целей оценки Приложение В (обязательное) В.1 Введение Подразумевается, что некоторые пользователи настоящего стандарта могут пожелать оценивать определенные реализуемые процессы в соответствии с [20]. В настоящем приложении рассматривается эталонная модель процессов (ЭМП), пригодная для совместного использования с настоящим стандартом. Исходными процессами для ЭМП служат процессы, описанные в основной части настоящего стандарта (разделы 5, 6 и 7). В каждом случае наименование, формулировка цели и выходов для каждого процесса основной части настоящего стандарта ссылаются на применение настоящего приложения. В некоторых случаях процессы в основной части стандарта имеют область применения слишком обширную для эффективной оценки. Поэтому с целью оценки в таких случаях в настоящее приложение добавлены процессы более низкого уровня. Каждый из таких дополнительных процессов более низкого уровня отражает разработку одного из видов деятельности связанного с ним процесса из основной части настоящего стандарта. В.2 Соответствие с ИСО/МЭК 15504-2 В.2.1 Общие положения Эталонная модель процессов, представленная в настоящем приложении, приспособлена для использования в процессе аттестации, выполняемой в соответствии с [20]. Часть 2. Проведение аттестации (ISO/IEC 15504-2, Information Technology - Process Assessment - Part 2: Performing an assessment). В подразделе 6.2 второй части [20] содержатся требования к эталонным моделям процессов, подходящим для аттестации с помощью настоящего стандарта. В последующих подразделах настоящего приложения цитируются требования к ЭМП и описывается, как они соответствуют требованиям настоящего стандарта. Выделенный курсовом текст цитирует требования из второй части [20], а текст, набранный прямым шрифтом, описывает способ, с помощью которого требование удовлетворяется в контексте настоящего стандарта. В.2.2 Требования к эталонным моделям процессов |