Привет

Поделитесь опытом. Очень интересна практическая польза use case'ов. Как много в реальных проектах СРЕДНЕГО объема (в моем случае это первая версия некой серверной системы со сложным RBAC) уделяется сил для их тщательной проработки и детализации, используются ли шаблоны для детализации из RUP. Пользуются ли люди возможностями трассировки use case'ов к их реализации или же сразу начинают разрабатывать диаграммы классов и последовательности действий. Какая роль use case'ов в таких проектах по отношению к использованию других средств для определения требований.

Мое представление о use-case'ах формировалось через книгу о Unified Process Буча, Якобсона и Румбао (бедный, как его имя только не переводят ), а также ряд статей сопровождающих RUP. В новом проекте я использую розу для определения требований через use case'ы и их анализ через другие диаграммы. У меня уже есть некое подобие бизнес модели, модели use case'ов и часть модели анализа + вордовский документ для нефункциональных требований и немного уже написанного кода.

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

Я вижу, что в соседнем проекте, где работает опытный project manager, use case'ы вообще не используются. Этот человек ведет всю документацию в вордовских документах, всем очень нравиться. Розу он иногда использует для рисования некоторых диаграмм, которые затем помещает в вордовский документ.

Интересно, как вы работаете с требованиями. Может что-нибудь посоветуете. Еще хотелось бы получить линки на реальные сложные проекты в розе, примеры из RUP, которые мне попадались, совсем неинтересные.

Документация тоже нужна!
Я тоже в ВОРДЕ описываю прожект, но с удовольствием бы применил РУП, если бы
была возможность найти программистов, знающих оного.
А переучивать нет времени и сил.
Есть еще ГОСТ и двойную работу делать не хочется.
Вот и не используем РУП

Здравствуйте, Аноним, Вы писали:

А>Документация тоже нужна!
А>Я тоже в ВОРДЕ описываю прожект, но с удовольствием бы применил РУП, если бы
А>была возможность найти программистов, знающих оного.
А>А переучивать нет времени и сил.
А>Есть еще ГОСТ и двойную работу делать не хочется.
А>Вот и не используем РУП

Кстати, ГОСТ очень хорошо сочетается с РУП. Можно использовать РУП как методологию организации разработки, внутреннюю документацию вести по шаблонам РУП, а документацию для заказчика предоставлять по ГОСТ.

Здравствуйте, nuklus, Вы писали:

N>Я вижу, что в соседнем проекте, где работает опытный project manager, use case'ы вообще не используются. Этот человек ведет всю документацию в вордовских документах, всем очень нравиться. Розу он иногда использует для рисования некоторых диаграмм, которые затем помещает в вордовский документ.

Отлично! Лучше тогда обратиться к реальному опыту коллеги.
Такой вариант (кое-что иллистрируется с помощью UML диаграмм, а остальное — обычные документы)
очень распространен. Лучше делать небольшие шаги по организации процесса,
чем пытаться освоить весь RUP в целом. Уверен, что тот project manager
все равно придерживается основных принципов, которые верны
для большинства методологий становления и улучшения процесса.

Здравствуйте, Аноним, Вы писали:

А>Я тоже в ВОРДЕ описываю прожект, но с удовольствием бы применил РУП, если бы
А>была возможность найти программистов, знающих оного.
А>А переучивать нет времени и сил.

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

А>Есть еще ГОСТ и двойную работу делать не хочется.
А>Вот и не используем РУП

А сейчас кому то ГОСТ нужен еще? Или вы на госпредприятия работаете?

Здравствуйте, bkat, Вы писали:

B>Отлично! Лучше тогда обратиться к реальному опыту коллеги.
B>Такой вариант (кое-что иллистрируется с помощью UML диаграмм, а остальное — обычные документы)
B>очень распространен.

Просто в том проекте есть специальный человек, исполняющий роль Project Manager’а, и есть отдельно разработчик (пока один). PM отвечает за определение требований и ведение документации, разработчик пока только помогает в определении нефункциональных требований.

