Ну в общем, есть такое. ))

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

И даже для небольших проектов я часто просто не могу себя заставить писать код, пока хотя бы на листочке не набросаю несколько диаграмм. Я начал мыслить UML`ом, понимать задачу в терминах UML`а. Даже в качестве документации предпочитаю UML-диаграммы разным средствам типа javadoc (если, конечно, они есть).

Однако проблемы с актуализацией (т.е. изменением диаграмм в соответствии с изменениями проекта в процессе разработки) всё-таки остались...

Большая часть «геморроя» и как правило провалов, связана с плохой или отсутствующей модели.. Ну не сделали как надо анализ, не поняли что надо, как это работает и как должно работать.. Потом, реализация писалась на коленках.. Потому что, «самый главный» («постановщик») задумчиво глядя в даль, принимал решения одному ему известным принципом.. Программист, разработчик БД и т.д. просто не знают о чем речь.. каждый реализует «главное, что бы работало»..
В общем, конечно мало где используются реальное построение моделей.. А жаль :( 
Но это не есть хорошо… 

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

Необходимости коммуникации внутри группы это не отменяет.

Все это конечно здоровски хорошо, но реалии таковы что на UML и другие важные задачи заказчик не дает времени - а деньги нужны.
Вообщем последний пункт - и без него пока нормально справляемся и поддерживаем код в актуальном состоянии. А я кроме того вообще графическую информацию не воспринимаю и вообще не люблю работать со всем, что связано с графикой, даже если нарисованы 2 прямоугольника мне нужно обьяснить словами все, чтобы я понял. Да и вообще, если обьяснять все словами - то все гораздо легче понять. Меня все еще эти алгоритмы умиляют, их наверное в ВУЗАХ до сих пор рисуют - я когда учился никогда их не понимал, стоило обьяснить все словами, я запросто мог написать реализацию.
ЗЫ . Фаулера тоже читал.

Се ля ви, 

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

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


Это сообщение отредактировал(а) Torsten - 10.6.2008, 22:33

Такие решения не в компетенции заказчика.
Их принимает компания-разработчик (руководитель проекта, например).


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


Это не имеет отношения к UML 
Только к тому, кто разрабатывает модели.

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

Это сообщение отредактировал(а) ida - 10.6.2008, 22:25

ida, 

Кто тебе это сказал ? Ты работаешь ? Сколько ты видила и сопровждала проекты ?

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


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


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


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

VictorP, 

А ты не думал, что есть другие способы обмена информацией ? Почему-то у всех сразу только uml в голове. Я лично на 100% текстовое и табличное представление информации намного удобнее графического + реальное общение разработчиков во время разработки. В качестве обмена информации идеально подходит вики. Там можно описать и все возможные операции БД, интерфейсы, коды возратов, системы тестов, документацию для разработчика (архитектура) - все что угодно.

Это сообщение отредактировал(а) Torsten - 10.6.2008, 22:54

Думаю, немало   


Не знаю, как это в небольших поектах, но в больших - это совсем не так. У нас подобными задачами занимается десяток людей, которые к программированию отошения не имеют - бизнес-аналитики, solution architect (3 штуки в текущем проекте), отчасти product manager... Если наши тимлиды будут ещё и с заказчиком постоянно контактировать - лучше сразу повеситься. Конечно, контакт есть, и тимлиды принимают участие в этом котле - но это не их прямые обязанности.

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


Для этого программист должен быть ещё и экспертом в предметной области, т.е. проработать в ней (причем в бизнес-части!) не менее пяти лет. Нереально.


Тут ты прав. UML, конечно, универсален, но отнюдь не всегда оптимален.

Для справки: ida - девушка   

Дискусия несколько отклонилась от темы необходимости UML'я или его ненужности, но всеравно интересно 

Полностью согласен, с собеседником ida, а допустим проект, где Заказчик вместе с постановщиком(подрядчиком) составляют ТОЛЬКО требования к ПО, подрядчик пишет ТЗ, а реализацию пишет третья контора на условиях конкурса - вам не знакомы? Скока не работал с заказчиками, ему глубоко филолетово будешь пользоваться ты UML' или опишешь все в виде "сочинения" на вольную тему, лишь бы он тебя понял.
UML выходит на первое место в тех проектах, где с заказчиком общается аналитик, потому что есть не мной сформулированное правило - реализатор не может поставить себе качественное ТЗ, т.к. мыслит низкоуровневыми категориями, что не позволяет ему взглянуть на проект "сверху".

Позвольте не согласиться и с этим. Время выполнения задачи должно соответствовать качеству исполнения продукта, если проанализировав предметную область, союз трех - аналитик, архитектор и РП(руководитель проекта) приходят к мнению, что реализовать такой проект КАЧЕСТВЕННО, в заданный срок НЕВОЗМОЖНО, то и заказчик об этом должен занать. И дальше сам принимать решение, иначе - ПРОВАЛ НЕМИНУЕМ, что подорвет вашу репутацию и уменьшит кол-во ваших постоянных клиентнов("Сарафанное радио" - сам понимаешь). А уж убедить заказчика, что лучше вас это никто не сделает - это прямая задача сотрудников, которые за это отвечают .

Мы здесь, шо, априори, решили, шо аналитик у нас, так "вышел погулять", а вот программисты, все сплошь как один корифеи? Я шо то такой точки зрения здесь не слышал. Каждый должен заниматься своим делом, для небольшого проекта можно все вообще объединить в одном лице, а вот при серьезном проекте, да еще и команде разработчиков с 10 работающих над проектом, без нормального распределения обязанностей вопрос не решается в нормальные сроки и с приемлимым качеством. Поэтому и ответственность на аналитике немалая и требования к нему "не детские" в серьезных проектах.

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

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

Можно и на глиняных табличках, клинописью , кому как удобно. Однако, я до сих пор тоже придерживался текстового и табличного предствлени, но остро чувствую их не достаток, особенно при описании многократных ссылок, а графически это показывается элементарно, и даже на чисто графической Диаграмме Классов уже видны и связи и их кратность и направление и много еще чего, что в текстовом варианте просто заморачивает реально, это первый момент. Второй момент, ведь даже читая свой текст ты его не чувствуешь, т.е. дописываешь в уме недостающие детали и расставляешь акценты, а посторонний человек читая это должен восстановить эту картинку без этих акцентов и деталей. Сам грешен не раз получал от РП взыскания за такие вещи. А чем хорош UML - однозначностью восприятия нотаций.
И еще общее впечатление от этой дискуссии, что пока еще никто на эти грабли не наступил серьезно, по большей части все люди пишущие здесь пока не уделяют должного внимания моделированию предметной области.

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

А спорить можно хоть до укакашивания - пускай спорят те, у кого *** короткая.

batigoal, 

Я по возрусту вижу, что мало.


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


Для этого надо с ней познакомится, и определится с закачкиком чего он хочет. Эта занимает обычно не меньше месяца.


Цитата(Torsten @  10.6.2008,  23:40 )

Я знаю, это вообще я отвечал VictorP, а не ей.

boloeng, 
Не убедил, сказанный слова не заменяет реальных условий и проектов. Но спорить я с тобой не буду, ты лучше в теории плаваешь. Я бы с тобой поспорил год назад, когда Фаулера почитал, однако после того как прочитал - я все из своей головы выкинул за ненадобностью.
Единственное, что :

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


ida, 

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


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

Это сообщение отредактировал(а) Torsten - 11.6.2008, 17:31

Вот с этого и надо было начать 

Это сообщение отредактировал(а) ida - 15.3.2009, 19:45