Реинжиниринг торговой системы

← →
clippership (2013-05-31 11:01) [0]

Добрый день!
Надо немного пофлудить вот на тему реинжиниринга, которая касается меня лично и с которой в жизни мне сталкиваться не приходилось. Итак, есть огромная торговая система написанная на Delphi, БД - FireBird 2.5
Программа писалась в свое время какой-то конторой, развалившейся в 2000 году и не оставившей после себя никакой документации. Комментариев в коде программы практически нет. С тех пор множество программистов приложили свои руки в "усовершенствование" программы. Естественно, все делалось бессистемно, в виде заплаток. Что имеем. Проект с кучей библиотек и форм. Количество форм в общей сложности (вместе с теми, что находятся в dll-ках) - около 500. Примерно, такая же БД. Огромное количество таблиц, триггеров, хранимых процедур. Причем, название таблиц, типа "ААА", "ВВВ" - вполне нормальное явление, и самое печальное, в подобных таблицах могут быть данные.
И вот, захотелось мне получить ясную картину того, что сейчас имеется в этой системе, чтобы, проанализировав, можно было понять - что здесь лишнее или где бизнес-процессы построены из рук вон плохо и их необходимо менять. Ибо глючит программа часто и "не по децки". Задача нетривиальная, здесь скорее нужен специалист, который имеет опыт по реинженирингу. Сразу скажу - переписать систему с нуля нельзя. Но, вот, начальство может не пойти на то, чтобы нанять специалиста, поэтому надо попробовать для начала самому.
Первая задача - получить картинку имеющегося бизнес - процесса торговой системы, а точнее - построить схему взаимодействия программы и БД такой, какая она есть сейчас. Но, если кто имеет представление, с чего начать, какие case-системы применить, в какой конфигурации (редакции) лучше всего их использовать для решения данной задачи - был бы благодарен.
В теме не возбраняется спорить, указывать в чем я не прав или в чем не понимаю совсем, ибо в споре рождается истина... :)
Заранее всем спасибо.

← →
turbouser © (2013-05-31 11:21) [1]

для начала - в ibexpert-е можно построить диаграмму (там есть реверсинжиниринг) и посмотреть все связи визуально
ну и помониторить SQL запросы к серверу (FBScanner например http://www.ibaseforum.ru/viewtopic.php?f=32&t=4938)

← →
знайка (2013-05-31 11:42) [2]

А зачем это всё делать?

← →
Jeer © (2013-05-31 11:56) [3]

Делал я реверсинжиниринг одной система ( только БД ) и только для того, чтобы переписать всю систему.
Какое-то время совместно работали две системы, потом исходная была послана, а новая слегка подкорректирована для оптимальности.

Разбираться в исходниках и БД большой системы, да еще недокументированной, с целью понять бизнес-процессы - неверно.

← →
"Добрый Сок" (2013-05-31 12:15) [4]

> Разбираться в исходниках и БД большой системы, да еще недокументированной,
> с целью понять бизнес-процессы - неверно.

+999999999999999999
и с вероятностью 0.99999999999999999999 - бесполезно

← →
clippership (2013-05-31 12:45) [5]

Jeer, ну а как же поступить? Выхода у меня нет, я описал задачу, которая передо мной стоит, имею то, что имею.
Система рабочая, писалась 20 лет, ни о каких новых решениях - речи нет. Начальство привыкло к ней и менять не собирается. Пока гром не ударит, мужик не перекрестится, как говорится. А гром ударит обязательно, через год или два, но это ж когда будет!!! :)
Но я свежим взглядом вижу, что система не просто в тупике - она сама себя "загоняет в угол". Все через одно место работает, глючит постоянно, причем глюки, как в каждой огромной и запутанной системе - загадочные и волшебные. В любом случае - мне бы увидеть - как всё взаимосвязано в программе сейчас. Изучать код, чтобы вывести эти зависимости - нереально.
Для начала я бы просто хотел увидеть картинку. Неужели нет какого-нибудь средства, которое облегчило бы эту задачу?