Мне кажется, что работа этого PM будет нужна ему для контроля выполнения проекта, руководству для понимания того, что разрабатывается, тестерам для тестирования, тех. писателю для документирования, но самим разработчикам это будет гораздо менее полезно, чем UML (а тем, кто был в проекте изначально вообще бесполезна).

У меня, как у разработчика, большие текстовые документы вообще вызывают отвращение. Они совершенно не объектно-ориентированные. Нельзя взять текст, подвигать его (самое важное при анализе ), проставить связи, детализировать через другие объекты, трассировать в другую вьюшку и др.

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

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

Может быть, я преувеличиваю возможности UML, и так бывает только в теории? Реально у меня сейчас первый проект, где я пытаюсь использовать его по настоящему, но условия у меня несколько экстремальные, я должен в первую очередь показывать руководству работающий код. К тому же, я единственный пропагандист UML & UP у нас в конторе, поэтому мне немного страшно.


B>Лучше делать небольшие шаги по организации процесса, чем пытаться освоить весь RUP в целом.

Я не пытаюсь внедрять RUP. В RUP входит множество методологий. Я лишь пытаюсь взять на вооружение UML, и использовать его по-настоящему, думать в нем, а не просто рисовать в розе несвязанные диаграммы.

Здравствуйте, nuklus, Вы писали:

N>Может быть, я преувеличиваю возможности UML, и так бывает только в теории?

Это бывает не только в теории, но это требует больших усилий, времени и денег,
чтобы все заработало, как ты себе представляешь.
Если у вас будет текстовый документ, в котором будут внятно и четко
сформулированы требования, пригодные для тестирования,
то поверь мне — это уже очень и очень неплохо.
Чтобы прослеживать все связи, начиная от требований, заканчивая тестами и кодом,
потребуется очень нехилая, дорогая инфраструктура плюс (самое главное)
люди, желающие и умеющие это все делать. Очень сложно поддерживать все связи
в актуальном состоянии.
Для начала можно ограничиться только одним типом связей (требования<->тесты).
Для этого ничего кроме Excel не нужно.
Посмотри, чего это стоит и дальше можешь попробовать связывать дизайн и требования.
Это, на мой взляд, уже гораздо сложнее...
Поддерживать же все связи — это под силу только очень немногим компаниям.

Кстати, спрашивал ты как все же про use case'ы

Мы комбинируем use case в смысле UML с текстовым описанием.
Текст у нас — это набор односложных утверждений, который можно протестировать.
Мне лично такие текстовые утверждения представляются более полезными,
чем картинки с "акторами", овалами и прочей атрибутикой от UML.
Для описания архитектуры системы и описания ее внутренностей UML как раз
мне лично кажется удобней, чем для описания требований.

Здравствуйте, bkat, Вы писали:

B>Мы комбинируем use case в смысле UML с текстовым описанием.
B>Текст у нас — это набор односложных утверждений, который можно протестировать.

Это один из аспектов использования use case'ов. К каждому use case'у в идеале прилагается подробное текстовое описание, например, в отдельном документе. Лучше всего взять шаблон из RUP, получается очень подробный четкий текст.

B>Мне лично такие текстовые утверждения представляются более полезными,
B>чем картинки с "акторами", овалами и прочей атрибутикой от UML.

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

Спасибо за полезный ответ!

С уважением,
Евгений

B>> Мы комбинируем use case в смысле UML с текстовым описанием.
B>> Текст у нас — это набор односложных утверждений, который можно
B>> протестировать.

n> Это один из аспектов использования use case'ов. К каждому use case'у в
n> идеале прилагается подробное текстовое описание, например, в отдельном
n> документе. Лучше всего взять шаблон из RUP, получается очень подробный
n> четкий текст.

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

А тот овал, которым в Розе обозначается Use Case, служит единственно для
обозначения документа на диаграммах, чтобы к нему можно было провести
стрелочки от акторов, других Use Case-ов и т.д., и соответственно эти связи
отслеживать.

