ГОСТ Р ИСО МЭК 12207 99 ПРОЦEССЫ ЖИЗНEННОГО ЦИКЛА ПРОГРАММН 4

<< Пред. стр. 4 (из 4) След. >>

a) установление графиков своевременного решения задач;
b) оценка необходимых трудозатрат;
c) определение ресурсов, необходимых для выполнения задач;
d) распределение задач по исполнителям;
e) определение обязанностей исполнителей;
f) определение критических ситуаций, связанных с задачами или самим процессом;
g) установление используемых в процессе критериев управления качеством;
h) определение затрат, связанных с реализацией процесса;
i) обеспечение условий и определение инфраструктуры выполнения процесса.
7.1.3 Выполнение и контроль
Данная работа состоит из следующих задач:
7.1.3.1 Администратор должен начать реализацию плана, чтобы удовлетворить поставленным целям и критериям проекта, выполняя управление процессом.
7.1.3.2 Администратор должен осуществлять текущий надзор за выполнением процесса, подготавливая как внутренние отчеты о развитии процесса, так и внешние отчеты для заказчика в соответствии с условиями договора.
7.1.3.3 Администратор должен исследовать, анализировать и решать проблемы, обнаруженные при выполнении процесса. Решение проблем может привести к изменениям планов. Обязанностью администратора является обеспечение того, чтобы влияние любых изменений на ход процесса было выявлено, управляемо и контролируемо. Все обнаруженные проблемы и их решения должны быть документально оформлены.
7.1.3.4 Администратор должен в установленные сроки отчитаться о реализации процесса, подтверждая выполнение утвержденных планов в ходе процесса и преодолевая возникающие в ходе процесса затруднения. Данные отчеты могут быть в соответствии с условиями договора как внутренними, так и внешними (для заказчика).
7.1.4 Проверка и оценка
Данная работа состоит из следующих задач:
7.1.4.1 Администратор должен обеспечить оценку программных продуктов и планов на соответствие установленным требованиям.
7.1.4.2 Администратор должен проверить результаты оценок программных продуктов, работ и задач, реализуемых в ходе процесса, на соответствие поставленным целям и на выполнение утвержденных планов.
7.1.5 Завершение
Данная работа состоит из следующих задач:
7.1.5.1 После создания всех программных продуктов, запланированных в процессе, и выполнения всех работ и задач процесса администратор должен определить степень их соответствия критериям, установленным в договоре или организационной процедуре.
7.1.5.2 Администратор должен проконтролировать результаты и полноту документации созданных программных продуктов и выполненных работ. Все представленные окончательные результаты и соответствующая документация должны быть сохранены в архиве в соответствии с условиями договора.
7.2 Процесс создают инфраструктуры
Процесс создания инфраструктуры является процессом установления и обеспечения (сопровождения) инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения.
Список работ. Данный процесс состоит из следующих работ:
1) подготовка процесса;
2) создание инфраструктуры;
3) сопровождение инфраструктуры.
7.2.1 Подготовка процесса
Данная работа состоит из следующих задач:
7.2.1.1 Должна быть определена и документально оформлена инфраструктура, удовлетворяющая требованиям к процессу, использующему процесс создания инфраструктуры, с учетом соответствующих процедур, стандартов, инструментальных средств и методик.
7.2.1.2 Создание установленной инфраструктуры должно быть спланировано и документально оформлено.
7.2.2 Создание инфраструктуры
Данная работа состоит из следующих задач:
7.2.2.1 Должна быть спланирована и документально оформлена конфигурация инфраструктуры. При этом должны быть учтены функциональные возможности, производительность, безопасность, защищенность, работоспособность, требуемые площади и оборудование, затраты и временные характеристики реализуемого процесса.
7.2.2.2 Инфраструктура должна быть создана к сроку, необходимому для реализации соответствующего процесса.
7.2.3 Сопровождение инфраструктуры
Данная работа состоит из следующей задачи:
7.2.3.1 Инфраструктура должна сопровождаться, контролироваться и, при необходимости, изменяться так, чтобы обеспечивать удовлетворение требований к процессу, использующему процесс создания инфраструктуры. Должна быть определена как часть сопровождения инфраструктуры - продолжительность нахождения инфраструктуры под управлением конфигурацией.
7.3 Процесс усовершенствования
Процесс усовершенствования является процессом установления, оценки, измерения, контроля и улучшения любого процесса жизненного цикла программных средств.
Список работ. Данный процесс состоит из следующих работ:
1) создание процесса;
2) оценка процесса;
3) усовершенствование процесса.
7.3.1 Создание процесса
Данная работа состоит из следующей задачи:
7.3.1.1 Организация должна определить набор организационных процессов для всех процессов жизненного цикла программных средств в соответствии с имеющимся практическим опытом.
Соответствующие процессы и их применение в конкретных ситуациях должны быть документально оформлены в организационных документах. Должен быть определен механизм управления процессом усовершенствования при разработке, контроле, управлении и улучшении соответствующего процесса(ов).
7.3.2 Оценка процесса
Данная работа состоит из следующих задач:
7.3.2.1 Должна быть разработана, документально оформлена и применена процедура оценки процесса. Должны сохраняться и обновляться отчеты о выполненных оценках процесса.
7.3.2.2 Организация должна планировать и выполнять анализы процессов в установленные сроки с тем, чтобы по результатам оценки обеспечить актуальность и эффективность их применения.
7.3.3 Усовершенствование процесса
Данная работа состоит из следующих задач:
7.3.3.1 Организация должна по результатам анализа и оценки внести соответствующие улучшения в выполняемый процесс, при этом должны быть внесены соответствующие изменения в документацию выполняемого процесса.
7.3.3.2 Должны быть собраны и проанализированы архивные, технические и оценочные данные для выявления сильных и слабых сторон выполняемых процессов. Результаты анализов должны быть использованы для усовершенствования данных процессов, выработки рекомендаций по внесению изменений в реализуемые или планируемые проекты и определения потребности в передовых технологиях.
7.3.3.3 Должны быть собраны, обновлены и использованы для усовершенствования организационных процессов административной деятельности данные о расходах. Эти данные должны быть использованы при определении стоимости работ по предотвращению и решению обнаруженных проблем и несоответствий в программных продуктах и услугах.
7.4 Процесс обучения
Процесс обучения является процессом обеспечения первоначального и продолженного обучения персонала. Заказ, поставка, разработка, эксплуатация и сопровождение программных продуктов в значительной степени зависят от квалификации персонала. Например, персонал разработчика должен быть соответствующим образом обучен управлению программированием и технологии программирования. Поэтому обязательно должно быть запланировано и заранее выполнено обучение персонала с целью готовности его к работам по заказу, поставке, разработке, эксплуатации или сопровождению программного проекта.
Список работ. Данный процесс состоит из следующих работ:
1) подготовка процесса;
2) разработка учебных материалов;
3) реализация плана обучения.
7.4.1 Подготовка процесса
Данная работа состоит из следующей задачи:
7.4.1.1 Должен быть выполнен анализ требований к проекту с целью определения и своевременного создания условий для формирования штата квалифицированного административного и технического персонала. Должны быть определены виды и уровни обучения и категории персонала, требующие обучения. Должны быть разработаны и документально оформлены: план обучения, графики реализации обучения, требования к ресурсам для обучения и программы обучения.
7.4.2 Разработка учебных материалов
Данная работа состоит из следующей задачи:
7.4.2.1 Должны быть разработаны руководства для обучения, включая материалы, используемые при проведении обучения.
7.4.3 Реализация плана обучения
Данная работа состоит из следующих задач:
7.4.3.1 Должен быть реализован план обучения для обеспечения обучения персонала. Отчеты о выполненном обучении персонала должны быть сохранены.
7.4.3.2 Должно быть обеспечено, чтобы соответствующим образом подобранный и обученный персонал своевременно был готов к правильному выполнению запланированных работ и задач.