turbouser, спасибо за конкретное предложение по FB. Буду его изучать обязательно.

← →
Jeer © (2013-05-31 12:56) [6]

Анриал.

Ну разве, что для практики в садомазохизме.

P.S.
Если система писалась 20 лет конторой, потом дописывалась отдельными умельцами, то с какого перепугу Вы решили, что можете один заменить их всех?

С таким же успехом Вы можете надеятся в одиночку написать подобную систему, что, кстати, и проще будет.

Или Вы считаете, что найдете два-три-*надцать узких мест и все волшебным образом рассосется?
Извините, я в чудеса не верю.

В общем, чудодейственного рецепта нет. Если так приспичило - сидеть и разбираться с БД, бизнес-процессы восстанавливать по методам работы персонала с этой системой.

Любой инструментарий - это не панацея и голову не заменит.

← →
clippership (2013-05-31 13:08) [7]

Jeer © , так, кто спорит.
Но я надеюсь общей картинкой хотя бы представить, что в системе лишнее и отделаться от балласта. Говорить о том, чтобы сделать идеальную систему - не приходится. Думаю, хотя бы упростить и кое-где оптимизировать.. Это все, что возможно сделать по максимуму.
Правда, есть еще один способ: продолжать накладывать заплатки и вносить свою лепту в существующий бардак, а затем во-время уволится - до того момента, когда все начнет рушиться. Но как-то не по мне последний вариант.
Есть, правда, еще и профессионалы, которые занимаются именно подобными задачами, но их вердикт предугадываю, он будет таким же, как и у Вас. Поэтому я и не ставлю задачей полностью провести грамотный реинжениринг, моя задача - выкинуть мусор, как из базы, так и из программы, а так же улучшить кое-что в особо-критичных направлениях бизнес-процесса. Это всё...
Теоретически, это возможно, я так думаю.

← →
clippership (2013-05-31 13:08) [8]

А как Rational Rose?

← →
"Добрый Сок" (2013-05-31 13:10) [9]

> как же поступить?

Вариантов 3.

1. Уйти оттуда.
2. Постоянно править, регулярно получая зп.
3. Уговорить перейти на готовое решение
4.
сесть с толковым конечным юзером, что бы он объяснил как работает система с его т.з., применимо к его направлению работы
Выяснить это у всех: Бухов, кладовщиков и т.п.

Купить обои и поклеить тыльной стороной наружу.
Перенести на них схему и наносить (параллельно, рядом) понятое от людей, пока не охватишь весь процесс.

Охватив процесс, начинать потихоньку править параллельную _свою, копию БД и программы, объединяя и разваливая процессы/структуры по мере надобности.

короче, на ближайшие год-два ничего существенно не планируй :)

← →
clippership (2013-05-31 13:21) [10]

"Добрый Сок" , понимаю.
То есть, все руками. Тоже выход, конечно. Собственно, так я уже и поступаю. Но в данном случае получается картина бизнес-процесса предприятия, который связан с программой, а программа - черный ящик.

По предложенным тобой вариантам :) , тогда лучше уж пункт 2, плавно переходящий в пункт 1.
Пункт 3 - нереален: уже уговаривал. Приводятся аргументы, которые приводить не буду, но суть которых одна :"Мы привыкли и нам ничего не надо"

← →
clippership (2013-05-31 13:25) [11]

Да здравствует садомазохизм, получается. То есть, дело дрянь.

← →
Компромисс1 © (2013-05-31 13:30) [12]

> моя задача - выкинуть мусор, как из базы, так и из программы

Для этого придется досконально разобраться в каждой строчке программы. А главное - зачем? Надежности это не прибавит (если действительно мусор), а новых ошибок добавить может (если будет выкинут не мусор)

← →
TUser © (2013-05-31 14:20) [13]

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

