База ГОСТовallgosts.ru » 03. УСЛУГИ. ОРГАНИЗАЦИЯ ФИРМ, УПРАВЛЕНИЕ И КАЧЕСТВО. АДМИНИСТРАЦИЯ. ТРАНСПОРТ. СОЦИОЛОГИЯ. » 03.100. Организация фирм и управление ими

ГОСТ Р 57195-2016 Ядро и язык для методов системной и программной инженерии. Общие положения

Обозначение: ГОСТ Р 57195-2016
Наименование: Ядро и язык для методов системной и программной инженерии. Общие положения
Статус: Действует

Дата введения: 05/01/2017
Дата отмены: -
Заменен на: -
Код ОКС: 03.100.01
Скачать PDF: ГОСТ Р 57195-2016 Ядро и язык для методов системной и программной инженерии. Общие положения.pdf
Скачать Word:ГОСТ Р 57195-2016 Ядро и язык для методов системной и программной инженерии. Общие положения.doc


Текст ГОСТ Р 57195-2016 Ядро и язык для методов системной и программной инженерии. Общие положения



ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

1 СТАНДАРТ V 11 V ? у РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТ Р 57195-2016

ЯДРО И ЯЗЫК ДЛЯ МЕТОДОВ СИСТЕМНОЙ И ПРОГРАММНОЙ ИНЖЕНЕРИИ

Общие положения

Издание официальное

Стшдфпшфцм

201*

ГОСТ Р 57195—2016

Предисловие

1    РАЗРАБОТАН Федеральным государственным бюджетным учреждением «Национальный исследовательский центр «Институт имени Н.Е. Жуковского», Союзом аеиапроиэводигелей России (САП). Федеральным государственным унитарным предприятием «Научно-исследовательский институт стандартизации и унификации» (ФГУП «НИИСУ»)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 323 «Авиационная техника»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 31 октября 2016 г. № 1545-ст

4    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — е ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также е информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регупиро-ванию и метрологии е сети Интернет ()

© Стандартинформ. 2016

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

II

ГОСТ Р 57195—2016

Содержание

1    Область применения..................................................................1

2    Термины и определения...............................................................1

3    Общие положения....................................................................2

4    Требования к ядру и его составным частям...............................................3

5    Расширения ядра....................................................................19

6    Требования к модели языка...........................................................19

ГОСТ Р 57195—2016

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЯДРО И ЯЗЫК ДЛЯ МЕТОДОВ СИСТЕМНОЙ И ПРОГРАММНОЙ ИНЖЕНЕРИИ

Общие положения

Kernel and language for system and software engineering methods. General

Дата введения — 2017—05—01

1    Область применения

Настоящий стандарт устанавливает детальные определения и описания ядра и языка методов системной и программной инженерии.

Настоящий стандарт предусматривает следующие требования к ядру и языку:

. определяет ядро и его формирование в трех областях интересов, касающихся заказчика, решения и деятельности;

•    определяет альфы ядра (т. е. основные элементы, с которыми потребуется работать) и пространства действий (т. е. основные элементы, которые необходимо выполнить);

•    определяет модель языка и элементы языка.

2    Термины и определения

8 настоящем стандарте применены следующие термины с соответствующими определениями:

2.1    альфа; Обязательный элемент программно-инженерной деятельности, относящийся к оценке прогресса и состояния деятельности.

2.2    возможность: Совокупность обстоятельств, которая обусловливает разработку или изменение программной системы.

2.3    действие: Определяет один или более видов единиц работ и дает указания по их выполнению.

2.4    деятельность: Действие или набор действий, направленных на достижение цели.

2.5    единица работы: Часть работы, которую необходимо сделать, чтобы завершить работу.

Примечание — Характеризуется наличием конкретного результата, приводящего либо к изменению состояния. либо к подтверждению текущего состоятя. Единица работы может иметь или не иметь связанных с ней действий.

2.6    заинтересованные стороны: Люди, группы или организации, которые влияют на программную систему или находятся под ее влиянием.

2.7    исполнение: Акт применения метода с каким-либо конкретным замыслом, обычно в рамках деятельности.

2.8    команда: Группа людей, активно вовлеченных в разработку, обслуживание, поставку, внедрение или поддержку конкретной программной системы.

2.9    компетенция: Характеристика представителя заинтересованной стороны или члена команды. которая отражает способность выполнять работу.

Примечание — Компетенция описывает возможность выполнять определенную работу. Компетенция определяет последовательность уровней компетентности — от минимального уровня компетентности до максимального. Обычно это уровни в диапазоне от 0 («помогает») до 5 («улучшает»).

Издание официальное

1

ГОСТ Р 57195—2016

2.10    метод: Композиция из практик, формирующая (на желаемом уровне абстракции) описание того, как выполняется деятельность.

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

2.11    область интересов: Составные части элементов ядер или практик, которым в рамках деятельности по разработке программного обеспечения следует уделять особое внимание.

Примечание — Каждый элемент попадает в одну и только одну область интересов.

2.12    ограничения: Условия, правила и нормативные требования, которые команда обязана соблюдать.

2.13    паттерн: Описание структуры практики.

2.14    практика: Повторяемый подход к совершению действий с определенным замыслом, обеспечивающий систематический и проверяемый способ выполнения конкретного аспекта работы.

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

2.15    программная система: Система, состоящая из программного и аппаратного обеспечения и данных, главная ценность которой создается посредством исполнения программного обеспечения.

2.16    пространство действий: Указание на то. что должно быть сделано в рамках деятельности по разработке программного обеспечения: может включать в себя несколько действий или не включать ни одного.

2.17    работа: Деятельность, в рамках которой предпринимают умственные или физические усилия. направленные на достижение результата.

2.18    роль: Набор обязанностей.

2.19    связь альф: Связь, определяющая отношения между двумя альфами.

2.20    состояние: Выражает ситуацию, в которой некоторые условия остаются неизменными.

