Omg semat essence основные принципы

1. OMG SEMAT ESSENCE

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

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

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

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

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

4. История OMG/SEMAT ESSENCE

Сентябрь 2009: инициатива Бертрана Майера, Ричарда Соли и
Ивара Якобсона
Декабрь 2009: опубликован призыв к действию
(http://semat.org/?page_id=2)
Февраль 2010: видение на год (http://blog.paluno.unidue.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.unidue.de/semat.org/wp-content/uploads/2012/03/Semat__Three_Year_Vision13Jan12.pdf)
Осень 2012: появляются инструменты (карты, моделер)
Январь 2013: вышла книга «The Essence of Software Engineering»
Март 2013: Второе голосование (fast track) в OMG

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

Промышленность
Специалисты
Менеджеры
Академическая среда
Образование
Исследования
Проблемы:
Проблемы:
Проблемы:
Проблемы:
- Компетенции
привязаны к продуктам
и с трудом переносятся
на другие продукты.
- Многократное
использование практик
- Преподавание и
изучение конкретных
методов (RUP,
SCRUM и др.) вместо
общей базы не
позволяет готовить
специалистов –
универсалов.
- Разрыв между
исследованиями и
промышленной
практикой
- Мечутся между
разными
направлениями, в
зависимости от
коньюктуры и
популярности.
- Многократное
использование программ
обучения
-«Многократное
использование" людей
- Трудность эволюционных
улучшений
SEMAT адресован всему этому сообществу
- Отсутствие
общепринятой
теории

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

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

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

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

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

9. УГО

10. Практика

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

11. Ядро (Kernel)

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

12. Ядро (Kernel)

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

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

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

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

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

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

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

Язык, сущности, практики
Язык
Сущности
(абстрактные)
...
...
17
Практики
(конкретные)

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

Альфа: состояния = чеклисты :
чекпойнты ALPHA -- Abstract-Level Progress Health Attribute.
Пример чеклиста стейкхолдеров
Состояние
Чеклист
Выявлены
(признаны)
Представлены
18
Все различные группы стейкхолдеров, которые влияют, или будут, влиять на
разработку и работу программной системы, идентифицированы.
Имеется соглашение на представление групп стейкхолдеров. Как минимум,
сформированы группы представителей стейкхолдеров, связанных с созданием,
использованием, поддержкой и обслуживанием системы.
Обязанности представителей стейкхолдеров определены.
Представители стейкхолдеров согласились принять на себя обязанности.
Представители стейкхолдеров имеют полномочия выполнять свои обязанности.
Порядок совместной работы среди представителей стейкхолдеров согласован.
Представители стейкхолдеров поддерживают и соблюдают технологию работы
группы.

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

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

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

Альфы

20. Альфы

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

21. Чеклисты.

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

22. Компетенции

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

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

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

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

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

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

Состояние
Начаты / (вар.Поняты)
(Conceived)
Ограничены (Bounded)
Непротиворечивы
(Coherent)
Приемлемы (Acceptable)
Адресованы (Addressed)
Выполнены /
удовлетворены (Fulfilled)
Чеклист
Начальный набор стейкхолдеров согласен в том, какая система должна быть получена.
Стейкхолдеры, которые будут использовать новую систему определены.
Стейкхолдеры, которые будет финансировать начало работ по новой системе определены.
Существует явная возможность для новой системы для решения.
Стейкхолдеры, участвующие в разработке новой системы определены.
Стейкхолдеры договорились о целях новой системы.
Понятны критерии успеха для новой системы.
Стейкхолдеры имеют единое представление о масштабах предлагаемого решения.
Порядок описания требований согласован.
Инструменты для управления требованиями готовы.
Расстановка приоритетов ясна.
Ограничения определены и учтены.
Предположения четко указаны.
Требования получены и разосланы команде и стейкхолдерам.
Происхождение требований ясно.
Обоснование требований ясно.
Противоречивые требования определены и выделены.
Требования связанные с существенными характеристиками системы получены.
Наиболее важные сценарии использования в системе разъяснены.
Приоритет требований ясен.
Влияние реализации требований понимается.
Команда понимает, что должен быть выполнено и согласна это выполнить.
Стейкхолдеры признают, что требования описывают приемлемое решение.
Скорость изменения согласованных требований относительно низка и находится под контролем.
Ценность, получаемая в результате реализации требований ясна.
Частичная возможность удовлетворения требования ясна.
Требования проверяемы.
Количество и качество требований к будущей системе удовлетворяет стейкхолдеров.
Стейкхолдеры принимают требования как точное отражение того, что система делает и что не делает.
Набор реализованных единиц требований предоставляет понятную ценность для стейкхолдеров.
Система, реализующая требования, принята стейкхолдерами как заслуживающая созданиия и эксплуатации.
Стейкхолдеры утвердили требования как точно выражающие их потребности в отношении создаваемой системы.
Отсутствуют неразрешенные единицы (пункты) требований, что позволяет системе быть считаться полностью удовлетворяющей
требованиям.
Система принимается стейкхолдерами как полностью удовлетворяющая требованиям.

26.

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

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

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

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

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

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

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

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

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

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

Суб-альфы

32. Суб-альфы

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

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

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

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

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

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

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

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

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

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

Пример для SCRUM

38. Пример для SCRUM

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

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

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

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

Колоды карт

41. Колоды карт

42. Колоды карт

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

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

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

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

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

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

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

46. Описания

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

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

Спасибо за внимание
(Продолжение следует….)