ПРИЛОЖЕНИЕ А
(обязательное)
Процесс адаптации
Процесс адаптации является процессом применения положений настоящего стандарта к условиям реализации конкретного программного проекта. В настоящем приложении установлены требования к адаптации настоящего стандарта.
Список работ. Данный процесс состоит из следующих работ:
1) определение условий выполнения проекта;
2) запрос исходных данных;
3) выбор процессов, работ и задач;
4) документирование решений по адаптации и их обоснование.
А.1 Определение условий выполнения проекта
Данная работа состоит из следующей задачи:
А.1.1 Должны быть определены характеристики условий выполнения проекта, влияющие на адаптацию К числу таких характеристик можно отнести: модель жизненного цикла; влияние жизненного цикла существующей системы; требования к системе и программным средствам; организационные подходы, процедуры и цели; размер, критичность и типы системы, программного продукта или услуги; количество задействованного персонала и участвующих в проекте сторон.
А.2 Запрос исходных данных
Данная работа состоит из следующей задачи:
А.2.1 От участвующих в проекте организаций должны быть запрошены и получены исходные данные которые могут повлиять на решения по адаптации. В работы по адаптации должны быть вовлечены пользователи, персонал сопровождения и поддержки, заказчик и потенциальные поставщики.
А.3 Выбор процессов, работ в задач
Данная работа состоит из следующих задач:
А.3.1 Должны быть определены необходимые для выполнения процессы, работы и задачи. При этом должна быть охвачена разрабатываемая документация и обязанности исполнителей. С этой целью следует проанализировать настоящий стандарт с учетом данных, полученных по А.1 и А.2.
А.3.2 Дополнительные процессы, работы и задачи, выбранные по А.3.1, но не описанные в настоящем стандарте, следует установить в самом договоре. Следует оценить организационные процессы жизненного цикла (раздел 7 настоящего стандарта) с точки зрения их соответствия выбранным процессам работам и задачам.
А.3.3 В настоящем стандарте имеются задачи, требования к которым содержат слова "должен" или "должны". Эти задачи следует тщательно проанализировать на предмет сохранения или исключения из проекта или данной области деятельности. К обязательно рассматриваемым факторам относятся: риск, стоимость, график работ, выполнимость, объем, критичность и интерфейс с пользователем.
А.4 Документирование решений по адаптации и их обоснование
Данная работа состоит из следующей задачи:
А. 4.1 Должны быть документально оформлены все решения по адаптации с обоснованиями принятых решений.

