Презентация на тему Omg semat essence основные принципы

OMG SEMAT ESSENCE

Основные принципы

Предпосылки создания

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

Необходимость

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

История OMG/SEMAT ESSENCE

Сентябрь 2009: инициатива Бертрана Майера, Ричарда Соли и Ивара Якобсона
Декабрь 2009: опубликован призыв к действию (http://semat.org/?page_id=2)
Февраль 2010: видение на год (http://blog.paluno.uni-due.de/semat.org/wp-content/uploads/2012/03/SEMAT-vision.pdf)
Июнь 2011: OMG FACESEM (Foundation for the Agile Creation and Enactment of Software Engineering Methods) RFP
Март 2012: видение на 3 года (http://blog.paluno.uni-due.de/semat.org/wp-content/uploads/2012/03/Semat_-_Three_Year_Vision13Jan12.pdf)
Осень 2012: появляются инструменты (карты, моделер)
Январь 2013: вышла книга «The Essence of Software Engineering»
Март 2013: Второе голосование (fast track) в OMG

Где нужны изменения

Ключевые принципы

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

Практический подход

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

Взаимосвязь сущностей

УГО

Практика

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

Ядро (Kernel)

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

Ядро (Kernel)

Ядро описывается при помощи небольшого подмножества языка ядра и состоит из трех областей. Каждая из областей содержит ограниченное количество т.н. «Альф» и «Областей активности».
Альфы (Alphas) представляют собой описания сущностей с которыми ведется работа.
Альфы описывают типы «вещей», которыми команда будет управлять, производить и использовать в процессе разработки, обслуживания и поддержки программного обеспечения.
Области дел (Activity Spaces) представляют действия, которые необходимо выполнить.
Активности описывают проблемы и вызовы, с которыми встретится команда при разработке, обслуживания и поддержке программных систем, а также действия, которые команда будет выполнять для их решения.

Организация Ядра

Ядро состоит из трех отдельных областей, каждая из которых посвящена конкретному аспекту разработки программного обеспечения.
Заказчик (Customer) – эта проблемная область содержит все, что связано с фактическим использованием и эксплуатацией программного обеспечения создаваемой системы.
Решение (Solution) – эта проблемная область содержит все, что связано описанием и разработкой программного обеспечения системы.
Предпринятие (Endeavor) - эта проблемная область содержит все, что связано с командой и способами ее работы.

Области интереса инженерной компании

Основная деятельность
Клиент (возможности, заинтересованные стороны): маркетинг
Решение (требования, система): инженерия
Предпринятие (работы, люди, технологии): операции
Организационно-техническое развитие предпринятия
Стратегирование
Организационная инженерия
Ведение проектов развития

системная инженерия

Пространства дел Ядра (activity spaces)

Ключевые активности в составе Ядра

Язык, сущности, практики

...

Язык

Сущности
(абстрактные)

Практики (конкретные)

...

Альфа: состояния = чеклисты : чекпойнты

ALPHA -- Abstract-Level Progress Health Attribute.

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

Представлены

Пример чеклиста стейкхолдеров

Выявлены (признаны)

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

Чеклист

Состояние

Деятельность меняет альфы Дела меняют рабочие продукты

меняют детальность

меняет состояния

продвигает

описывает

Альфы

Чеклисты.

Отражают не всё, а только главное (что все знают, но почему-то забывают и игнорируют).
чеклист запуска двигателя в полёте: 1. Fly the aircraft!
Прогон в специальных паузах (pause point) перед началом или перед окончанием каких-то работ (обнаружить проблемы, пока не поздно, гарантировать их обнаружение!)
Обязательно вслух перед всеми (общее знание проблем)
Проблемы находятся только 1 раз из 10. Этот один раз полностью окупает все затраты на остальные десять.

Компетенции

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

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

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

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

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

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

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

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

Как пользоваться

Суб-альфы

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

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

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

Элемент системы Независимо разрабатываемая и тестируемая часть системы.

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

Пример для SCRUM

Объединение Scrum и UserStory (пример)

=

Пример ЖЦ типа «Waterfall»

Колоды карт

Колоды карт

Essence и архитектура

Не представлена в текущей версии стандарта
Должна быть в описании СИ-методологии
Возможные варианты:
Архитектура – это альфа
Архитектура – это субальфа альфы «Система»
Архитектура – это паттерн

Системно-инженерный Essence: Альфы

V-диаграмма подальф

Описания

Описания (definitions) = Требования, Архитектура, Разработка (design)
Составляются из моделей, сгруппированных по «точкам зрения» (views)
Архитектурные фреймворки – субальфы альфы «Технология работы»
Архитектурные языки - также субальфы альфы «Технология работы» (использование языка есть практика)

Состояния описания

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

Спасибо за внимание

(Продолжение следует….)