76

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

« : 13 Ноября 2007, 17:56:03 »

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

Появление новых требований в этой схеме тоже возможно.
Вот приблизительный возможный сценарий:

Для начала роли персон андер дискашшинз:
- Менджер требований (RM): центральная фигура, в фокусе нашего внимания,
- Дизайнер требований (RD): некий Умный и Всезнающий Дядя (УВД), способный закрыть любую дыру в проблемах с требованиями. Как работает - неизвестно, Что делает - не понятно, но проблему решает любую.
- Представитель Заказчика (CR): некая совсем уж обобщённая роль для любых действий, предполагаемых от Заказчика.

1. (CR): Звонит на фирму, просит выслушать его очередную хотелку.
2. (RM):
- Принимает звонок,
- регистрирует новое требование во внутренней системе управления Требованиями (СУТ).
- Признаётся, что ничего не понимает в словах (CR)-а,
- договаривается с ним и
- регистрирует в СУТ задачу для (RD): провести интервью и извлечь требование:
    "Поди туда, ЗНАЮ, куда, - возьми то, НЕ_ЗНАЮ, что.
3. (RD):
- Проводит интервью,
- уж неизвестно как изощряется, но
- приносит формулировку нового требования,
- его классификацию и связи с другими.
4. (RM):
- регистрирует выполнение задачи (RD)-мом,
- Регистрирует принесённые результаты в СУТ,
- обнаруживает, что (RD) забыл определить список заинтересованных лиц,
- ПЫТАЕТ оного по данному вопросу.
5. (RD):
- отделывается выбором заинтересованных лиц из списка уже имеющихся в СУТ,
- отбивается, чтобы не решать задачу формулировки их интересов по данному требованию.
6. (RM):
- регистрирует заинтересованных лиц, фиксирует напоминалку, что список заинтересованных лиц не проверен на полноту,
- регистрирует напоминалку, что список интересов по требованию не определён,

77

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

« : 13 Ноября 2007, 17:09:01 »

Gevorg? давай уж эти свои 10 требований и начнем их обсуждать. Я буду с использованием раквеста чур...

Вот, на вскидку:

1. Система должна обеспечивать учёт скрэтч-карт.
2. Система должна поддерживать интеграцию с Клиент-Банком.
3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.
8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.
10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
12. Необходима интеграция с внешними системами считывания бар-кодов.
13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

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

Набросок списка первых заданий студенту:
- классифицировать требования по 3-м уровням.
- Определить наличие и тип простейших зависимостей между требованиями одного уровня (детализация\агрегирование).
- Определить наличие связей проблема-решение между требованиями различных уровней.

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

78

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

« : 13 Ноября 2007, 15:05:55 »

Т.е. производством мы не управляем?

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

А я полагал, что для дизайна выходной продукт - решение.
Да, конечно, между требованием и решением много общего.

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

79

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

« : 13 Ноября 2007, 14:31:30 »

Легко придумывались штук 300 требований? ...
- может сразу все сделать и выдать готовый результат? :-)

Именно это я и предлагаю: "выдать готовый результат", в смысле - сАми требования.
И дальше - показать студенту, что даже когда требования УЖЕ классно описаны и связи между ними - определены
-- Всё равно остаётся куча проблем в работе с ними.
Их решение - и будет предметом курсовой работы именно по УПРАВЛЕНИЮ требованиями.

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

так мы о теории говорим или о практическом опыте?
Проблема, ещё какая проблема! И не одна.
Только не научные эти проблемы, а инженерные и манагерские.
Согласования терминов и сути в наборе из различных, но тесно связанных технологий,
Интеграция средств автоматизации,
Регламентирование и документирование самого процесса,
Саботаж персонала.

Если честно я не очень понимаю в чем проблема связи требований?

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

Значит справедливо и утверждение - использование систем управления требованиями - по сути не научит делать требования и управлять ими.

ЫМХО, справедливы след.2  утверждения:

использование _ПО_ для управления требованиями - по сути не научит делать требования и управлять ими.

использование _КОНЦЕПТУАЛЬНОЙ СИСТЕМЫ_  как раз-то и научит делать требования и управлять ими как по-сути, так и по-форме.

80

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

« : 13 Ноября 2007, 13:45:56 »

Gevorg, Вы это greesha  в пику или в одобрение казали?

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

а по сути вопроса, так однозначно - одобрение,
очень стОящее свойство требования, хорошо, что greesha напомнил

81

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

« : 13 Ноября 2007, 13:29:16 »

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

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

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

82

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

« : 13 Ноября 2007, 13:05:23 »

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

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

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

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

83

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

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

Вообще по классике, управление нуждается в объекте управлением - в данном случае требованиями и определяется функциями: сбор, учет, контроль, анализ, прогноз, планирование, оперативное управление (изменение), организация и координация, доведение до исполнителя.

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

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

Кроме того в РУП записано: "управление требованиями - систематизированных подход к поиску, документированию, организации и отслеживанию изменчивых требований к системе" К.Ларман "Применение UML2 и шаблонов проектирования" 3-е издание. М.:Вильямс, 2007, стр. 90

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

Напомню, что по ГОСТ ТЗ пишет разработчик. Понятно что требования поступают извне, не нам же их придумывать самим.

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

     ...не нам же их придумывать самим.

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

Вообще по классике, управление нуждается в объекте управлением - в данном случае требованиями

а поскольку управление требованиями идёт в контексте комплексного управления ВСЕМИ объектами процесса управления разработкой ПО,
то здесь же следует рассматривать и контекст из других объектов, так или иначе связанных или связываемых с требованиями.


если пойти дальше в распутывании терминологической паутины, то мне видится такое:
процесс разработки ПО состоит из:
- производственного процесса, для которого требование является
-- артефактом (в моём примитивном понимании - продуктом), и
- процесса управления, для которого требование - один из
-- объектов управления.

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

84

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

« : 13 Ноября 2007, 11:32:45 »

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

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

85

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

« : 13 Ноября 2007, 11:20:01 »

такой подход интересный, только почему по сути тоже самое?

по сути процесса обучения :-)

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

в нашем примере нужно осваивать
- процесс управления требованиями,
- с помощью инструмента....?

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

86

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

« : 13 Ноября 2007, 11:00:11 »

А вы не путаете управление требований с управлением проектом или процессом разработки в целом?

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

87

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

« : 12 Ноября 2007, 19:36:05 »

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

Ну возможно. А что с бумагой и нелиновоной тут делается?

да по-сути, то же самое, что и при обучении ЮМЛу или бухгалтерии:

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

студент вынужденно остаётся без подсказок, а концепция, которая должна уложиться в его голове - без костылей и подпорок

88

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

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

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

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

89

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

« : 12 Ноября 2007, 19:05:21 »

А что есть дизайн?

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

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

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

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

90

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

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

Думаю стоит описать в кратце процесс в рамках которого использовалась интеграция инструментария.

вот, собрал осколки документации, да ещё и не последней версии, но приблизительную картину должно дать