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

×


Управление требованиями(Прочитано 190539 раз)
Re: Управление требованиями Ответ #15 : 07 Ноября 2007, 18:04:56
Gevorg,

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



Re: Управление требованиями Ответ #16 : 07 Ноября 2007, 19:44:37
Gevorg,
Надеюсь, Вы присоединитесь к нашему ноябрьскому семинару и поделитесь своим опытом во время дискуссии.
Дак я ж в Киеве работаю :-(



Re: Управление требованиями Ответ #17 : 07 Ноября 2007, 19:49:26
Жаль.
Дак я ж в Киеве работаю :-(
Жаль... Надо делать транслирование через веб, а то много народу из др. городов остается не охваченным
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Управление требованиями Ответ #18 : 07 Ноября 2007, 20:24:21
Интересный опыт. Gevorg

2. Без системы управления версиями реального мнеджмента требований - нет, есть только игрушка.
Версионность требования - раньше трассировки.
насколько я понимаю - это фиксация baseline? Если да например в RaQuest есть такой инструмент как сохранения таких baselines и версионный контроль.

Цитировать
3. Трассировка между требованиями - задача менее приоритетная,
чем трассировка от требования - к коду и тест-кейсу, которые это требование закрывают и проверяют,
и к проектным задачам, имеющим какое-то отношение к требованию.
В RaQuest вместе с EA существует многопрофильная трассировка. Требования к требованиям. Требования к вариантам использования, Требования к элементам UML, где в качестве элементов могут выступать и тест-кейсы.

Цитировать
6. Те же знающие люди рассказывали легенды про решение аналогичной мощности на базе интеграции СабВершин-Джира-Телелоджик Дорз.
Но доработки по обеспечению этой интеграции обошлись компании в хорошую копеечку.
Да цена на ДООРС неслабая. Но как инструмент - действительно можная вещь. особенно в интеграции с System Architectи другой линейки от Telelogic. Но цены....




Re: Управление требованиями Ответ #19 : 08 Ноября 2007, 14:43:31
насколько я понимаю - это фиксация baseline? Если да например в RaQuest есть такой инструмент как сохранения таких baselines и версионный контроль.
дак и в калибере baselines имеют место быть, НО практика показала, что:
 нужен ЦЕНТРАЛИЗОВАННЫЙ версионный контроль всех артефактов
(в нашем случае мне пришлось вести целую войну с отщепенцами-аналитиками, чтобы приучить их хранить версии своих требований в StarTeam-е - общем для всех хранилище артефактов ),
благо - из Калибера можно вызывАть Стартимовские формы для работы с требованиями и строить в ём матрицу трассировки как между родными элементами, так и между хранящимися в СтарТиме.
Между прочим, Питерцы тоже столкнулись с этой же проблемой, только решили её заранее и кардинально:
Увидели, что аналитики сторят свой отдельный курятник - и полностью закрыли им работу в Калибере.


поймите меня правильно: я отнюдь не апологет Борландовских продуктов, они мне достались без каких-либо вариантов выбора и намучился я немеряно.
Многое из очевидной функциональности приходилось либо конструировать на механизме дополнительных пользовательских полей и ручной работы с ними,
либо дорабатывать свои "примочки".
Но в этом процессе родилось понимание как общеметодических принципов так и преимуществ Борландовской ALM-концепции и пакета приложений для её реализации.

Так вот, все красивости Калибера (трейс-мэтриксы, бейз-лайны, дизайн-туллзы) оказались менее знАчимыми, чем возможность требованиям "жить" в одном хранилище с другими артефактами.

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

В RaQuest вместе с EA существует многопрофильная трассировка. Требования к требованиям. Требования к вариантам использования, Требования к элементам UML, где в качестве элементов могут выступать и тест-кейсы.
А вот это действительно замечательно в Архитекте и чего нет в помине у Борланда:
Создать требование, а потом "показать пальцем" на соответствующий элемент поясняющей диаграммы - это круто.
EA рулит своей гениальной простотой:
- есть ЮМЛ-модель, состоящая из Элементов,
- для модели есть проекции-вьювы: диаграммы,
- есть возможность связать трассировочной связью требование и соответствующий набор Элементов Модели,
- если для требования нет специально разработанной диаграммы, (которую тоже можно при желании притрассировать к требованию),
- то для каждого из притрассированного к требованию элемента модели остаётся возможность увидеть список диаграмм, где он присутствует и выбрать подходящую диаграмму для просмотра.

НО! вспомним пункт из моего предыдущего поста:
Менеджмент требований раньше дизайна!
Т.е. многопрофильная трассировка раньше нужна для связывания ВЕРСИЙ задач, результатов их выполнения и результатов тестирования в их самом простом виде, но в комплексе.

Насколько я знаю - версионность для ЕА - вещь внешняя, хотя и возможная в интеграции с другим соответствующим туллзом.

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

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



Re: Управление требованиями Ответ #20 : 08 Ноября 2007, 17:56:07
нужен ЦЕНТРАЛИЗОВАННЫЙ версионный контроль всех артефактов
Мне кажется, в случае с EA это может прокатить, только если задействовать его же менеджерские вещи - issue, tasks. И все это вогнать под бейзлайны, но такое может и не получиться, не копалась.
Насколько я знаю - версионность для ЕА - вещь внешняя, хотя и возможная в интеграции с другим соответствующим туллзом.
У них есть внутренняя версионность по пакетам. но она не такая удобная, как поэлементная.
В общем, есть над чем подумать.
Cпасибо, Gevorg!



Re: Управление требованиями Ответ #21 : 08 Ноября 2007, 18:29:44
Но в этом процессе родилось понимание как общеметодических принципов так и преимуществ Борландовской ALM-концепции и пакета приложений для её реализации.
А поделиться пониманием? Надо же формировать качественный контент на сайте. Отличная задача. Хотя понимаю - время!

Цитировать
Вот и получается, что для проджект-манагера и других тим-мемберов нужно вначале обеспечить возможность комплексной работы с требованием в самой примитивной форме его существования: текстовое описание.
А уже потом, для "избранных", давать возможность дизайна: моделирования и трассировки требований к элементам модели.
Насколько я знаю - эволюция Телелоджиковских продуктов  тоже шла по этому пути: вначале были абзацы текста со своими ИД-шками и линками на другие абзацы, а диаграммы с моделями появились намного позже.
Насколько я понял в RaQuest есть именно возможность работы с текстами требований до дизайна. Причем как в собственном типе файла, так и в интегрированном. Правда RaQuest имхо сыроват еще, многие функци обозначены, но не реализованы.



Re: Управление требованиями Ответ #22 : 08 Ноября 2007, 19:34:37
Цитировать
Чаще всего используются старые добрые блок-схемы алгоритмов, в том числе в тех ситуациях, где вроде бы самое подходящее место для вариантов использования.
А например?

Читаю очередные обновления спецификаций EMV, увидел блок-схему и вспомнил это "например".
http://emvco.com/documents/bulletin/view/AN35_Draft%20DCC%20Clarification%20v1.0.pdf

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Управление требованиями Ответ #23 : 08 Ноября 2007, 20:45:58
По этим спецификациям, без преувеличения, работают десятки (если не сотни) тысяч людей. Блок-схемы ещё очень нескоро "выйдут из моды".
А кто спорит. Вещь надежная. Структурный подход однако никто не отменял. а компутеры в реале последовательные машины Тьюринга пока :)



Re: Управление требованиями Ответ #24 : 08 Ноября 2007, 23:59:50
2Gevorg
Если честно, не припомню вас в клиентах Борланда, которые бы к нам в офис обращались с такой проблемой в 2006 г :-). Второй важный вопрос, какие версии инструментария вы использовали ... ? Кстати, у Борланд был написанный консультантами неплохой модуль интеграции с MS Project :-) ... при соответствующих коммуникациях с нами, этот модуль можно было получить забесплатно :-). Еще один вопрос -- так это собственно КАК у вас был организован процесс разработки ПО и КАКУЮ отчетность вы собирали ... т.к. действительно можно придумать множество отчетов, которых нет ни в одном инструментарии.
Насчет доработки -- которая стала в копеечку я не скажу, таки зависит от того что вы хотели делать :-) ... но я написал через API на Delphi off-line клиента для Caliber 2005 SP2 с базовой функциональностью за неполных 3 дня :-).
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Управление требованиями Ответ #25 : 12 Ноября 2007, 12:54:14
Если честно, не припомню вас в клиентах Борланда,
которые бы к нам в офис обращались с такой проблемой в 2006 г :-).
дак и не были мы в клиентах Борланда, токо теребили шефа насчёт покупки стартима :-(
"Дельпи", правда, был честно куплен, ещё в 90-ых, задолго до меня.

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

так они затянули довгу чумацьку пісню:
"Вы нам опишите в почту техническую суть Ваших вопросов - мы перешлём в Москву...." ну, и далее - понятно.

Нашёл Питерцев, у которых СтарТим был честно куплен американским хед-офисом и навязан всем филиалам, у них и через них
в Борландовском саппорте справлялся по техническим деталям.


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

А свою интеграцию Борландовских продуктов мы делали своими силами, как полагается, "топором и на коленях". :-(
Не знаю, стоит ли сразу выносить на форум обсуждение технических деталей по граблям, на которые пришлось понаступать?
Может, для начала лучше в почту, а уж полезные результаты - на форум, для общественности?



Re: Управление требованиями Ответ #26 : 12 Ноября 2007, 13:28:37
А поделиться пониманием? Надо же формировать качественный контент на сайте. Отличная задача. Хотя понимаю - время!
Вот, пытаюсь.

А насчёт времени -так точно:
два предыдущих поста с самыми поверхностными тезисами - в сумме 2,5 часа затянули, специально время засекал :-(

Искренне изумляюсь, как участники форума успевают вести такую обширную переписку:
тут читать не успеваешь, а они успевают написать.....




Re: Управление требованиями Ответ #27 : 12 Ноября 2007, 13:59:57
(речь шла о блок-схемах вместо вариантов использования), ....
   ... Блок-схемы ещё очень нескоро "выйдут из моды".

ЫМХО: Активити-диаграммы в UML - есть результат эволюции блок-схем.

А я всю свою сознательную жизнь Аналитика писал текстовые сценарии в описаниях ВИ исключительно в ключе прямого мэппинга каждого шага сценария на  квадратик в диаграмме активности.
Была даже одна курьёзная, но реальная задача на работе: убрать из ТЗ блок-схемы и заменить их текстовыми описаниями в стандарте ЮзКейсов(!!!)
Заказчик наотрез отказывался изучать блок-схемы, описывающие логику взаимодействия Пользователя с Системой, - и легко принял UC-стандарт текстовых сценариев :-)

Для меня активити-диаграмма, объединяющая сценарии по одному или нескольким близким Юз-Кейсам, всегда была естественным следующим шагом уточнения требований после написания ВИ-шек.

Так что в этом смысле для дилемма ВИ\блок-схема вообще не стоит:

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



Re: Управление требованиями Ответ #28 : 12 Ноября 2007, 14:25:59
Кстати, у Борланд был написанный консультантами неплохой модуль интеграции с MS Project :-)
... при соответствующих коммуникациях с нами, этот модуль можно было получить забесплатно :-)
Был у нас этот модуль, где-то админ заполучил.
Действительно, замечательная штука, благодаря ей таски заносили в Проджекте и экспортились в СтарТим для трейсинга с остальными объектами процесса разработки:
Версиями Требований, Версиями ТестКейзов, Версиями исходников и версиями сборок.

