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

ГОСТ Р 57195-2016

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

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

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

Kernel and language for system and software engineering methods. General

ОКС 03.100.01

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

Предисловие

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

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

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

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

5 ПЕРЕИЗДАНИЕ. Февраль 2020 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Ядро должно быть небольшим и легким по своей структуре, но открытым, чтобы обеспечить возможность охвата новых технологий, практик, социальных рабочих моделей и новых исследований.

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.

Рисунок 1 - Альфы ядра в областях интересов "Клиент", "Решение", "Деятельность"

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 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 Целью программной инженерии является разработка рабочего программного обеспечения как части решения некой проблемы. Любой утвержденный метод должен описывать совокупность практик, предназначенную для того, чтобы помочь команде совместными усилиями и продуктивным образом создать высококачественное программное обеспечение.

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 - Состояния требований

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

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

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

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

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

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

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 Для оценки состояния программной системы используют контрольные списки согласно таблице 8.

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

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

- понимание требований к программной системе;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.6.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 - Состояния команды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- расширение разработки;

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

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

- запрос;

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

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

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

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

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

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

- задачи;

- практики.

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

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

- пакет "Основа";

- пакет "Альфа и рабочий продукт";

- пакет "Пространство действий и действие";

- пакет "Компетенция";

- пакет "Вид".

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

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

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

- основной элемент;

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

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

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

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

- ядро;

- элемент языка;

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

- паттерн;

- ассоциация паттернов;

- практика;

- ресурс;

- тэг.

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

- альфа;

- связь альф;

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

- контрольная точка;

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

- состояние;

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

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

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

- действие;

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

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

- пространство действий;

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

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

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

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

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

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

- выбор вида.

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

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

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

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

Электронный текст документа
и сверен по:

, 2020