Прошу совета.

В моей конторе появилось следующее предложение по организации процесса разработки БД:

1. Построение в Access модели БД для отработки интерфейса клиента, запросов и таблиц хранения данных.
2. Обкатка модели в сетевом варианте с чем-то вроде mySQL.
3. Построение полномасштабной БД на MS SQL Server или Oracle с использованием ранее сделанной наработки на Access в качестве клиента.

Идея обусловлена тем, что в конторе присутствует большое количество юзеров, которых приходиться сначала долго мучать на предмет составления толкового тех.задания под БД, а потом - хрен знает сколько переписывать БД, поскольку: "Ой, а мы эту формочку совсем не так себе представляли" и "А можно сюда прикрутить ещё 10, 20, 30 ... (возрастает в геометрической прогрессии) полей данных", ну и конечно "А как бы заставить БД на основании вот этого запроса нам нарисовать диаграмку?"      

В расширении идеи обсуждаеться перспектива массовой дрессировки юзеров для обучения основам Access 2007.  

Что скажете? Насколько это реально и перспективно?

Если не считать совершенно не вписывающегося в идею пункта номер 2 - все вроде бы ничего.

По п. 2 - MS Access поддерживает 2 разных формата организации базы. Это база данных - данные и средства их обработки и отображения в одном флаконе, и проект - база данных на сервере MS SQL, а средства обработки и отображения на рабочей станции.

Так что получается вполне нормальная схема - сначала построение основы в базе данных, затем перенос данных и средств T-SQL-обработки из БД на сервер MS SQL с соответствующей адаптацией, и наконец... а собственно всё. Осталась дрессировка - но это уже выходит за рамки форума.

Спасибо.

А насколько эффективно взаимодействие клиента на Access и базы на Oracle? Всё же не родные, в отличие от MS SQL?  

А ему, Аксессу то есть, какая разница? он драйверу запрос отдал, а что тот дальше с этим запросом делать будет - Аксессу фиолетово. Знай себе блюди синтаксис...

На мой взгляд в этих шагах нет никакой необходимости и смысла. Никто не мешает сразу же делать макет в MS SQL (в итоговой БД, как говорится). Тем более, что клиент для редактирования структуры очень функциональный. Не придется перебрасывать структуру бд из одной БД в другую. А клиента делать MS SQL очень просто.

И вообще по-мойму с проектированием у вас туго. Есть такие понятия, как листик, карандаш и стирка. Помойму единственный самый функциональный инструмент разработчика. Очень сильно помогает при сборе требований. Формочку можно нарисовать за 5 мин, а не тратить на это 1 час. А потом, учтите, макет обсуждать придется и пользователь обязательно передумает. 

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

То что пользователь сразу не все говорит, это стандартная ситуация. Все остальное частности. И то что через месяц он передумает, тоже стандарт (бизнес - ничего личного. И поэтому процесс разработки у вас не остановится никогда! (Я так понимаю компания держит свой отдел разработчиков.) Очень рекомендую ознакомится с методологией XP. В ней есть толковые идеи, которые позволят через годика два избежать хаоса в проекте.

P.S. И зарубите у себя на носу - пользователь всегда прав, если что-то не так - значит разработчик не с того бока зашел или не понятно рассказал. И так далее... Я могу долго на эту тему  .

Это сообщение отредактировал(а) bopoha - 10.9.2008, 00:21

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

Отдел разработчиков действительно есть свой. Так что ситуация с договором не очень актуальна.
А что касаеться варианта - "Сначала закончим - потом переделаем" - так сейчас и происходит. В результате от проекта до базы проходит время от полугода и до нескольких (!) лет. А уж когда в полный рост встаёт проблема подготовки автоматических отчётов - начинаеться тихая вешалка.
Кстати, разработчики у нас - ребя достаточно грамотные. Просто структуры данных, о которых идёт речь очень уж разноплановые. По-идее, именно заказчик должен чётко сформулировать, чего он в базе хочет видеть (какие данные и в каком объёме) - а с этим проблемы.

Гм.. как показывает опыт, заказчику надо (и это совсем несложно) объяснить именно озвученную выше мысль - за свои деньги ты получишь ровно то, что мы сейчас напишем в ТЗ, и ни граммом больше, если ты сейчас что-то прозяваешь или сформулишь не так - то это что-то отложится на срок до выполнения нынешнего задания, и обойдется тебе в дополнительные деньги. Как правило, усвоив эту истину, заказчик умнеет прямо на глазах. Особенно если сроки и суммы достаточно приличные.

100% согласен.
Тока ведь в данном случае нет такого рычага воздействия на заказчика, как договор. Заказчик - это подразделение той же конторы, что и разработчик. В итоге пробелы в ТЗ выливаються в бесконечное кивание друг на друга на совещаниях - а базы как не было, так и нет. А из-за этого стоят куда более серьёзные проекты, которые без нужной БД становяться просто неподъёмными.

Кстати, вчера мы уже опробовали первую часть:
Посадили рядом с собой заказчика и начали составлять модель. В итоге формы, которые не могли до того утрясти 3(!) месяца, согласовали за день. Когда заказчик своими глазами увидел чего где вводиться/нажимаеться и как это работает - процесс сразу пошёл легче. Дальше мы собираемся дать попробовать ему эту БД как настольную - всё равно заказчик работает только с клиентом, поэтому берёт база данные из файла или с сервера - ему фиолетово.

Аааааа!!! Это ужасно. В результате по ТЗ можно год делать проект. Придти, внедрить и понять. Что то, что написано не может быть использовано. Изменились условия, ошибки или не точности в ТЗ (писали со слов начальника, а работать пользователю). И что, заказчик будет платить за переделку? Хер!!! Он спросит что за ******** вы сделали. И посчитает реализацию ошибкой (т.е. нет денег!!!). У меня есть подобный опыт. 

Объясню почему так. При первичной автоматизации, когда еще ничего нет, технология работы после автоматизации меняется. Есть много нюансов, основанных на виденье пользователя и отношениях с ним. Например, я вижу как оно станет, пользователь не согласен. И тут хоть об стенку разбейся. Я не порчу с ним отношения, учитываю мое виденье и в дальнейшем упрощаю свою жизнь.

И еще пользователь не умеет абстрактно думать. Ему нужно показать примерный готовый результат (листик ;-)). И вы сразу же увидите у него блеск в глазах.


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