Потому что когда что-то не просто заглючит, а полноценно упадет, - виноват будет, угадай кто.

← →
картман © (2013-05-31 14:21) [14]

> Все через одно место работает, глючит постоянно, причем
> глюки, как в каждой огромной и запутанной системе - загадочные
> и волшебные

нельзя ли глюки классифицировать и через них найти где и что править?

← →
"Добрый Сок" (2013-05-31 14:25) [15]

> нельзя ли глюки классифицировать и через них найти где и
> что править?

причем, методом :

:Start
Подойти к
> толковым конечным юзером, что бы он объяснил как работает
> система с его т.з., применимо к его направлению работы
> Выяснить это у всех: Бухов, кладовщиков и т.п.

И у каждого спросить "если бы я мог прямо сейчас исправить одну твою бизнес-операцию, что бы ты хотел исправить?"

Получив от всех их первоочередную проблему - устранить.

goto Start;

← →
брат Птибурдукова (2013-05-31 14:38) [16]

> "Добрый Сок" (31.05.13 14:25) [15]
goto operator considered harmful :-D

← →
Inovet © (2013-05-31 14:54) [17]

> [16] брат Птибурдукова (31.05.13 14:38)
> goto operator considered harmful :-D

Надо:
Пока платят зарплату или не упало

← →
картман © (2013-05-31 16:07) [18]

> Надо:
> Пока платят зарплату или не упало

собирать бумажные отмазки))

← →
sniknik © (2013-05-31 17:26) [19]

> что, кстати, и проще будет.
однозначно проще.

как то давали подобное "задание" для более менее мелкой программы правда... оценил и выдал начальству - сделаю новую за две недели... ответ, не не не, нам новую не нужно, нам эту поправить чтобы не глючило... ок, тогда срок от 2-ух месяцев до полгода, и без гарантии, что уберу "глючность" полностью. задумались, и пока думали, и т.к. задача действительно была мелкая, но нужная написал новую без ТЗ (с саппортом поговорил, для чего, и кому нужно). но блин, начальство после раздумий все таки "выдало" - не нужно новую. эту поправь... а новая к тому времени у клиентов уже три дня как работала...

← →
Anatoly Podgoretsky © (2013-05-31 17:35) [20]

clippership (31.05.13 11:01)
Начать с определения строков (не менее 2 лет) и стоимости - тоже много.

← →
Anatoly Podgoretsky © (2013-05-31 17:42) [21]

> "Добрый Сок" (31.05.13 14:25) [15]

Не смеши, в лучшем случае получишь - ты программист, делай все правильно, я в этом не разбираюсь. В худшем случае саботаж и подсиживание.

← →
Anatoly Podgoretsky © (2013-05-31 17:44) [22]

Да и насколько хорошо ты сам разбираешься в бизнес процессах?

← →
Dennis I. Komarov © (2013-06-01 13:09) [23]

Чет начальство с легкостью пересаживается с 20-летних ВАЗов с заплатками...

← →
Юрий Зотов © (2013-06-01 13:21) [24]

> И вот, захотелось мне получить ясную картину того, что сейчас имеется в
> этой системе, чтобы, проанализировав, можно было понять - что здесь
> лишнее или где бизнес-процессы построены из рук вон плохо и их
> необходимо менять.

ИМХО, в данном случае это практически невозможно. По крайней мере, в разумные сроки - то есть, если каким-то чудом даже и удастся сделать, то затраты времени (и, соответственно, денег) будут несоразмерно огромными.

> Ибо глючит программа часто и "не по децки".

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

Время это, конечно, тоже будет не малым. Но оно при таком подходе оправдывается тем, что программа все время продолжает работать, раз уж к ней привыкли.

← →
RDen © (2013-06-01 13:39) [25]

Юрий Зотов © (01.06.13 13:21) [24]

Получаем от юзера конкретный глюк

получаем от юзера ответ: глюки возникают различные при различных обстоятельствах

← →
Юрий Зотов © (2013-06-01 13:41) [26]

