Да, речь идёт в основном про различного рода бизнес-приложения - либо для внутренних пользователей организации, либо для иного ограниченного круга лица. Максимум речь шла о десятках тысяч конкурентных пользователей (на систему в целом) - и такой процесс моделирования данных был эффективен.
Есть речь идет о более высоких нагрузках - вероятно процесс должен как-то видоизмениться. Но как именно - из-за отсутствия собственного практического опыта предметно обсудить затрудняюсь.
Несколько раз подступался к использования онтологий в проектах, но ни разу полноценно не внедрил.
Либо онтология была космического размера и никем не использовалась — т.к. слишком сложно и непонятно зачем (а трудозатраты на её составление были существенными), либо она была примитивна и тоже не использовалась (т.к. всё это и так понятно).
То есть что-то рисовали на старте, а потом не актуализировали — так как никому не надо.
Крайне интересен опыт практического использования онтологий (например, на базе IDEF5) на проектах не связанных с темой ИИ.
Уважаемый автор, можете уточнить — был ли у вас опыт использования онтологий на реальных проектах? Какую пользу они там принесли?
Отношусь к UML как к «латыни программирования».
С одной стороны — это «мертвый язык», и успешного полноценного применения (когда UML — это основной инструмент проектирования, о чем мечтали авторы) ни разу не видел.
С другой стороны, изучение UML крайне полезно в плане переформатирования мозгов. Сама идея что приложение можно описать с разных точек зрения с помощью различных диаграмм UML (и то как эти диаграммы согласованы друг с другом) — для начинающих специалистов часто является революционной и двигает их вперед.
P.S. На практике применяю порядка 5 видов диаграмм UML — в основном в иллюстративных целях.
Неоднократно составлял такие таблицы — вот только цель была не «выбрать платформу», а «обосновать выбор платформы». Удачный подбор критериев и весов творит чудеса :)
Предложенная техника представляет интерес если веса определяют одни люди, а оценивают другие — причем независимо друг от друга. Тогда есть какая-то объективность в этом процессе и результат может быть неожиданным.
Я имел в виду именно опыт организации flow — когда задача последовательно проходит этапы «бизнес-анализа» и «системного анализа», которые выполняются разными людьми.
Спасибо за статью.
Интересует успешный опыт сосуществования на одном проекте бизнес-аналитиков и системных аналитиков — как была разграничена зона ответственности между ними, какие артефакты передавались, как разрешались конфликты и т.д.
Насколько, согласно опыту, существенна разница в ведении проекта с командой аналитиков и без?
Я бы немного перефразировал вопрос. Даже если в вашей команде нет человека с должностью «аналитик», то кто-то всё равно работает с требованиями. Может это руководитель проекта, может один или несколько разработчиков, может вся команда, а может вообще продвинутый заказчик. Отличие в том, что «аналитик» становится выделенной ролью.
Жить без выделенных аналитиков можно (одно время у нас так и было), основная проблема — это немасштабируемая схема. Если вам нужно расширяться, то найти человека, который пишет код и одновременно работает с требованиями (и делает это одинаково хорошо), крайне сложно. Найти отдельного разработчика и отдельного аналитика — проще.
Типичный вопрос специализации и разделения труда (как в 19 веке в промышленном секторе).
Скажите пожалуйста, какие инструменты/подходы/методологии наиболее активно сейчас применяются у вас в компании?
Вопрос очень общий. Отвечу тоже в общем, если что-то нужно раскрыть поглубже — просьба уточнить.
Подход к разработке в целом интеративный, как правило 2-3 недельные итерации.
Требования к ПО у нас представлены в виде текста, который проиллюстрирован картинками.
Текст мы пишем в вики-редакторе Confluence. Он обеспечивает версионность, ссылочную целостность и т.д.
Текст может сопровождаться схемами бизнес-процесса (BPMN, BizAgi Process Modeller), отдельными видами диаграмм UML (Sequence, State Machine, Class), макетами интерфейса (Axure), логическими моделями данных.
Если есть интеграция — либо WSDL/XSD, либо JSON/REST. В первом случае аналитики составляют схемы и WSDL (Altova XML Spy), во втором — описывают набор данных и методов.
Да, вы всё верно написали. Но у меня был вопрос не про приложения созданные на платформе 1С, а про саму платформу, которая поддерживает разные СУБД.
Приложения на платформе 1С понятно что используют абстракции предоставляемые платформой и далеки от конкретной СУБД.
Да, речь идёт в основном про различного рода бизнес-приложения - либо для внутренних пользователей организации, либо для иного ограниченного круга лица. Максимум речь шла о десятках тысяч конкурентных пользователей (на систему в целом) - и такой процесс моделирования данных был эффективен.
Есть речь идет о более высоких нагрузках - вероятно процесс должен как-то видоизмениться. Но как именно - из-за отсутствия собственного практического опыта предметно обсудить затрудняюсь.
Либо онтология была космического размера и никем не использовалась — т.к. слишком сложно и непонятно зачем (а трудозатраты на её составление были существенными), либо она была примитивна и тоже не использовалась (т.к. всё это и так понятно).
То есть что-то рисовали на старте, а потом не актуализировали — так как никому не надо.
Крайне интересен опыт практического использования онтологий (например, на базе IDEF5) на проектах не связанных с темой ИИ.
Уважаемый автор, можете уточнить — был ли у вас опыт использования онтологий на реальных проектах? Какую пользу они там принесли?
С одной стороны — это «мертвый язык», и успешного полноценного применения (когда UML — это основной инструмент проектирования, о чем мечтали авторы) ни разу не видел.
С другой стороны, изучение UML крайне полезно в плане переформатирования мозгов. Сама идея что приложение можно описать с разных точек зрения с помощью различных диаграмм UML (и то как эти диаграммы согласованы друг с другом) — для начинающих специалистов часто является революционной и двигает их вперед.
P.S. На практике применяю порядка 5 видов диаграмм UML — в основном в иллюстративных целях.
Предложенная техника представляет интерес если веса определяют одни люди, а оценивают другие — причем независимо друг от друга. Тогда есть какая-то объективность в этом процессе и результат может быть неожиданным.
Я имел в виду именно опыт организации flow — когда задача последовательно проходит этапы «бизнес-анализа» и «системного анализа», которые выполняются разными людьми.
Интересует успешный опыт сосуществования на одном проекте бизнес-аналитиков и системных аналитиков — как была разграничена зона ответственности между ними, какие артефакты передавались, как разрешались конфликты и т.д.
Был ли у вас такой опыт?
Я бы немного перефразировал вопрос. Даже если в вашей команде нет человека с должностью «аналитик», то кто-то всё равно работает с требованиями. Может это руководитель проекта, может один или несколько разработчиков, может вся команда, а может вообще продвинутый заказчик. Отличие в том, что «аналитик» становится выделенной ролью.
Жить без выделенных аналитиков можно (одно время у нас так и было), основная проблема — это немасштабируемая схема. Если вам нужно расширяться, то найти человека, который пишет код и одновременно работает с требованиями (и делает это одинаково хорошо), крайне сложно. Найти отдельного разработчика и отдельного аналитика — проще.
Типичный вопрос специализации и разделения труда (как в 19 веке в промышленном секторе).
Вопрос очень общий. Отвечу тоже в общем, если что-то нужно раскрыть поглубже — просьба уточнить.
Подход к разработке в целом интеративный, как правило 2-3 недельные итерации.
Требования к ПО у нас представлены в виде текста, который проиллюстрирован картинками.
Текст мы пишем в вики-редакторе Confluence. Он обеспечивает версионность, ссылочную целостность и т.д.
Текст может сопровождаться схемами бизнес-процесса (BPMN, BizAgi Process Modeller), отдельными видами диаграмм UML (Sequence, State Machine, Class), макетами интерфейса (Axure), логическими моделями данных.
Если есть интеграция — либо WSDL/XSD, либо JSON/REST. В первом случае аналитики составляют схемы и WSDL (Altova XML Spy), во втором — описывают набор данных и методов.