Модераторы: Се ля ви

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Проза жизни... Нужен ли UML? 
:(
    Опции темы
 
Используете ли вы в крупных проектах UML-диаграммы и методологию RUP?
да, у нас очень ответственный подход к проектированию. Только после того, как всё спроектировано и сгенерирован код, возможно качественно написать ПО! [ 9 ]  [13.64%]
Частично. Только Use Case и Class - диаграммы. Первая - для общения с заказчиком, вторая - иногда что бы разобраться со структурой классов (восстановление из кода). [ 17 ]  [25.76%]
Частично - только Class Diagram - больше и не надо [ 8 ]  [12.12%]
Частично - только Use Case Diagram - больше и не надо [ 3 ]  [4.55%]
Пробовали, разочаровались и отказались совсем [ 3 ]  [4.55%]
Даже и не пробовали - возможно, будем в будущем, но честно говоря, необходимости пока нет (или есть, но не острая - и средств жалко)... [ 26 ]  [39.39%]
Всего проголосовавших: 66
В этом опросе возможен один вариант ответа
Гости не могут голосовать 
Се ля ви
Дата 19.5.2008, 12:04 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Java/SOAрхитектор
****


Профиль
Группа: Модератор
Сообщений: 2016
Регистрация: 5.6.2004
Где: place without tim e and space

Репутация: 3
Всего: 127



Цитата(ida @  14.5.2008,  17:10 Найти цитируемый пост)
Как много изменилось за 3 года, да? ;)

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

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

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

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


--------------------
  )
 (
[_])
проф. блог

Кролики думали, что занимаются любовью, а на самом деле их просто разводили...
PM MAIL WWW Skype GTalk   Вверх
VictorP
Дата 9.6.2008, 09:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 2
Регистрация: 9.6.2008

Репутация: нет
Всего: нет



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

PM MAIL   Вверх
boloeng
Дата 9.6.2008, 18:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 7
Регистрация: 4.6.2008

Репутация: 1
Всего: 1



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


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



Цитата(boloeng @ 9.6.2008,  19:01)
А теперь подумайте, если бы проект был документирован в UML'е - у всех однозначное понимание нотаций, насколько проще было бы разобраться?

Необходимости коммуникации внутри группы это не отменяет.
PM WWW   Вверх
Torsten
Дата 10.6.2008, 21:28 (ссылка)    | (голосов:2) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 174
Регистрация: 10.6.2008
Где: Pskov

Репутация: нет
Всего: 7



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

