всем доброго дня.

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

в данной теме хочу вывести:
1. критерии становления требований к проектированию в целом.
2. обеспечение/доказательство требований.
3. разбиение требований и объединение в категории и вывод общих требований для формирования теоретической основы.
4. принципы и аргументацию разбиения требований/условий на отдельные задачи для реализации(на С++).
5. тестирование каждой задачи и обеспечение повторяемости кода.

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

зы
огромная просьба к тем, кто не уверен в надобности запостить в эту тему - не постьте. сильно благодарен.

всем огромное спасибо за понимание и желание помочь в этом сложном вопросе.

Up.
конечная реализация любой идеи - не цель. можно вообще ничего не реализовывать. смысл-то в другом.

Это сообщение отредактировал(а) boostcoder - 11.7.2011, 22:52

.....

Это сообщение отредактировал(а) boostcoder - 11.7.2011, 22:51

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

Короче изначально надо объяснять заказчику, что проект завтра не стартует. И пока не выяснятся все такие случаи (которые 1 на 10000) даже не стоит начинать.

Далее. Нужно добиваться объяснения зачем нужна каждая цифра. Тоже ситуация распространеная:
З: Здесь мне нужно получить значение C, а здесь значение B. (это могут быть достаточно ресурсоемкие алгоритмы)

Потом выясняется, что эти два значения в общем то нужны лишь для получения значения R.....    И, в общемто, если сразу искать значение R в итоге требуется меньше ресурсов.

Бывало и такое: есть некий протокол для клиент серверной технологии. Задача написать клиента. (Сама цель: связь по этому протоколу). Есть эмулятор и все дела.... Вроде сдавать. Полевые испытания..... Оппааа.... А на том конце тоже клиент......

Короче, прежде чем начинать, что то писать, нужно выесть весь мозг и себе и заказчику.... 

Надеюсь я правильно понял вопрос.

deleted by TS's request 

Это сообщение отредактировал(а) borisbn - 12.7.2011, 06:20

Есть две школы. Под старой школой я подразумиваю каскадную модель разработки, когда заказачик приходит с задачей, формулируются требования, проектируется система, пишется, тестируется, сдается. Так, вот - каскадная модель не работает. Причина элементарная - любой заказчик меняет требования в ходе проекта. Если только это не сферический заказчик в вакууме. Забудьте про каскадную модель. Навсегда.

Новая школа - это итерационная модель и всевозможные гибкие разработки, Scrum и экстремальное программирование. Смысл в том, что мы должны смириться с постоянной переменой требований, если хотим довести проект до конца. Некоторые методики (кажется, XP) предлагает чуть ли не отказаться от всякой документации, а сразу приступать к кодированию. То есть в понедельник показываем заказчику прототип - только формочки с кнопочками, которые ничего не делаем. Совещаемся, что будем делать на этой неделе. Со вторника по четверг кодим и отлаживаем. Нужно получить грязный код, главное в котором - чтобы он работал. В пятницу производим рефакторинг. Вся документация - в JUnit или Doxygen, тесты пишем параллельно с кодированием, а иногда - до кодирования (TDD).

Что интересно, не обязательно, чтобы начальство знало об используемой вами методологии. Главное, чтобы был сервер с багтрекером и системой контроля версий.

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

Сразу скажу тут вопрос не только в проектировании, а ещё и в аналитике. То есть по-хорошему, решаются две задачи:
1) аналитическая - анализ предметной области, выяснение требований, их систематизация, проверка на адекватность решаемой задаче и непротиворечивость здравому смыслу и техническим возможностям.
2) архитектурная - выделение слабосвязных компонентов системы, разделение и балансировка функциональной и информационной нагрузки между ними, определение интерфейсов этих компонентов и разработка протоколов взаимодействия между ними.

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

Так как приходится делать работу и аналитика и проектировщика - придётся разобраться в предметной области. После того как начали понимать чем заказчик занимается мы можем получить только словесное описание необходимой системы, которое нужно воплотить в код. Сам переход осуществляется одновременно с проверкой требований примерно так:
существительные - это объекты системы
прилагательные - это свойства объектов
глаголы - это методы объектов

Следовательно заказчику (а по-хорошему, аналитику) надо задавать вопросы "Что это?" "Какое оно?" и "Что оно делает?".

PS:
На работе сейчас та же фигня. Основная причина - информационный голод в котором меня держат. Поэтому за последний месяц архитектуру проекта менял трижды. По мере возникновения дополнительных требований. В такой ситуации я просто предупредил, что если информационный голод продолжится - работа будет выполняться долго и плохо. Заказчика такой расклад устроил...

.............

Это сообщение отредактировал(а) boostcoder - 14.7.2011, 18:31

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


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

Добавлено @ 23:14

ваше мнение не бесполезно. я благодарен за то, что вы обратили внимание на топик. и хотелось бы видеть вас в этом топике и дальше ;)

Это сообщение отредактировал(а) boostcoder - 14.7.2011, 18:31

boostcoder, яма та самая, о которой вы спрашиваете. Я тоже работаю над внутренними проектами. Просто под "заказчиком" нужно понимать человека, выполняющего его роль. Это не обязательно должен быть дядька со стороны, в нашем с тобой случае это начальник отдела, к примеру. 

borisbn, да это описание одной из наиболее радикальных методологий. Вообще-то не стоит слепо следовать одной из них. Например, я пишу тесты после написания кода, таким образом я не следую TDD (хотя, не повредило бы). Также иногда полезно задокументировать требования заказчика на ранних этапах. Но обычно эту документацию бесполезно пытаться поддерживать в актуальном состоянии. Пока скорректируешь, требования уже могут поменяться. С другой стороны, схему БД, автоматически генерируемые из кода диаграммы классов, описание каких-нибудь API документировать совсем не повредит.