AL
Я бы тоже послал, но убедить Заказчика внедрить VP не получилось. Поэтому пользую его только во внутренних проектах и ттлько там, где archmate не нужен.
Я для архимейта применяю Арчи с его coLab плагином и мне норм.
Size: a a a
2020 March 12
AL
Если учесть, что они ещё и colab сервер пилят - нахрен вообще со спраксом ради архимейта заморачиваться.
YB
Я для архимейта применяю Арчи с его coLab плагином и мне норм.
А как трассируете архимэйт в прочие элементы?
AL
А как трассируете архимэйт в прочие элементы?
Какие например? )
YB
Process в BPMN, DB Artifact в ER...
YB
И чтобы выгружать докумпнтацию, надо как-то в одном месте жить, или быть просто богом кустаринга.
AL
Определитесь чего вы хотите от ER и BPMN.
AL
Если это замещаемо в Archimate - то переехать туда. Если это execetable BP - то сопоставление на уровне view
AL
Про ER - вообще можно транслятор 1 к 1 сделать, но нафига? Проще внешними ссылками.
AL
А так - вообще-то в 42010 не зря придумали correspondence rules ;)
YB
А так - вообще-то в 42010 не зря придумали correspondence rules ;)
Ок, если archi это умеет.
AL
Ок, если archi это умеет.
при призыве богов кустаринга и опенсорс сообщества - вполне
PS
Решили )
Я ковырял бейслайны, но так и не понял, как их к версионности прикрутить, чтобы можно было смотреть историю изменения конкретной арх модели 😒
AL
Petr Shmotov
Я ковырял бейслайны, но так и не понял, как их к версионности прикрутить, чтобы можно было смотреть историю изменения конкретной арх модели 😒
Минимум должны бейзлайниться:
0. Версии опорных документов для проектирования.
1. Версия требований.
2. Версия архитектурного описания
3. Версия методики испытаний.
4. Версия конструкторской документации
5. Версия программной документации
6. Версия пользовательской документации
Иначе смысла нет. Теряется прослеживаемость и как следствие управляемость процессом разработки.
Это всё может быть весьма неформально, с недоработками и т.п. но должно быть. Поскольку вы так ещё и технический долг можете считать и из него выводить риски для разработки.
0. Версии опорных документов для проектирования.
1. Версия требований.
2. Версия архитектурного описания
3. Версия методики испытаний.
4. Версия конструкторской документации
5. Версия программной документации
6. Версия пользовательской документации
Иначе смысла нет. Теряется прослеживаемость и как следствие управляемость процессом разработки.
Это всё может быть весьма неформально, с недоработками и т.п. но должно быть. Поскольку вы так ещё и технический долг можете считать и из него выводить риски для разработки.
AL
Желательно ещё хранить версии планов разработки.
AL
В итоге бейзлайн закрывается при выпуске версии продукта.
AL
Ну и соответственно при запуске разработки новой версии открывается новый.
PD
У нас есть пара мазохистов конечно, которые там требования ведут, но пока они в гордом одиночестве и их никто не трогает.
У меня от опыта Sparx ровно те же самые ощущения. Гадость, плохо спроектированная и плохо реализованная.
AL
У меня от опыта Sparx ровно те же самые ощущения. Гадость, плохо спроектированная и плохо реализованная.
Не, Фил, оно норм, если команда поддержки есть. Станки за заводе тоже ж чинить и допиливать надо ;)
PD
Ну, если для поддержки архитектурного тула за кучу денег нужна еще и команда поддержки - то это как раз о проблемах проектирования.
А с учетом ужасного UX и медленной работы - то нафиг.
Вообще, смешно, что у средства проектирования архитектуры явно плохая архитектура )
А с учетом ужасного UX и медленной работы - то нафиг.
Вообще, смешно, что у средства проектирования архитектуры явно плохая архитектура )