ПРИЛОЖЕНИЕ В
(справочное)
Руководство по адаптации
Не существует двух одинаковых проектов. Варианты организационных подходов и процедур, методов и политики заказа, размеров и сложности проекта, требований к системе и методов разработки в том числе влияют на то, как система приобретается, разрабатывается, эксплуатируется и сопровождается. Настоящий стандарт разработан для типового проекта с максимально возможным учетом этих вариантов. Поэтому в интересах сокращения стоимости и улучшения качества настоящий стандарт следует адаптировать к конкретному проекту. Все стороны, вовлеченные в проект, должны участвовать в адаптации.
В.1 Общее руководство по адаптации
Данный раздел представляет руководство по адаптации настоящего стандарта и не является исчерпывающим. Данный раздел может быть использован для выполнения первого уровня адаптации настоящего стандарта к конкретной области деятельности, например, авиационной, атомной, медицинской, военной, национальной или организационной. Адаптацию второго уровня следует выполнять для каждого конкретного проекта или договора.
В.2 Адаптация процесса разработки
Процесс разработки (подраздел 5.3 настоящего стандарта) требует особого внимания, так как этот процесс может быть использован различными сторонами с различными целями. В качестве первого уровня адаптации данного процесса рекомендуется следующее:
а) для программного продукта, встроенного или присоединенного к системе, следует рассмотреть все работы в процессе и выяснить, требуется ли от разработчика выполнение или обеспечение работ по созданию системы;
b) для отдельно поставляемого программного продукта работы по созданию системы (см. 5.3.2, 5.3.3, 5.3.10 и 5.3.11 настоящего стандарта) могут не потребоваться, но должны быть рассмотрены.
В.3 Адаптация работ, относящихся к оценке
Лица, вовлеченные в любую работу жизненного цикла проекта или процесса, проводят оценки либо своих собственных, либо других программных продуктов и работ. Настоящий стандарт группирует эти оценки в пять категорий, приведенных ниже. Первые четыре категории оценки применяются на проектном уровне; последняя - на организационном уровне. Данные оценки следует выбирать и адаптировать пропорционально области, действия, величине, сложности и критичности проекта или организации. Проблема, несоответствие и усовершенствование, выявленные в результате следующих оценок, попадают в процесс решения проблем (см. 6.8 настоящего стандарта):
a) оценок внутри процесса (задачи оценки см. в 5.1-5.5 настоящего стандарта). Данные оценки проводятся персоналом, выполняющим определенные в процессе задачи во время своих ежедневных работ;
b) верификации (см. 6.4 настоящего стандарта) и аттестации (см. 6.5 настоящего стандарта). Выполняются заказчиком, поставщиком или независимой стороной для того, чтобы верифицировать или аттестовать продукты с различной степенью зависимости от проекта. Эти оценки не дублируют и не заменяют другие оценки, а напротив дополняют их;
c) совместных анализов (см. 6.6 настоящего стандарта) и аудиторских проверок (см. 6.7 настоящего стандарта). Они проводятся на совместном совещании проверяемой и проверяющей сторон для того, чтобы оценить состояние и соответствие продуктов и работ предварительно установленному графику;
d) обеспечения качества (см. 6.3 настоящего стандарта). Выполняется персоналом, независимым от кадров, непосредственно отвечающих за разработку программного продукта или за реализацию процесса. Целью этой работы является представление независимой гарантии соответствия программных продуктов и процессов требованиям договора и соблюдению установленных планов. Данный процесс может использовать результаты по перечислениям а), b) и с) в качестве исходных данных и может координировать свои работы с работами по этим перечислениям;
e) усовершенствования (см. 7.3 настоящего стандарта). Выполняется организацией для эффективного управления реализуемыми процессами и усовершенствования их. Проводится без учета требований проекта или договора.
B.4 Вопросы адаптации и применения
В настоящем разделе в общих чертах рассматриваются вопросы адаптации и применения для основных характеристик проекта. Ни рассматриваемые вопросы, ни характеристики не являются исчерпывающими и отражают только современное понимание. На рисунке В.1 представлен пример применения настоящего стандарта.
Организационные подходы. Должно быть определено, какие из организационных подходов уместны и применимы, например, к машинным языкам, безопасности и защите, требованиям по резервированию технических средств и управлению риском. Следует сохранить пункты настоящего стандарта, относящиеся к этим организационным подходам.

