91

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 18:35:42 »

- ДД СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.
Т.е. Вы полагаете - это зер гут? А почему если не секрет

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

92

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 18:22:28 »

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

 Предположим я буду использовать RaQuest или нечто другое

Гиблое это дело: одновременно учить студентов концепциям и средству автоматизации...
если хотим научить, что такое Требование и как им управлять - бумагу с карандашом в руки, да ещё и нелинованную :-)
И ДУМАТЬ-ДУМАТЬ-ДУМАТЬ, а компьютер - отобрать, чтоб не мешал.

93

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 18:13:18 »

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

Главное мне не очень понятно с чего все-таки начать.

Прежде всего - уточнить программу, чтобы она соответствовала названию практикума:
- управление требованиями (2 уровень СММ)
- или дизайн требований (3 уровень СММ)

а то в названии - управление,
а в программе - и то и другое

94

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 18:07:46 »

особенно когда ВИ сложный

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

95

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 17:10:31 »

Согласен. Но применять диаграммы ВИ до деятельности или нет должно истекать из того, оправдано это или нет.

А "оправданность" использования нужно оценивать из того, что требует бОльшей проработки:
контекст процесса или сам процесс.

Хочу обратить внимание на "рулёзные" особенности ВИ:
- хорошее, а местами - единственное в своём роде, описание  КОНТЕКСТА процесса: пред-, пост-условие, ДЛ-ы, Заинтересованные Лица с их интересами и т.д.
(единственное в своём роде - в том смысле, что других мест для описания всего этого в стандартах на структуру соответствующих документов иногда вообще нет)
- СОЗНАТЕЛЬНО снижены требования к строгости и детальности описания САМОГО процесса.

В противовес(а точнее - в дополнение) к ВИ, ДД рулит:
- обеспечивает строгость и наглядность представления именно ПРОЦЕССА,
- даёт возможность учитывать в явном и стандартизированном виде поток входных\выходных объектов, да ещё и отслеживать их состояния на входе и на выходе каждой активности,
- показывает исполнителей каждой активности (свим-лайны),
- СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.

96

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 16:53:52 »

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

тогда точнее будет так:
- сначала ДД или БВИ на бизнес-уровне, а затем
- снова ДД или СВИ на уровне пользовательских требований?

всего по комбинаторному принципу получается 4 возможных варианта :-)

97

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 14:25:59 »

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

Был у нас этот модуль, где-то админ заполучил.
Действительно, замечательная штука, благодаря ей таски заносили в Проджекте и экспортились в СтарТим для трейсинга с остальными объектами процесса разработки:
Версиями Требований, Версиями ТестКейзов, Версиями исходников и версиями сборок.

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

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

98

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 13:59:57 »

(речь шла о блок-схемах вместо вариантов использования), ....
   ... Блок-схемы ещё очень нескоро "выйдут из моды".

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

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

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

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

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

99

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 13:28:37 »

А поделиться пониманием? Надо же формировать качественный контент на сайте. Отличная задача. Хотя понимаю - время!

Вот, пытаюсь.

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

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

100

Системный Анализ и Требования / Re: Управление требованиями

« : 12 Ноября 2007, 12:54:14 »

Если честно, не припомню вас в клиентах Борланда,
которые бы к нам в офис обращались с такой проблемой в 2006 г :-).

дак и не были мы в клиентах Борланда, токо теребили шефа насчёт покупки стартима :-(
"Дельпи", правда, был честно куплен, ещё в 90-ых, задолго до меня.

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

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

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

Насчет доработки -- которая стала в копеечку я не скажу, таки зависит от того что вы хотели делать :-)

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

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

101

Системный Анализ и Требования / Re: Управление требованиями

« : 08 Ноября 2007, 14:43:31 »

насколько я понимаю - это фиксация baseline? Если да например в RaQuest есть такой инструмент как сохранения таких baselines и версионный контроль.

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


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

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

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

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

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

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

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

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

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

102

Системный Анализ и Требования / Re: Управление требованиями

« : 07 Ноября 2007, 19:44:37 »

Gevorg,
Надеюсь, Вы присоединитесь к нашему ноябрьскому семинару и поделитесь своим опытом во время дискуссии.

