ГОСТ Р ИСО-МЭК 12207-2010 Процессы ЖЦ ПС. Процессы жизненного цикла программных средств
 Скачать 457.34 Kb.
|
 Рисунок 1 - Группы процессов жизненного цикла Эталонная модель процесса не представляет конкретного подхода к осуществлению процесса, как и не предопределяет модель жизненного цикла системы (программного средства), методологию или технологию. Вместо этого эталонная модель предназначается для принятия организацией и базируется на деловых потребностях организации и области приложений. Определенный организацией процесс принимается в проектах организации в контексте требований заказчиков. Результаты процесса используются для демонстрации успешного достижения цели процесса, что помогает оценщикам процесса определять возможности реализованного процесса организации и предоставлять исходные материалы для планирования улучшений организационных процессов. 5.2.2 Краткое содержание процессов жизненного цикла В настоящем стандарте существует два важных подразделения процесса. В разделе 6 представлен системный контекст для работы с автономным программным продуктом или услугой, или программной системой. Раздел 7 содержит специальные процессы программных средств для использования в реализации программного продукта или услуги, которые являются некоторым элементом более крупной системы. Для помощи в одновременном использовании [18] и настоящего стандарта соответствующие процессы раздела 6 имеют одинаковые обозначения подразделов. В общем случае совокупность процессов, представленная в настоящем стандарте, приспособлена к программным средствам или вкладам в результаты процессов, предусмотренных [18]. Многие процессы из [18] подобны реализациям процессов, специфических для программных средств, однако они сохраняют важные различия, базирующиеся на целях, результатах и аудиториях. Пользователям как [18], так и настоящего стандарта следует обязательно рассматривать пояснения и примечания в каждом таком специфическом процессе. 5.2.2.1 Процессы в контексте системы 5.2.2.1.1 Процессы соглашения Процессы соглашения определяют действия, необходимые для выработки соглашений между двумя организациями. Если реализуется процесс приобретения, то он обеспечивает средства для проведения деловой деятельности с поставщиком продуктов, предоставляемых для применения в функционирующей системе, услугах поддержки этой системы или элементах системы, разработанных в рамках проекта. Если реализуется процесс поставки, то он обеспечивает средства для проведения проекта, в котором результатом является продукт или услуга, поставляемые приобретающей стороне. Таким образом, процессы соглашения, приведенные в настоящем стандарте, ориентированы на программные средства процессами соглашения из [18]. 5.2.2.1.2 Процессы организационного обеспечения проекта Процессы организационного обеспечения проекта осуществляют менеджмент возможностей организаций приобретать и поставлять продукты или услуги через инициализацию, поддержку и управление проектами. Эти процессы обеспечивают ресурсы и инфраструктуру, необходимые для поддержки проектов, и гарантируют удовлетворение организационных целей и установленных соглашений. Они не претендуют на роль полной совокупности деловых процессов, реализующих менеджмент деловой деятельности организации. Процессы организационного обеспечения проекта включают в себя: a) процесс менеджмента модели жизненного цикла; b) процесс менеджмента инфраструктуры; c) процесс менеджмента портфеля проектов; d) процесс менеджмента людских ресурсов; e) процесс менеджмента качества. В общем случае процессы организационного обеспечения проекта, предусмотренные настоящим стандартом, являются процессами, ориентированными на программные средства из соответствующей совокупности процессов в [18]. 5.2.2.1.3 Процессы проекта В настоящем стандарте проект выбран как основа для описания процессов, относящихся к планированию, оценке и управлению. Принципы, связанные с этими процессами, могут применяться в любой области менеджмента организаций. Существуют две категории процессов проекта. Процессы менеджмента проекта используются для планирования, выполнения, оценки и управления продвижением проекта. Процессы поддержки проекта обеспечивают выполнение специализированных целей менеджмента. Обе категории процессов проекта описаны ниже. Процессы менеджмента проекта применяются для создания и развития планов проекта, оценки фактического выполнения и продвижения относительно плановых заданий и управления выполнением проекта вплоть до полного его завершения. Отдельные процессы менеджмента проекта могут привлекаться в любое время жизненного цикла и на любом уровне иерархии проекта в соответствии с планами проекта или возникновением непредвиденных событий. Процессы менеджмента проекта применяются на уровне строгости и формализации, зависящих от риска и сложности проекта: а) процесс планирования проекта; b) процесс управления и оценки проекта. Процессы поддержки проекта формируют специфическую совокупность задач, ориентированных на выполнение специальных целей менеджмента. Все эти процессы очевидны при осуществлении менеджмента любой инициируемой деятельности, располагаясь по нисходящей от организации в целом вплоть до отдельного процесса жизненного цикла и его задач: a) процесс менеджмента решений; b) процесс менеджмента рисков; c) процесс менеджмента конфигурации; d) процесс менеджмента информации; е)процесс измерений. В общем случае процессы поддержки проекта, представленные в настоящем стандарте, идентичны процессам поддержки проекта, приведенным в [18], за исключением некоторых отличий в форме их представления. В некоторых случаях процессы поддержки программных средств могут иметь взаимосвязи с процессами поддержки проектов. 5.2.2.1.4 Технические процессы Технические процессы используются для определения требований к системе, преобразования требований в полезный продукт, для разрешения постоянного копирования продукта (где это необходимо), применения продукта, обеспечения требуемых услуг, поддержания обеспечения этих услуг и изъятия продукта из обращения, если он не используется при оказании услуги. Технические процессы определяют деятельность, которая дает возможность реализовывать организационные и проектные функции для оптимизации пользы и снижения рисков, являющихся следствием технических решений и действий. Эта деятельность обеспечивает возможность продуктам и услугам обладать такими свойствами, как своевременность и доступность, результативность затрат, а также функциональность, безотказность, ремонтопригодность, продуктивность, приспособленность к применению, и другими качественными характеристиками, требуемыми приобретающими и поддерживающими организациями. Она также предоставляет возможность продуктам и услугам соответствовать ожиданиям или требованиям гражданского законодательства, включая факторы здоровья, безопасности, защищенности и факторы, относящиеся к окружающей среде. Технические процессы состоят из следующих процессов: a) определение требований правообладателей (специальный случай процесса определения требований правообладателей, приведенного в [18]); b) анализ системных требований (специальный случай процесса анализа требований); c) проектирование архитектуры системы (специальный случай процесса проектирования архитектуры, приведенного в [18]); d) процесс реализации (специальный случай процесса реализации элементов системы, приведенного в [18] и далее разработанного в разделе 7 настоящего стандарта как процесса реализации программных средств); e) процесс комплексирования системы (специальный случай процесса комплексирования, приведенного в [18]); f) процесс квалификационного тестирования системы (процесс, который способствует достижению результатов процесса верификации, приведенного в [18]); g) процесс инсталляции программных средств (процесс, который способствует достижению результатов процесса передачи, приведенного в [18]); h) процесс поддержки приемки программных средств (процесс, который способствует достижению результатов процесса передачи, приведенного в [18]); i) процесс функционирования программных средств (специальный случай процесса функционирования, приведенного в [18]); j) процесс сопровождения программных средств (специальный случай процесса сопровождения, приведенного в [18]); k) процесс изъятия из обращения программных средств (специальный случай процесса изъятия и списания, приведенного в [18]). В общем случае технические процессы, представленные в настоящем стандарте, ориентированы на программные средства специальными случаями или вкладами в результаты технических процессов, представленных в [18]. Большинство из них схожи с процессами реализации программных средств, но сохраняют важные различия, например, анализ системных требований и анализ требований к программным средствам начинаются с разных исходных позиций и имеют разные предназначения. 5.2.2.2 Специальные процессы программных средств 5.2.2.2.1 Процессы реализации программных средств Процессы реализации программных средств используются для создания конкретного элемента системы (составной части), выполненного в виде программного средства. Эти процессы преобразуют заданные характеристики поведения, интерфейсы и ограничения на реализацию в действия, результатом которых становится системный элемент, удовлетворяющий требованиям, вытекающим из системных требований. Специальным процессом является процесс реализации программных средств, выражающий специфически программную особенность процесса реализации, приведенного в [18]. Процесс реализации программных средств включает в себя несколько специальных процессов более низкого уровня: а) процесс анализа требований к программным средствам; b) процесс проектирования архитектуры программных средств; c) процесс детального проектирования программных средств; d) процесс конструирования программных средств; e) процесс комплексирования программных средств; f) процесс квалификационного тестирования программных средств. 5.2.2.2.2 Процессы поддержки программных средств Процессы поддержки программных средств предусматривают специально сфокусированную совокупность действий, направленных на выполнение специализированного программного процесса. Любой поддерживающий процесс помогает процессу реализации программных средств как единое целое с обособленной целью, внося вклад в успех и качество программного проекта. Существует восемь таких процессов: a) процесс менеджмента документации программных средств; b) процесс менеджмента конфигурации программных средств; c) процесс обеспечения гарантии качества программных средств; d) процесс верификации программных средств; e) процесс валидации программных средств; f) процесс ревизии программных средств; g) процесс аудита программных средств; h) процесс решения проблем в программных средствах. 5.2.2.2.3 Процессы повторного применения программных средств Группа процессов повторного применения программных средств состоит из трех процессов, которые поддерживают возможности организации использовать повторно составные части программных средств за границами проекта. Эти процессы уникальны, поскольку, в соответствии с их природой, они используются вне границ какого-либо конкретного проекта. Процессами повторного применения программных средств являются: a) процесс проектирования доменов; b) процесс менеджмента повторного применения активов; c) процесс менеджмента повторного применения программ. 5.2.3 Эталонная модель процессов Эталонная модель процессов (ЭМП) на уровне абстракции, более высоком, чем детальные требования, содержащиеся в основном тексте настоящего стандарта, приведена в приложении В. ЭМП применяется к организации, оценивающей эти процессы для определения их возможностей. Целью и выходами является установление конечных целей рабочих характеристик каждого процесса. Эта формулировка конечных целей позволяет оценивать результативность процессов другими способами, нежели простая оценка соответствия. Например, построение нового процесса может быть оценено скорее по отношению к формулировкам цели и выходов, приведенным в приложении В, чем в сравнении с детальными условиями, описанными в тексте настоящего стандарта. Примечание 1 - В настоящем стандарте термин "эталонная модель процесса" используется в том же значении, что и в [20]. Примечание 2 - Эталонная модель процесса предназначается для применения при разработке модели (моделей) оценки для процессов оценки в соответствии с [20]. 6 Процессы жизненного цикла систем 6.1 Процессы соглашения 6.1.1 Процесс приобретения 6.1.1.1 Цель Цель процесса приобретения состоит в получении продукта и (или) услуги в соответствии с потребностями приобретающей стороны. Процесс начинается с выяснения потребностей заказчика и заканчивается приемкой продукта и (или) услуги, необходимых приобретающей стороне. 6.1.1.2 Выходы В результате успешного осуществления процесса приобретения: a) определяются потребности в приобретении, конечные цели, критерии приемки продукта и (или) услуги и стратегии приобретения; b) разрабатывается соглашение, которое ясно выражает ожидания, ответственность и обязательства как приобретающей стороны, так и поставщика; c) выбирается один или несколько поставщиков; d) приобретается продукт и (или) услуга, которые удовлетворяют заданным потребностям приобретающей стороны; e) приобретение контролируется таким образом, чтобы удовлетворялись заданные ограничения, такие как, например, ограничения по стоимости, срокам и качеству; f) принимаются продукты и (или) услуги от поставщиков; g) по всем идентифицированным открытым позициям получены удовлетворительные заключения, согласованные приобретающей стороной и поставщиком. 6.1.1.3 Виды деятельности и задачи Приобретающая сторона должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса приобретения. Примечание - Виды деятельности и задачи в настоящем процессе могут выполняться одним или несколькими поставщиками. 6.1.1.3.1 Подготовка к приобретению Данный вид деятельности состоит из решения следующих задач: 6.1.1.3.1.1 Приобретающая сторона начинает процесс приобретения, описывая свое представление или потребность в приобретении, разработке или расширении системы, программного продукта или программной услуги. 6.1.1.3.1.2 Приобретающая сторона должна определять и анализировать системные требования. Необходимо, чтобы системные требования охватывали деловые, организационные и пользовательские требования, а также требования к безопасности, защищенности и другим критическим свойствам, наряду со связанными с ними проектированием, тестированием, стандартами и процедурами оценки соответствия. 6.1.1.3.1.3 Приобретающая сторона может выполнять определение и анализ требований к программным средствам самостоятельно или поручить поставщику осуществить эту задачу. 6.1.1.3.1.4 Если приобретающая сторона поручает какому-либо поставщику выполнить анализ системных требований или требований к программным средствам, то она должна оставить за собой право утвердить проанализированные требования. 6.1.1.3.1.5 Технические процессы (см. 6.4) следует использовать для выполнения задач в соответствии с 6.1.1.3.1.2 и 6.1.1.3.1.4. Приобретающая сторона может использовать процесс определения требований правообладателей для установления требований заказчиков. 6.1.1.3.1.6 Приобретающая сторона должна рассмотреть варианты приобретения на основе анализа соответствующих критериев, учитывающих риски, стоимость и полезность каждого варианта. Варианты приобретения включают в себя: a) покупку готового программного продукта, удовлетворяющего требованиям; b) разработку программного продукта или получение программной услуги внутри приобретающей организации; c) разработку программного продукта или получение программной услуги по контракту; |