2.21    технология работы: Адаптированный набор практик и инструментов, используемых командой для ведения и поддержки ее работы.

2.22    требования: То. что должна сделать программная система, для того чтобы воспользоваться возможностью и удовлетворить заинтересованные стороны.

2.23    элемент контрольного списка: Элемент в контрольном списке, состояние которого должно быть проверено.

2.24    ядро: Набор элементов, используемых для формирования общей основы для описания деятельности по созданию программного обеспечения.

3 Общие положения

3.1    Настоящий стандарт определяет ядро и язык для установления требований к методу программной инженерии.

3.2    Ядро обеспечивает общую основу для определения методики программного обеспечения.

3.2.1 Ядро включает в себя основные элементы, которые присутствуют в каждом процессе разработки программного обеспечения, такие как управление требованиями, программное обеспечение системы и командная работа.

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

3.4    Ядро должно быть небольшим и легким ло своей структуре, но открытым, чтобы обеспечить возможность охвата новых технологий, практик, социальных рабочих моделей и новых исследований.

2

ГОСТ Р 57195—2016

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

4 Требования к ядру и его составным частям

4.1    При создании методов программной инженерии ядро должно предоставлять возможность:

-    применять столько практик, сколько необходимо для создания каждого конфетного метода:

•    оценивать текущие практики в рамках контроля нейтрального положения метода:

•    согласовывать и сравнивать текущую работу и методы собщепринятыми рамками контроля нейтральности метода и дополнять их любыми недостающими важными практиками или элементами процесса:

-    начать работу с помощью минимально необходимого метода, добавляя практики по ходу осуществления деятельности и в те моменты, когда это необходимо.

4.2    Требования к составу ядра

4.2.1    Ядро состоит из трех областей интересов, каждая из которых фокусируется на конфетном аспекте программной инженерии:

-    «Клиент» — данная область интересов включает в себя все. что связано с фактической эксплуатацией и использованием производимой программной системы.

•    «Решение» — данная область интересов включает в себя все. что связано со спецификацией и разработкой программной системы:

•    «Деятельность» — данная область интересов включает в себя все. что связано с командой и способом, с помощью которого команда подходит к выполнению своей работы.

4.2.2    Ядро не включает в себя экземпляры других элементов языка, такие как продукты и процессы работы. Они имеют смысл только в контексте конкретной практики.

4.2.3    Ядро описывают с помощью подгруппы языка ядра. Каждая из трех областей интересов ядра содержит;

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

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

4.3    Альфы ядра

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

4.3.2    Альфы ядра служат основой для определения методов и практик программной инженерии.

4.3.3    Ядро должно включать в себя следующие альфы, взаимосвязанные в областях интересов

ядра:

-    возможность:

•    заинтересованные стороны;

•    требования:

•    программная система:

•    работа:

•    команда;

•    технология работы.

взаимосвязь альф в трех областях интересов представлена на рисунке 1.

3

ГОСТ Р 57195—2016

4.3.3.1    6 области интересов «Клиент» команда должна выявить заинтересованные стороны и возможности, которые будут рассмотрены, при этом:

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

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

4.3.3.2    В области интересов «Решение» команда должна сформировать общее понимание требований и внедрить, построить, протестировать, запустить и обеспечить поддержку программной системы. которая их осуществляет, при этом:

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

Программная система может быть частью более крупного решения по программному и аппаратному обеспечению, социального или бизнес-решения.

4.3.3.3    В области интересов «Деятельность» должны быть сформированы команда и технология работы, выполнена работа.

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

Команда планирует и выполняет работу, необходимую для обновления и изменения программной системы.

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

4

ГОСТ Р 57195—2016

4.4    Пространства действий ядра

4.4.1    Ядро должно обеспечивать пространства действий, которые дополняют альфы и предлага-ют новое видение программной инженерии, основанное на деятельности.

4.4.1.1    В области интересов «Клиент» команда должна изучить возможность, оказания поддержки заинтересованным сторонам и привлечения их к участию в работе. При этом необходимо:

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

•    установить контакт с заинтересованными сторонами, чтобы понять их потребности и гарантировать получение нужных результатов;

•    обеспечить удовлетворенность заинтересованных сторон;

•    использовать систему в реальных условиях эксплуатации для повышения эффективности деятельности заинтересованных сторон.

4.4.1.2    В области интересов «Решение» команда должна разработать соответствующее решение для развития возможности и удовлетворения заинтересованных сторон, при этом необходимо:

•    добиться общего понимания того, что должна делать созданная программная система:

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

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

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

•    управлять системой, поддерживать эксплуатацию программной системы в реальных условиях.

4.4.1.3    В области интересов «Деятельность» команда должна быть сформирована и выполнять работу в соответствии с согласованной технологией работы, при этом необходимо:

-    подготовиться к выполнению работы, сформировать команду и рабочую среду:

•    координировать и направлять работу команды, осуществлять текущее и ретроспективное планирование работы, добавлять дополнительные ресурсы, необходимые для завершения формирования команды;

•    поддерживать команду, помогая ее членам сотрудничать друг с другом и совершенствовать технологию работы;

•    отслеживать, измерять и оценивать прогресс, достигнутый командой:

-    остановить деятельность по разработке программного обеспечения и завершить передачу дел другой команде.

4.5    Область интересов ядра «Клиент»

4.5.1    Область интересов ядра «Клиент» включает в себя все. что связано с фактическим использованием и эксплуатацией разрабатываемой программной системы.

4.5.2    Программная система может быть разработана исключительно при наличии, как минимум, одного клиента, готового использовать данную программную систему.

4.5.3    Область интересов «Клиент» включает в себя следующие альфы:

-    заинтересованные стороны;

•    возможность.

4.5.4    Альфа ядра «заинтересованные стороны»

4.5.4.1    Заинтересованные стороны предоставляют возможность и одновременно являются источником требований к программной системе. Они должны принимать участие во всех аспектах деятельности по разработке программного обеспечения, оказывая поддержку команде и гарантируя выпуск приемлемой программной системы.