Се ля ви
Цитата
Возможно, если бы все сели и стали проектировать перед программированием, то достаточно быстро возникла бы культура и написания программ по UML`у, которая увеличила бы темпы и качество написания кода

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

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


Это сообщение отредактировал(а) Torsten - 10.6.2008, 22:33
--------------------
We have no begining, we have no end. We are infinite.
PM MAIL   Вверх
ida
Дата 10.6.2008, 22:19 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



Цитата(Torsten @ 10.6.2008,  22:28)
Все это конечно здоровски хорошо, но реалии таковы что на UML и другие важные задачи заказчик не дает времени 

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

Цитата(Torsten @ 10.6.2008,  22:28)
качество кода зависит только от программиста.

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

Цитата(Torsten @ 10.6.2008,  22:28)
по опыту уже наелся другими средствами, которые код генерируют - если это возможно стараюсь от них отказатся совсем.

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

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

Это сообщение отредактировал(а) ida - 10.6.2008, 22:25
PM WWW   Вверх
Torsten
Дата 10.6.2008, 22:40 (ссылка)    | (голосов:4) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 174
Регистрация: 10.6.2008
Где: Pskov

Репутация: нет
Всего: 7



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

Кто тебе это сказал ? Ты работаешь ? Сколько ты видила и сопровждала проекты ?
Цитата
Все это конечно здоровски хорошо, но реалии таковы что на UML и другие важные задачи заказчик не дает времени - а деньги нужны.

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

Цитата
А от аналитика зависит качество постановки задачи.

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

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

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

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

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

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

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

Это сообщение отредактировал(а) Torsten - 10.6.2008, 22:54
--------------------
We have no begining, we have no end. We are infinite.
PM MAIL   Вверх
batigoal
Дата 11.6.2008, 11:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Нелетучий Мыш
****


Профиль
Группа: Участник Клуба
Сообщений: 6423
Регистрация: 28.12.2004
Где: Санктъ-Петербургъ

Репутация: 4
Всего: 151



Цитата(Torsten @  10.6.2008,  23:40 Найти цитируемый пост)
Кто тебе это сказал ? Ты работаешь ? Сколько ты видила и сопровждала проекты ?

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

Цитата(Torsten @  10.6.2008,  23:40 Найти цитируемый пост)
Программист и должен быть аналитиком, а точнее ведующий программист, который отвечает за проект. Он должен помнить и знать о всех мелких деталях, контактировать с закачиком,  и грамно информировать людей, которые вместе с ним пишут различные компоненты системы. 

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

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

Цитата(Torsten @  10.6.2008,  23:40 Найти цитируемый пост)
Профессионализм как раз в этом и заключается, чтобы не смотря на все выдумки заказчика, уметь все предугадать и сделать конечный продукт, несмотря на то что там этот заказчик придумает.

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

Цитата(Torsten @  10.6.2008,  23:40 Найти цитируемый пост)
А ты не думал, что есть другие способы обмена информацией ?

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

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


--------------------
"Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли)
ЖоржЖЖ
PM WWW   Вверх
boloeng
Дата 11.6.2008, 11:43 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 7
Регистрация: 4.6.2008

Репутация: 1
Всего: 1



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

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


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

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

Цитата
Все это конечно здоровски хорошо, но реалии таковы что на UML и другие важные задачи заказчик не дает времени - а деньги нужны.


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

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

А от аналитика зависит качество постановки задачи.


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

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

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

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

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


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

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

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

Можно и на глиняных табличках, клинописью smile, кому как удобно. Однако, я до сих пор тоже придерживался текстового и табличного предствлени, но остро чувствую их не достаток, особенно при описании многократных ссылок, а графически это показывается элементарно, и даже на чисто графической Диаграмме Классов уже видны и связи и их кратность и направление и много еще чего, что в текстовом варианте просто заморачивает реально, это первый момент. Второй момент, ведь даже читая свой текст ты его не чувствуешь, т.е. дописываешь в уме недостающие детали и расставляешь акценты, а посторонний человек читая это должен восстановить эту картинку без этих акцентов и деталей. Сам грешен не раз получал от РП взыскания за такие вещи. А чем хорош UML - однозначностью восприятия нотаций.
И еще общее впечатление от этой дискуссии, что пока еще никто на эти грабли не наступил серьезно, по большей части все люди пишущие здесь пока не уделяют должного внимания моделированию предметной области.
PM MAIL   Вверх
ida
Дата 11.6.2008, 12:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



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

А спорить можно хоть до укакашивания - пускай спорят те, у кого *** короткая.
PM WWW   Вверх
Torsten
Дата 11.6.2008, 17:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 174
Регистрация: 10.6.2008
Где: Pskov

Репутация: нет
Всего: 7



batigoal
Цитата

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

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

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

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

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

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

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


Цитата(Torsten @  10.6.2008,  23:40 )
Цитата
А ты не думал, что есть другие способы обмена информацией ?
Тут ты прав. UML, конечно, универсален, но отнюдь не всегда оптимален.
Для справки: ida - девушка   

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

boloeng
Не убедил, сказанный слова не заменяет реальных условий и проектов. Но спорить я с тобой не буду, ты лучше в теории плаваешь. Я бы с тобой поспорил год назад, когда Фаулера почитал, однако после того как прочитал - я все из своей головы выкинул за ненадобностью.
Единственное, что :
Цитата
 Второй момент, ведь даже читая свой текст ты его не чувствуешь, т.е. дописываешь в уме недостающие детали и расставляешь акценты, а посторонний человек читая это должен восстановить эту картинку без этих акцентов и деталей. Сам грешен не раз получал от РП взыскания за такие вещи. А чем хорош UML - однозначностью восприятия нотаций.

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


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

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


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

Это сообщение отредактировал(а) Torsten - 11.6.2008, 17:31
--------------------
We have no begining, we have no end. We are infinite.
PM MAIL   Вверх
ida
Дата 11.6.2008, 19:51 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



Цитата(Torsten @ 11.6.2008,  18:23)
я уже сказал, что многие люди, такие как я плохо разбираются в рисованных данных 

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

Это сообщение отредактировал(а) ida - 15.3.2009, 19:45
PM WWW   Вверх
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Системный анализ, проектирование и UML"
Се ля ви

Форум "Системный анализ, проектирование и UML" предназначен для обсуждения вопросов, так или иначе связанных с этапами жизненного цикла автоматизированных (программных, информационных, автоматических) систем:

• предпроектные обследования объектов автоматизации;

• разработка концепции создания систем;

• моделирование бизнес-процессов (в т.ч. на UML);

• проектирование архитектуры систем;

• управление проектами;

• управление качеством;

• CASE-средства;

• реинжиниринг.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Се ля ви.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Системный анализ, проектирование и UML | Следующая тема »


 




[ Время генерации скрипта: 0.1116 ]   [ Использовано запросов: 23 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.