Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Gevorg

Страницы: « 1 2 3 4 5 6 7 8 »
31
Вообще для меня это несколько не привычно
Юзкейсы системного уровня по определению должны быть реализованы в той или иной итерации
и дополнительное утверждение о необходимости реализации того или иного юзкейса в этом случае нет.
это всё к той же теме антипрецедента
тяжело работать с требованиями в ключе "делаем только И ТОЛЬКО то, что записано в документе".
Легче в таком стиле:
- точно делаем то, что записано,
- точно НЕ делаем, что явно указано НЕ делать,
- о чём явно не договорились в документе - разбираем по ходу возникновения проблем.


А вот покрытие бизнес-потребности обчно вводится не через атрибут, а через связи трассировки.
Но вам удобнее так .. никто за это не осуждает :-).
да нет, я тоже делаю это трассировкой с соответствующим стереотипом, но это же в диаграмме.
согласен, в текстовом описании нужно было  добавить явно, что не атрибут, а трассировочная ссылка.
Но опять же, от какого источника? от ЮзКейса или от отдельно выделенного требования по данному ЮзКейсу?

Ещё пример-аргумент в защиту такого разделения (Требования и ЮзКейса):
- система давно написана, досталась в наследство на сопровождение,
- разрабатывалась не то чтобы просто партизанами, а целым партизанским движением,
- соответственно, отсутствует как документация так и какая-либо структуризация в продукте,
- Кровавым пОтом аналитики реинжирят функциональность в виде ЮзКейсов.

Приходит очередная хотелка.
По-сути - это дополнительный альтернативный сценарий для одного из отреинжиреных ВИ.
Как такую хотелку оформлять?
Я завожу отдельный объект "требование",
- даю название,
- вставляю в текст описания соответствующий бред из письма Кастомера, как есть.
- "тычу пальцем" в соответствующее место ДОРАБОТАННОЙ модели ВИ:
если это текстовый документ - кликабельную ссылочку,
если есть диаграммы - то рисую трассировочную ссылочку на ВИ, а ещё лучше - на соответствующий новый сценарий.
Теперь, если добавится ещё и соответствующая активити-диаграмма, то нарисуем и трассировку от нашего требования
к соответствующей ветке на диаграмме.
Но не так всё просто, если пытаться задействовать средства автоматизации:
с ними особо не договоришься про атрибуты, тут они либо есть - либо их нет.
Остаётся, правда, возможность пользовательских полей, но с ними тоже не особо развернёшься.
Кстати, именно здесь мне пришлось использовать связку StarTeam+Caliber+MSProject.

32
Лично мне не очень понятно для чего нужно дополнительное ТРЕБОВАНИЕ: "Реализовать UC12", хотя прошу заметить, что это ВОВСЕ не требование (по определению требований), а чистой воды TASK,
сорри за неточность:
Название: UC12 ДОЛЖЕН быть реализован(или НЕ реализован в данном проекте).
Покрываемая бизнес-потребность: BR007
Источник требования: должностная инструкция менеджеру А отдела Х.
и т.д.
Насколько я знаю, традиционные шаблоны такие атрибуты в ЮзКейс не включают.

33
два вопроса:
1. Триал-период в раквесте закончился, как работать дальше?
2. Куда и как выкладывать свои правки в раквестном файле, который я открываю и всю работу по-сути делаю в ЭА?




34
Ну не знаю, диаграмма communication есть. Другое дело, что автопреобразование как в розе, к сожалению нет.
 Почему - вопрос к ЕА. Однако чтобы задать этот вопрос, нужно быть владельцем.
да я сам видел возможность создать диаграммы с таким названием,
только попробуйте в ней мессиджи прикрепить к коммуникативным ассоциациям.... :-)
я не нашёл, поэтому и выразился в порыве возмущения, что нет диаграмм коммуникации.
Irr, что, действительно всё так печально в ЭА, или я чего-то не замечаю?

35
уфф, появилась маленькая передышка на работе.
попробовал "на зуб" РаКвэст и его связку с ЭА, вот первые впечатления.

По ЭА.

1. Странно, создаю в ЭА требование и класс, который его реализует, создаю связь.
Открываю свойства класса,  в закладке Links вижу связь с требованием.
Открываю свойства требования - закладки Links нет вААще.

