4741

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

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

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

4742

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

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

Помещу, вот ссылочку чтобы не забыть: http://www.pmexpert.ru/services/training/moscow/detail.php?ID=107.

Ключевое слово для будущего поиска: рюшечка

4743

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

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

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

Почему добыча требования - это его дизайн?

процессов по оценке качества, упаковке, маркировке, транспортировке, хранению (менеджмент требований)

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

для дизайна - выходным продуктом.

А я полагал, что для дизайна выходной продукт - решение. Видимо неверно полагал.
Да, конечно, между требованием и решением много общего. Денис (Майевтик) тут высказывал такую идею и обосновывал ее состоятельность. Но мне как-то это не по зубам, видимо. Требования результат дизайна?

- акцент на систематизированность подхода,

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

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

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

 

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

Ну это возможно и это никак не противоречит намшей дискуссии

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

Да вообщем, тут и обсуждать нечего - совершенного естественно. Тем более, что в рамках итеративного подхода требования определятся практически на всем протяжении проекта.

- производственного процесса, для которого требование является
-- артефактом (в моём примитивном понимании - продуктом), и

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

4744

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

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

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

Вашими бы устами да мёд пить.

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

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

Мне кажется есть проблема извлечения, формулировки требований.

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

Я конечно понимаю Ваш тезис. Главное не в навороченности системы, красивости и удобстве ее. Главное в умение и понимании, а оно безусловно достигается не использованием инструментов, хотя и помогает этому.

Изучая UML(в графическом его смысле), совершенно нельзя научиться объектному проектированию.

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

4745

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

« : 13 Ноября 2007, 13:36:43 »

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

4746

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

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

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

Гриша, ну и что Вы испугались? Надо было продолжать и дело с концом. У меня такое частенько бывает, когда я пишу ответ и появляется некоторое новое сообщение. А то что не сохранил изменения - богу весть.

4747

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

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

- правильно его изложить, как есть,

Да думаю именно так и нужно - это будет опорная точка

- проанализировать и выделить действительно стОящие части,

т.е. те интересные фишки, которые стоит развивать?

- оформить их в удобном для пользования другими.

Будет нужна помощь, обращайтесь

4748

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

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

Gevorg, на самом деле любой опыт полезен:
а/ если он верный - то им можно воспользоваться
б/ если в нем есть ошибки - то их можно понять

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

Я поднял эту тему, поскольку попытался осмыслить, а что есть управление требованиями вообще. Как, когда и с помощью чего его применять на практике. И обнаружил, что вопросов больше, чем ответов. Более того - даже не сумел опеределиться, а когда же оно начинается и как выражается...

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

4749

Sparx / Re: Enterprise Architect: Практика использования

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

Оказывается нашел.

Делается так.

На желаемой диаграмме, где по смыслу следует разместить ссылку, из меню проекта перетаскиваете например ВИ Закрыть счет и делаете симпл линк.

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

Далее правой кнопкой по Note Link и выбираем Link this Note to Element Feature. Появится окошко, в нем этих фич как тарканов. Ищем нужный фич (думаю он контекстный) - выбираем Scenario, там появится список нужных нам сценариев. Усе дело сделано.

4750

Sparx / Re: Enterprise Architect: Практика использования

« : 12 Ноября 2007, 20:31:57 »

В ЕА есть такая фишка как привязка Note в внутренним элементам.

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

Экспериментируя я удалил это связку типа, пытался восстановить. Облазил справку, но так и не понял как сделать этот самы Linking Note to Internal Elements.

А фишка очень удобная. Меняешь этот самый элемент, а заметка тутже отображает его изменение

4751

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

« : 12 Ноября 2007, 19:56:40 »

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

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

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

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

такой подход интересный, только почему по сути тоже самое?
Вообще напридумывать кучу требований на 30 студентов - это очень сложная по-моему задачка.
Далее, естественно при чтении этих требований логика комбинации у всех своя, и варианты возможны самые разнообразные.
У нас уже с этим были проблемы. Преподаватель дал задачу - некий набор существительных и глаголов и сказал постройте семантические связи. Ну все стали строить: кто-то выбрал в качестве критерия минимальность связей, кто-то сделал группировки по своему. В результате оценка у всех 2 - типа не сходится с ответом у преподаателя.
Например еще, в рамках задачи были заданы такие слова музыка медведь сцена. Практически все написали, что типа цирк приехал и медведь танцует на сцене - всем 2. Поскольку преподаватель сказал, что какие вы дураки, какой медведь. Это группа "медведь" выступала.

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

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

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

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

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

4752

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

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

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

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

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

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

4753

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

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

- или дизайн требований (3 уровень СММ)

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

4754

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

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

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

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

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

4755

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

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

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

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

Выбрать неочень сложную, но обязательно коллективную задачу. Обыграть роли, распределить обязанности и посмотреть, что из этого получиться. Здесь я буду работать примерно неделю по 5-6 академических часов в день. так что следует успеть.

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

Главное мне не очень понятно с чего все-таки начать.Предположим я буду использовать RaQuest или нечто другое (будет зависить от возможности приобретения лицензии на вуз, личная у меня есть).

В самом общем понимании что нужно будет делать:?
1. осуществить сбор требований
2. осуществить извлечение требований
3. осуществить ранжирование требований
4. осуществить моделирование части требований
5. осуществить фиксацию базовой линии

Предположим бизнес-цели или цели создания у нас будут поставлены.
мы будим формировать Видение. Сразу вопрос имеет ли смысл фиксировать бизнес-требования в системе управления требованиями? Если да то как грамотно это делать, Если нет то почему?

Далее функциональные требования будем в первую очередь описывать через прецеденты. Вопрос - ВИ и есть функциональные требования? имеет ли смысл разбивать ВИ на списки требований и фиксировать их в RaQuest? Или в RaQuest описать фичи? выделенные при создании Видения, а сами прецеденты описывать в рамках ЕА (Enterprise Arcitect) с трассировкой их к фичам описанным в RaQuest