Согласен с kolobok0
Но все таки решил написать такой КРЕАТИФ.
1) Определиться с командой. Определить кто занимается менеджментом проекта, т.е. парит заказчика, управляет изменениями в проекте. Определить кто архитектор системы. Остальная команда естественно учатвует в обсуждении, но решение принимать им.
2) Сбор информации. Определиться у заказчика - кто технолог процесса, таких может быть 1 или 2, но не весь персонал - это ахтунг. Работать с технологами, остальных учить.
3) Проектировка системы. Система проектируется с 2-х сторон, как со стороны клиента, так и со стороны БД. Выбрать сервер БД, который подойдет в проекте, он должен содержать как минимум хранимые процедуры, иначе бизнес логику на сторону сервера не положить. Разделить полномочия клиента и сервера в системе. Клиент отвечает за визуализацию данных журналов, справочников и пр. Предоставляет интерфейс для изменения данных, но не владеет бизнес логикой поведения системы. Бизнес логика ложится в многослойную концепцию на стороне БД. т.е. внешний уровень работает с клиентом, далее уровень логики и уровень элементарных действий. Это случай, когда логика делается на ХП. Если на триггерах, то похоже, но клиент при изменении делет прямо к таблицам, а весь разворот проектируется в несколько слоев процедур на триггерах.
4) Разработка начала. Команда делится на 2 части - кто пишут клиента и кто проектирует структуру и логику на сервере. Деление примерно общее. Если в команде более 2-х человек - нужно поставить какой-нибудь проджект менеджер, иначе может получится бардак. 1 эталонный репозиторий клиента, остальное стандартно - взял - положил. Клиента нужно начинать с базовых объектов (форм), базу со структуры ядра предметной области. Все остальное достраивается по ходу. Начинают обычно сразу с 2-х сторон. Для склада например - главное товарное движение, базовые справочники и документы.
5) Разработка, разгар. Сращивание проекта в единую систему и постоянное тестирование базового поведения системы. Базовая часть бизнес логики в базе. Демонстрация технологам от заказчика. Даже если им не нравится - они не знают что им нравится - нужно приучать к прекрасному :)
6) Разработка настройка предметной области под заказчика. Вот тут понадобятся все записи, первичные документы, диалоги и пр. Постоянное запаривание технологов заказчика. Начало обучения сотрудников заказчика. Коррекции "на лету" и пр., т.к. на практике заказчик сразу не знает, что хочет. Постоянное приучение к прекрасному...

Дальше не попускатся и будет щастя и хеппи энд :)

Old NickПрочитайте это про ОО проектирование баз данных

http://www.ibase.ru/devinfo/oop_rdbms.htm

Это полезнее
http://www.ibase.ru/devinfo/NaturalKeysVersusAtrificialKeysByTentser.html
взял в литературе статьи. Статья слабенькая, но для накопления информации пойдет.
Не люблю интербейс, но стаью ни ibase.ru бывают очень даже интересные.
Для афтара вопроса - читать обязательно.

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