Здравствуйте, henson, Вы писали:
H>Спасибо за обстоятельный ответ. В принципе, я использую UML, но дальше красивых схем приспособить его не получается. Хотелось бы продвинуться в направлении совместной работы над требованиями с заказчиком. Чтобы было понятно кто крайний если заложены никому не нужные фичи Но, похоже, придется довольствоваться эволюционными методами Еще раз спасибо!
Мне кажется UML при общении с заказчиком (если он не эксперт по UML) — только вреден, так как создаёт иллюзию понимания там, где понимания нет.
Поскольку речь идёт о вариантах использования (use cases) — могу посоветовать описывать варианты использования в текстовом виде — как это советуют делать эксперты в области сбора и анализа требований. Диаграммы же использовать в любом виде — лишь бы они были осмысленны и проясняли, что требуется сделать и Вам и заказчику.
Здравствуйте, henson, Вы писали:
H>Перед началом нового проекта хотел бы спросить у уважаемых посетителей какие инструменты они предпочитают с точки зрения удобства, эффективности, скорости работы при решении следующих задач:
H>.: Сбор требований заказчика H>.: Формализация бизнес-процессов H>.: Разработка объектной модели H>.: Документирование модели для передачи исполнителям
Если ничего не испоьзовал до этого ... то удобнее всего будет карандаш и лист бумаги .
Если есть желание описывать и бизнес-процессы и дизайн на одном языке, то можно порекомендовать UML. Требования можно писать хоть просто в Ворде, а можно использовать RequisitePro или CalibrRM. Только нужно сначала понять вообще как собираешься работать с требованиями. Если просто писать -- то лучше просто в Ворде, как минимум быстрее .
H>Есть ли XML языки описания всех этапов разработки например по RUP?
Есть RUP Builder, можно собственный вэб-сайт a-la RUP делать ...
H>Вопрос возник в связи с необходимостью стандартизации всей документации описывающий проект и ее прямом использовании при разработке вплоть до автоматической генерации кода, хотя это конечно во многом утопическая задача, но есть желание хотя бы встать на правильный путь. UML диаграммы вещь наглядная, но они снижают скорость работы, текстом было бы быстрей описать ту же самую функциональность IMHO.
Самая короткая дорогата -- которую знаешь. Эффект "кривой обучения" инкто не отменял ... быстро можно будет делать, только если проффесионально освоить все ...
Здравствуйте, hrg, Вы писали:
hrg>"Просто вы не умеете их готовить"(с)
Я то умею. Но далеко не все предпочитают японскую кухню...
hrg>Диаграммы — это отличное оглавление для текстовых юзкейсов
Да — но только оглавление. И не более того. Причём часто оглавление такого размера, который сопоставим со всей книгой. Гуру утверждают (и я на собственном опыте убедился в том же) — что текстовые описания должны быть всегда. А вот диаграмм UC может и вообще не быть. Ну а если таки очень хочется — лучше делать отдельные диаграммы наиболее общих вариантов использования.
Перед началом нового проекта хотел бы спросить у уважаемых посетителей какие инструменты они предпочитают с точки зрения удобства, эффективности, скорости работы при решении следующих задач:
.: Сбор требований заказчика
.: Формализация бизнес-процессов
.: Разработка объектной модели
.: Документирование модели для передачи исполнителям
Под каждую задачу можно найти лучший инструмент, но может существуют интегрированные системы проектирования? Которые бы решали рутинные задачи регистрации сущностей, связей, событий, отношений между объекта. Выдавали бы на выходе XML для дальнейшей обработки, рисовали UML диаграммы и т.п.
Есть ли XML языки описания всех этапов разработки например по RUP?
Вопрос возник в связи с необходимостью стандартизации всей документации описывающий проект и ее прямом использовании при разработке вплоть до автоматической генерации кода, хотя это конечно во многом утопическая задача, но есть желание хотя бы встать на правильный путь. UML диаграммы вещь наглядная, но они снижают скорость работы, текстом было бы быстрей описать ту же самую функциональность IMHO.
Заранее спасибо за ответы!
01.12.04 02:35: Перенесено из 'Проектирование'
Re: Чем облегчить проектирование?
От:
Аноним
Дата:
05.11.04 14:50
Оценка:
Здравствуйте, henson, Вы писали:
H>Перед началом нового проекта хотел бы спросить у уважаемых посетителей какие инструменты они предпочитают с точки зрения удобства, эффективности, скорости работы при решении следующих задач:
Могу посоветовать изучить нотацию UML, а также попробовать соответствующий инструментарий. Например, здесь.
Здравствуйте, byur, Вы писали:
B>Здравствуйте, henson, Вы писали:
H>>Перед началом нового проекта хотел бы спросить у уважаемых посетителей какие инструменты они предпочитают с точки зрения удобства, эффективности, скорости работы при решении следующих задач:
H>>.: Сбор требований заказчика H>>.: Формализация бизнес-процессов H>>.: Разработка объектной модели H>>.: Документирование модели для передачи исполнителям
B>Если ничего не испоьзовал до этого ... то удобнее всего будет карандаш и лист бумаги . B>Если есть желание описывать и бизнес-процессы и дизайн на одном языке, то можно порекомендовать UML. Требования можно писать хоть просто в Ворде, а можно использовать RequisitePro или CalibrRM. Только нужно сначала понять вообще как собираешься работать с требованиями. Если просто писать -- то лучше просто в Ворде, как минимум быстрее .
H>>Есть ли XML языки описания всех этапов разработки например по RUP?
B>Есть RUP Builder, можно собственный вэб-сайт a-la RUP делать ...
Спасибо за обстоятельный ответ. В принципе, я использую UML, но дальше красивых схем приспособить его не получается. Хотелось бы продвинуться в направлении совместной работы над требованиями с заказчиком. Чтобы было понятно кто крайний если заложены никому не нужные фичи Но, похоже, придется довольствоваться эволюционными методами Еще раз спасибо!
AndreyFedotov -> "Re[3]: Чем облегчить проектирование?"
A> Мне кажется UML при общении с заказчиком (если он не эксперт по UML) A> — только вреден, так как создаёт иллюзию понимания там, где понимания A> нет.
"Просто вы не умеете их готовить"(с)
A> Поскольку речь идёт о вариантах использования (use cases) — могу A> A> посоветовать описывать варианты использования в текстовом виде — как A> A> это советуют делать эксперты в области сбора и анализа требований. A> A> Диаграммы же использовать в любом виде — лишь бы они были осмысленны A> и A> проясняли, что требуется сделать и Вам и заказчику.
у.
Диаграммы — это отличное оглавление для текстовых юзкейсов
Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, hrg, Вы писали:
hrg>>"Просто вы не умеете их готовить"(с)
AF> Я то умею. Но далеко не все предпочитают японскую кухню...
hrg>>Диаграммы — это отличное оглавление для текстовых юзкейсов
AF> Да — но только оглавление. И не более того. Причём часто оглавление такого размера, который сопоставим со всей книгой. Гуру утверждают (и я на собственном опыте убедился в том же) — что текстовые описания должны быть всегда. А вот диаграмм UC может и вообще не быть. Ну а если таки очень хочется — лучше делать отдельные диаграммы наиболее общих вариантов использования.
А бывают жестко формализованные текстовые описания тех же вещей, что фигурируют в UML? Можно договориться один раз об общем языке, а затем с ним работать.
Здравствуйте, henson, Вы писали:
H>А бывают жестко формализованные текстовые описания тех же вещей, что фигурируют в UML? Можно договориться один раз об общем языке, а затем с ним работать.
Бывают. Более того — они как раз широко использовались до появления UML. Однако с появлением UML — за которым стоит не только сам UML но и целый ряд сопутствующих идей, таких как UP/RUP или XP и техник (таких как описание вариантов использования), была показана эфективность смешенного описания — т.е. что то эффектинее описывается словами, а что-то в виде диаграмм (UML, DTD или произвольными — хоть блоксхемами). Т.е. существует ряд рекомендаций (от людей с большим опытом успешной разработки проектов) — что эффективнее использовать и почему, в каждом конкретном случае. Одну из этих рекомендаций я приводил выше.
Впрочем жёстко формализованные текстовые описания до сих пор прекрасно используются.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Здравствуйте, henson, Вы писали:
H>Перед началом нового проекта хотел бы спросить у уважаемых посетителей какие инструменты они предпочитают с точки зрения удобства, эффективности, скорости работы при решении следующих задач:
H>.: Сбор требований заказчика H>.: Формализация бизнес-процессов H>.: Разработка объектной модели H>.: Документирование модели для передачи исполнителям
H>Под каждую задачу можно найти лучший инструмент, но может существуют интегрированные системы проектирования? Которые бы решали рутинные задачи регистрации сущностей, связей, событий, отношений между объекта. Выдавали бы на выходе XML для дальнейшей обработки, рисовали UML диаграммы и т.п.
H>Есть ли XML языки описания всех этапов разработки например по RUP?
H>Вопрос возник в связи с необходимостью стандартизации всей документации описывающий проект и ее прямом использовании при разработке вплоть до автоматической генерации кода, хотя это конечно во многом утопическая задача, но есть желание хотя бы встать на правильный путь. UML диаграммы вещь наглядная, но они снижают скорость работы, текстом было бы быстрей описать ту же самую функциональность IMHO.
H>Заранее спасибо за ответы!
Rational XDE — интегрирован в среды разработки и внутренний формат описания на основе XML.
Честно говоря за всю свою практику работы не видел ничего лучше тетради формата A4 с клеточкой и гелевой ручки -- честное слово, рисовать диаграмы в розе, заставлял бы секретаршу (если бы была) -- проведите замеры времени если не верите, роза или (кто-то посоветова) visual mind проиграет, а для не опытного проиграет в разы -- к тому же стеснит вас в выражении и как следствие в адекватности восприятия ваших мыслей... Для публикации можно использовать сканер и прочие следствия из сканера (FineReader, например, отдать секретарше).
Для того чтобы понять сказанное, нужно отбросить всякие "модно", "начальство требует", "как в соседней фирме", "говорят помогает", "так все делают", и подобное.
Ясен пень, думать удобнее на бумаге... А вот как сохранить для потомства?
Каракули на салфетке и сам через неделю не разберешь, а если есть привычка приводить все периодически в порядок, то и перевести уже придуманное в электронный вид будет не так сложно.
Здравствуйте, nixite, Вы писали:
N>Честно говоря за всю свою практику работы не видел ничего лучше тетради формата A4 с клеточкой и гелевой ручки -- честное слово, рисовать диаграмы в розе, заставлял бы секретаршу (если бы была) -- проведите замеры времени если не верите, роза или (кто-то посоветова) visual mind проиграет, а для не опытного проиграет в разы -- к тому же стеснит вас в выражении и как следствие в адекватности восприятия ваших мыслей... Для публикации можно использовать сканер и прочие следствия из сканера (FineReader, например, отдать секретарше).
О! Ты не встречал что-то типа "UMLReader"? Т.е. софтину для автоматического распознавания UML из отсканированной картинки? Я на abbyy.com глянул — у них нету.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.