S
вообще, трассировка в целом полезна. Если на требование можно создать URI/URL то спецкомменты по коду будут полезны (и комменты в commit message)
Size: a a a
2019 August 25
GK
Да. Больше того, с моей точки зрения, трассировка это единственный способ связать артефакты аналитики (требования) с артефактами разработки. MDD, как мы понимаем, работает только в лабораторных условиях.
AL
Я предлагаю всё таки вспомнить, что говорили про MB-тулы их создатели в Vitech MBSE Primer, и остановиться на том, что MB - это всего-лишь способ поддержать инструментально некотоые мыслительные процессы.
AL
Таким образом в любом случае автоматизировав некоторые действия людей в блжайшей перспективе не получится их заменить.
AL
MDD хорош когда:
1. Есть компетенции в людях в отношении процесса разработки и необходимо снизить рутинные затраты на провеку качества принимаемых решений.
2. Есть заведомо качественное описание и его нужно проанализировать на возможность внесения изменений.
1. Есть компетенции в людях в отношении процесса разработки и необходимо снизить рутинные затраты на провеку качества принимаемых решений.
2. Есть заведомо качественное описание и его нужно проанализировать на возможность внесения изменений.
AL
Другие примеры мне пока не известны.
GK
Таким образом в любом случае автоматизировав некоторые действия людей в блжайшей перспективе не получится их заменить.
Зависит от мастерства. Идеальный проект состоит всего из двух фаз: заключение договора и подписание актов приёма-сдачи. Шутка, разумеется)
AL
Зависит от мастерства. Идеальный проект состоит всего из двух фаз: заключение договора и подписание актов приёма-сдачи. Шутка, разумеется)
Идеальный из одного. Перевод денежных средств.
GK
Идеальный из одного. Перевод денежных средств.
Вынужден признать, ты усовершенствовал понимание идеального проекта)
AL
Вынужден признать, ты усовершенствовал понимание идеального проекта)
Угу, а карманник - идеальный проджект менеджер)
GK
MDD хорош когда:
1. Есть компетенции в людях в отношении процесса разработки и необходимо снизить рутинные затраты на провеку качества принимаемых решений.
2. Есть заведомо качественное описание и его нужно проанализировать на возможность внесения изменений.
1. Есть компетенции в людях в отношении процесса разработки и необходимо снизить рутинные затраты на провеку качества принимаемых решений.
2. Есть заведомо качественное описание и его нужно проанализировать на возможность внесения изменений.
Хорош только тогда, когда с первого раза можно всё сделать правильно. Потому что обычно на изменениях всё разъезжается
AL
Хорош только тогда, когда с первого раза можно всё сделать правильно. Потому что обычно на изменениях всё разъезжается
Есть прям такая практика Change management. Говорят помогает.
AL
Это я про людей всё туда же, если что.
GK
Есть прям такая практика Change management. Говорят помогает.
Нет. Автогенерируемый код разъезжается. Особенно если его уже подправили вручную. Change management тут не помогает
AL
Нет. Автогенерируемый код разъезжается. Особенно если его уже подправили вручную. Change management тут не помогает
Стоп, а где я про автогенерируемый код говорил? Я пока только про создание хорошего, согласованного описания продукта, которое удовлетворяет всем важным выявленным требованиям.
AL
Можно ли из это сгенерировать код? Не проверял.
GK
Стоп, а где я про автогенерируемый код говорил? Я пока только про создание хорошего, согласованного описания продукта, которое удовлетворяет всем важным выявленным требованиям.
А я пошёл дальше. Мы ведь про MDD, нет?
AL
Да. Про MDD, но я ровно про ту часть, что позволяет начать кодировать код, планировать изготовление железок и т.п. Я про кусок CAM/CASE исключаю пока из рассмотрения.
AL
Да, это логичный следующий шаг. Но его сложность, на данный момент, мне кажется непреодолимой скорее по социальным причинам.
AL
Я кстати тут нашёл книжку, Model based system architecture. От всяких там идеологов моделеориентированного подхода. Покурю в ближайшее время, может даже что-то интересное найду.