4.5.4.2    Заинтересованные стороны критически важны для успеха программной системы и работы. выполняемой для ее разработки. Их вклад и обратная связь помогают организовать деятельность по разработке программного обеспечения и сформировать итоговую программную систему.

4.5.4.3    Во время разработки программной системы заинтересованные стороны проходят через изменения состояний согласно таблице 1.

5

ГОСТ Р 57195—2016

Таблица 1 — Состояния заинтересованных сторон

Порядковый

номер

состояния

Наименование состояния

Описание состояния

1

Заинтересованные стороны признаны

Заинтересованные стороны идентифицированы

2

Заинтересованные стороны представлены

Механизмы привлечения заинтересованных сторон согласованы. а представители заинтересованных сторон назначены

3

Заинтересованные стороны привлечены

Предстаеигегы заинтересованных сторон принимают активное участив в работе и выполняют свои обязанности

4

Заинтересованные стороны согласованы

Представители заадресованных сторон согласованы

5

Заинтересованные стороны удовлетворены запуском программной системы

Минимальные ожидания представителей заинтересованных сторон оправданы

6

Заинтересованные стороны удовлетворены эксплуатацией программной системы

Программная система удовлетворила или превысила минимальные ожидания заинтересованных сторон

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

4.5.4.5    Число и тип групп идентифицируемых заинтересованных сторон могут в значительной степени отличаться в зависимости от конкретной системы.

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

4.5.4.7    Группы заинтересованных сторон должны быть активно представлены, т. е. должны быть выбраны один или несколько представителей заинтересованной стороны, представляющие каждую группу заинтересованных сторон, или один представитель заинтересованной стороны, представляю* щий все группы заинтересованных сторон и помогающий команде.

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

4.5.4.8    Команда должна обеспечить активное участие представителей заинтересованных сторон в разработке программкой системы.

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

4.5.4.10    Для оценки состояния заинтересованных сторон используют контрольные списки согласно таблице 2.

б

ГОСТ Р 57195—2016

Таблица 2 — Контрольный список для состояний заинтересованных сторон

Состояние

Контрольный слисос

Заинтересованные стороны признаны

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

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

Обязанности представителей заинтересованных сторон определены

Заинтересованные стороны представлены

Представители заинтересованных сторон согласились принять на себя обязанности.

Представители заинтересованных сторон уполномочены выполнять свои обязанности.

Коллаборативный подход представителей заинтересованных сторон согласован.

Представители заинтересованных сторон поддерживают и уважают технологию работы команды

Заинтересованные стороны привлечены

Представители заинтересованных сторон помогают группе в соответствии со своими обязанностями.

Представители заинтересованных сторон обеспечивают оперативную обратную связь и принимают участие в принятии решений.

Представители заинтересованных сторон оперативно распространяют информацию об изменениях, актуальных для представляемых ими трупп заинтересованных сторон

Заинтересованные стороны согласовали свои ожидания

Представители заинтересованных сторон согласовали минимальные ожидания от следующего запуска новой системы.

Представители заинтересованных сторон довольны степенью своего участия в работе.

Представители заинтересованных сторон признают, что их вклад высоко оценен командой, и к нему относятся с уважением.

Члены команды признают, что их вклад высоко оценивается представителями заинтересованных сторон, и к нему относятся с уважением.

Представители заинтересованных сторон согласны с тем. как именно их различные приоритеты и точки зрения приводятся в равновесие в целях обеспечения четкого направления для команды

Заинтересованные стороны удовлетворены запуском программной системы

Представители заинтересованных сторон предоставляют обратную связь по системе с точки зрения своих групп заинтересованных сторон.

Представители заинтересованных сторон подтверждают, что система готова к вводу в эксплуатацмо

Заинтересованные стороны удовлетворены эксплуатацией программной системы

Представители заинтересованных сторон используют новую систему и предоставляют обратную связь о своих впечатлениях.

Заинтересованные стороны подтверждают, что новая система соответствует их ожиданиям

4.5.5 Альфа ядра «возможность»

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

4.5.5.2    Понимание возможности позволяет команде:

•    идентифицировать и мотивировать заинтересованные стороны:

•    понять потенциал, предлагаемый программной системой заинтересованным сторонам;

•    понять, зачем разрабатывается программная система:

•    понять, каким образом будет оцениваться эффект ввода в эксплуатацию программной системы;

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

7

ГОСТ Р 57195—2016

4.5.5.3    Возможность должна объединять заинтересованные стороны и служит мотивацией для производства новой или усовершенствованной программной системы.

4.5.5.4    Во время разработки программной системы возможность проходит через изменения со» стояний согласно таблице 3.

Таблица 3 — Состояния возможности

Порядке* вый номер состояния

Наименование

состояния

Описание состояния

1

Возможность идентифицирована

Идентифицирована коммерческая, социальная или деловая возможность. которая может быть реализована с помощью решения на базе программного обеспечения

2

Необходимо решение

Возможность проанализирована и подтверждена потребность в решении на базе программного обеспечения

3

Ценность установлена

Ценность возможности установлена, и требуемые результаты решения определены

4

Возможность целесообразна

Известно достаточно о стоимости создания и использования предполагаемого решения, и с учетом данной информации есть понимание, что разработка возможности цепесообразна

5

Возможность рассмотрена

Подготовлено ре шейте, отражающее, что возможность рассмотрена

б

Выгода извлечена

Извлечена выгода из эксплуатации итогового решения

4.5.5.5 Для оценки состояния возможности и прогресса на пути к ее успешной реализации используют контрольные списки согласно таблице 4.

Таблица 4 — Контрольный список для возможности

Состояние

Контрольный список

Возможность идентифицирована

Идея по поводу усовершенствования текущего способа работы, увеличения доли рынка или применения новой или инновационной программной системы идентифицирована.