Рисунок В. 1 - Пример применения настоящего стандарта
Политика заказа. Должно быть определено, какие из подходов к заказу уместны и применимы для проекта (например, типы договора, наличие более одного подрядчика, привлечение субподрядчиков и посредников по верификации и аттестации, уровень связи заказчика с подрядчиками), а также оценка возможностей подрядчиков. Следует сохранить пункты настоящего стандарта, относящиеся к этим вопросам.
Концепция поддержки. Должно быть определено, какие из концепций поддержки уместны и применимы, например, ожидаемая длительность поддержки, степень изменения и то, кто будет осуществлять поддержку - заказчик или поставщик. Если программный продукт предполагает длительный жизненный цикл поддержки или ожидаются значительные изменения, то следует рассмотреть все требования к документации. Рекомендуется осуществлять автоматизированную разработку документации.
Модель(и) жизненного цикла. Должно быть определено, какая модель(и) жизненного цикла уместна и применима для проекта, например, каскадная, эволюционная, формирующая, заранее планируемого улучшения продукта, спиральная. Все эти модели предопределяют некоторые процессы и работы, которые могут быть выполнены последовательным, повторяющимся образом и комбинированно; в рамках этих моделей соответствующие работы жизненного цикла из настоящего стандарта следует отобразить на выбранной модели(ях). Для моделей эволюционной, формирующей и заранее планируемого улучшения продукта выходные результаты одной проектной работы передаются на следующую. В этих случаях документирование должно выполняться в конце работы или задачи.
Вовлеченные стороны. Должно быть определено или указано, какие стороны вовлечены в проект (например, заказчик, поставщик, разработчик, субподрядчик, посредник по верификации и посредник по аттестации, персонал сопровождения) и численность соответствующего персонала. Должны быть рассмотрены все требования, относящиеся к организационным интерфейсам между двумя сторонами, например, интерфейс заказчика с разработчиком и поставщика с посредниками по верификации или аттестации. Большой проект, включающий много (десятки или сотни) лиц, требует значительного административного надзора и контроля. Для большого проекта важны такие средства, как внутренние и независимые оценки, анализы, аудиторские проверки и инспекции, а также сбор важнейших данных по проекту. Для малых проектов такой контроль может быть излишним.
Работа жизненного цикла системы. Должно быть определено, какая из работ жизненного цикла существующей системы уместна и применима, например, подготовка проекта заказчиком, разработка поставщиком и сопровождение. Ниже приведены некоторые сценарии:
* заказчик готовит или определяет требования к системе, изучает выполнимость и прототипность требований и проекта. Может быть выполнено программирование для прототипов, результаты которого могут использоваться или не использоваться в дальнейшем при разработке программных продуктов по договору. Могут быть разработаны требования к системе и предварительные требования к программным средствам. В этих случаях может быть использован процесс разработки (см. 5.3 настоящего стандарта) скорее как руководство, чем как требование; может не потребоваться строгое отношение к квалификации и оценке и могут не потребоваться совместные анализы и аудиторские проверки;
* разработчик создает программный продукт в соответствии с договором. В этом случае все требования к процессу разработки (см. 5.3 настоящего стандарта) следует учитывать при адаптации;
* персонал сопровождения модифицирует программные продукты. Учитывается процесс сопровождения (см. 5.5 настоящего стандарта). Части процесса разработки (см. 5.3) могут быть использованы в качестве мини-процессов.
Характеристики системного уровня. Должно быть определено, какие из характеристик системного уровня уместны и применимы, например, количество подсистем и объектов конфигурации. Если система содержит много подсистем или объектов конфигурации, то процесс разработки (см. 5.3 настоящего стандарта) следует тщательно адаптировать к каждой подсистеме и объекту конфигурации. Следует учесть все требования к интерфейсу и сборке.
Характеристики программного уровня. Должно быть определено, какие из характеристик программного уровня уместны и применимы, например, количество программных объектов, типы, объемы и критичность программных продуктов, а также технические риски. Если программный продукт включает много программных объектов, компонентов и модулей, то следует тщательно адаптировать процесс разработки (см. 5.3) к каждому программному объекту. Следует учесть все требования к интерфейсу и сборке.
Должно быть определено, какие из типов программных продуктов присутствуют в проекте, так как для различных типов программных продуктов требуются различные решения по адаптации. Ниже приведены некоторые примеры:
a) Новая разработка. Должны быть учтены все требования, особенно к процессу разработки (см. 5.3);
b) Использование готового программного продукта. Весь процесс разработки (см. 5.3) может быть излишним. Должны быть оценены функциональные характеристики, документация, патентная чистота, используемость, права собственности, гарантийные и лицензионные права, а также возможность дальнейшей поддержки, относящиеся к программному продукту;
c) Модификация готового программного продукта. Документация может отсутствовать. В зависимости от критичности и ожидаемых дальнейших изменений в процессе сопровождения (см. 5.5 настоящего стандарта) должен быть реализован процесс разработки (см. 5.3). Должны быть оценены функциональные характеристики, документация, патентная чистота, используемость, права собственности, гарантийные и лицензионные права, а также возможность дальнейшей поддержки, относящиеся к программному продукту;
d) Программный или программно-аппаратный продукт, встроенный или подключенный к системе. Так как такой программный продукт является частью большой системы, то следует учитывать работы процесса разработки (см. 5.3), связанные с системой. Из работ, связанных с системой, необходимо выбрать только те, описаны глаголами "выполнять" или "поддерживать". Если программный или программно-аппаратный продукт, скорее всего, не будет в дальнейшем изменяться, то следует тщательно проверить необходимую степень его документируем ости;
е) Отдельно поставляемый программный продукт. Так как такой программный продукт не является частью системы, то не требуется рассматривать работы процесса разработки (см. 5.3), связанные с системой, Следует тщательно проверить потребность в документации, особенно для сопровождения [1];
f) поставляемый программный продукт. Так как данные объекты не заказываются, не поставляются е разрабатываются, то не следует учитывать положения настоящего стандарта, за исключением 5.3.1.5
процесса разработки по 5.3. Однако если заказчик желает приобрести часть такого программного продукта для дальнейших эксплуатации и сопровождения, то данный программный продукт следует рассматривать перечислениях b) или с) настоящего пункта.
Другие соображения.
Система в значительной степени зависима от правильной эксплуатации и своевременного окончания создания программного продукта, поэтому должен быть усилен административный контроль во время тестирования, анализов, аудиторских проверок, верификаций, аттестации и т.д. Напротив, усиленный административный контроль за некритичными или малыми программными продуктами может привести к неэффективным затратам.
Разработка программного продукта может иметь технические риски. Если используется несовершенная технология программирования, то разрабатываемый программный продукт будет несовершенным или сложным, а если к программному продукту предъявляются требования по безопасности, защите или другие критические требования, то может потребоваться точное установление технических требований к нему тщательное его проектирование, тестирование и оценка. Могут оказаться важными независимая верификация и аттестация.