2. А где же полноценные диаграммы коммуникации в ЭА?
Сиквенс-есть, а коммуникации - нету, а тем более автоматического преобразования их друг в друга.
Что это? Я чего-то не нахожу, или у меня старая версия ЭА? (v7.08)

3. Странно, а какое назначение закладки "Сценарии" у многих элементов, не имеющих ничего общего с ВИ?
Например - свим-лайны, артефакты, актёры, бизнес-ентити.

4. Ещё про сценарии. Очень хочется выделить сценарии ЮзКейса отдельными элементами диаграммы,
чтобы ссылаться на них трассировочными связями от требований или других элементов диаграмм.
Например, чтобы можно было наглядно показать, что подключение отдельной дополнительной
компоненты необходимо для реализации только одного альтернативного сценария (или нескольких, но из разных ВИ).
Пока не вижу в ЭА стандартных средств для этого.
И уж совсем очевидная потребность:
связать определённый сценарий ВИ хотя бы с соответствующей Сиквенс-диаграммой, раз уж нет полноценных диаграмм коммуникации.


5. Вот, хотелось чтобы требование типа
"Система должна обеспечивать до 3тыс позиций у одной товарной накладной"
Можно было явно притрассировать к мощности связи на диаграмме классов, ан-нет, -
трассировать требование можно только к "квадратику или овальчику".
Даже просто на связь сослаться трассировкой ниЗЗя, хотя требований типа
"Интерфейс Z между компонентами А и Б должен удовлетворять требованиям стандарта Х" - море.
В Визио - там есть возможность создать на линии "точку привязки"
и цеплять к ней конец другой стрелочки, неужели Архитект не даёт подобных возможностей?.


6. Требования, ишью и реквесты в ЭА нарисованы одинаковой фигурой
- наталкивает на мысль, что между ними должно быть много общего.
Не случайно, наверное, многие изобретательные разработчики приспосабливают баг-трекеры к управлению требованиями.
В СтарТиме - так там баг трекер прямо так и оперирует не с БАГом, а с чейндж-реквестом.


По РаКвесту.

1. Нет Ишьёв и чейндж-ревестОв.
Если в ЭА велось обсуждение проблемы, или было заказано изменение требования в чейндж-реквесте,
то всего этого не увидишь в РаКвесте.

2. Возможность генерации классов по элементам глоссария порадовала, но есть ли дальнейшая синхронизация?
К примеру, если я заметил грамматическую ошибку в названии соответствующего класса -  и тут же на месте её исправил,
то что нужно проделать для исправления оной в РаКвестном глоссарии?
И как я могу увидеть трассировки от требований к строчке глоссария? Есть такое в РаКвесте?
Или только в ЭА вручную проставлять трассировки от требований к соответствующему строке глоссария классу?

3. Сильно раздражает отсутсвие  прав на редактирование диаграмм зависимости требований.
Не гарантирую чистоту эксперимента, но у меня получалась такая досадная ситуация:
Открываю диаграмму зависимости требований в РаКвесте - автоматически сгененрированная картинка не нравится.
Открываю ЭА, нахожу соответствующую диаграмму, правлю расположение, сохраняю.
Открываю эту же картинку снова в РаКвесте - он снова её переделывает на свой автоматический манер.
Снова иду в ЭА, смотрю картинку там, надеюсь увидеть свой сохранённый вариант размещения алементов,
 но оказывается, РаКвест и её "подправил".

4. Какой смысл в дереве иерархии требований?
Что это за связь между ними такая, что есть в структуре дерева проекта и никак не отображается в матрице?
У меня есть свои соображения по этому поводу, опять же, как результат неявно предлагаемой разработчиками ЭА концепции.
Как дойдут руки - напишу, а пока просто не буду использовать эту возможность.


36
В каких Вы книжках это прочитали?? И как это вас спасало?

дак речь у нас не о книжках, а о "поделиться опытом" и получить критику от форумчан, в том числе и в плане есть\нет в книжках, может я велосипед изобрёл :-)

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

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

к примеру, - наша текущая ситуация:

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