А я вам о чем говорил???   


Это сообщение отредактировал(а) bopoha - 10.9.2008, 11:25

Блин, какие таблицы, какие поля, какие соотношения? ты о чем? окстись!
Он заказывает себе РАБОЧИЙ ИНСТРУМЕНТ. Блин, автомеханик никогда не закажет себе ни бензопилу, ни асфальтоукладчик. Он закажет именно то, что ему надо - ключи, обжимки, зарядное устройство и прочую лабуду. А если надо, он придет к токарю и скажет - мне нужна вот такая опрессовка, тут диаметр такой, тут длина такая ... и получит в результате тот инструмент, который ему нужен.
А если заказчик [censored], и желает только ходить с поднятым носом и гордиться своим бизнес-процессом - пусть получит то дерьмо, которое заказал. И дальше платит за доведение этого инструмента до нужной кондиции. Или заказывает новый инструмент, но с учетом пройденных граблей и с поправкой на собственный кретинизм.

Что сказал - то и сделали. У программиста это постоянно - программа делает то что скажешь, а не то что хочешь. И пенять тут надо только на себя. 
А если заказчик неспособен, но у него есть проблески интеллекта в глазах - он заключит договор на СОСТАВЛЕНИЕ ТЗ на программирование. Совершенно нормальная практика - у умных заказчиков. И вот если по этому ТЗ будут те же грабли - вот тогда пусть орет. Но на того, кто сделал ТЗ, а не на того кто по нему программировал.
И вот именно на этом этапе строются макеты, рисуются формы и обсуждается всё остальное. А если заказчик решил сэкономить и сделать эту часть самостоятельно, не поручая ее профессионалу - пусть расплачивается своими временем, деньгами и всем остальным. Ибо дурак.

Ну да. Увольнять кого-то за свои просчёты - это самый наш метод. Только в русском языке слово "стрелочник" имеет два значения.

Я считаю это не правильной позицией. Мое мнение следующее. Заказчик знает, чтого хочет, но не может это сказать, потому что он не знает как это будет выглядеть. Ему известен только результат. Не стоит перекладывать всю ответственность за вид результата не пользователя. 

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

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


Увы реалии моей практики таковы, что ТЗ не содержало точных указаний к действию, да и тяжело их придумать пока проверить мысли не на чем. Вот у BearEvg и пришла мысль макетирования, которая облегчает этот труд. Я же в свое время упростил макет до листиков с рисунком и сценарием работы. В результате в подробном ТЗ необходимость отпала сама собой, его роль получилась описать в общем объем работ и текущее положение вещей. А дальше в народ за деталями.


Не за просчеты, а за отношение. Заказчик это тот же клиент для продажника, те же принципы.