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

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

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

Якобсона
Декабрь 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) - акцент на наиболее значимые вещи.

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

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

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

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

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

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

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

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

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

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

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

Чеклист

Состояние

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

дополняют Альфы, и Пространства Дел.

системой.

удовлетворить стейкхолдеров.

главную пользу путём выполнения программ.

поддержке какой-либо программной системы.

ведения и поддержки работы.

или достижения цели.

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

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

«точкам зрения» (views)
Архитектурные фреймворки – субальфы альфы «Технология работы»
Архитектурные языки - также субальфы альфы «Технология работы» (использование языка есть практика)