Дак я ж в Киеве работаю :-(

103

Системный Анализ и Требования / Re: Управление требованиями

« : 07 Ноября 2007, 17:18:35 »

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

Мне повезло на прошлой работе в этом смысле:
- Софтовая фирма,
- один постоянный Заказчик,
- основная масса работ - сопровождение унаследованного ПО,
- ПО реально необходимо, активно и широко используется,
- требования на доработки поступают постоянно и в большом количестве,
- сроки их реализации очень жёсткие,
- ситема большая, досталась в наследство от нескольких компаний-разработчиков,
- сотавляющие компоненты разнородные по всем направлениям: среда разработки, культура разработчиков, архитектурные принципы,
- что их объединяет: общий заказчик-потребитель, общая предметная область, общий на данный момент разработчик,
- но сами требования на доработку достаточно простые и маленькие по объёму.

От руководства пришло задание: сконструировать и внедрить автоматизированный процесс управления всем этим зверинцем.
StarTeam и Caliber, как инструменты, были в качестве необсуждаемой данности.

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

1. Опытно проявилась правильность принципа из CMMi: управление требованиями осваивается на ступеньку раньше, чем дизайн требований.
процесс управления требованиями уже был поставлен и даже был принят аналитиками, а до толкового дизайна, тем более - с использованием диаграмм, - было ещё ой как далеко.
Самое кино было в том, что наиболе резвые из аналитиков ухватились за Caliber, как за свой родной инструмент, и давай его активно применять для всего, чего угодно, кроме главного: дизайна требований.
Ладно,управление требованиями, - это родное,
но умудриться притянуть за уши Caliber для менеджмента проектных задач, учёта трудозатрат исполнителей и в качестве системы управления версиями всех артефактов - это уже было слишком.
Ещё раз, "опыт военных действий" подтверждает теорию: менеджмент требований осваивается раньше, чем дизайн оных.

2. Без системы управления версиями реального мнеджмента требований - нет, есть только игрушка.
Версионность требования - раньше трассировки.

3. Трассировка между требованиями - задача менее приоритетная,
чем трассировка от требования - к коду и тест-кейсу, которые это требование закрывают и проверяют,
и к проектным задачам, имеющим какое-то отношение к требованию.

4. Заявленная Борландом совместимость приобретённых продуктов для пресловутой полной поддержки цикла ALM на деле имеет кучу хомутов и граблей.
Нужно крепко исхитриться, чтобы заставить эти средства (в моём случае: StarTeam, Caliber, Delphi, MS-Project) согласованно работать по обеспечению цикла разработки ПО.

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

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

104

Нововведения / Re: Процесс обратной семантической трассировки

« : 06 Ноября 2007, 18:24:41 »

Там какой-то подвох. Либо архитекторы так глубоко знают UML, что он им окончательно заменил естественный язык ,
либо круг задач ограничен так, что все базовые решения по архитектуре уже приняты (или тривиальны).

может, всё-таки, не подвох, а жёсткая мера, аналогичная принципу проведения мозгового штурма (на время генерации идей - никакой критики)?

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

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

105

Нововведения / Re: Процесс обратной семантической трассировки

« : 06 Ноября 2007, 16:38:23 »

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

Да нет особой гарантии, но есть опытное подтверждение того факта, что
записанное со слов Заказчика и переформулированное Аналитиком описание требований даёт одновременно и дополнительный и новый взгляд Заказчику на его требования.
Это даёт дополнительный шанс как-то "зацепить"эти коварные стеллс-требования, которые очевидны для Заказчика и полностью упущены Аналитиком.
Чаще всего это удаётся, когда Аналитик хотя бы малой частью СВОЕГО описания цепляет стеллс-требование и это малое описание оказывается НЕ совпадающим с представлениями Заказчика.
Вот тут нужно цепко хватать и разрабатывать эту золотую жилу.
 

Согласен, если по модели в точности восстанавливается её текстовое описание - тоже есть шанс, что стеллс-требования в скрытом виде будут присутствовать и в модели.
Но во-первых, - это далеко не факт, а во-вторых, они всё равно продолжают оставаться НЕзамеченными Аналитиком!


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

Я хотел обратить внимание, что ещё ДО проблем с наличием стеллс-требований, есть другие, не менее болезненные и коварные:
- неоднозначность понимания требований Заказчиком и Аналитиком,
- несогласованность требований "в недрах" самого Заказчика.

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