BagaBagaХм, как-то неправильно заквотилось.
Я извиняюсь, вы мне говорили про waterfall подход или тем, кто не понимает почему аналитики вносят изменения?

BagaBagapomoev.uАналитик - это человек наиболее близкий к бизнесу. В процессе разработки требования бизнеса могут изменяться, уточняться и т.д. Поэтому именно аналитик вносит изменения в логическую модель, никого не спрашивая, т.к. его требования первичны. А все остальные должны быстро привести свои данные в соответствие.


Ваше описание - водопад. Ещё хуже - серия водопадов, каждый из которых начинается (наплевав на все предыдущие) тогда, когда "аналитик вносит изменения ... никого не спрашивая". При этом все остальные поставлены в позу дурачка, который возьмёт под козырёк на любую прихоть и выбросит предыдущие наработки... или является штатным ясновидящим, который сделает "как надо" ещё до полученной модели и заранее "предусмотрит невероятное".

Обратной связи, чтобы дать вовремя по рукам аналитеГу, в вашем описании не предусмотрено. В результате его модель может "не уложиться" в используемый стек технологий. Желающих переписывать всё на каждый чих нет, поэтому на практике имеющийся код будет обрастать костылями, а при добавлении нового разработчики будут просто применять избыточно "гибкие" схемы, не налагающие практически никаких ограничений (а следовательно создающие проблему обеспечения согласованности данных и выполнения бизнес-регламентов) и далеко не идеальные по производительности (за "гибкость" надо платить). Вас же не удивляет, что внедрение покупных продуктов сопровождается не только "допилом под себя коробки", ни и перестройкой части бизнес-процессов под требования системы?
Аналитики в достаточно мере представляют себе используемые технологии, чтобы вносить изменения более менее осмысленно. Изменения это например добавление атрибута к сущности или уточнение допустимого диапазона значений, переименование и т.д.
Откуда вы придумываете эти сценарии про "наплевать на все предыдущие" и "переписывать всё на каждый чих" и прочее?
По теме есть что добавить, или тут одни Капитаны собрались?

Если быть честным, то тема создавалась, чтобы послушать людей, имеющих опыт автоматизации указанных процессов с помощью соответствующих инструментов, а большинство присутствующих почему-то пытаются перевести тему в разряд флуда о том, что такого не бывает и рассказать, как важно делить систему на подсистемы и как организовать общение между архитекторами и аналитиками. Все эти проблемы уже решены: всё поделено, аналитики даже с тимлидами разработки общаются постоянно, а с архитекторами они вообще не разлей вода. Но это всё не о том.
Вопрос: кто на практике выполнял все изложенные в первом сообщении задачи с помощью PowerDesigner? Или может быть с помощью IBM Data Architect? Какие впечатления? Удалось ли всё выполнить в автоматическом режиме или всё равно в конце всё пришлось переделывать руками?

BagaBagapomoev.u,
ARIS вас устроит?

Если у вас есть опыт решения задач, описанных в топике, с помощью ARIS - расскажите, пожалуйста, очень интересно.
BagaBagaНа самом деле, лучший инструментарий - тот, которым владеет ваша команда. Иначе вы будете не проект делать, а обучаться использованию конкретного CASE-средства за счёт заказчика.
Я вас прошу, давайте без банальностей, я уже не знаю как еще намекнуть.

prog123BagaBagapomoev.u,
ARIS вас устроит?

На самом деле, лучший инструментарий - тот, которым владеет ваша команда. Иначе вы будете не проект делать, а обучаться использованию конкретного CASE-средства за счёт заказчика.

Эти программы предназначены для выкачки бабла из ламерских структур которые при деньгахZ:)
Для настоящего решения настоящих проблем, весь этот шлак абсолютно не нужен.
Вы абсолютно правы, я даже больше скажу: вообще все коробочные продукты предназначены для выкачки бабла из ламерских структур, которые при бабле.