а проблема, ЫМХО, в том, что теория требований
до сих пор отстаёт и не выдерживает проверки практикой.
Стоит только начать попытки её применять - как обнаруживаюся дыры,
при попытке самостоятельно залатать которые сильно рискуешь попасть на подозрение в ереси и неуважении мировых Гуру.

Чего мне стоило вытянуть признание Galogen-а:
"Коберн к сожалению относится к картинкам халатно - потому у него стрелочки теряют свою информативность"
http://www.uml2.ru/forum/index.php?topic=194.0

Чего стоят дебаты на форуме в русле "так является ли ВИ требованием по-сути?"...
Один почтенный мэтр однозначно называет ВИ требованием,
другой, не менее почтенный, указывает такие атрибуты у Требования_в_общем_виде, которых и в помине нет у ЮзКейса.
А уважаемые форумчане пытаются согласовать эти пазлы в цельную картину.
Я туда же, а мне: "где в книжке написано?" :-)
Не написано, свой дополнительный кусочек для пазлов  вырезал, :-)
чтоб согласовать написанное в разных книжках и
чтобы в своих задачах ВСЁ ВМЕСТЕ можно было СОГЛАСОВАНО на практике применять.

Но это уже явно отклонение от текущей темы.
Здесь бы справиться с намного меньшей задачей: толком изложить свой частный опыт.

Может, заведём отдельную тему:
"Известные разногласия и рассогласования мировых учений о требованиях"?

37
некоторые итоги
Galogen, очень уместная инициатива, искренне благодарен.

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

- источник требований не один Gevorg, но и обсуждения и результаты с форума,
- в документ попали только первоначальные формулировки требований, а дополнительное требование относительно
-- учёта состояния карт (от Greesh-ы) и
-- хамовитые "разъяснения" от ТОПа относительно учёта номеров бракованных карточек в упаковке (от меня)
 в документе (или приложении) не отражены.

- смарт-карта, описанная в документе - это несколько другое, отличное от того, что я изначально имел в виду и что было подхвачено Greesh-ей.
Скрэтч-карта намного более примитивная вещь, но она имеет секретный код, которого касается одно из интересных для нас в поучительном плане требование.

Нужны следующие ближайшие доработки документа:
исправить глоссарий:
- заменить описание смарт-карты на описание скрэтч-карты от Greesh-ы (2 варианта скрэтч-карт)
- добавить описание скрэтч-кода.
- добавить результаты обсуждения требований хотя бы в виде вопрос-ответ.
- добавить варианты ПЕРЕформулировок, предложенных Вами.

сорри, что перегружаю эту работу на Вас, я ещё неделю буду очень стеснён временем.

К сожалению, я сам не успел, а мои студенты так и не смогли открыть Раквестный файл с Вашими результатами, но это направление меня живо интересует, я обязательно хочу "руками посмотреть" возможности связки Раквест+ЭА.


38
В каких Вы книжках это прочитали?? И как это вас спасало?
Поясните свой ответ.
дак речь у нас не о книжках, а о "поделиться опытом" и получить критику от форумчан, в том числе и в плане есть\нет в книжках, может я велосипед изобрёл :-)

по существу вопроса: откуду такие конструкции?
так от практики с нашими любимыми средствами работы  с требованиями, в частности, от ЭА:

там есть в явном виде объекты под названием "требования" и отдельно - ЮзКейсы и другие элементы UML-моделирования,
да ещё и трассировочные связи между ними обеспечиваются.

да и Борландовские продукты (CaliberRM and StarTeam) работают с требованиями и ЮзКейсы таковыми не называют, а согласовать это очень хочется...

вот и родилась описанная конструкция.

39
И вообще дайте плиз определение антипрецеденту, или ткните где почитать.
http://www.osp.ru/os/2005/04/185537/
не гуру, конечно, но идея мне понравилась

40
А не легче тут выделить ВИ включения или расширения? И сосредоточится на детализации каких-то шагов ВИ? Зачем по 10 раз все переписывать?
не легче
Гуры настоятельно советуют НЕ прегружать ВИ глубокой детализацией.
кроме того - функциональная детализация мне видится принципиально отличной от концепции ВИ, а соответственно, и место ей в другом документе, с другой структурой.
мне очень понравился термин "ортогональность" понятий ВИ и функции в одной из тем на форуме.