> RDen © (01.06.13 13:39) [25]

Вы слово "конкретный" не прочитали, вероятно.

← →
Dennis I. Komarov © (2013-06-01 13:42) [27]

> В итоге имеем реверс-инжиниринг как бы "по кускам", а через
> какое-то время получаем приличную программу.

Ой, не факт... :)

← →
Юрий Зотов © (2013-06-01 13:47) [28]

> Dennis I. Komarov © (01.06.13 13:42) [27]

По крайней мере, получаем программу:
а). которая работает все более устойчиво, чем исходная;
б). в которой мы уже частично разобрались.

> Приводятся аргументы, которые приводить не буду, но суть
> которых одна :"Мы привыкли и нам ничего не надо"

Не на том языке разговариваете...

> По крайней мере, получаем программу:а). которая работает
> все более устойчиво, чем исходная;б). в которой мы уже частично
> разобрались.

Вы этим будите заниматься, Юрий Сергеевич? Если да, то у меня нет сомнений...

Юрий Зотов © (01.06.13 13:41) [26]

> RDen © (01.06.13 13:39) [25]

Вы слово "конкретный" не прочитали, вероятно.

тогда это уже не юзер, а вeтатестер с опытом, ибо

>clippership (31.05.13 11:01)

>Ибо глючит программа часто и "не по децки"

пардон, бета тестер

> Dennis I. Komarov © (01.06.13 13:52) [30]
> Вы этим будите заниматься

Если ничего другого не остается, то придется, деваться некуда. Но, конечно, разбираться в чужом глючном коде огромного размера - задача из серии "Боже упаси".

> RDen © (01.06.13 14:07) [31]
> тогда это уже не юзер, а вeтатестер с опытом

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

>Юрий Зотов © (01.06.13 14:27) [33]

ну >clippership (31.05.13 11:01) ничего не сообщает о контингенте юзеров, может там кучка бабушек-одуванчиков, и тогда ваще не получишь ничего внятного.

Попадал в подобную ситуацию- лет 10 без должного бюджета и постоянной сменой коллектива, сторонняя фирма-разработчик, занималась ....хм...

разработкой чего-то (ни мне, не для конторы - не нужным, что я и пытался объяснить руководству), в итоге контора разработчиков накрылась -

предложили продолжать проект мне - еле открестился. Сейчас с улыбкой соболезнования наблюдаю над нанятыми за копейки продолжателями разработки...))

зы. и Вы говорили в [24] - конкретный, а в [33] хоть какие-то сведения

> RDen © (01.06.13 14:58) [34]

> может там кучка бабушек-одуванчиков,

Видел я одну такую бабушку... дай бог каждому. В программу была встроена "маленькая Delphi" - так эта бабушка свои формы лепила. Разные они, бабушки-то.

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

> [24] - конкретный, а в [33] хоть какие-то сведения

Так это же и есть конкретика - "что делал, что получилось и что должно было получиться".

Юрий Зотов © (01.06.13 15:20) [35]

Так это же и есть конкретика - "что делал, что получилось и что должно было получиться".

ну мож быть, просто по описанию ситуации у автора, ошибки возникают не подлежащие однозначной локализации, а это плохо...

> RDen © (01.06.13 15:28) [36]
> ну мож быть

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

И не надо гадать на кофейной гуще - мож бабушки, мож дедушки, мож локализуется, мож нет... есть данность, вот и все.

А мож там сплошь одни гениальные девушки?

Юрий Зотов © (01.06.13 15:40) [37]

да, наверное ТС принял решение)

> "Добрый Сок" (31.05.13 13:10) [9]

> как же поступить?

>Вариантов 3.

>1. Уйти оттуда.

> 1. Уйти оттуда.

Зачем? Лучшего шанса стать незаменимым просто не бывает. А это вкусно.

нет незаменимых, к сожалению

Реинжиниринг торговой системы Найти похожие ветки