Как минимум, одна заинтересованная сторона желает инвестировать в улучшение понимания возможности и ценности, сопутствующей ее реализации.

Другие заинтересованные стороны, разделяющие возможность, идентифицированы

Необходимо решение

Заинтересованные стороны в рашах возможности и предполагаемое решение идентифицированы.

Потребности заинтересованных сторон, являющиеся источником возможности, определены.

Все скрытые проблемы и их первопричины идентифицированы.

Подтверждена необходимость разработки решения на базе программного обеспечения.

Предложено, как минимум, одно решение на базе программного обеспечения

Ценность уста новое на

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

Воздействие решения на заинтересованные стороны установлено.

Ценность, предлагаемая программной системой заинтересованным сторонам, которые финансируют и используют систему, установлена.

Критерии эффективности, по которым следует оценивать ввод в эксплуатацию программной системы, четко определены.

Требуемые результаты решения четко определены и выражены количественно

8

ГОСТ Р 57195—2016

Окончание таблицы 4

Состояние

Контрольный список

Возможность целесообразна

Решение намечено в общих чертах.

Все указывает на то. что решение может быть разработано и запущено е рамках ограничений.

Риски, связанные с решением, приемлемы и управляемы.

Ориентировочная стоимость решения меньше, чем ожидаемая ценность возможности.

Причины разработки решения на базе программного обеспечения понятны всем членам команды.

Целесообразность разработки возможности очевидна

Возможность рассмотрена

Пригодная к использованию система, явным образом реализующая возможность, есть в наличии.

Заинтересованные стороны признают необходимость запуска доступного решения. Заинтересованные стороны удовлетворены тем. как выполненное решение реализует возможность

Выгода извлечена

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

4.5.6    Область интересов «Клиент» включает в себя четыре пространства действий:

•    изучение возможности;

•    понимание (определение) нужд заинтересованных сторон;

•    обеспечение удовлетворенности заинтересованных сторон;

•    использование программной системы.

4.5.6.1    Изучение возможности должно позволить:

•    привлечь к участию нужные заинтересованные стороны;

•    понять запросы заинтересованных сторон;

•    идентифицировать возможности использования программной системы:

•    понять, зачем нужна программная система;

•    определить ценность, предлагаемую программной системой.

4.5.6.2    Понимание (определение) нужд заинтересованных сторон должно позволить:

•    гарантировать создание нужного решения:

•    согласовать ожидания;

•    собрать обратную связь и сгенерировать входные данные:

•    гарантировать, что выполненное решение приносит пользу заинтересованным сторонам.

4.5.6.3    Обеспечение удовлетворенности заинтересованных сторон должно позволить:

•    получить одобрение на запуск программной системы;

•    подтвердить, что программная система полезна для заинтересованных сторон;

•    подтвердить, что программная система приемлема для заинтересованных сторон;

•    независимо верифицировать, что итоговая программная система соответствует требованиям;

•    подтвердить ожидаемую выгоду, обеспечиваемую программной системой.

4.5.6.4    Использование программной системы должно позволить.

•    получить измеримые выгоды;

•    собрать обратную связь по итогам использования программной системы;

•    подтвердить, что программная система соответствует ожиданиям заинтересованных сторон;

. определить доход на инвестиции программной системы.

4.6    Область интересов ядра «решение»

4.6.1    Область интересов ядра «решение» включает в себя все, что связано со спецификацией и разработкой программной системы.

4.6.2    Целью программной инженерии является разработка рабочего программного обеспечения как части решения некой проблемы. Любой утвержденный метод должен описывать совокупность прак-тик. предназначенную для того, чтобы помочь команде совместными усилиями и продуктивным образом создать высококачественное программное обеспечение.

9

ГОСТ Р 57195—2016

4.6.3    Область интересов «Решение» включает в себя следующие альфы:

• требования;

- программная система.

4.6.4    Альфа ядра «требования»

4.6.4.1    Требования отражают то. что хотят от системы заинтересованные стороны.

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

4.6.4.3    Требования устанавливают рамки и ограничения работы посредством определения того, что должно быть достигнуто.

4.6.4.4    Требования состоят из набора элементов требований. Элементы требований могут быть доведены до сведения и записаны в различных формах и с различным количеством подробностей. Элементы требований всегда документируют и отслеживают.

4.6.4.5    во время разработки программной системы требования проходят через изменения состояний согласно таблице 5.

Таблица 5 — Состояния требований

Порядке-аый номер состояния

Наименование состояния

Описание состояния

1

Требования сформулированы

Все заинтересованные стороны признают, что существует потребность в новой программной системе

2

Требования ограничены

Определены масштаб новой системы, аспекты возможности, которые должны быть рассмотрены, и механизмы управления и принятия новых или измененных элементов требований

3

Требования непротиворечивы

Требования обеспечивают непротиворечивое описание существенных характеристик новой системы

4

Требования приемлемы

Требования описывают систему для заинтересованных сторон

5

Требования адресованы

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

б

Требования удовлетворены

В итоговую программную систему внедрено достаточно требований, для того чтобы заинтересованные стороны признали, что данная программная система в полной мере удовлетворяет потребность в новой системе, и программную систему можно признать законченной

4.6.4.6 Для оценки требований на пути к их успешному осуществлению, следует использовать контрольные списки согласно таблице 6.

Таблица 6 — Контрольный список для требований

Состояние

Контрольный СПИСОК

Требования сформулированы

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

Заинтересованные стороны, которые будут использовать новую систему, идентифицированы.

Заинтересованные стороны, которые профинансируют начальную работу по созданию новой системы, идентифицированы.

Существует очевидная возможность, которую реализует новая система

10

ГОСТ Р 57195—2016

Окончание таблицы 6

Состояние

Контрольный СЛИСОК

Требования ограничены

Заинтересованные стороны, вовлеченные в разработку новой системы, идентифицированы.

Заинтересованные стороны согласны с назначением новой системы.