И даже механизм обратного экспорта из СтарТима в Проджект данных по прогрессу выполнения тасок укротили:
реально программеры заносили свои трудозатраты в Works-ах по Task-ам в StarTeam-е, и это всё дело синхронизировалось с ходом выполнения задач в Проджекте.

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



Re: Управление требованиями Ответ #29 : 12 Ноября 2007, 15:08:19
ЫМХО: Активити-диаграммы в UML - есть результат эволюции блок-схем.
Так что в этом смысле для дилемма ВИ\блок-схема вообще не стоит:
- одно другому не противоречит, а второе является результатом развития первого,
- первое - ближе Заказчику, второе - Разработчику,
- в зависимости от специфики проекта, одного из них может не быть.
Согласен. Но применять диаграммы видо деятельности или нет должно истекать из того, оправдано это или нет.

Если ВИ достаточно прост и понятен, вряд ли стоит его фиксировать в виде ДД. Ведь это все-таки лишняя работа. И кто-то за нее платит. Если же ВИ большой с развитой структурой алтернатив и исключений - тут вероятно без ДД сложнее.

Опять же ДД может и предшедствовать ВИ. Есть такой интересный пример у Шмуллера "Освой UML за 24 часа".
Аналитик берет интервью у администратора и по ходу дела рисует ДД. Затем по ДД рассказывает ему, что он понял и администратор вдруг видит какие-то слабые или некорректные места.

Анализ же ДД позволяет выделить задачи участников и скомбинировать из этой большой ДД массу ВИ и соотвественно небольших ДД.

Т.е. сначала ДД используется на уровне бизнеса, как некая сложная комбинация блок-схемы, IDEF3 и возможно DFD.

Затем реализуются уже ВИ к системе и соотвественно ДД системы.

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

Например в VP-UML даже есть инструментарий перевода ВИ в системную диаграмме последовательности. Правда ВИ нужно набиратьпрямо в спецификации ВИ (там используется табличный шаблон ВИ). При этом поддерживается round-trip сопровождение. Но это естественно касается анализа требований. А не самого формирование требований




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19