ГОСТ Р ИСО-МЭК 12207-2010 Процессы ЖЦ ПС. Процессы жизненного цикла программных средств
 Скачать 457.34 Kb.
|
|
портфель проектов (project portfolio): Совокупность проектов, направленных на достижение стратегических целей организации 4.31 квалификация (qualification): Процесс демонстрации, определяющий, способен ли какой-либо объект полностью удовлетворять заданным требованиям 4.32 квалификационное требование (qualification requirement): Совокупность критериев или условий, которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как соответствующий спецификациям и готовый для применения в заданном окружении или интеграции с системой, для которой он предназначен 4.33 квалификационное тестирование (qualification testing): Тестирование, проводимое разработчиком и санкционированное приобретающей стороной (при необходимости) с целью демонстрации того, что программный продукт удовлетворяет спецификациям и готов для применения в заданном окружении или интеграции с системой, для которой он предназначен 4.34 гарантия качества (quality assurance): Все запланированные и систематические действия, выполняемые в рамках системы качества и продемонстрированные надлежащим образом для обеспечения соответствующей уверенности в том, что объект полностью удовлетворяет требованиям к качеству Примечание 1 - Существуют как внутренние, так и внешние цели гарантии качества: a) внутренняя гарантия качества: в пределах организации гарантия качества обеспечивает уверенность руководству организации; b) внешняя гарантия качества: в контрактных ситуациях гарантия качества обеспечивает уверенность заказчику или другим сторонам. Примечание 2 - Некоторые действия по управлению качеством и гарантии качества взаимосвязаны. Примечание 3 - До тех пор, пока требования к качеству полностью не удовлетворяют потребностям пользователя, гарантия качества не может обеспечить необходимой уверенности. 4.35 выпуск (release): Конкретная версия элемента конфигурации, которая становится доступной для специфической цели (например, выпуск теста) 4.36 заявка на участие в предложенном тендере (request for proposal tender): Документ, используемый приобретающей стороной как средство для объявления своего намерения стать потенциальным покупателем и приобрести конкретную систему, программный продукт или программную услугу 4.37 ресурс (resource): Актив, который используется или потребляется в ходе выполнения процесса 4.38 снятие с эксплуатации (retirement): Прекращение активной поддержки эксплуатирующей и сопровождающей организацией, частичная или полная замена новой системой или инсталляция обновленной системы 4.39 защита (защищенность) (security): Предохранение информации и данных с тем, чтобы неуполномоченные лица или системы не могли их читать или изменять, а уполномоченным лицам или системам не было отказано в доступе к ним 4.40 услуга (service): Выполнение действий, работы или обязанностей, связанных с продуктом 4.41 программная составная часть (software item): Исходный код, объектный код, контрольный код, контрольные данные или совокупность этих составных частей Примечание - Программная составная часть может рассматриваться как системный элемент в [18]. 4.42 программный продукт (software product): Совокупность компьютерных программ, процедур и, возможно, связанных с ними документации и данных 4.43 программный блок (software unit): Отдельная компилируемая часть кода 4.44 стадия (stage): Период в пределах жизненного цикла некоторого объекта, который относится к состоянию его описания или реализации Примечание 1 - В настоящем стандарте принято, что стадии относятся к основному развитию и достижению контрольных точек этим объектом в течение его жизненного цикла. Примечание 2 - Стадии могут быть взаимно перекрывающимися. 4.45 правообладатель (stakeholder): Лицо или организация, имеющие право, долю, требование или интерес в системе или в обладании ее характеристиками, удовлетворяющими ее потребности и ожидания 4.46 задание на выполнение работы (statement of work): Документ, используемый приобретающей стороной как средство для описания и конкретизации задач, которые должны быть выполнены по условиям контракта 4.47 поставщик (supplier): Организация или лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги Примечание 1 - "Поставщиком" может быть подрядчик, производитель, торговец или продавец. Примечание 2 - Иногда приобретающая сторона и поставщик являются частью одной и той же организации. 4.48 система (system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей Примечание 1 - Система может рассматриваться как продукт или предоставляемые им услуги. Примечание 2 - На практике интерпретация данного термина зачастую уточняется с помощью ассоциативного существительного, например, "система самолета". В некоторых случаях слово "система" может заменяться контекстно-зависимым синонимом, например, "самолет", хотя это может впоследствии затруднить восприятие системных принципов. 4.49 системный элемент (system element): Представитель совокупности элементов, образующих систему Примечание - Системный элемент является отдельной частью системы, которая может быть создана для полного выполнения заданных требований. Системный элемент может представлять собой технические и программные средства, данные, людей, процессы (например, процессы для обеспечения услуг пользователям), процедуры (например, инструкции оператору), средства, материалы и природные объекты (например, вода, живые организмы, минералы) или любые их сочетания. 4.50 задача (task): Требование, рекомендация или разрешенное действие, предназначенное для содействия достижению одного или более выходов процесса 4.51 тестовое покрытие (test coverage): Степень, с которой данный тест проверяет требования для системы или программного продукта 4.52 тестируемость (testability): Степень, с которой объективный и физически реализуемый тест может быть спроектирован для определения того, что требование выполняется 4.53 пользователь (user): Лицо или группа лиц, извлекающих пользу из системы в процессе ее применения Примечание - Роль пользователя и роль оператора могут выполняться одновременно или последовательно одним и тем же человеком или организацией. 4.54 валидация (validation): Подтверждение (на основе представления объективных свидетельств) того, что требования, предназначенные для конкретного использования или применения, выполнены [3] Примечание - Валидация в контексте жизненного цикла представляет собой совокупность действий, гарантирующих и обеспечивающих уверенность в том, что система способна реализовать свое предназначение, текущие и перспективные цели. 4.55 верификация (verification): Подтверждение (на основе представления объективных свидетельств) того, что заданные требования полностью выполнены [3] Примечание - Верификация в контексте жизненного цикла представляет собой совокупность действий по сравнению полученного результата жизненного цикла с требуемыми характеристиками для этого результата. Результатами жизненного цикла могут являться (но не ограничиваться ими): заданные требования, описание проекта и непосредственно система. 4.56 версия (version): Идентифицированный экземпляр составной части Примечание - Модификация какой-либо версии программного продукта, воплощенная в новой версии, требует действий менеджмента конфигурации. 5 Применение настоящего стандарта В разделе 5 представлен обзор процессов жизненного цикла программных средств, которые могут быть использованы для приобретения, поставки, разработки, применения по назначению, сопровождения и прекращения применения программных продуктов и услуг. Целью обзора является предоставление "дорожной карты" пользователям настоящего стандарта для того, чтобы они могли ориентироваться в нем и применять его осмысленно. 5.1 Ключевые понятия В подразделе 5.1 приведены ключевые понятия, предназначенные для изучения и применения настоящего стандарта. В некоторых случаях общеупотребимые слова используются в специфическом смысле. Ниже будут также описаны такие специальные применения. Дальнейшие уточнения этих понятий можно найти в [16]. Примечание - ИСО/МЭК TО 24748 "Руководство по менеджменту жизненного цикла" может также способствовать последующим уточнениям. 5.1.1 Отношения между программными продуктами и программными услугами В общем случае настоящий стандарт применяется как для программных продуктов, так и для программных услуг. Условия конкретных процессов определяют их применимость. Примечание - Определения процессов, требования и руководства провайдерам услуг для предоставления управляемых услуг приведены в [26]. 5.1.2 Отношения между системами и программными средствами Настоящий стандарт устанавливает строгую связь между системой и применяемыми в ней программными средствами. Такая связь основывается на общих принципах системной инженерии. Программное средство трактуется как единая часть общей системы, выполняющая определенные функции в данной системе, что осуществляется посредством выделения требований к программным средствам из требований к системе, проектирования, производства программных средств и объединения их в систему. Этот принцип является фундаментальной предпосылкой для настоящего стандарта, в котором программные средства всегда существуют в контексте системы, даже если система состоит из единственного процессора, выполняющего программы. В таком случае программный продукт или услуга всегда рассматриваются как одна из составных частей системы. Например, в настоящем стандарте проводится различие между анализом системных требований и анализом требований к программным средствам, так как в общем случае построение системной архитектуры определяет системные требования для различных составных частей системы, а анализ требований к программным средствам предопределяет требования к ним, исходя из системных требований, назначенных каждой программной составной части. Конечно, в некоторых случаях непрограммных элементов в системе может быть настолько мало, что можно не делать различия между анализом системы и анализом программных средств. Настоящий стандарт имеет сильную взаимосвязь с [18] и может использоваться вместе с ним. Во многих случаях процессы в настоящем стандарте непосредственно соответствуют процессам в [18], но с некоторой спецификой для программных продуктов и услуг. Примечательным примером является то, что процесс реализации программных средств в настоящем стандарте является специальным, частным случаем процесса реализации, приведенного в [18]. В случае, если система имеет важные непрограммные элементы, то организация может по желанию применять [18] для обеспечения соответствующих процессов жизненного цикла. Для каждого программного элемента системы организации следует применять процесс реализации программных средств из настоящего стандарта для создания программного элемента. В случае, если количество непрограммных средств системы минимально, то организация может по своему усмотрению применять настоящий стандарт, не ссылаясь на [18]. В настоящем стандарте содержится дополнительный процесс системного уровня, тем не менее приспособленный к потребностям программных средств и предназначенный для обеспечения минимально приемлемого системного контекста для программных средств. В случае, если настоящий стандарт применяется в сочетании с [18], то должно учитываться любое незначительное несоответствие в терминологии. В [18] производится декомпозиция системы на совокупность системных "элементов". Некоторые из этих элементов могут определяться как программные продукты, которые реализуются с использованием настоящего стандарта. В настоящем стандарте применяется термин "составная часть" для указания на некоторый основной элемент системы. Короче говоря, в настоящем стандарте используется термин "составная часть" тогда, когда в [18] используется термин "элемент программного средства". Некоторые составные части могут, в конечном счете, назначаться как объект менеджмента конфигурации; тогда они называются "составными частями конфигурации". Процесс проектирования архитектуры программных средств преобразует составные части в "компоненты", а процесс детального проектирования программных средств переводит "компоненты" в "программные блоки". 5.1.3 Организации и стороны В настоящем стандарте термины "организация" и "сторона" тесно связаны. Организация - это группа лиц с определенными обязанностями и полномочиями, объединенных для реализации некоторых конкретных целей, таких как клуб, союз, корпорация или общество. Если организация полностью или частично входит в контрактное соглашение (договор), то это - сторона. Стороны могут быть из одной или из разных организаций. Отдельное лицо является примером организации, если на него возлагается определенная ответственность и полномочия. Организация или сторона получают свои наименования от процессов, за которые они ответственны. Например, организация называется приобретающей стороной, если она выполняет процесс приобретения. Таким образом, когда следующие термины используются в настоящем стандарте, они не имеют своего изначального значения, а вместо этого указывают на организацию или сторону, ответственную за выполнение процесса со сходным названием: приобретающая сторона, поставщик, исполнитель, сопровождающая сторона и оператор. В настоящем стандарте применяются также другие термины по отношению к организации: "пользователь" - может быть организацией, которая извлекает выгоду от применения программного продукта или услуги; "заказчик" - рассматривается совместно как пользователь и приобретающая сторона; "правообладатель" - рассматривается как организация, заинтересованная в успехе проекта. Процессы и организации (стороны) связаны только функционально. Настоящий стандарт не диктует или не включает в себя структуру для организации (стороны). Процессы в настоящем стандарте составляют полную совокупность для охвата различных организаций. Организация (малая или крупная) в зависимости от ее деловых целей или стратегии приобретения может выбрать подходящую совокупность процессов (а также связанных с ними действий и задач) для выполнения этих целей. Организация может выполнять один или несколько процессов. Например, по условиям контракта или применения настоящего стандарта конкретная сторона не должна выполнять ни процесс приобретения, ни процесс поставки, но она может выполнять другие процессы. Процесс может реализовываться одной или несколькими организациями. Примером процесса, выполняемого более чем одной организацией, является процесс ревизии программных средств. Настоящий стандарт предназначен для применения двумя или большим числом организаций (как внутри, так и вне организаций). Если он применяется внутри организации, то две стороны соглашения обычно действуют согласно положениям, установленным в соглашении, которые могут изменяться с соблюдением принятых правил при различных обстоятельствах. Если он применяется при отношениях с внешними сторонами, то стороны соглашения обычно действуют согласно положениям, изложенным в контракте. Для того, чтобы облегчить применение настоящего стандарта как для внутренних целей, так и для контрактных отношений, задачи выражаются на языке контракта. Если стандарт применяется для внутренних целей, то положения контракта следует интерпретировать как установленную в пределах организации исполнительскую дисциплину. Для целей настоящего стандарта предполагается, что любой проект осуществляется в пределах контекста организации. Это важно, так как программный проект зависит от различных результатов, производимых деловыми процессами организации, например, найма работников для укомплектования штатного персонала проекта и средств обеспечения проекта. Для этой цели настоящий стандарт предоставляет совокупность процессов "организационного обеспечения проекта". Предполагается, что эти процессы не охватывают ни деловой деятельности, ни какого-либо отдельного процесса проекта. Вместо этого процессы, рассматриваемые в совокупности, предназначаются для установления минимального множества зависимостей, которые проект возлагает на организацию. 5.1.4 Внедрение на уровне организации и на уровне проекта Современные организации, осуществляющие свою деятельность в области программного обеспечения, стремятся разрабатывать устойчивую совокупность процессов жизненного цикла программных средств, которые применяются по нескольку раз для программных проектов в деловой сфере. Поэтому настоящий стандарт предназначен для внедрения либо на уровне организации, либо на уровне проекта. Организации следует внедрить стандарт и дополнить его соответствующими процедурами, практическими рекомендациями, инструментарием и политиками. Программный проект организации обычно следует согласовывать в большей степени с процессами организации, чем согласовывать непосредственно с настоящим стандартом. В некоторых случаях проекты могут выполняться организацией, которая не имеет конкретной совокупности процессов, принятых на организационном уровне. В этом случае положения настоящего стандарта могут применяться непосредственно к таким проектам. 5.1.5 Адаптация Основные действия, необходимые для адаптации настоящего стандарта, определены в приложении А. Следует заметить, что адаптация может снизить восприятие значимости требований соответствия настоящему стандарту. Это происходит потому, что другим организациям трудно оценить степень, с которой адаптация может исключить важные для них положения. Организация, выдвигающая одностороннее утверждение о соответствии настоящему стандарту, может посчитать выгодным для себя требование полного соответствия меньшему числу процессов вместо адаптированного соответствия большему числу процессов. 5.1.6 Временные отношения между процессами В настоящем стандарте процессы, входящие в них действия и задачи располагаются в виде упорядоченной последовательности, подходящей для пояснений. Эта последовательность не предполагает или не устанавливает какой-либо зависимости от времени. Из-за невозможности достичь единого мнения или применить универсальную, развернутую во времени последовательность пользователь настоящего стандарта может самостоятельно выбирать и назначать процессы, виды деятельности и задачи как наиболее подходящие и эффективные. Настоящий стандарт способствует выполнению итераций между действиями и рекурсий в пределах отдельных действий для того, чтобы нейтрализовать нежелательное влияние любой подразумевающейся последовательности действий и задач. Стороны, применяющие настоящий стандарт, ответственны за выбор модели жизненного цикла для проекта и отображение процессов, действий и задач в этой модели. 5.1.7 Оценивание по отношению к верификации и валидации Организации, заинтересованные в каком-либо процессе жизненного цикла, проводят оценку результатов такого процесса. Процессы верификации и валидации программных средств предусматривают возможность проведения дополнительных оценок. Эти процессы реализуются приобретающей стороной, поставщиком или независимой стороной для верификации и валидации продуктов с различной степенью в зависимости от проекта. Такие оценки не дублируют или не заменяют другие оценки, но дополняют их. Дополнительные возможности для оценивания предусматриваются процессами ревизий программных средств, аудита программных средств, обеспечения гарантий качества программных средств и менеджмента моделей жизненного цикла. 5.1.8 Критерии для процессов Настоящий стандарт устанавливает структуру работ в пределах жизненного цикла программных средств. Жизненный цикл начинается от замысла или потребности, которая может быть удовлетворена полностью или частично программным средством, и завершается прекращением применения этого программного средства. Такая архитектура создается совокупностью процессов и взаимосвязями между этими процессами. Определение процессов жизненного цикла основывается на двух базовых принципах: связности и ответственности. Принцип связности: процессы жизненного цикла являются связными и соединяются оптимальным образом, считающимся практичным и выполнимым. Принцип ответственности: процесс передается под ответственность какой-либо организации или стороне в пределах жизненного цикла программного средства. 5.1.9 Описание процессов Процессы в настоящем стандарте описываются способом, подобным способу, представленному в ИСО/МЭК 15288, для того, чтобы обеспечить использование обоих стандартов в одной организации или проекте. Каждый процесс настоящего стандарта описывается в терминах следующих атрибутов: - наименование - передает область применения процесса как целого; - цель - описывает конечные цели выполнения процесса; - выходы - представляют собой наблюдаемые результаты, ожидаемые при успешном выполнении процесса; - деятельность - является перечнем действий, используемых для достижения выходов; - задачи - представляют собой требования, рекомендации или допустимые действия, предназначенные для поддержки достижения выходов процесса. Дополнительные подробности относительно подобной формы описания процессов представлены в [27]. 5.1.10 Общие характеристики процессов Атрибуты, описанные в 5.1.9, характеризуют специфику каждого процесса. Если реализуемый процесс соответствует этим атрибутам, то специально определенная цель процесса и его результаты достигаются посредством реализации определенной деятельности. В дополнение к описанным атрибутам процессы могут характеризоваться другими атрибутами, общими для всех процессов. В [20] определяются общие атрибуты процессов, которые характеризуют шесть уровней достижений возможностей процессов в пределах структуры их измерений. Перечень атрибутов процессов, определенных в [20], которые вносят вклад в достижение более высоких уровней возможностей процессов, приведен в приложении В. 5.1.11 Декомпозиция процессов Каждый процесс, представленный в настоящем стандарте, удовлетворяет общему описанию, приведенному в 5.1.9. С целью более подробного описания процессы иногда подвергают декомпозиции на более мелкие части. Некоторые процессы декомпозируют в совокупность действий и (или) в процессы более низкого уровня. Процесс более низкого уровня описывается тогда, когда декомпозированная часть процесса сама удовлетворяет критериям, характеризующим процесс. Деятельность используется тогда, когда определенная часть процесса, полученная в результате декомпозиции, не является процессом. Деятельность может рассматриваться просто как набор задач. Иногда полезно выполнить декомпозицию процессов на процессы более низкого уровня с более четким уровнем детализации. Некоторые процессы более низкого уровня описываются исключительно для целей оценки. Такие процессы не представлены в основной части настоящего стандарта, но содержатся в приложении В. В каждом случае оценка процесса более низкого уровня, описанного в приложении В, является результатом развития конкретного действия связанного с ним процесса из основной части настоящего стандарта. Задача выражается в форме требования, рекомендации или допустимого действия, предназначенных для поддержки достижения выходов процесса. Для этой цели в настоящем стандарте используются вспомогательные глаголы "должен", "следует" и "может", чтобы подчеркнуть различие между разными формами задач. Глагол "должен" используется для выражения условия, требуемого для соответствия, "следует" - для выражения рекомендации среди других возможностей и "может" - для того, чтобы отразить направление допустимых действий в пределах ограничений настоящего стандарта. Дополнительный справочный материал представлен в виде необязательных примечаний или необязательных приложений. 5.1.12 Модели и стадии жизненного цикла Процесс жизни любой системы или программного продукта может быть описан посредством модели жизненного цикла, состоящей из стадий. Модели могут использоваться для представления всего жизненного цикла от замысла до прекращения применения или для представления части жизненного цикла, соответствующей текущему проекту. Модель жизненного цикла представляется в виде последовательности стадий, которые могут перекрываться и (или) повторяться циклически в соответствии с областью применения, размером, сложностью, потребностью в изменениях и возможностях. Каждая стадия описывается формулировкой цели и выходов. Процессы и действия жизненного цикла отбираются и исполняются на этих стадиях для полного удовлетворения цели и результатам каждой стадии. Различные организации могут использовать различные стадии в пределах жизненного цикла. Однако каждая стадия реализуется организацией, ответственной за эту стадию, с надлежащим рассмотрением информации, имеющейся в планах жизненного цикла и решениях, принятых на предшествующих стадиях. Аналогичным образом организация, ответственная за текущую стадию, ведет записи принятых решений и записи допущений, относящихся к последующим стадиям данного жизненного цикла. Настоящий стандарт не требует использования какой-либо конкретной модели жизненного цикла. Однако он требует, чтобы в каждом проекте определялась подходящая модель жизненного цикла, предпочтительно та, которая уже выбиралась организацией для применения в различных проектах. Применение модели жизненного цикла обеспечивает средства для установления зависимой от времени последовательности, необходимой для менеджмента проекта. Кроме того, настоящий стандарт не содержит требований использования какой-либо заданной совокупности стадий. Пример совокупности стадий жизненного цикла системы включает в себя стадии концепции, разработки, производства, применения по назначению, поддержки и прекращения применения. Примером совокупности стадий жизненного цикла программного продукта является разработка, применение по назначению и сопровождение. Описаны различные типы или классы моделей жизненного цикла. Примеры этих типов моделей известны под такими наименованиями, как каскадная, пошаговая разработка, эволюционная и спиральная разработка. Следует отметить, что простой выбор наименования типа модели не удовлетворяет требованию определить модель, состоящую из стадий с определенными целями и результатами, достигнутыми посредством процессов настоящего стандарта. Примечание - ИСО/МЭК ТО 24748 содержит дополнительные детали, относящиеся к моделям и стадиям жизненного цикла. 5.2 Организация настоящего стандарта 5.2.1 Категории процессов жизненного цикла Настоящий стандарт группирует различные виды деятельности, которые могут выполняться в течение жизненного цикла программных систем, в семь групп процессов. Каждый из процессов жизненного цикла в пределах этих групп описывается в терминах цели и желаемых выходов, списков действий и задач, которые необходимо выполнять для достижения этих результатов. a) процессы соглашения - два процесса (см. 5.2.2.1.1 и 6.1); b) процессы организационного обеспечения проекта - пять процессов (см. 5.2.2.1.2 и 6.2); c) процессы проекта - семь процессов (см. 5.2.2.1.3 и 6.3); d) технические процессы - одиннадцать процессов (см. 5.2.2.1.4 и 6.4); e) процессы реализации программных средств - семь процессов (см. 5.2.2.2.1 и 7.1); f) процессы поддержки программных средств - восемь процессов (см. 5.2.2.2.2 и 7.2); g) процессы повторного применения программных средств - три процесса (см. 5.2.2.2.3 и 7.3). Цели и результаты процессов жизненного цикла образуют эталонную модель процессов. В настоящем стандарте принята следующая нумерация: 6.а и 7.а - указывают на группу процесса; 6.а.b и 7.а.b - указывают на процесс (или процесс более низкого уровня) в пределах этой группы; 6.а.b.1 и 7.а.b.1 - описывают цели процесса; 6.а.b.2 и 7.а.b.2 - описывают выходы процесса; 6.а.b.3.с и 7.а.b.3.с - перечисляют виды деятельности процесса и пункты; 6.a.b.3.c.d и 7.a.b.3.c.d - перечисляют задачи в пределах деятельности (с). Группы процессов жизненного цикла представлены на рисунке 1. Рисунок 1 - Группы процессов жизненного цикла |