Определено, что будет считаться положительным эффектом от внедрения новой системы.

Заинтересованные стороны имеют одинаковое понимание пределов предлагаемого решения.

Технология описания требований согласована.

Механизмы управления требованиями есть в наличии.

Приоритезационная схема ясна.

Ограничения определены и приняты во внимание.

Допущения ясно сформулированы

Требования непротиворечивы

Требования задокументированы и достутыы команде и заинтересованным сторонам.

Происхождение требований ясно.

Обоснование требований ясно.

Противоречивые требования идентифицированы, и ими занимаются.

Требования сообщают существенные характеристики разрабатываемой системы. Наиболее важные сценарии использования системы могут быть объяснены. Приоритетность требований ясна.

Влияние реализации требований понимается.

Команда понимает, что должно быть осуществлено, и соглашается осуществить это

Требования приемлемы

Заинтересованные стороны признают, что требования описывают приемлемое решение.

Скорость изменений согласованных требований относительно низка и под контролем.

Польза, обеспечиваемая внедрением требований, ясна.

Части возможности, удовлетворяемые исполнением требований, ясны

Требования адресованы

Адресовано достаточное количество требований, чтобы результирующая система была приемлема для заинтересованных сторон.

Заинтересованные стороны признают, что требования точно отражают, что система должна и не должна делать.

Набор внедренных единиц требований обеспечивает очевидную пользу для заинтересованных сторон.

Система, реализующая требования, воспринимается заинтересованными сторонами как заслуживающая эксплуатации

Требования удовлетворены

Заинтересованные стороны принимают требования в качестве точно фиксирующих то. что требуется для полного удовлетворения потребности в новой системе.

Нет никаких невыполненных элементов требований, которые не дают принять систему как полностью удовлетворяющую требованиям.

Система принята заинтересованными сторонами как полностью удовлетворяющая требованиям

4.6.5 Альфа ядра «программная система»

4.6.5.1    Программная система может быть частью более крупного решения по программному и аппаратному обеспечению, социального или бизнес-решения.

4.6.5.2    Во время разработки программная система проходит через изменения состояния согласно таблице 7. Данные состояния могут быть применены к первоначальной версии программной системы или к любой последующей ее модификации или замене.

11

ГОСТ Р 57195—2016

Таблица 7—Состояния программной системы

Порядке* оый номер состояния

Наименование состояния

Описание состояния

1

Архитектура выбрана

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

2

Программная система демонстрируема

Создана демонстрируемая программная система, подтверждающая архитектуру и обеспечивающая условия для начала тестирования

3

Программная система подходит для использования

Программная система развита и усовершенствована в такой степени, что становится готовой к использованию и демонстрирует все качественные характеристики эксплуатируемой системы

4

Программная система готова

Пригодная к использованию программная система доработана в такой степени, что признается готовой к запуску

5

Программная система эксплуатируется

Программная система предоставлена в распоряжение заинтересованным сторонам, которые ее используют, и введена в эксплуатацию

6

Программная система выведена из эксплуатации

Программная система выведена из эксплуатации, а ее поддержка прекращена

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

4.6.5.4    Программная система должна быть полностью наглядна и отражать все важные характеристики выбранной архитектуры.

4.6.5.5    Программная система должна поддерживать как функциональное, так и нефункциональное тестирование.

4.6.5.6    Программная система становится пригодной для использования после того, как устранены все дефекты, выявленные в процессе тестирования программной системы.

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

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

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

*    программная система полностью заменяется программкой системой нового поколения:

•    у программной системы не остается пользователей;

- в коммерческом отношении нет смысла продолжать эксплуатацию программной системы.

4.6.5.10    Для оценки состояния программной системы используют контрольные списки согласно таблице 6.

Таблица 8 — Контрольный список для программной системы

Состояние

Контрольный список

Архитектура выбрана

Критерии, которые должны быть использованы при выборе архитектуры, согласованы.

Аппаратные платформы определены.

Языки программирования и используемые технологии выбраны.

Границы программной системы известны.

Значимые решения об организации программной системы приняты.

Решения о том. что покупать, что создавать, а что использовать повторно, приняты

12

ГОСТ Р 57195—2016

Окончание таблицы В

Состояние

Контрольный СПИСОК

Программная система демонстрируема

Ключевые архитектурные характеристики продемонстрированы.

Программная система может быть опробована, а ее рабочие характеристики могут быть измерены.

Критические конфигурации оборудования продемонстрированы.

Критические интерфейсы продемонстрированы.

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

Программная система подходит для использования

Программная система может эксплуатироваться использующими ее заинтересованными сторонами.

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

Содержание версии известно.

Добавочная ценность, обеспечиваемая программной системой, определена

Программная система готова

Установочная и иная пользовательская документация доступна.

Представители заинтересованных сторон принимают программную систему как удовлетворяющую своему назначению.

Представители заинтересованных сторон хотят принять программную систему в эксплуатацию.

Эксплуатационная поддержка в наличии

Программная система эксплуатируется

Программная система доступна заинтересованным сторонам, которые намерены ее использовать.

Есть, как минимум, один пример полностью работающей программной системы. Программная система полностью поддерживается на согласованном уровне сервиса

Программная система выведена из эксплуатации

Программная система была заменена или прекращена в использовании. Программная система больше не поддерживается.

Нет «официальных» заинтересованных сторон, которые до сих пор используют программную систему.

Обновления к программной системе больше не будут выпускаться

4.6.6 Область интересов «Решение» включает е себя шесть пространств действий:

•    понимание требований к программной системе:

•    формирование программной системы:

•    внедрение программной системы:

•    тестирование программной системы;

•    развертывание программной системы;

•    эксплуатация программной системы.

4.6.6.1    Понимание требований к программной системе должно позволить:

. определить масштаб программной системы:

•    определить, каким образом программная система будет генерировать ценность;

•    согласовать, что будет делать программная система:

•    идентифицировать конкретные способы использования и тестирования программной системы:

