421

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

« : 08 Августа 2008, 11:41:24 »

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

Привет. Мы в проекте формы пользовательского интерфейса трассируем на ВИ, т.е UC-->GUI, если в дальнейшем будем создавать для каждого варианта использования реализацию в виде взаимодействия классов анализа, то будем трассировать через граничные классы, т.е UC-->Boundary --> GUI. Но почти всегда, имхо последняя связь будет один к одному. Если проект не большой то, думаю, первого случая достаточно, т.к. из анализа сценария ВИ можно свободно накидать прототип (макет) пользовательского интерфейса. Если же форм много и они могут использоваться в разных ВИ, удобней делать через классы анализа, но это требует дополнительных временных затрат.

Т.е. вы хотите трассировать требования на GUI, вплоть до конкретных контролов? ...
На самом деле будет довольно напряжно поддерживать такую трассировку в состоянии целостности, особенно на первых итерациях проекта. Более практично утверждать GUI у заказчика через прототипы. Я бы вообще в таком тяжелом случае, когда заказчик ТАК ТРЕБОВАТЕЛЕН к GUI рекомендовал бы  использовать сторибоардинг

Юрий, я думаю в случае Анастасии, заказчик не требователен к GUI и не выдвигает жестких требований. Наверное аналитики, хотят сами убедится в том, что вся функциональность в требованиях учтена в формах GUI и ничего не забыто. Анастасия, я прав?
Если так. То может описать варианты использования, а далее в документе привести графическое представление формы и сослаться на ВИ.

422

Обучение / Перенесено: Термины: "Политика"

« : 13 Июля 2008, 14:36:36 »

Тема перенесена в Термины и Определения.

http://www.uml2.ru/forum/index.php?topic=186.0

423

Обучение / Перенесено: Термин: Swimlane

« : 13 Июля 2008, 14:36:00 »

Тема перенесена в Термины и Определения.

http://www.uml2.ru/forum/index.php?topic=385.0

424

Обучение / Перенесено: Термины: Swimlane

« : 13 Июля 2008, 14:34:50 »

Тема перенесена в Термины и Определения.

http://www.uml2.ru/forum/index.php?topic=294.0

425

Обучение / Перенесено: Термин: Business case

« : 13 Июля 2008, 14:32:56 »

Тема перенесена в Термины и Определения.

http://www.uml2.ru/forum/index.php?topic=605.0

426

Термины и Определения / Создание подраздела Термины

« : 26 Июня 2008, 19:00:02 »

Друзья, у нас появляется много топиков с переводом англоязычных терминов на русский язык.
Предлогаю сделать отдельный раздел "Темины и определения". Возможно вести общий глоссарий терминов и их перевода. Для терминов можно ввести понятие статуса, например предложен, утвержден. Причем пока термин не обсудится на форуме и не утвердится большинством участников не менять его статус. Если не будет желающих могу курировать раздел. Общий глоссарий треминов думаю пригодится многим, особенно в ситуациях, когда "буржуинские" технологии применяются в проектах для отечественного заказчика, который не позволяет использовать в документации английскую терминологию. Создание общего глобального словаря может перерости в то, что русские айтишники начнут общаться на одном языке  .

427

Sparx / Анализ влияния в EA и Raquest

« : 26 Июня 2008, 12:51:03 »

Друзья! Всем привет

Подскажите пожалуйста, как в Sparx EA + Raquest отслеживать влияние изменения одного требования на другие?

Например, имеется набор ВИ и связанных с ними функциональных требований. Связь между требованиями можно проставить с помощью трассировки в матрице трассировки. Один ВИ может быть трассировн на несколько требований.
Если я изменил вариант использования (наименование, описание и тд.) изменения могут повлиять на связанные с ним требования. В Raquest я не нашел подобной фичи.
Для сравнения в RequisitePro при изменении требования связь трассировки помечается как suspect и я сразу вижу, что необходимо проверить остальные требования на непротиворечивость. Хотелось бы иметь такую фичу в Raquest.

428

Для всех / Re: как не нужно делать. пример неудачной классификации.

« : 23 Июня 2008, 17:05:41 »

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

429

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

« : 11 Июня 2008, 10:01:27 »

... а ты приходишь и говоришь - в 200 раз. А он - за счет чего??

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

Для убеждения заказчиков можно, имхо, использовать аналитические обзоры, как уже сказал Эдуард.
Например, те же всем известные данные Standish Group. Цифры приведенные Лиффингуэлом, не знаю как других, но меня почему убеждают и я ему верю.

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

430

Варианты Использования (Use Case) / Re: Варианты использования для средств графического проектирования

« : 07 Июня 2008, 11:12:16 »

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

431

Варианты Использования (Use Case) / Варианты использования для средств графического проектирования

« : 06 Июня 2008, 10:28:43 »

Привет всем!
Коллеги, может быть кто-нибудь сталкивался с написанием сценариев вариантов использования для средств графического проектирования. Имеется ввиду средства, в которых есть бланк и панель виджетов. Виджеты выбираются из панели и размешаются на бланке.
Все мы с вами работает с CASE средствами и рисуем диаграммы подобным образом, также создаются формы отчетов, например, в Crystal Reports.
Мой вопрос заключается в том, что по вашему мнению в данном случае является целью пользователя и как дробить и описывать варианты использования?
На мой взгляд, цель пользователя - создать конечный графический объект (набор виджетов), например шаблон отчета, а не разместить на бланке элементарный виджет.
Т.е. я создаю ВИ "Создать шаблон отчета", в сценарии которого описываю последовательность действий пользователя. Все вроде бы нормально, но возникает проблема в том, что пользователь может размещать элементы на бланке в различной последовательности.
Может быть написать просто, пользователь выбирает элемент и добавляет его на бланк? Тогда необходимо описывать правила добавления и размещения для каждого типа элемента, например, в разделе связанные с ВИ бизнес-правила. Так?

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

Заранее спасибо.

432

Примеры / Re: Приложение телефонной книги при помощи Rational Software Architect V7

« : 15 Апреля 2008, 10:25:30 »

ОФФТОП

На последок, перед умиранием продуктов Rational...

Александр, почему вы считаете, что продукты Rational умрут? Кто-то об этом официально заявил?
Кстати, пример довольно пустой и ничего толком не показывает, ИМХО

433

Примеры / Re: План управления требованиями

« : 15 Апреля 2008, 10:22:10 »

Юрий, спасибо
Я использовал Вашу презентацию о классификации требований. Очень полезная вешь.

434

Примеры / План управления требованиями

« : 03 Апреля 2008, 13:48:21 »

Привет!
Коллеги, мог бы кто-нибудь поделиться примером плана управления требованиями.
Мне нужен пример плана заточенного под ГОСТ, где описывались бы основные типы требований с трассировкой, их атрибуты и документы, применяемые при разработке требований.

435

Варианты Использования (Use Case) / Re: Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ

« : 26 Марта 2008, 21:02:52 »

Александр, описанный Вами сценарий, мне напомнил crud ВИ, приведенный Коберном в своей всем известной книге .
Посмотрите ВИ32 в книге коберна, помоему вы написали нечто похожее.