41
вот, прочитал в соседней теме:
------------------------------------------------------
bas  Re: И все таки вариант использования - это функция :P
---------------
ВИ - это пользовательские требования, как написано, например, у Вигерса.
------------ -------------------------------------------------
так у меня здесь всё та же наработка
В первую очередь нужно описать свою концептуальную наработку:
Разнесение понятий элемента модели и требования на каждом из уровней.
Меня этот принцип особенно выручал на 2-х верхних уровнях: бизнес и пользовательском.
Для меня ВИ - это не совсем требования, это элементы модели уровня пользовательского взаимодействия с системой.
А требования - это:
RQ№ххх,
Уровень: пользовательский,
Автор: Analyst1,
Источник: должностная инструкция Менеджеру отдела Х,
Необходимость:....
Описание: должен быть реализован ВИ000ХХ.
и т.д.

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

кстати, посоветуйте, как правильно вставить цитату из соседней темы?

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

это очень близко моему опыту:
функциональные требования к разрабатываемой системе уровня пользователей (использование системы)
- однозначно в ВИ,

далее по ним - строю функциональные требования системного уровня,
а именно так:

собираю все строки сценариев, начинающиеся "Система(в ответ на пред-й шаг пользователя)...чего-то делает"

НО! Строю по ним ДРУГУЮ, логичную с т.зр. зависимостей функций, без учёта логики работы отдельных пользователей.

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

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

за выходные или на след неделе выложу соответствующее продолжение в тему об управлении требованиями.

43
В первую очередь нужно описать свою концептуальную наработку:
Разнесение понятий элемента модели и требования на каждом из уровней.
Меня этот принцип особенно выручал на 2-х верхних уровнях: бизнес и пользовательском.

Поясню это по ходу изложения своей классификации наших требований по уровням.

Итак, требование
1. Система должна обеспечивать учёт скрэтч-карт.

Какую проблему должно закрывать его удовлетворение?
- Карт много, менеджеры не справляются с учётом.

Какая модель, на которую должно опираться требование?
- Текстовое описание бизнеса у Заказчика (не случайно его отсутствие так возмущало Greesh-у).

Какие элементы этой модели связываем с Требованием1 вообще и с его Проблемой в частности?
- Строчки из описания бизнеса:
-- Ведётся учёт скрэтч-карт.
-- На д.м. оборот: 10тыс карт в месяц, планируется – 200тыс.(привязываем к проблеме)
-- Скрэтч-карта имеет номер и БАР-код этого номера.

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

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

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

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

Это ни в коем случае не в пику Greesh-е, а  в прояснение сути кажущегося противостояния наших позиций.
- С одной стороны, пробелы и противоречия в представлениях о бизнесе Заказчика  - неизбежное явление на всех стадиях разработки.
Рвение и максимализм аналитиков к максимальному прояснению картины и устранению противоречий часто приводит к ситуации, когда Разработчик вынужден выполнять для Заказчика бизнес-анализ и бизнес-дизайн.
И самое страшное не то, что Разработчику приходится это делать за свой счёт, а то, что этим он вторгается в “чужую парафию”, становится эдаким агрессором-обличителем по отношению к Заказчику, который и от себя-то скрывает дыры в своём бизнесе, а тем более – будет всячески саботировать обнародование их в документах от Разработчика.

- с другой стороны, - требования не могут “болтаться” в воздухе, они обязательно должны опираться на модели соответствующих уровней (уровень проблемы и уровень решений по ней). На начальных этапах сбора и анализа требований не следует ожидать, что такие модели будут цельными, согласованными, полными, - приходится  довольствоваться тем, что объективно есть на текущий момент и выжимать из него всё, что можно. 

44
Уважаемый Gevorg, мы все Вас с нетерпением ждем. Будет ли продолжение урока? все-таки интерес к теме 1615 просмотров
thnx всем писателям и читателям темы за интерес,
продолжение обязательно, уже есть части.

к сожалению, не успеваю собрать их в нечто цельное,
буду от правлять по частям, как есть

45
Но наверное это неизбежный процесс притирки, а может gevorg нас проверял.

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

С целью проявить те стороны требований, с которыми можно и следует работать даже в такой ситуации, ещё до того, как будет получено общее понимание.

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

Страницы: « 1 2 3 4 5 6 7 8 »