•    стимулировать разработку программной системы.

4.6.6.2    Формирование программной системы должно позволить:

•    структурировать программную систему и идентифицировать ключевые элементы программной системы:

•    распределить требования по элементам программной системы:

•    обеспечить необходимую надежность и гибкость программной системы.

4.6.6.3    Внедрение программной системы должно позволить:

•    создать рабочую программную систему:

. разработать, интегрировать и протестировать элементы программной системы;

13

ГОСТ Р 57195—2016

•    увеличить число реализованных требований к программной системе:

-    исправить дефекты программной системы:

•    усовершенствовать программную систему.

4.Б.6.4 Тестирование программной системы должно позволить:

•    верифицировать соответствие программной системы требованиям:

•    идентифицировать дефекты программной системы.

4.6.6.5    Развертывание программной системы должно позволить:

•    подготовить программную систему к использованию в реальных условиях эксплуатации;

•    сделать программную систему эксплуатируемой.

4.6.6.6    Эксплуатация программной системы должна позволить:

•    обеспечить обслуживание программной системы на необходимом уровне:

-    поддерживать заинтересованные стороны, которые используют программную систему;

-    поддерживать заинтересованные стороны, которые развертывают, эксплуатируют и помогают поддерживать программную систему.

4.7 Область интересов «Деятельность»

4.7.1    Область интересов ядра «Деятельность» включает в себя все. что связано с командой и технологией работы команды.

4.7.2    Методы программной инженерии должны описывать набор практик для эффективного планирования. руководства и мониторинга работы команды.

4.7.3    Область интересов «Деятельность» включает в себя следующие альфы ядра:

•    команда;

-    работа;

-    технология работы.

4.7.4    Альфа ядра «команда»

4.7.4.1    Команда должна планировать и выполнять работы, необходимые и достаточные для создания. обновления и/или изменения программной системы.

4.7.4.2    во время разработки программной системы команда проходит через изменения состояний согласно таблице 9.

Таблица 9—Состояния команды

Порядковый номер

СОСТОЯНИЯ

Наименование состояния

Описание состояния

1

Команда отобрана

Определена миссия команды, и есть понимание того, как развивать команду

2

Команда сформирована

Команда была пополнена достаточным количеством людей с принятыми обязательствами, чтобы начать миссию

3

Команда сотрудничает

Члены команды работают вместе как одно целое

4

Команда успешно работает

Команда работает результативно и эффективно

5

Команда распущена

Команда больше не несет ответственность за выполнение своей миссии

4.7.4.3    Если к команде присоединяется или команду покидает определенное число людей или контекст миссии меняется, команда может вернуться в предыдущее состояние.

4.7.4.4    Если команда больше не имеет целей или ее миссии выполнены, она должна быть распущена.

4.7.4.5    Для оценки состояния команды используют контрольные списки согласно таблице 10.

14

ГОСТ Р 57195—2016

Таблица 10—Контрольный список для команды

Наименование

состояния

Контрольный список

Команда отобрана

Миссия команды в плане возможностей и результатов определена.

Ограничения на работу команды известны.

Механизмы для роста команды есть в наличии.

Состав команды определен.

Все ограничения, определяющие где и как будет выполняться работа, установлены. Обязанности команды обрисованы в общих чертах.

Уровень принятых командой обязательств ясен.

Требуемые компетенции определены.

Размер команды определен.

Правила контроля за деятельностью определены.

Форма управления выбрана

Команда сформирована

Индивидуальные обязанности понимаются.

Было набрано достаточное число членов команды, чтобы работа продвигалась. Каждый член команды понимает, как организована команда.

Все члены команды понимают, как выполнять работу.

Все члены команды встретились (возможно, виртуально) и познакомились друг с другом.

Члены команды понимают свои обязанности и то. как они увязаны с их компетенциями. Члены команды принимают работу.

Все внешние смежные соисполнители (организации, команды и индивиды) определены. Механизмы общения в команде определены.

Каждый член команды принял обязательство работать в команде, как это определено

Команда сотрудничает

Команда работает как одно сплоченное подразделение.

Общение в команде открытое и доверительное.

Команда сфокусирована на достижение миссии команды.

Члены команды ставят успех команды выше своих собственных целей. Члены команды знают друг друга

Команда успешно работает

Команда систематически выполняет обязательства.

Команда непрерывно адаптируется к изменяющемуся контексту.

Команда определяет и рассматривает проблемы без внешней помощи.

Команда неизменно добивается высоких реэутътатов.

Команду считают высокоэффективной.

Прогресс в результатах достигается с минимальным необходимым возвращением к сделанному и с минимальными исправлениями.

Работа вхолостую и причины для нее постоянно устраняются

Команда распущена

Обязанности команды были переданы или прекращены.

Члены команды готовы к назначению в другие команды.

Командой больше не предпринимается никаких усилий для завершения миссии

4.7.5 Альфа ядра «работа»

4.7.5.1    В программной инженерии работой является все. что делает команда для достижения цели, заключающейся в производстве программной системы, отвечающей требованиям, и реализации возможности, предоставленной заинтересованными сторонами.

4.7.5.2    Работу следует осуществлять с применением практик, из которых состоит технология работы команды.

4.7.5.3    Во время разработки программной системы работа проходит через изменения состояний согласно таблице 11.

15

ГОСТ Р 57195—2016

Таблица 11 — Состояния работы

Порядке* яый номер состояния

Наименооаиио

состояния

Описание состояния

1

Работа инициирована

Определен требуемый результат, и созданы необходимые и достаточные условия для выполнения работы

2

Работа подготовлена

Все предварительные условия для начала работы выполнены

3

Работа начата

Команда собрана, и работа выполняется

4

Работа под контролем

Работа продвигается хорошо, риски под контролем, уровень производительности достаточен для достижения удовлетворительного результата

5

Работа закончена

Работа, нацеленная на достижение результатов, закончена

6

Работа закрыта