ПРИЛОЖЕНИЕ С
(справочное)
Руководство по процессам и организациям
В настоящем приложении с целью лучшего понимания текста стандарта обсуждаются процессы, организации и их взаимоотношения по ключевым вопросам.
С.1 Процессы с ключевых точек зрения
Настоящий стандарт содержит процессы, применяемые на протяжении жизненного цикла программных средств. Однако данные процессы могут быть использованы разными способами различными организациями и сторонами с разных точек зрения и с различными целями. В данном разделе процессы и их взаимосвязи рассматриваются с ключевых точек зрения. Краткий обзор процессов приведен в 4.1.1 настоящего стандарта.
На рисунке С.1 изображены процессы жизненного цикла программных средств и их взаимосвязи при различных подходах к использованию настоящего стандарта. Основными представленными подходами являются: договор, управление, эксплуатация, технология и поддержка. С точки зрения договора стороны заказчика и поставщика ведут переговоры и вступают в договорные отношения, используя при этом, соответственно, процесс заказа и процесс поставки. С точки зрения управления заказчик, поставщик, разработчик, оператор, персонал сопровождения или другие стороны управляют соответствующим процессом. С точки зрения эксплуатации оператор представляет пользователям услуги по эксплуатации программных средств. С точки зрения технологии разработчик или персонал сопровождения выполняет соответствующие технологические задачи при создании или модернизации программных продуктов. С точки зрения поддержки стороны (такие, как управление конфигурацией, обеспечение качества) предоставляют услуги по поддержке другим сторонам при выполнении специфических, уникальных задач. Также показаны (см. нижнее окно на рисунке С.1) организационные процессы; они применяются организацией на уровне объединения, чтобы установить и реализовать подчиненную структуру соответствующего процесса(ов) жизненного цикла и персонала и постоянно улучшать ее.
На рисунке С.2 представлены основные (верхнее левое окно), вспомогательные (верхнее правое окно) и организационные (нижнее окно) процессы жизненного цикла и наименования входящих в них работ при различных подходах. Цифра, стоящая перед наименованием процесса, указывает на номер пункта раздела настоящего стандарта.
Подход к договору связан с двумя процессами жизненного цикла (см, верхнее затененное окно основных процессов жизненного цикла): процессом заказа для заказчика и процессом поставки для поставщика. Для каждого процесса показаны составляющие его работы. Данные процессы определяют соответствующие задачи для заказчика и поставщика с точки зрения договора.
Технологический подход связан с двумя процессами жизненного цикла (смотри левое нижнее затененное окно в основных процессах жизненного цикла): процессом разработки и процессом сопровождения. Для каждого процесса показаны составляющие его работы. Процесс разработки реализуется в технологиях разработки при создании программных продуктов. Процесс сопровождения реализуется технологиями сопровождения для модификации программных средств и сохранения их исходного состояния.
Подход к эксплуатации связан с одним процессом жизненного цикла (смотри среднее правое затененное окно в основных процессах жизненного цикла): процессом эксплуатации и составляющими его работами. Процесс эксплуатации реализуется при эксплуатации программных средств пользователями.
Подход к управлению качеством связан с пятью процессами жизненного цикла (смотри затененное окно во вспомогательных процессах жизненного цикла): процессом обеспечения качества; процессом верификации; процессом аттестации; процессом совместного анализа и процессом аудита. Составляющие их работы не оказаны. Эти, связанные с качеством, процессы, применяются для управления качеством на всем жизненном цикле программных средств. Процессы верификации, аттестации, совместного анализа и аудита могут реализовываться различными сторонами независимо и также в качестве методов реализации процесса обеспечения качества.
Подход к управлению связан с одним процессом (смотри затененное окно в организационных процессах жизненного цикла): процессом управления, который используется любой организацией для управления соответствующим процессом. Показаны работы, составляющие данный процесс.