prog123Пора по так называемым IT-конторам и IT-проектам пройтись железной метлой и сократить их всех десятами тысячь, а на полпроцента сэкономленных денег нанять нужное количество учётчиков, которые с Экселем и планшетами, а еще лучше - с обычными бумажными журналами будут спокойно фиксировать ход происходящего, например, - производство, а по их скрупулезным записям можно будет сосчитать НАСТОЯЩУЮ себестоимость изделий, и настоящую структуру этой самой себестоимости. На сегодняшний момент, ни 1С, Ни SAP/3(это даже не программа в обычном смысле, а это троянское коррупционное оружие), ни прочие поделки, - ничего не решают, кроме поглощения денег.

Нужен простой крестьянский здравый смысл. Законодательно должны признаваться любые неокупившиеся договора автоматитизации, - недействительними и не подлежащими страхованию!

Меры возможны и другие, но смысл тот же, - против жульничества на ниве "автоматизации".

Прочитал вашу речь и прям представил себя на сисопке. Обязательно вечером накачу 50 грамм за крестьянский здравый смысл и занюхаю пыльной книжкой Питера Абеля.

Judopomoev.u....
1. Аналитики изучают предметную область, рисуют логическую модель: сущности, их атрибуты и связи.
2. Проектировщики БД добавляют сущностям дополнительные свойства и, используя логическую модель, в автоматическом режиме формируют физическую модель (структуру БД с учетом выбранной СУБД).
3. Разработчики, используя логическую модель, формируют интерфейсы сущностей на языке программирования (например, java).
.....


Из опыта. То что выбором инструмента задались это правильно. Без него будет большая свалка документов и схем. Важно чтобы грань между Аналитики и Проектировщики была как можно тоньше, т.к.
первые - рисуют логическую модель: сущности, их атрибуты и связи.
вторые - добавляют сущностям дополнительные свойства и, используя логическую модель
Т.е. лучший вариант когда они используют один инструмент. Иначе схем будет в двойном количестве.
Важно чтобы инструмент какой бы Вы не выбрали умел рисовать Диаграммы связей таблиц - например - master-detail - они все равно будут даже если Foreign Keys в базе нет (к примеру у меня такое встречалось в DWH на Exadata), но если рассматривать OLTP и к примеру банковское ПО или процессинг, или SaaS Cloud то скорее всего FK будут.
Важно чтобы ИНструмент мог рисовать стрелки между таблицами - сущностями. Еще круче если инструмент может привязывать к сущностям операции над ними - тоже графически.
И потом все выгружать это все в XML, JSON, CSV и т.п.
Еще лучше если инструмент может создавать сам таблицы в базе.
У нас был именно последний вариант. Т.е. полноценный - еще и многопользовательский, со своей БД о мета-инфо.
Повторюсь что он был самописный - поэтому вам рекламироваать не могу.
Но чем меньше прослоек между разными типами людей тем лучше.
И лучше забыть про проектирование и аналитику в Ворде и Эксель - этот уже прошлый век.
Так что либо создавайте инструмент под себя или выберите платный или бесплатный - а таких превеликое множество

Спасибо за то, что вникли в проблему. Насчет разработки под себя - как всегда нет ресурсов, чтобы сделать что-то полноценное. Опять же сопровождение. Среди великого множества пока что нашел только PowerDesigner, но с ним были какие-то трудности на каждом преобразовании, поэтому коллеги не смогли мне его порекомендовать как решение всех проблем.

Кот Матроскинguest_20040621 ТС говорит о ста таблицах, - совершенно искренне не понимаю, какие задачи он решает.

Да, 10 аналитиков на 100 таблиц - это что-то крутое, не иначе :)
У нас в проекте есть, например, агрегирующая бизнес-сущность, содержащая около 700 реквизитов, поставляемых от разных источников, и над ней работают несколько аналитиков.

Если вы не понимаете чего-то - это означает только то, что вы этого не понимаете. И вы раз за разом возвращаетесь, чтобы продемонстрировать непонимание. Зачем это?