Все оставшиеся служебные задачи завершены, и работа официально закрыта

47.5.4    Уровень, глубина и степень распределения работ зависят от типа и сложности работы и от конкретных практик, которые выбирает команда для облегчения координации, мониторинга, контроля и осуществления работы.

47.5.5    Если по какой-либо причине работа не продвигается успешно, ее можно приостановить, прекратить и вернуть в предыдущее состояние.

47.5.6    Если работа прекращается после начала, ее все равно необходимо корректно закрыть, даже несмотря на то что состояние «закончена» достигнуто не было.

4.7.57 Для оценки текущего и требуемого состояния работы следует использовать контрольные списки согласно таблице 12.

Таблица 12 — Контрольный список для работы

Няименомние

состояния

Контрольный список

Работа инициирована

Результат, требуемый от инициированной работы, понятен.

Любые ограничения на выполнение работы точно определены. Заинтересованные стороны, которые будут финансировать работу, известны. Инициатор работ известен.

Заинтересованные стороны, которые будут принимать работу, известны. Источник финансирования известен.

Приоритет работы понятен.

Работа подготовлена

Обязательства приняты.

Стоимость и требуемые усилия оценены.

Доступность ресурсов понимается.

Правила и процедуры управления ясны.

Риски понимаются.

Критерии приемки определены и согласованы с клиентом.

Работы разбиты достаточно, для того чтобы началась продуктивная работа.

Задачи определены и приоретизированы командой и заинтересованными сторонами. План, разработанный с учетом практических задач, есть в наличии.

Финансирование для начала работы есть в наличии.

Команда готова начать работу.

Моменты интеграции и поставки определены

Работа начата

Разработка начата.

Прогресс работы отслеживается.

Работа разбита на единицы действий с ясными определениями того, что нужно сделать.

Члены команды принимают и выполняют единицы работы

16

ГОСТ Р 57195—2016

Окончание таблицы 12

Наименование

состояния

Контрольный список

Работа под контролем

Число завершенных задач растет.

Незапланированная работа под контролем.

Риски под контролем, их влияние, если они реализуются, и вероятность их возникновения снижены до приемлемых уровней.

Оценки пересматриваются, для лучшего отражения производительности команды. Доступны меры для показа прогресса и скорости работы.

Исправления под контролем.

Задачи успешно завершаются вовремя и в соответствии с их оценками

Работа закончена

Все невыполненные задачи относятся к административным или к подготовке к следующему этапу работ.

Результаты были достигнуты.

Заинтересованные стороны приняли итоговую программную систему

Работа закрыта

Полученный опыт был сформулирован, записан и обсужден. Метрики были сделаны доступными.

Все было архивировано.

Бюджет был сверен и закрыт.

Команда была расформирована.

Нет незавершенных, недоделанных задач

4.7.6 Альфа ядра «технология работы»

4.7.6.1 Команда должна развивать технологию работы. По мере продвижения работы команда должна непрерывно адаптировать технологию работы к текущей обстановке.

47.6.2 Во время разработки программной системы технология работы проходит через изменения состояний согласно таблице 13.

Таблица 13 — Состояния технологии работы

Порядке* еын номер состояния

Наименование состояния

Описание состояния

1

Принципы установлены

Принципы и ограничения, которые определяют технологию работы. установлены

2

Основа заложена

Ключевые практики и инструменты, которые формируют основу технологии работы, выбраны и готовы к использованию

3

Технология работы используется

Некоторые члены команды используют технологию работы и адаптируют ее

4

Технология работы используется для выполнения работы

Все члены команды используют технологию работы, чтобы выполнять свою работу

5

Технология работы работает хорошо

Для команды технология работает хорошо

6

Технология работы вышла из употребления

Технология работы больше не используется командой

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

47.6.4    При разработке программной системы технология работы должна:

•    обеспечивать эффективную совместную работу команды:

•    обеспечивать возможность планирования и контроля работы:

•    помогать команде и соответствующим заинтересованным сторонам успешно выполнять свои обязанности.

17

ГОСТ Р 57195—2016

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

4.7.6.6    Для оценки текущего и требуемого состояния технологии работы следует испольэоаать контрольные списки согласно таблице 14.

Таблица 14 — Контрольный список для технологии работы

Наименование состояния

Контрольный слисо>

Принципы установлены

Команда придерживается принципов и ограничений.

Принципы и ограничения согласованы с заинтересованными сторонами. Необходимые для работы практики и заинтересованные стороны согласованы. Необходимые для работы инструменты и заинтересованные стороны согласованы. Рекомендации по избранному подходу доступны.

Контекст, в котором будет работать команда, понятен.

Ограничения, применимые к выбору и использованию практик и инструментов, известны.

Ограничения, регулирующие выбор и приобретение практик и инструментов, известны

Основа заложена

Ключевые практики и инструменты, которые формируют основу технологии работы. выбраны.

Командой согласовано достаточное число практик, чтобы начать работу.

Все не подлежа шив обсуждению практики и инструменты определены.

Неувязки, которые есть между доступными практиками и инструментами и необходимыми практиками и инструментами, проанализированы и поняты.

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

Выбранные практики и инструменты интегрированы, чтобы сформировать технологию работы, которую можно использовать

Технология работы используется

Практики и инструменты используются для реальной работы.

Использование выбранных практик и инструментов регулярно проверяется. Практики и инструменты адаптированы к контексту команды.

Использование практик и инструментов командой поддерживается.

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

Практики и инструменты поддерживают работу команды и сотрудничество

Технология работы используется для выполнения работы

Прахтики и инструменты используются всей командой для аыпотмения работы. Все члены команды имеют доступ к практикам и инструментам, требующимся для их работы.

Вся команда вовлечена в проверку и адаптацию технологии работы

Технология работы работает хорошо

Члены команды продвигаются 8 работе согласно плану, используя технологию работы и адаптируя ее к текущей обстановке.

Команда естественным образом применяет практики, без предварительной подготовки.

