Спасибо за хорошую статью. На предыдущем месте работы тоже воевал против "автоматизации". Хотя сам был в ДИТ.
На первом месте должны быть рентабельность, увеличение объема продаж, сокращение издержек. Так то по-хорошему, автоматизация часто это увеличение затрат (оборудование, программист на поддержку, сотрудник на первую линию и т.п.) без особого "выхлопа" для автоматизируемого процесса.
Отличная статья (точнее: так как придерживаюсь подобных взглядов, то считаю статью отличной).
Перестал пользоваться UML уже достаточно давно, хотя глубоко изучал все виды диаграмм на специализированных курсах и пытался использовать в практике. Перестал по причине того, что все варианты «не про то», бизнес-пользователям непонятно, разработчикам непонятно, да и самим аналитикам не всегда понятно. Плюс сильный редукционизм (упрощение) моделей UML не позволяет адекватно описывать поведение и реального мира и программной модели.
Мои бизнес пользователи (отдел стандартизации, отдел развития производственной системы) понимают EPC, прямо стандарты у нас пишутся в такой нотации. А обычное производство, снабжение, финансы (начальники цехов, отделов, мастера, начальники участков) понимают нормально прямоугольники и линии со стрелками. Самая популярная нотация на предприятии: вожу руками в воздухе рядом с доской, на которой нарисованы подписанные прямоугольники и стрелочки.
При этом реальный мир — мир взаимодействия, мир интерфейсов. Причем взаимодействие достаточно сложное, многоуровневое и с большим количеством ветвлений. Пока для этого лучше всего подходит простой текст с добавлением прямоугольников со стрелками. Мне представляется, что нотация будущего должна быть близка к семантическому графу, где ребро=взаимодействие, достаточно сложная сущность. ИМХО.
Спасибо за хорошую статью. На предыдущем месте работы тоже воевал против "автоматизации". Хотя сам был в ДИТ.
На первом месте должны быть рентабельность, увеличение объема продаж, сокращение издержек. Так то по-хорошему, автоматизация часто это увеличение затрат (оборудование, программист на поддержку, сотрудник на первую линию и т.п.) без особого "выхлопа" для автоматизируемого процесса.
Не хочу обидеть. Очень режет слух "Вопросы, которые меня спрашивали...". Наверное лучше использовать "Вопросы, которые мне задавали ..."
Перестал пользоваться UML уже достаточно давно, хотя глубоко изучал все виды диаграмм на специализированных курсах и пытался использовать в практике. Перестал по причине того, что все варианты «не про то», бизнес-пользователям непонятно, разработчикам непонятно, да и самим аналитикам не всегда понятно. Плюс сильный редукционизм (упрощение) моделей UML не позволяет адекватно описывать поведение и реального мира и программной модели.
Мои бизнес пользователи (отдел стандартизации, отдел развития производственной системы) понимают EPC, прямо стандарты у нас пишутся в такой нотации. А обычное производство, снабжение, финансы (начальники цехов, отделов, мастера, начальники участков) понимают нормально прямоугольники и линии со стрелками. Самая популярная нотация на предприятии: вожу руками в воздухе рядом с доской, на которой нарисованы подписанные прямоугольники и стрелочки.
При этом реальный мир — мир взаимодействия, мир интерфейсов. Причем взаимодействие достаточно сложное, многоуровневое и с большим количеством ветвлений. Пока для этого лучше всего подходит простой текст с добавлением прямоугольников со стрелками. Мне представляется, что нотация будущего должна быть близка к семантическому графу, где ребро=взаимодействие, достаточно сложная сущность. ИМХО.