да... жжоте товарисчи! 
ок, жду ))

Тем временем начитался других разных тем и пришел к заключению что все делают как хотят.
Вот например вопрос человека с линукс.орг:
Ответы:

Или вот (http://www.prog.org.ru/topic_14399_0.html), по соседству искали идеал архитектуру. Претендентами были:

• Классика: классы "Х", "Y", "Z". Их методы - логика приложения. Классы прикручиваем к БД, ну и потом UI
• Подход ORM (бизнес-логика в виде хранимых процедур)
• Промежуточной слое, сервер приложений

Так и не выяснили что и к чему...
Вот я сейчас и хочу простенькое приложение "под присмотром" спроектировать. Т.к. что-то сварганить можно всегда, а тут есть возможность чему-то хорошему научится... Хотя все предусмотреть/спроектировать невозможно (когда-то заморачивался как лучше переменную назвать car_count или count_car), поэтому я думаю можно что-то и упускать и пускать на самотек... Хотя тут, ИМХО, идет в ход характер человека, один импульсивный - пишет сходу, правит, меняет итд и потом называет это методом Agile, другой три дня думает и за 10 мин пишет идеальный продукт...
Но это все уже разработка, а пока еще только исследование и анализ (затянулся однако ).

Спасибо, скачал, буду изучать...
Я пока что обхожусь малой кровью: выбрал model-view подход. Для таблиц товаров, блюд итд использую модели, все их засунул в отдельный класс cofeeEngine, а в UI для таблиц представления подставляю эти модели, а на кнопочки удаления/создания/итд вешаю методы этого (cofeeEngine) класса... Разная хитрая кафешная логика тоже будет в том единственном классе. Как считаете такой подход очень плохой? или еще можно жить? )

Очень интересная тема. И много советов по части теории(в том числе чтение книжек по uml, где много воды и сложных запутанных фраз).  а вот как на практике реально спланировать диаграмму классов со всеми операциями и атребутами и взаимодействиями перед непосредственно кодированием, причем полностью во всех деталях. При этом учитывая весь инструментарий QT, наследуя от встроенных классов фреймворка, чтобы не изобретать велосипеды, а использовать все возможности по максимуму. Вот стала рыться в исходниках assistanta и designera, так как мой проект над которым работаю похож на эти, много нового узнала в том числе как они разделяют model-controller-view , почти разобралась с assistantoм,  построила UML диаграммы этого проекта, залезла в дизайнер, там жесть (мозг чуть не поломался). Короче, нужны какието знания как это проектировать все, может этому учат в вузах, просто я самоучка и получается всю практику получать только через чужой код. Хотя наверно это единственный способ

1 - никак. забудьте попытку (ла и саму идею) спроектировать программу "причем полностью во всех деталях" как бред сивой кобылы, как маразм ночного кошмара, как золотую мечту или "серебрянную пулю" ( Брукса же читали?)
Программа  - не здание. Она может и должна проектироваться по другому. Нет, вы конечно можете все сначала спроектировать, потом долго делать, а потом долго тестировать.... но и получите вы такую программу - лет через 5. В лучшем случае. Когда оно никому уже не нужно будет.
Это проходит только тогда, когда у вас достаточно времени и объемы программы не большие.

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

а потому-
2 - учите итерационные технологии. Имхо, учите 6-й RUP (тот который был до текущего) и его принципы - в частности - "компонентно-ориентированная аритектура" и "разработка отталкивающаяся от прецедентов" т.п.
Как вводная информация - приведенная выше моя методичка.

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

PS: И ещё - не ждите что у все получится))) у меня ушел год на то, что бы перестроить мышление с рамок "ТЗ, и только потом программа", на "итерационное развитие".
Не ждите что любое ваше руководство смоет вас понять. Часто это люди "старшего образа мышления" и с далеко не лучших шаблонами в голове. То что "спроектировать в деталях, а потом писать" критиковалось ещё с 60-х годов - в советских вузах не учили.
 Ну где-то так) удачи, обращайтесь))))

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

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

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

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

Но, имхо, вы забыли, наверное, упомянуть что :
 - или у вас проект был не большим (имею в виду объем разработки и её сложность, а не длительность проекта),
 - или область вам хорошо знакомая, для которой есть много наработок или фреймворков,
 - или вы не проводили совсем-детальное проектирование системы, сразу ринувшись в реализацию проекта (по причине что ест наработки, есть фреймворки или т.п.).
 - или вы говорите про неизменчивость высокоуровневых требований, забыв, что детали вы все равно меняли.... Мы можем наверное согласиться, что высокоуровневые требования останутся неизменными, но мелочи-то будут меняться. и мелочи могут поменять и извратить все .

 так? ну может ещё пара-тройка деталей и/или вариантов.

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

Т.е. ваш проект - исключение.

Есть ещё один вариант (увы так чаше всего бывает когда люди говорят про успешность применения ТЗ).
"проект построенный по ТЗ" - "фейк". (я вам верю, но привожу статистику о том, что часто кроектся за тем, что люди говорят про "успешные проекты построенные по водопаду").
За фразой "мы работали по тз" сегодня часто кроется откровенная ложь, лукавство...  часто - выгораживнаие себя, ради того что бы хорошо выглядеть в глазах клиента/заказчика. (да, иногда и в силу того, что заказчик "глух", но чаще - это "пылевглазапускание"). Иногда доходит до того, что "ТЗ" пишется постфактум или подгонятеся под реальную программу - после реализации проекта.
И не надо мне говорить что это не так. Это именно так, особенно в гос-конторо-подобных организациях (в том же РЖД) .
 (я тут работаю и вижу многие бумаги приходящие нам на рецензию и не только). или оно (ТЗ, ТП, "ПМ", "ПЗ") не соответствует действительности, или слишком абстрактно и витеевато написано, или пишется постфактум. Прочее представлено в исчезающе малом объеме.

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

- нам надо чтобы альфа-канал можно было загружать/контролировать из отдельного имеджа. 

Они не пытаются "проскочить на шару", т.е. понимают что такие изменения требуют времени и денег. Но технически не легче - имедж для альфы может иметь др. формат, размеры, разрешение чем для RGB, надо что-то решать с UI и.т.п. - от моей стройной архитектуры остаются "рожки да ножки" 

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

Наверное это про фреймворки... или какие-нибудь библиотеки реализующие тот или иной велосипед;)