Инструменты естественным образом поддерживают способ работы команды. Команда постоянно подстраивает способ использования практик и инструментов

Технология работы вышла из употребления

Технология работы команды больше не используется. Полученный опыт опубликован для использования в будущем

4.7.7 Область интересов «Деятельность» включает в себя пять пространств действий

-    подготовка к выполнению работы;

-    координация деятельности;

•    поддержка команды;

•    отслеживание прогресса;

•    остановка работы.

4.7.7.1 Подготовка к выполнению работы должна позволить:

•    реализовать первоначальные планы;

•    сформировать начальную технологию работы;

ГОСТ Р 57195—2016

•    собрать и мотивировать проектную команду;

•    привлечь финансирование и ресурсы.

47.7.2    Координация действий должна позволить:

•    выбрать работу и расставить приоритеты;

•    адаптировать планы для отражения результатов;

•    привлечь в команду нужных людей;

•    обеспечить соответствие целям;

•    проанализировать изменения.

47.7.3    Поддержка команды должна позволить:

•    улучшить командную работу;

. преодолеть все препятствия в работе;

. совершенствовать технологию работы.

47.7.4    Отслеживание прогресса, достигнутого командой, должно позволить:

•    оценить результаты проделанной работы:

•    измерить прогресс, достигнутый командой.

•    определить трудности, возникшие у команды при выполнении работы.

4.77.5    Прекращение работы должно позволить:

•    закрыть работу;

. передать все невыполненные обязательства;

. передать все невыполненные задачи;

•    отозвать команду;

•    архивировать всю проделанную работу.

5    Расширения ядра

5.1    Для эффективного управления работой по разработке программного обеспечения ядро может быть расширено.

5.2    Расширения ядра могут быть использованы следующими способами:

•    для конкретизации ядра, в целях обеспечения более полной картины разработки программного обеспечения:

•    в качестве шаблонов для создания собственных практик;

•    в качестве мотивации и примеров.

5.3    Ядро может иметь следующие расширения:

•    расширение бизнес-анализа;

•    расширение разработки.

•    расширение управления задачами.

5.3.1    Расширение бизнес-анализа осуществляют в области интересов ядра «Клиент» путем добавления двух альф для продвижения возможности и заинтересованных сторон, а именно:

•    запрос;

-    представитель заинтересованной стороны.

5.3.2    Расширение разработки осуществляют в области интересов ядра «Решение» путем добавления двух альф для продвижения требований и программной системы:

-    элемент требования;

•    элемент системы.

5.3.3    Расширение управления задачами осуществляют в области интересов ядра «Деятельность» путем добавления трех альф для продвижения команды, работы и технологии работы:

•    член команды;

•    задачи;

•    практики.

6    Требования к модели языка

6.1 Для создания грамматически корректных языковых конструкций при создании программной системы следует использовать модель языка, состоящую из элементов языка, сгруппированных в пять основных пакетов метамоделей:

19

ГОСТ Р 57195—2016

•    пакет «Основа»;

•    пакет «Альфа и рабочий продукт»;

•    пакет «Пространство действий и действие».

•    пакет «Компетенция»;

•    пакет «Вид».

Модель языка представлена на рисунке 2.

Рисунок 2 — Модель языка

6.1.1    Пакет «Основа» должен обеспечивать все основные элементы языка, необходимые для соз* дания базовой основы для языка, и содержать следующие элементы:

•    основной элемент:

•    группа элементов;

-    ассоциация деятельности;

•    характеристика деятельности:

-    элемент расширения:

-ядро:

•    элемент языка:

-    библиотека:

-    паттерн;

•    ассоциация паттернов:

-    практика:

•    ресурс;

-    тэг.

6.1.2    Пакет «Альфа и рабочий продукт» должен обеспечивать основные элементы, необходимые для простейшей формы практик, и содержать следующие элементы:

•    альфа;

•    связь альф:

-    локализация альфы;

•    контрольная точка:

> уровень детализации;

•    состояние;

•    рабочий продукт;

-    манифест рабочего продукта.

20

ГОСТ Р 57195—2016

6.1.3    Пакет «Пространство действий и действие» должен обеспечивать дополнительные элементы. необходимые для более продвинутых практик, и содержать следующие элементы, расширяющие практики посредством выражения действий, навыков и паттернов:

•    действие:

•    ассоциация действия;

•    манифест действия;

•    пространство действий:

•    критерии завершения.

6.1.4    Пакет «Компетенция» должен обеспечивать средства для добавления компетенций в практики и содержать следующие элементы для поддержки спецификации компетенций и навыков:

•    компетенция;

•    уровень компетенции.

6.1.5    Пакет «Вид» должен содержать элементы, предотвращающие избыток информации в элементе языковой конструкции, и элементы для поддержки спецификации содержимого вида:

•    выбор характеристик;

•    выбор вида.

6.2 Элементы языка могут быть расширены в целях создания более сложных и эффективных языковых конструкций.

6.2.1    При расширении элемент языка модифицируют или адаптируют в целях приведения его в соответствие с новым контекстом.

6.2.2    Расширение элемента следует проводить таким образом, чтобы оригинальный элемент при этом оставался доступным.

6.3 Элементы языка допускается сочетать в целях создания более эффективных элементов языка из простых элементов.

21

ГОСТ Р 57195—2016

УДК 004.912:006.354    ОКС 03.100.01

Ключевые слова: альфа, ядро. язык, системная и программная инженерия

22

Редактор М.И. Штык Технический редактор В.Н. Прусакова Корректор Ю.М. Прокофьева Компьютерная верстка Е.Е. Кругова

Сдано в набор 11.11.20(6. Подписано в печать 06.12.2016. Формат 60 *64%. Гарнитура Ариал Уст», печ. n. 3.26. Уч.-изд. п. 3.17. Тираж 28 экз. Зак. 3036.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта.

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ*. 12399S Москва. Гранатный пер.. 4.