Здравствуйте, S-SH, Вы писали:

SS>В оригинале Use Case — это и есть текстовое описание какого-то конкретного
SS>аспекта применения системы.

В оригинале чего?

SS>Текст может содержать схемы, диаграммы, таблицы,
SS>но лишь с целью улучшения понимаемости текста.

Наверное, можно на это смотреть и так...

SS>А тот овал, которым в Розе обозначается Use Case, служит единственно для
SS>обозначения документа на диаграммах, чтобы к нему можно было провести
SS>стрелочки от акторов, других Use Case-ов и т.д., и соответственно эти связи
SS>отслеживать.

Вот цитата OMG Unified Modeling Language Specification

3.55 Use Case

3.55.1 Semantics

A use case is a kind of classifier representing a coherent unit of functionality provided
by a system, a subsystem, or a class ...

3.55.2 Notation

A use case is shown as an ELLIPSE containing the name of the use case.

The behavior of a use case can be described in several different ways, depending on
what is convenient. PLAIN TEXT is used often, but state machines, operations, and
methods are examples of other ways of describing the behavior of the use case.

Так что я вроде бы ничего не наврал...

SS>> В оригинале Use Case — это и есть текстовое описание какого-то
SS>> конкретного аспекта применения системы.

n> В оригинале чего?

n> Вот цитата OMG Unified Modeling Language Specification

На цитату отвечу цитатой, но из RUP:

A use case consists primarily of a textual specification (called a Use-Case
Specification) that contains a description of the flow of events decribing
the interaction between actors and the system. The specification also
typically contains other information such as preconditions, postconditions,
special requirements and key scenarios. The use case may also be represented
visually in UML in order to show relationships with other the use cases and
actors.

Здравствуйте, S-SH, Вы писали:

SS>На цитату отвечу цитатой, но из RUP:
SS>

SS>A use case consists primarily of a textual specification (called a Use-Case
SS>Specification) that contains a description of the flow of events decribing
SS>the interaction between actors and the system. The specification also
SS>typically contains other information such as preconditions, postconditions,
SS>special requirements and key scenarios. The use case may also be represented
SS>visually in UML in order to show relationships with other the use cases and
SS>actors.

OK! Спор не имеет смысла

Я знаю о содержимом спецификации use case'ов в RUP'е. В UP каждый может смотреть на проект через свою вьюшку, кому-то действительно нужно только текстовое описание требований. Я разработчик и мне удобнее работать с UML. Моя главная задача реализовать систему, мне удобнее смотреть на нее через объекты.

Здравствуйте, nuklus, Вы писали:

N>Я знаю о содержимом спецификации use case'ов в RUP'е. В UP каждый может смотреть на проект через свою вьюшку, кому-то действительно нужно только текстовое описание требований. Я разработчик и мне удобнее работать с UML. Моя главная задача реализовать систему, мне удобнее смотреть на нее через объекты.

Через какие объекты?
В use case'ах об объектах речи не идет.
Рано еще о них говорить на этом уровне.
Или ты о чем-то другом?

Здравствуйте, bkat, Вы писали:

B>Через какие объекты?
B>В use case'ах об объектах речи не идет.
B>Рано еще о них говорить на этом уровне.
B>Или ты о чем-то другом?

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

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

Мне удобнее работать с требованиями, как с объектами, детали которых я могу легко посмотреть, а реализацию проследить.

Вот, посмотрите, пожалуйста, здесь несколько интересных цитат из OMG Unified Modeling Language Specification:

A use case is a kind of classifier representing a coherent unit of functionality provided
by a system …

…

As a classifier, a use case may also have compartments displaying attributes and operations.


…

In the metamodel, UseCase is a subclass of Classifier, specifying the sequences of actions performed by an instance of the UseCase.

…

A classifier is an element that describes behavioral and structural features; it comes in several specific forms, including class, data type, interface, component, artifact, and others that are defined in other metamodel packages.

С уважением,
Евгений

Здравствуйте, nuklus, Вы писали:

N>Да нет, конечно, я не про классы реализации, ну можно же посмотреть на функцию системы, как на элемент этой системы, как на класс, экземпляры которого будут создаваться, когда актант начинает использовать функцию.

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

RUP очень тяжеловесный процесс разработки и его имеет смысл пытаться внедрять только в очень крупных проектах.
Использовать в проектной документации наповал один UML — умрешь. UML, это схема к которой нужны комментарии. Проектная документация должна быть понятна всем, поэтому без текста не обойтись и не надо пытаться избавиться от текстовых документов.
Думаю, что XP тебе подойдет как раз. Кстати, имеет смысл посмотреть, что пишут XP-сты про UML и как они к нему относятся.
Вообщем, суть в балансе — надо понять, чего ты хочешь добиться и объективно решить, что для этого надо. Если тебе просто надо перевести все на RUP, это одно, если надо вести правильную проектную документацию и процесс разработки, это другое.

S> RUP очень тяжеловесный процесс разработки и его имеет смысл пытаться
S> внедрять только в очень крупных проектах.

RUP очень тяжеловесный процесс разработки, если его пытаться внедрять
целиком. Как раз в RUP определяется необходимость его адаптации под
конткретный проект.
Да что там говорить — все сказано в RUPе:

Concepts: RUP Tailoring
...
The Rational Unified Process framework constitutes guidance on a rich set of
software engineering practices. It is applicable to projects of different
size and complexity, as well as for different development environments and
domains. This means that no single project will benefit from using of all
of RUP. Applying all of RUP on a single project will likely result in an
inefficient project environment, where teams will struggle to keep focused
on the important tasks, and struggle to find the right set of information.
Thus, we recommend that all projects tailor the RUP.
...

Здравствуйте, S-SH, Вы писали:

S>> RUP очень тяжеловесный процесс разработки и его имеет смысл пытаться
S>> внедрять только в очень крупных проектах.

SS>RUP очень тяжеловесный процесс разработки, если его пытаться внедрять
SS>целиком. Как раз в RUP определяется необходимость его адаптации под
SS>конткретный проект.
SS>Да что там говорить — все сказано в RUPе:

SS>

SS>Concepts: RUP Tailoring
SS>...
SS>The Rational Unified Process framework constitutes guidance on a rich set of
SS>software engineering practices. It is applicable to projects of different
SS>size and complexity, as well as for different development environments and
SS>domains. This means that no single project will benefit from using of all
SS>of RUP. Applying all of RUP on a single project will likely result in an
SS>inefficient project environment, where teams will struggle to keep focused
SS>on the important tasks, and struggle to find the right set of information.
SS>Thus, we recommend that all projects tailor the RUP.
SS>...

И как? Были успехи у кого-нить? Есть специальные методологии, которые расчитаны на внедрение в небольших проектах. Зачем пытаться изобрести велосипед, адаптируя RUP под них? Есть где-нить документанция насчет того, что из RUP надо выкинуть, а что оставить в небольшом проекте? Даже методологии расчитанные на небольшие проекты подразумевают адаптацию, в случае с RUP она будет гораздо более сложной.
Кстати, вышенаписанное (это я про цитату) пишут почти про любые методологии.

Здравствуйте, StanislavK, Вы писали:

SK>Есть где-нить документанция насчет того, что из RUP надо выкинуть, а что оставить в небольшом проекте?

Скоро будет. В книжке RUP &mdash; это легко Кролла и Крачтена.

Здравствуйте, S-SH, Вы писали:

SS>Здравствуйте, StanislavK, Вы писали:

SK>>Есть где-нить документанция насчет того, что из RUP надо выкинуть, а что оставить в небольшом проекте?

SS>Скоро будет. В книжке RUP &mdash; это легко Кролла и Крачтена.

Ну поделись потом впечатлениями