Рисунок С.1 - Процессы жизненного цикла программных средств. Роли и взаимосвязи

Примечание- Порядок расположения работ не соответствует последовательности их выполнения. Наименования работ процесса разработки не являются названиями стадий (фаз) разработки. ПС - программные средства.
Рисунок С.2 - Процессы, работы и подходы к жизненному циклу программных средств
С.2 Процессы, организации и взаимоотношения
Процессы и организации (или стороны) связаны только функционально. Процессы не определяют структуру организации (или стороны).
В настоящем стандарте термины "организация" и "сторона" являются близкими по значению. Организация является группой лиц, объединенных некоторой конкретной целью, например, клуб, союз, корпорация или общество. Когда организация целиком или частично вступает в договорные отношения, она является стороной. Организации являются отдельными органами, но стороны могут быть из одной или из разных организаций.
Организация или сторона получает свое наименование от процесса, который она выполняет, например, она называется "заказчик", если она выполняет процесс заказа.
Организация может выполнять один или более одного процесса, процесс может выполняться одной или более чем одной организацией. В рамках одного договора или применения настоящего стандарта данная сторона не может выполнять одновременно процесс заказа я процесс поставки, но она может выполнять другие процессы.
В самом настоящем стандарте взаимоотношения между процессами всегда статические. Более важные динамические, соответствующие реальной жизни, взаимоотношения между процессами, между сторонами и между процессами и сторонами автоматически устанавливаются, когда настоящий стандарт применяется к программным проектам. Каждый процесс (и сторона, выполняющая его) включается в программный проект своим собственным уникальным образом. Процесс заказа и заказчик включаются при определении системы, которая должна содержать программный продукт. Процесс поставки и поставщик включаются при представлении программного продукта или услуги, от которых зависит система. Процесс разработки и разработчик включаются при анализе системы на предмет корректного выделения и определения программного продукта при обеспечении соответствующего подключения программного продукта к системе и при разработке программного продукта в период между этими двумя действиями. Процесс эксплуатации и оператор включаются при эксплуатации программного продукта в системной среде в интересах пользователей, деятельности и задач. Процесс сопровождения и персонал сопровождения включаются при сопровождении и поддержке программного продукта в эксплуатационной готовности и при обеспечении поддержки и консультаций коллективам пользователей. Каждый вспомогательный или организационный процесс включаются при необходимости обеспечения уникальных, специализированных функций для других процессов.

ПРИЛОЖЕНИЕ D
(справочное)
Библиография
[1] ИСО/МЭК 12119-941 Информационная технология. Пакеты программ. Требования качества и тестирование

УДК-681.3.06:006.354 ОКС 35.080 П85 ОКСТУ 5001
Ключевые слова: обработка данных, оборудование обработки данных, вычислительные машины, программные средства вычислительных машин, жизненный цикл

Редактор Т.С. Шеко
Технический редактор В.Н. Прусакова
Корректор М.В. Бучная
Компьютерная верстка В.И. Грищеяко
1 Оригиналы международных стандартов ИСО/МЭК - во ВНИИКИ Госстандарта России.
??

??

??

??

ГОСТ Р ИСО/МЭК 12207-99

<< Пред. стр. 4 (из 4) След. >>

Список литературы по разделу