В настоящем стандарте термины "организация" и "сторона" тесно связаны. Организация - это группа лиц с определенными обязанностями и полномочиями, объединенных для реализации некоторых конкретных целей, таких как клуб, союз, корпорация или общество. Если организация полностью или частично входит в контрактное соглашение (договор), то это - сторона. Стороны могут быть из одной или из разных организаций. Отдельное лицо является примером организации, если на него возлагается определенная ответственность и полномочия.
Организация или сторона получают свои наименования от процессов, за которые они ответственны. Например, организация называется приобретающей стороной, если она выполняет процесс приобретения. Таким образом, когда следующие термины используются в настоящем стандарте, они не имеют своего изначального значения, а вместо этого указывают на организацию или сторону, ответственную за выполнение процесса со сходным названием: приобретающая сторона, поставщик, исполнитель, сопровождающая сторона и оператор.
В настоящем стандарте применяются также другие термины по отношению к организации: "пользователь" - может быть организацией, которая извлекает выгоду от применения программного продукта или услуги; "заказчик" - рассматривается совместно как пользователь и приобретающая сторона; "правообладатель" - рассматривается как организация, заинтересованная в успехе проекта.
Процессы и организации (стороны) связаны только функционально. Настоящий стандарт не диктует или не включает в себя структуру для организации (стороны).
Процессы в настоящем стандарте составляют полную совокупность для охвата различных организаций. Организация (малая или крупная) в зависимости от ее деловых целей или стратегии приобретения может выбрать подходящую совокупность процессов (а также связанных с ними действий и задач) для выполнения этих целей. Организация может выполнять один или несколько процессов. Например, по условиям контракта или применения настоящего стандарта конкретная сторона не должна выполнять ни процесс приобретения, ни процесс поставки, но она может выполнять другие процессы. Процесс может реализовываться одной или несколькими организациями. Примером процесса, выполняемого более чем одной организацией, является процесс ревизии программных средств.
Настоящий стандарт предназначен для применения двумя или большим числом организаций (как внутри, так и вне организаций). Если он применяется внутри организации, то две стороны соглашения обычно действуют согласно положениям, установленным в соглашении, которые могут изменяться с соблюдением принятых правил при различных обстоятельствах. Если он применяется при отношениях с внешними сторонами, то стороны соглашения обычно действуют согласно положениям, изложенным в контракте. Для того, чтобы облегчить применение настоящего стандарта как для внутренних целей, так и для контрактных отношений, задачи выражаются на языке контракта. Если стандарт применяется для внутренних целей, то положения контракта следует интерпретировать как установленную в пределах организации исполнительскую дисциплину.
Для целей настоящего стандарта предполагается, что любой проект осуществляется в пределах контекста организации. Это важно, так как программный проект зависит от различных результатов, производимых деловыми процессами организации, например, найма работников для укомплектования штатного персонала проекта и средств обеспечения проекта. Для этой цели настоящий стандарт предоставляет совокупность процессов "организационного обеспечения проекта". Предполагается, что эти процессы не охватывают ни деловой деятельности, ни какого-либо отдельного процесса проекта. Вместо этого процессы рассматриваемые в совокупности, предназначаются для установления минимального множества зависимостей, которые проект возлагает на организацию.
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);