ГОСТ Р 56923-2016/ISO/IEC TR 24748-3:2011. Национальный стандарт Российской Федерации. Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

4.6 Понятия проекта

 

4.6.1 Общее

Проект - это попытка с определенными датами начала и окончания, предпринятая для создания продукции или услуг в соответствии с заданными ресурсами и требованиями. Портфель проектов - это некое множество собранных проектов, которые направлены на достижение стратегических целей организации.

Проект может быть рассмотрен как уникальный процесс, включающий скоординированные и управляемые действия, которые могут быть составлены из действий, относящихся к процессам проекта и техническим процессам по ИСО/МЭК 12207.

Примечания

1 ИСО/МЭК 24748-1 (подпункт 3.1.4) обеспечивает детализацию относительно структуры в системах и проектах.

2 ИСО/МЭК 24748-1 (подпункт 3.1.5) обеспечивает детализацию относительно обеспечивающих систем.

 

Любой проект согласно цели ИСО/МЭК 12207 проводится в пределах контекста организации. Это важно, потому что программный проект зависит от различных результатов, произведенных с использованием бизнес-процессов организации, например - от работников для комплектации обслуживающего персонала проекта и оборудования. Для решения этих задач настоящий стандарт обеспечивает множество процессов организационного обеспечения проекта. Важно отметить, что изначально ни процессы организационного обеспечения проекта, ни процессы проекта не могут быть адекватными для оперирования бизнесом и использования в проекте. Вместе с тем, процессы, рассматриваемые в совокупности, предназначены для установления минимального множества зависимостей проекта, размещаемого в организации.

ИСО/МЭК 12207 описывает множество процессов, которые составляют жизненный цикл любой программной системы. Поэтому ИСО/МЭК 12207 разработан так, чтобы он мог быть приспособлен к программному проекту любого типа, размера и сложности, сосредоточен ли он на материальных продуктах, услугах или и на том, и на другом. Учтено также то, рассматриваются ли программные средства как автономные или как часть объемлющей системы.

Процессы, действия и задачи в ИСО/МЭК 12207 описаны в их самой общей, естественной последовательности. Такая позиционная последовательность не навязывает последовательности в модели жизненного цикла. Она предназначена лишь для того, чтобы программный проект сам выбирал, упорядочивал, адаптировал и повторял процессы, действия и задачи как применимые или приемлемые.

На том же самом проекте ИСО/МЭК 12207 может быть отдельно применен несколько раз. Например, в конкретном проекте реализации программных средств приобретающая сторона может просить поставщика выполнить программную реализацию, причем приобретающая сторона и поставщик выполняют одно применение ИСО/МЭК 12207. Соответственно поставщик может просить своего субподрядчика выполнить все или часть реализации программных средств. Поставщик (теперь уже в роли приобретающей стороны) и его субподрядчик (в роли поставщика) выполняют отдельное применение ИСО/МЭК 12207. В обоих ситуациях необходимо адаптировать ИСО/МЭК 12207 для отражения ситуации.

Примечание - Стандарт IEEE 1490 Принятие стандарта Института PMI: Руководство органам знаний по управлению проектами (Adoption of PMI Standard: A Guide to the Project Management Body of Knowledge) предоставляет больше информации о проектах и руководстве проектом.

 

4.6.2 Проектные отношения

Отношения могут существовать между проектом и другими проектами и подпроектами. Как используется в настоящем стандарте и показано на рисунке 12, подпроект является множеством ресурсов и задач, организованных для выполнения части проекта. Подпроект можно считать проектом для выполнения этих назначенных работ. Рисунок 12 иллюстрирует типичные роли соглашений, которые устанавливают внутренние и внешние отношения применительно к проекту.

 

 

Рисунок 12 - Роли соглашения

 

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

Может быть использовано другое соглашение, не показанное на рисунке 12, когда две или более организации сотрудничают на единственном проекте. В этом случае важно определить полномочия каждой организации, ответственности и права, включая разделение прав собственности на информацию, применимую к проекту в соглашении.

Независимо от вида соглашения есть некоторая основная информация, необходимая для выполнения работы и требуемая по ИСО/МЭК 12207. Каждое соглашение, формальное или неофициальное, должно включать следующую информацию с соответствующим уровнем детализации:

a) ответственности за работу, выполнение которой ожидается, например в форме рабочих положений;

