Практическая польза use case'ов - Управление проектами

Здравствуйте, 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-ов и т.д., и соответственно эти связи
отслеживать.

Posted via RSDN NNTP Server 1.8

Здравствуйте, 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.

Posted via RSDN NNTP Server 1.8

Здравствуйте, 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.
...

Posted via RSDN NNTP Server 1.9 alpha

Здравствуйте, 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 — это легко Кролла и Крачтена.

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

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

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

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

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

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

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

На кой _программисту_ знать RUP???? Если в конторе используется процесс на основе RUP, то разработчику достаточно уметь читать, например те же юзкейсы ... и UML диаграммы.

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

RUP вы не используете, скорее потому, что сами его толком не знаете ...

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

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

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

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

. Имеет смысл смотреть в сторону Agile вообще. Почитать? -- Скотт Амблер.

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

N>Привет

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

1. Юзкейсы в первую очередь это ТЕКСТОВЫЕ описания!!!!
Использовал юзкейсы в "средневесном" проекте -- очень доволен, здорово все упорядочивают, и заказчик их читает и понимает на "ура", все-таки сжатый текст, без воды ... . Правда полной трассировки в РеквизитеПро не делал.

N>Мое представление о use-case'ах формировалось через книгу о Unified Process Буча, Якобсона и Румбао (бедный, как его имя только не переводят

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

Не правильная книга ... нужно читать Алистера Коберна (Alister Cockburn. Writting Effective Use Cases), есть уже и на русском эта книга -- только называется по-другому (что-то про современные методы описания функциональных требований). После этой книги очень многое станет на свои места.

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

Тогда лучше Rose+RequisitePro или Together + CalibrRM ...

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

Нафиг тогда Роза ему нужна ... можно просто на Visio например рисовать, или еще что попроще ...

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

Из RUP очень трудно выковырять что-то практически стоящее, повторюсь -- читай Alister Cockburn, S. Ambler.

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

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

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

Например, книга Крэга Лармана Применение UML и шаблонов проектирования. (Введение в объектно-ориентированный анализ и проектирование) построена на примере использования UP (Unified Process или Унифицированный процесс — это предшественник RUP и его можно рассматривать как урезанный RUP) и шаблонов для создания торгового приложения. Мы также используем урезанный RUP (т.е наш процесс — это связанные подмножества деятельностей из RUP в зависимости от проекта) + Agile практики (в частности, парное программирование из XP) + конечно шаблоны. Буду рад ответить на любые конкретные вопросы, связанные с адаптивностью(настраваемостью) и применимостью RUP в небольших проектах

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

А>На кой _программисту_ знать RUP???? Если в конторе используется процесс на основе RUP,
А>то разработчику достаточно уметь читать, например те же юзкейсы ... и UML диаграммы.

Вообще уровень знаний бывает разный. Программисту, к-рый учавствует в процессе разработки, основанном на RUP, необходимо иметь, как минимум, общее представление о нём, а ещё лучше понимать суть и назначение смежных с программированием деятельностей: анализа, дизайна ГИП, проектирования, тестирования, управления изменениями и т.п, т.к это всё тоже относится к процессу и вот ещё почему:

нередко решения в проекте, относящиеся к одной или к смежным областям, принимаются
совместно, например, когда программист консультирует проектировщика или тестера
по вопросам, имеющим отношение к программированию — чтобы этот процесс был более эффективным;
не возникает желания заняться самодеятельностью, залезая в чужую область ответственности.
Хотя, конечно, менеджер может регулярно "бить по рукам", но зачем если человеку можно объяснить,
чтобы он понял;
это простые и небольшие по объёму знания.

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

B>Думаю что XP столь же экстремальное решение, как и тяжеловесные методики (i.e. слишком легковесное
B>для <некотороых проектов).

B>Во-первых -- XP требует тесной коммуникации с заказчиком, что не всегда возможно ...

Заказчик, присутствующий в команде — это ладно, но ведь есть и заказчики/пользователи (хотя этим руководство может по "настучать" по башке), к-рые ленятся даже пообщаться 1 час в день с аналитиком, к-рый сам за них записывает ВИ, не смотря на договоренности и то, что руководство им за это з/п платит. Вечно этот злосчастный человеческий фактор

