про #моделирование
Я проповедую подход под названием Model Based System Engineering (MBSE) в применении к созданию программных систем. Изначально этот подход создавался для физических инженерных систем, но сами принципы вполне применимы в ИТ.
Суть в том, что мы на этапе анализа, проектирования не ТЗ на разработку пишем, а создаем структурированное описание в виде модели системы, точнее набор согласованных между собой моделей с разных точек зрения, включая, но не ограничиваясь теми, которые принято относить к описанию архитектуры. Модель включает в себя явное представление спецификации, требований к поведению системы в ключевых аспектах. На стадии разработки происходит реализация воплощения системы, соответствующей этой модели.
В инкрементальном процессе разработки у нас всегда есть какое-то актуальное состояние {модель + система}, и есть поток инкрементальных изменений модели и соответствующих изменених системы.
Цель создания и поддержания модели - снятие неопределенностей, подтверждение полезности будущей системы или её изменения до того, как будут потрачены существенные ресурсы на реализацию, поэтому модель еще на стадии проектирования должна позволять как-то оценить, насколько создаваемая система будет решать задачи, ради которых создается, а потом, после реализации, сравнить то что получилось с тем что ожидалось.
Важные моменты:
1. Глубина детализации моделей и технология их создания, поддержания и модификации должны быть достаточно легковесными, чтобы не превратить модели в обузу. Модель должна позволять до разработки быстро прогонять множество итераций обсуждения, верификации и модификации.
2. Способ представления моделей должен быть понятен заказчикам, разработчикам, тестировщикам и т.п., чтобы обсуждения и уточнения моделей были конструктивными.
3. Технология ведения моделями должна позволять представлять в виде отдельного читаемого артефакта инкрементальные изменения модели - это позволяет отказаться от ТЗ. На стадии анализа и проектирования очередного инкремента достаточно внести и согласовать в команде изменения в модель исходной системы, и артефакт, представляющий это изменение становится почти готовой постановкой на реализацию, останется лишь для полноты картины приложить к нему описание мотивации изменений.
Если на старте проекта договориться о составе и формате представления моделей, то дальше процесс становится почти прозрачным, с минимумом писанины. Звучит красиво, вопрос в том, какая же технология представления моделей позволяет работать таким образом. Удивительно, но пока что самый удобный и лаконичный способ моделирования, который удалось найти - это текстовые описания под гитом в markdown, plantuml, yaml и прочие лаконичные умеренно структурированные представления. Популярный в отрасли Confluence не удалось приспособить, он не позволяет явно управлять изменениями.
Post #156
348
- 👍 3
- 🤔 2