b) известных функциональных требований и требований выполнения, признаков и характеристик, которые ясно означают то, что программная система и ее соответствующие сервисы должны выполнять, быть подобными или содержать, включая интерфейсы с другими системами, людьми и окружающей средой. Они могут быть в форме ряда формальных требований или в виде спецификации;

c) получаемые результаты, например продукты, услуги и данные;

d) стадия(и) применимой модели жизненного цикла, включая соответствующий вход стадии или критерии решения для выхода. Критерии обеспечивают основание для определения, готов ли проект к переходу на следующую применимую стадию жизненного цикла;

e) необходимые технические ревизии, чтобы отследить выполнение соглашения и оценить зрелость системы;

f) другая соответствующая информация, такая как:

1) стоимость и ограничения по плану;

2) "контрольные точки" реализации;

3) сроки оплаты;

4) планирующие документы, включая применимую системную структуру разделения работ, связанную с документами конфигурации и техническими планами, предоставляемыми приобретающей стороне;

5) ответственности верификации и аттестации (аттестации);

6) условия приемки и инструкции по передаче (например для упаковки, обращения, поставки и инсталляции);

7) права и ограничения, связанные с техническими данными (например для авторского права, интеллектуальной собственности и патентов).

Примечание - Модель предоставлена в 5.4.2 для применения процессов ИСО/МЭК 12207 и достижения соглашения.

 

4.6.3 Обеспечивающие системные отношения

Иной тип отношений среди проектов связан с вовлечением обеспечивающих систем. Проект ответственен за то, что необходимые обеспечивающие системы будут доступны для выполнения функций или обеспечения готовности к реализации программных средств. Некоторые или, возможно, все обеспечивающие системы могут быть вне прямой ответственности (границ) проекта. Некоторые или все обеспечивающие системы могут уже существовать в пределах организации проекта. Другие обеспечивающие системы могут быть легко сделаны доступными, например, путем их аренды или покупки. Вместе с тем, одна или несколько обеспечивающих систем, возможно, могут не существовать, и может потребоваться их создание и готовность в срок для обеспечения требуемых услуг.

Именно в пределах периода совпадения (пересечения) интересов в проекте должны соответственно быть доступными не только программные средства, но также и все обеспечивающие системы, которые необходимы в жизненном цикле программной системы. Таким образом, проект должен определить необходимые обеспечивающие системы и предпринять надлежащие действия, чтобы гарантировать их пригодность к использованию.

Соглашения должны быть установлены между проектом и внутренней или внешней организацией или иной приемлемой организацией для гарантий того, что указанные услуги обеспечивающей системы будут обеспечены тогда, когда это оказывается необходимым. Совпадение интересов в проекте в определенный период проиллюстрировано на рисунке 13.

 

 

Рисунок 13 - Совпадение интересов в проекте в определенный

период времени

 

4.6.4 Иерархия проекта

Для иерархического представления проекта основные отношения на рисунке 13 могут быть объединены с иерархическим представлением системной структуры, проиллюстрированным на рисунке 2 ИСО/МЭК 24748-1, и структуры рассматриваемой системы на рисунке 3 ИСО/МЭК 24748-1. Систему, за которую проект ответственен, считают системой интереса и в настоящем стандарте называют рассматриваемой системой. Каждый подчиненный проект или подпроект рассматривают как проект сам по себе. Тогда может быть сформирована результирующая иерархия проектов. Эта иерархия проиллюстрирована на рисунке 4 ИСО/МЭК 24748-1 и изображается более детально на рисунке 14 настоящего стандарта.

 

 

Рисунок 14 - Иерархия проектов

 

Рисунок 14 показывает только более низкий уровень проектов одной системы. Вместе с тем, каждая система должна быть декомпозирована в проекты более низкого уровня, и так далее - до системного элемента и его обеспечивающих систем. Два таких проекта на рисунке 14 заканчиваются элементом системы. Каждый проект должен быть выполнен до необходимой степени согласно требованиям, используя применимые процессы жизненного цикла системы, и должен удовлетворять применимому входу на следующую стадию жизненного цикла или критериям выхода.

Как пояснено на рисунке 13, обеспечивающие системы рисунка 14 могут находиться под проектным управлением или с внешней к проекту стороны под управлением других организаций. Проект должен работать с этими другими организациями через соглашения, чтобы гарантировать, что необходимые обеспечивающие системы доступны тогда, когда это является необходимым для поддержки рассматриваемой системы в течение ее жизненного цикла.