B>да, и не забываем про парное программирование .

Мы, например, используем парное программирование (ПП) в контексте нашего RUP — когда дело касается передачи приёмов и стиля программирования от более опытных программистов к новым коллегам или менее опытным, и на особо важных участках, т.к две головы лучше, чем одна. Если имелось в виду, что ПП трудно применимо в командах, где его не использовали, то часто эти трудности либо просто надуманны, либо опять упираются в человеческий фактор (нежелание программистов работать парами, боязнью критики со стороны коллег, нежелание делиться "своими" приёмами, чувство психологического дискомфорта и т.п)

Pair programming
XP claims that pair programming is beneficial to code quality, and that once this skill is
acquired it becomes more enjoyable. The RUP doesn't describe the mechanics of code production
at such a fine-grained level, although it would certainly be possible to use pair programming
in a RUP-based process. Some information on pair programming—as well as test-first design and
refactoring—is now provided with the RUP, in the form of white papers. Obviously, it is not
a requirement to use any of these practices in the RUP, however in a team environment, with
a culture of open communication, we would hazard a guess that the benefits of pair programming
(in terms of effect on total lifecycle costs) would be hard to discern. People will come together
to discuss and solve problems quite naturally in a team that's working well, without being obliged
to do so.

IMHO нерационально отказываться от тех преимуществ, к-рые даёт ПП (конечно, после начала его полноценного использования, когда "пыль улеглась"

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

B>Из RUP очень трудно выковырять что-то практически стоящее, повторюсь -- читай Alister Cockburn, S. Ambler.

Если не секрет, то на чём основано ваше мнение? У Коберна в WEUC (я ценю эту книгу и сам часто ссылаюсь на неё), хорошо описаны суть, уровни/степени детализации, типы, шаблоны (однако сами шаблоны Коберна далеко не являются идеальными — это не только моё мнение) и примеры ВИ, но там нет процесса/методов получения ВИ, их анализа (включая шаблоны) и моделирования — это также важная часть работы со спецификациями ВИ.
Сам процесс описан, например, в документации к RUP (там также описана суть, есть примеры, шаблоны и статьи, посвященные ВИ) или в книгах, посвященных работе с требованиями, например, в контексте процесса/методологии разработки ПО, например, в Леффингуэлл, Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. – М.: «Вильямс», 2002. – 448 с. "Низкоуровневые" методы и шаблоны анализа описаны в книгах, например, у Фаулера, Лармана и других.
Однако даже в довольно подробной документации как, например, к RUP не описан процесс как нужно проводить собеседование, общаться с заказчиком/пользователями (коммуникативные, психологические, культурные и т.п аспекты) или как нужно работать с документацией заказчика/пользователей (получение знаний о предметной области). Есть лишь некий "Guidelines: Interviews" (пара страниц), содержащий общие рекомендации вроде:

When you formulate a set of questions, you also should consider the following:

Don't ask people to describe things they don't usually describe.

Don't ask questions that assume that users can describe complex activities. Example: tying your shoelace.

In general, people can do many things they cannot describe.

Empirical evidence — poor correlation.

Ask open-ended questions.

Avoid questions that begin with "Why?", since such questions can provoke a defensive posture.

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

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

А>>На кой _программисту_ знать RUP???? Если в конторе используется процесс на основе RUP,
А>>то разработчику достаточно уметь читать, например те же юзкейсы ... и UML диаграммы.

RUP>Вообще уровень знаний бывает разный. Программисту, к-рый учавствует в процессе разработки, основанном на RUP, необходимо иметь, как минимум, общее представление о нём, а ещё лучше понимать суть и назначение смежных с программированием деятельностей: анализа, дизайна ГИП, проектирования, тестирования, управления изменениями и т.п, т.к это всё тоже относится к процессу и вот ещё почему:

знать и понимать ... это таки две разницы

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

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

B>>Думаю что XP столь же экстремальное решение, как и тяжеловесные методики (i.e. слишком легковесное
B>>для <некотороых проектов).

B>>Во-первых -- XP требует тесной коммуникации с заказчиком, что не всегда возможно ...

RUP>Заказчик, присутствующий в команде — это ладно, но ведь есть и заказчики/пользователи (хотя этим руководство может по "настучать" по башке), к-рые ленятся даже пообщаться 1 час в день с аналитиком, к-рый сам за них записывает ВИ, не смотря на договоренности и то, что руководство им за это з/п платит. Вечно этот злосчастный человеческий фактор

прошу прощения, но не совсем понял что такое "ВИ"?

B>>да, и не забываем про парное программирование .

RUP>Мы, например, используем парное программирование (ПП) в контексте нашего RUP — когда дело касается передачи приёмов и стиля программирования от более опытных программистов к новым коллегам или менее опытным, и на особо важных участках, т.к две головы лучше, чем одна. Если имелось в виду, что ПП трудно применимо в командах, где его не использовали, то часто эти трудности либо просто надуманны, либо опять упираются в человеческий фактор (нежелание программистов работать парами, боязнью критики со стороны коллег, нежелание делиться "своими" приёмами, чувство психологического дискомфорта и т.п)

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

RUP>IMHO нерационально отказываться от тех преимуществ, к-рые даёт ПП (конечно, после начала его полноценного использования, когда "пыль улеглась"

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

B>>Из RUP очень трудно выковырять что-то практически стоящее, повторюсь -- читай Alister Cockburn, S. Ambler.

RUP>Если не секрет, то на чём основано ваше мнение? У Коберна в WEUC (я ценю эту книгу и сам часто ссылаюсь на неё), хорошо описаны суть, уровни/степени детализации, типы, шаблоны (однако сами шаблоны Коберна далеко не являются идеальными — это не только моё мнение) и примеры ВИ, но там нет процесса/методов получения ВИ, их анализа (включая шаблоны) и моделирования — это также важная часть работы со спецификациями ВИ.

Повторюсь, что не совсем понял термин "ВИ", если не сложно ... расшифруйте. Что касается выковыривания из RUP ... честно говоря, мне не разу не приходилось видеть людей, которые после ознакомления с RUP смогли бы что-то применить оттуда. Я повторюсь -- это при условии "просто сижу и изучаю RUP", в т.ч. изучая его по книгам, даже в оригинале (i.e. не по переводным книгам о RUP...). Например, дисциплина Бизнес-моделирование ... не сразу понятно как выстраивать Business Goals и описывать Business Rules ... до этого доходишь только после прочтения соответствующей этой тематики литературы (на которые в RUP есть ссылки) и ... после консультаций с теми, кто это уже делал! Но таких в нашей стране я думаю не много... Что касается управления требованиями ... то первое что бросается -- это все-таки use case driven development ... и первое, что начинают делать люди после прочтения RUP -- правильно, РИСОВАТЬ диаграммы юзкейсов! Пример -- у меня перед глазами ТЗ (!), полученно с Калининской АЭС .. там люди после изучения RUP ... именно так и подходят ... рисуют юзкейсы -- потом строят domain model. Теперь про Алистэра

... мне интересно было бы увидеть шаблоны юзкесов которые используете вы в своей практике, если конечно это не секрет. Лично я использую достаточно часто fully dressed формат ... изредка casual. В большинстве случаев они меня вполне устраивают ... при желании,там же можно и бизнес-правила размещать.

RUP>Сам процесс описан, например, в документации к RUP (там также описана суть, есть примеры, шаблоны и статьи, посвященные ВИ) или в книгах, посвященных работе с требованиями, например, в контексте процесса/методологии разработки ПО, например, в Леффингуэлл, Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. — М.: <Вильямс>, 2002. — 448 с. "Низкоуровневые" методы и шаблоны анализа описаны в книгах, например, у Фаулера, Лармана и других.
RUP>Однако даже в довольно подробной документации как, например, к RUP не описан процесс как нужно проводить собеседование, общаться с заказчиком/пользователями (коммуникативные, психологические, культурные и т.п аспекты) или как нужно работать с документацией заказчика/пользователей (получение знаний о предметной области). Есть лишь некий "Guidelines: Interviews" (пара страниц), содержащий общие рекомендации вроде:

Что касается Лармана -- то на мой взгляд это достаточно интересный подход, он дает идею, которую можно развивать и применять это на практике. Бесспорно шаблоны GRASP там описаны хорошо, и вооружают критериями оценки объектного дизана как минимум. И конечно же -- абсолютная правда, о том, что RUP очень вскользь упоминает о "получении знаний о предметной области" ... я так столкнулся с определенными трудностями и нехваткой информации о том, как эффективно проводить юзкейс-воркшопы ... попытка провести его в компании на которую я сейчас работаю привела к тому ... что через 2 часа я был просто выжат как лимон ... и с тех пор провожу "блиц-обсуждения", хотя это меннее эффективно. И я действительно сталкиваюсь с проблемой "выуживания знаний из экспертов", особенно в такой тематике как капстроительство АЭС ...

Но, вобщем RUP и не призван научить КАК проводить семнары и прочия ... для этого есть видимо отдельная литература, проавда я этот вопрос пока не изучал специально.

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

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

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

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

B>знать и понимать ... это таки две разницы

А какой в данном случае смысл в знании без понимания?

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

B>Наконц-то до меня дошло, что ВИ -- это сокращение от Варианты Использования! точно ... так их переводят у нас ... просто я обычно использую термин юзкейсы ... посему не врубился сразу ... сорри.

Кроме термина "вариант использования" есть ещё термин "прецедент". Несколько лет назад между аналитиками случались флеймы на тему "ВИ vs прецедент". IMHO "вариант использования" более выразительный и удобный (из-за аббревиатуры ВИ аналогичной UC), чем "прецедент". "Юзкейс" будучи англицизмом может вызывать негативную реакцию у нек-рых заказчиков/пользователей. Также был спор, что лучше "актор", "актёр" или "действующее лицо". (Неправильные или некорректные варианты вроде "актант" или "пользователь системы", встречающиеся в российской ИТ лит-ре, даже нет смысла рассматривать.) IMHO "актёр" более выразительный (кто-то или что-то, выполняющее определённую роль по отношению к системе или сама эта система) и опять же не является англицизмом, чем другие варианты

B>если не секрет, мы это кто?

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

B>мне просто любопытно где у нас в стране все-таки процессы поставлены?

Какие именно процессы имеются в виду и что значит поставлены? Вообще процессы разработки как некие последовательности деятельностей для достижения чего-то есть везде, но только зачастую они неэффективны, их деятельности не являются подмножествами каких-то других научных и проверенных подходов/методологий, они меняются от проекта к проекту ("так ладно.. сроки поджимают — пропускаем проектирование и сразу переходим к кодированию") в ущерб качеству системы, управляемости и т.п. Возможно полезное наблюдение: Если вы общаетесь с представителями компаний, к-рые утверждают, что у них работает некий процесс (XP, урезанный RUP, MSF и т.п) или вы приходите на собеседование в такую компании, то кое-что можно выяснить. Когда главный аналитик или менеджер компании не знает или не понимает назначение фаз или прототипов в RUP, или говорит, что они не используют рефакторинг, но при этом они утверждают, что в компании используется RUP или XP соответственно, то это уже вызывает сомнение. Затем, конечно, выясняется, что используется, например, деятельность ОО проектирования с использованием средств Rational — "RUP"

B>Потому как отрицательных примеров я насмотрелся много, вот с положительными менее повезло, и каждый положительный пример мне, можно сказать душу греет. Кроме этого, при желании можно организовать workshop ... по обмену опытом.

Можно, но просто я пока не ощущаю объективной необходимости в каком-то дополнительном опыте именно по части процесса разработки. Возможно полезное наблюдение: процесс, спроектированный и работающий благодаря собственным усилиям при полном понимании руководства зачем это нужно и его одобрении, гораздо ценнее, чем походы разработчиков и руководства в другую компанию и наблюдение чужуго процесса из-за плеча — в этом случае не исключено, что у руководства, к-рому передаётся опыт, ещё больше усилится "комплекс неполноценности", а деньги за просмотр "шоу" будут потрачены. Если кто-то (назовём их "внедренцами") собирается внедрять процесс/средства, то я бы рекомендовал попробовать это сделать своими силами, т.к...

проектирование процесса и обоснованный выбор средств автоматизации — задача, требующая
не бог весть какого интеллекта или эксклюзивных знаний и это не проектирование-внедрение,
например, бизнес-процессов на крупном предприятии, банке или холдинге.
При спланированном, постепенном и аккуратном подходе эта задача выполнима в разумные сроки
даже 1 человеком;
пройдя через "муки" деятельностей п.1 внедренцы будут не только знать свой и референтный
(XP, RUP и т.п) процессы прекрасно, но и преобретут кругозор в этой области, что также очень
полезно;
исключается копирование чужух ошибок или неэффективных подходов, представленных или
понятых как неошибочные или эффективные, т.к внедренцы проводят самостоятельный и доскональный
анализ полезности всего и вся, а также лично отвечают за результаты;
повышается авторитет внедренцев в глазах руководства и коллег, а также и вознаграждение.

B>{skip} Что касается выковыривания из RUP ... честно говоря, мне не разу не приходилось видеть людей, которые после ознакомления с RUP смогли бы что-то применить оттуда. повторюсь -- это при условии "просто сижу и изучаю RUP", в т.ч. изучая его по книгам, даже в оригинале (i.e. не по переводным книгам о RUP...).

Документация или даже книги по RUP содержат большую часть знаний, необходимых для понимания и описания/настройки/проектирования своего процесса. Любая документация или книга по RUP, XP или любой другой методологии — это не есть её модель, артефакты и т.п сразу готовые к применению => чтобы использовать свой RUP нужно, как минимум (IMHO с т.з, например, эффективности освоения), создать модель с необходимым уровнем детализации и описание своих процессов, включая роли, артефакты, шаблоны и т.п для своих типов проектов и положить это в общедоступный источник, чтобы разработчики могли использовать его для эффективного ознакомления, а не тонули в объемной документации по RUP.

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

B>Например, дисциплина Бизнес-моделирование ... не сразу понятно как выстраивать Business Goals и описывать Business Rules ... до этого доходишь только после прочтения соответствующей этой тематики литературы (на которые в RUP есть ссылки) и ... после консультаций с теми, кто это уже делал! Но таких в нашей стране я думаю не много...

А что по-вашему в RUP описано не очень понятно про Business Goals (BG) или Business Rules (BR), и какая версия RUP имеется в виду? Я могу посмотреть, начиная с v2000, т.к не исключаю, что в более ранних версиях эти вещи не описывались достаточно детально

B>Что касается управления требованиями ... то первое что бросается -- это все-таки use case driven development ... и первое, что начинают делать люди после прочтения RUP -- правильно, РИСОВАТЬ диаграммы юзкейсов! {skip}

Может они невнимательно читали документацию к RUP, не говоря уже про "Унифицированный процесс разработки" (Три амигос) или другие книги, где описывается работа с ВИ? Если читать внимательно, то сразу становится ясно, что диаграммы ВИ вторичны, т.е служат для удобства восприятия структуры модели ВИ

Коберн, "Writing Effective Use Cases" (WEUC):

1.1 What is a Use Case (more or less)?
Use cases are fundamentally a text form, although they can be written using flow charts,
sequence charts, Petri nets, or programming languages. Under normal circumstances, they serve
to communicate from one person to another, often to people with no special training. Simple
text is, therefore, usually the best choice. ......

The UML use case diagram
The use case diagram, consisting of ellipses, arrows and stick figures, is not a notation for
capturing use cases. The ellipses and arrows show the packaging and decomposition of the use
cases, not their content. ......

The point of this section is to prevent you from trying to replace the text of the use cases
with ellipses. One student in a lecture asked me, "When do you start writing text? At the leaf
level of the ellipse decomposition?"

The answer is that the use case lives in the text, and all or any drawings are only an illustration
to help the reader locate the text they need to read.

RUP, "Guidelines: Use Case":

Use-Case Diagrams
You may choose to illustrate how a use case relates to actors and other use cases in a use-case
diagram (in unusual cases, more than one diagram), owned by the use case. This is useful if the
use case is involved with many actors, or has relationships to many other use cases.

Ларман, "Применение UML и шаблонов проектирования. ...":

6.13. Диаграммы прецедентов
Диаграммы прецедентов и их взаимосвязей имеют второстепенное значение при работе над прецедентами.
Прецеденты — это текстовые документы. Работать над прецедентами — значит составлять текстовые
описания.
Обычно новички в области моделирования прецедентов начинают с составления диаграмм прецедентов и
из взаимоотношений, а не с составления текстовых описаний. ...... В таком ракурсе диаграмма лишь
иллюстрирует способы использования системы внешними исполнителями.

B>Теперь про Алистэра ... мне интересно было бы увидеть шаблоны юзкесов которые используете вы в своей практике, если конечно это не секрет. Лично я использую достаточно часто fully dressed формат ... изредка casual. В большинстве случаев они меня вполне устраивают ... при желании,там же можно и бизнес-правила размещать.

У нас full dressed (FD) — это конечная формат ВИ, т.е все ВИ, к-рые планируются к реализации должны иметь формат FD, т.к она содержит детальное описание бизнес-правил, работы с ГИП, ссылки на прототипы ГИП и требования, а также вопросы. Начальной форматом ВИ, конечно, является brief — в зависимости от времени, затраченного на ВИ: это название, актёры, область действия и краткое описание целей актёров — в самом начале; -//- и основные шаги сценария — в конце. Если есть желание обсудить шаблоны описаний ВИ, то, пожалуйста, постите русские названия полей/атрибутов для своего (Коберновского) FD — обсудим. Я запостю и расскажу про тот FD, к-рый используем мы, но раз я в его оптимальности уже убедился, то просто хочется от обсуждения получить больше, чем просто постинг, т.е чтобы в процессе обсуждения немного уйти от Коберновского и либо прийти к тому, к-рый используем мы (для краткости я буду называть его "наш" хотя это, конечно, результат переработки Коберновского варианта несколькими аналитиками), либо, возможно, ещё более лучшему варианту

B>{skip} я так столкнулся с определенными трудностями и нехваткой информации о том, как эффективно проводить юзкейс-воркшопы ... попытка провести его в компании на которую я сейчас работаю привела к тому ... что через 2 часа я был просто выжат как лимон ... и с тех пор провожу "блиц-обсуждения", хотя это меннее эффективно. И я действительно сталкиваюсь с проблемой "выуживания знаний из экспертов", особенно в такой тематике как капстроительство АЭС ...

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

B>Но, вобщем RUP и не призван научить КАК проводить семнары и прочия ...

Не уверен, что термин "призван делать что-то" корректен по отношению к процессу, когда границы применимости этого процесса не обозначены чётко. Ведь RUP (его документация) также не призван учить как писать код на Java или проектировать приложения под .NET, но он по умолчанию содержит статьи (guides) на эту тему или имеет массу дополнительных информационных плагинов. Что касается проведения интервью и т.п, то это важная и неотъемлимая часть деятельности анализа, не зависимо используем ли мы Java, по к-рому в инете информации более чем достаточно, или .NET

B> для этого есть видимо отдельная литература, проавда я этот вопрос пока не изучал специально.

Спец лит-ру, посвящённую отдельно этом вопросу я тоже не встречал хотя я периодически (раз в 3-4 месяца интересуюсь новыми книгами, связанными с анализом/проектированием). Есть "обрывки" информации, разбросанные по разным источникам: книги-статьи, посвящённые SADT, RUP, XP, практической психологии (коммуникации, тренинги и т.п), обсуждения в форумах, задокументированный и проанализированный собственный опыт (что-то наподобии antipatterns) и т.п

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

RUP>Кроме термина "вариант использования" есть ещё термин "прецедент". Несколько лет назад между аналитиками случались флеймы на тему "ВИ vs прецедент". IMHO "вариант использования" более выразительный и удобный (из-за аббревиатуры ВИ аналогичной UC), чем "прецедент". "Юзкейс" будучи англицизмом может вызывать негативную реакцию у нек-рых заказчиков/пользователей. Также был спор, что лучше "актор", "актёр" или "действующее лицо". (Неправильные или некорректные варианты вроде "актант" или "пользователь системы", встречающиеся в российской ИТ лит-ре, даже нет смысла рассматривать.) IMHO "актёр" более выразительный (кто-то или что-то, выполняющее определённую роль по отношению к системе или сама эта система) и опять же не является англицизмом, чем другие варианты

Интересно то, что будучи в Австрии, я интересовался у представителей разных национальностей (австрийцы, голландцы, поляки ...) по поводу применения термина "юзкейс" -- в плане переводят ли его на национальные языки, оказалось, что не переводят, а используют оригинальные англоязычные термины. Во всяком случае те люди с кем я общался (они имели представление что это такое

. Ну это так, просто к теме

B>>если не секрет, мы это кто?

RUP>Страшный "секрет" — компания, в к-рой я работаю в данный момент,

А название компании можно озвучить (если это конечно возможно, обещаю хранить в секрете

? Просто я гадаю

... Сибинтек, Аплана, IBS/Люксофт ...???

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

Сколько стоит консалтинг, ориентировочно?

B>>мне просто любопытно где у нас в стране все-таки процессы поставлены?

RUP>Какие именно процессы имеются в виду и что значит поставлены? Вообще процессы разработки как некие последовательности деятельностей для достижения чего-то есть везде, но только зачастую они неэффективны, их деятельности не являются подмножествами каких-то других научных и проверенных подходов/методологий, они меняются от проекта к проекту ("так ладно.. сроки поджимают — пропускаем проектирование и сразу переходим к кодированию") в ущерб качеству системы, управляемости и т.п. Возможно полезное наблюдение: Если вы общаетесь с представителями компаний, к-рые утверждают, что у них работает некий процесс (XP, урезанный RUP, MSF и т.п) или вы приходите на собеседование в такую компании, то кое-что можно выяснить. Когда главный аналитик или менеджер компании не знает или не понимает назначение фаз или прототипов в RUP, или говорит, что они не используют рефакторинг, но при этом они утверждают, что в компании используется RUP или XP соответственно, то это уже вызывает сомнение. Затем, конечно, выясняется, что используется, например, деятельность ОО проектирования с использованием средств Rational — "RUP"

1. Начсчет "процессы поставлены", я думаю Вы конечно же догадались что имелось ввиду

I.e. унификация процесса -- т.е. именно выработка собственного процесса на основе известных методологий/подходов. Конечно же очевидно, что если группа разработчиков выпускает ПО, то видимо они таки имеют некую последовательность действий и коммуникаций внутри группы, что в конечном итоге приводит к выпуску ПО, за которое им платят деньги. Но если следовать Вашему стилю комментариев, тогда видимо имеет смысл пояснить что такое "эффективный процесс" (критерий эффективности?). И почему этой команде имеет смысл реинжениририть свой процесс разработки. Первый вопрос который задаст такая команда будет "нам и так платят деньги за наш софт/услуги которые подкреплены софтом, нам проще тут собраться на словах все обсудить и всем все понятно без бумаг и UP", да, что такое agile они тоже не знают

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

2. Да, примеров очень много, когда RUP=Rational Rose=OOAD, т.е. люди не чуствуют разницы. Я лично сталкиваюсь с этим постоянно. Вот и хочеться узнать где .. в каких организациях есть положительные примеры выстраивания собственного процесса на основе например RUP и/или XP.

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

Судя по всему Вы прекрасно представляете как "выстраивать" процесс разработки. Тогда скорее может идти речь о менторинге или консалтинге на коммерческой основе ... это вопрос обсуждаемый. В этом у Вас имеется интерес?

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

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

, а информация о положительном опыте IMHO довольно полезна. Вопрос к Вам, вы используете RUP Builder для формализации процессов, например в компании на которую вы работаете?

RUP>А что по-вашему в RUP описано не очень понятно про Business Goals (BG) или Business Rules (BR), и какая версия RUP имеется в виду? Я могу посмотреть, начиная с v2000, т.к не исключаю, что в более ранних версиях эти вещи не описывались достаточно детально

Я получил гораздо больше информации о BR отсюда:
Business Rules and Information Systems:Aligning IT with Business Goals. Tony Morgan;
Principles of the Business Rule Approach. Ronald G. Ross.

RUP>Может они невнимательно читали документацию к RUP, не говоря уже про "Унифицированный процесс разработки" (Три амигос) или другие книги, где описывается работа с ВИ? Если читать внимательно, то сразу становится ясно, что диаграммы ВИ вторичны, т.е служат для удобства восприятия структуры модели ВИ

Боюсь, что они вообще этого не читали. А так их научили на курсах в Интерфейсе. I.e. курс который читает Золотухина. И этот курс популярен!

B>>Теперь про Алистэра ... мне интересно было бы увидеть шаблоны юзкесов которые используете вы в своей практике, если конечно это не секрет. Лично я использую достаточно часто fully dressed формат ... изредка casual. В большинстве случаев они меня вполне устраивают ... при желании,там же можно и бизнес-правила размещать.

RUP>У нас full dressed (FD) — это конечная формат ВИ, т.е все ВИ, к-рые планируются к реализации должны иметь формат FD, т.к она содержит детальное описание бизнес-правил, работы с ГИП, ссылки на прототипы ГИП и требования, а также вопросы. Начальной форматом ВИ, конечно, является brief — в зависимости от времени, затраченного на ВИ: это название, актёры, область действия и краткое описание целей актёров — в самом начале; -//- и основные шаги сценария — в конце. Если есть желание обсудить шаблоны описаний ВИ, то, пожалуйста, постите русские названия полей/атрибутов для своего (Коберновского) FD — обсудим. Я запостю и расскажу про тот FD, к-рый используем мы, но раз я в его оптимальности уже убедился, то просто хочется от обсуждения получить больше, чем просто постинг, т.е чтобы в процессе обсуждения немного уйти от Коберновского и либо прийти к тому, к-рый используем мы (для краткости я буду называть его "наш" хотя это, конечно, результат переработки Коберновского варианта несколькими аналитиками), либо, возможно, ещё более лучшему варианту

исходя из Вашей любви к точности терминов, позволю заметить, что у Коберна таки используется fully dressed, а не full dressed и формы briefя у него тоже не встречал

.

что касается обсуждений шаблонов -- готов запостить -- тема очень интересная! Подготовлю и закину.

RUP>Я буду рад ответить на любые вопросы по этой Теме, т.к думаю, что эта Тема будет интересна тем, кто получает требования и если она, возможно, не обсуждалась на форуме RSDN, то может быть данный топик будет своеобразным FAQом

да, интересно было бы развить это обсуждение, постараюсь подготовить вопросы

	От:	nuklus
	Дата:	03.05.04 15:47
	Оценка:

	От:	Аноним
	Дата:	03.05.04 22:03
	Оценка:

	От:	_master
	Дата:	04.05.04 06:57
	Оценка:

	От:	bkat
	Дата:	04.05.04 07:03
	Оценка:	+1

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	04.05.04 07:21
Оценка:

От:	S-SH	http://shmakov.ru/
Дата:	05.05.04 08:18
Оценка:	+1

От:	byur	http://yurybuluy.blogspot.com/
Дата:	28.05.04 09:55
Оценка:

От:	RUPman	http://www.rational.net/
Дата:	22.07.04 08:31
Оценка:

	От:	StanislavK
	Дата:	14.05.04 07:11
	Оценка:

	От:	StanislavK
	Дата:	14.05.04 09:39
	Оценка:

	От:	StanislavK
	Дата:	14.05.04 10:05
	Оценка: