361

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

« : 10 Ноября 2008, 11:18:02 »

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

362

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

« : 10 Ноября 2008, 10:42:59 »

Саша, в EA в иерархии много лишнего, имхо, и depends on и needed by...
А как например сделать, чтобы не просматривать всю иерархию, а требования только одного уровня?
+ Я уже сказал, что единственный способ при использовании иерархии - это "тыкание" в нужное требование. Это можно использовать, когда требований мало, когда их много - это каюк.
Без возможности формирования гибких запросов, например как ReqPro, управлять требованиями не реально. Сплошной оверхед.

363

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

« : 10 Ноября 2008, 09:46:43 »

AlexTheRaven, к сожалению это не решает проблемы анализа влияний. Даже если я вытащу все требования на диаграммку и свяжу и друг с другом, при изменении любого из них, EA не укажет мне на требования, которые могут измениться, т.е. на которые может повлиять измение. Это можно делать через просмотр иерархии, но это совсем не то что нужно, просматривать все требваония в дереве - это большой оверхед.
Диаграммки удобны когда у вас до 100 требований, а когда их переваливает за сотни и тысячи, тут уже извините, диаграммки не помогут. IMHO

364

О Сайте и Форуме / Снова о логотипе

« : 07 Ноября 2008, 16:58:28 »

Друзья, решил немного поучаствоать в обсуждении логотипа сайти и внести свои пять копеек. Саша предложил начать новую тему, поэтому здесь лишь даю ссылку на раннее обсуждение данного вопроса:
http://www.uml2.ru/forum/index.php?topic=242.0

Итак, в чем собственно пробема, или не проблема
Предложенные ранее логотипы не очень всех удовлетворили и сайт так и остался с тем что есть сейчас. Выслушав пожелания Александра по использованию процессных стрелочек в логотипе, решил накидать прототипчик, свое видение.
Графика и дизан оставляет желать лучшего, да с этим я сейчас и не парился, главное идея. В общем смотрим и комментируем.
В дополнении картинка, на которой изображена, имхо, хорошая идея. Если взять вместо пазлов и поместить в руки к человечкам стрелки процесса, то может получится не плохо.

В заключении: Почему стрелки и человечки?
1. Стрелки показывают процесс разработки и напоминают некий цикл, например непрырывное улучшение, и тп
2. Человечки символизируют сообщество

365

Конференции Семинары и Тренинги / Re: [Семинар] Классификация требований, 29 ноября, СПб

« : 06 Ноября 2008, 12:40:35 »

Зарегистироваться на семинар можно здесь

Друзья, не забудьте указать ваши ФИО, компанию и должность.
Указать данные можно в комментарии к событию, или выслать мне письмом на адрес Vitaliy_Grigorash@epam.com
Спешите, количество человек ограничено

366

Конференции Семинары и Тренинги / [Семинар] Классификация требований, 29 ноября, СПб

« : 05 Ноября 2008, 11:45:55 »

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

Приблизительная тема семинара "Классификация требований и связь требований с тестированием"
Данный семинар пройдет в субботу 29 ноября в 10:00 в Петербургском офисе компании EPAM
По огранизационным вопросам обращаться ко мне.

Примерный план семинара такой (будет уточняться):
1. Классификация требований - какие бывают виды требований, как различать требования разных видов, трассировка - Шемис Алексей, 1 час
2. Связь требований с артефактами тестирования - от требований к тест кейсам Сергей Атрощенков, 1 час
3. Практика выявления системных требований из пользовательских (разбор примера (ов) вместе с аудиторией) - 2 часа

Регистрация на семинар будет открыта чуть позднее.

В данной теме высказываем свои пожелания.

367

Поздравления / Re: Поздравляем Denis'а с Днем Рождения

« : 05 Ноября 2008, 11:30:35 »

Присоединясь. Всего всего и побольше  

368

Проектирование / Re: Как описать существующий интерфейс системы?

« : 01 Ноября 2008, 14:03:03 »

На проекте сейчас применяем следующую схему.
1. Пишем ВИ
2. По ВИ создаем модели анализа (Boundary (GUI|API), Control, Entity) + сиквенс
3. Для каждого Boundary:GUI рисуем форму пользовательского интерфейса. Все сообщения от Пользовтеля к GUI на сиквенсе перерастают в элементы управления на формах.
4. В итоге поведение описано в виде ВИ, детализировано на сиквенсах и отображено в виде форм ПИ с элементами и их описанием. Через все это идет трассировка.

1. Надо описывать зависимость состояния иконок или меню (Например:
 кликнули на текстбокс и часть меню лочится но видно. Нажали на другое
 место и меню или иконка стали опять видны)

У нас это описано в таблике с описанием элементов управления в графе "Ограничения"

2. Надо вытащить все формы а именно: формы,
 закладки, сообщения (об ошибках, состояние системы),предупреждения, формы
 открытия/сохранения файлов.

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

3. Подробно описать эти формы. Должно включено: Элементы
 управления(название кнопки),грид(описание столбцов), тесктбоксы (их назначение)

У нас таблица

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

Можно сделать такие сценарии, тольк, имхо, нужно все формы идентифицировать номерами.

У вас обратный случай. Сиквенсы вам конечно не нужны, но вот сценарии подробные стоит написать. Могу примерчик выслать или шаблон документа показать

369

Проектирование / Re: Как описать существующий интерфейс системы?

« : 01 Ноября 2008, 12:44:52 »

Может быть отдельно описать все формы и их элементы управления - статическая модель.
А отдельно, что то типа ВИ, только с описанием конкретных кнопок, полей и форм - модель поведения.
Сделать что-то типа сторибординга, только в обратную сторону?

370

Конференции Семинары и Тренинги / Re: Направление серии семинаров

« : 31 Октября 2008, 12:19:21 »

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

371

Конференции Семинары и Тренинги / Re: Направление серии семинаров

« : 30 Октября 2008, 12:27:37 »

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

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

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

372

Системный Анализ и Требования / Re: Относится ли данное требование к "нефункциональным"?

« : 24 Октября 2008, 11:39:57 »

Таким образом, вы (и мы ) относите данное требование к функциональным, в соотвествии с классификацией К.Вигерса?

Да. Я отношу его к функциональным. Считаю, что это функциональное требование уровня подсистемы.

Тогда, надеюсь, последний вопрос. Куда все же надо отнести это требование в соответствии с ГОСТ 34.602-89?

Я бы записал его в раздел требований к функциям. Но данный раздел поделил ли бы на подсистемы и записал требование в подсистему Администрирования. Администирование - это служебная область функциональности системы.

PS Гы.. Да мы с вами еще и коллеги по фирме
    Пишите мне в скайп vitaliy.grigorash

373

Системный Анализ и Требования / Re: Относится ли данное требование к "нефункциональным"?

« : 24 Октября 2008, 10:38:56 »

Но ведь у К.Вигерса, например, требования к безопасности не выделены отдельно. К какой же тогда категории требований можно отнести данное требование согласно его классификации?

Как я уже написал выше, это немного разные типы классификации:
1. Фунциональные/нефункциональные - Вигерс:
 - что?(функциональное),
 - с каким качеством? (нефункциональное),
 - что ограничивает или нужно учесть? (бизнес-правило и ограничение)
2. Смысловое - деление требований по областям:
 - Служебные (журналирование, администрирование, вход в систему)
 - Предметная область

Если я не прав, то пусть меня коллеги поправят, я высказал свою точку зрения.
Если Вы работает по гостам, то в гостовских ТЗ немного намешано в разделах. Почитайте презентацию Юрия Булуя.
http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=135

374

Системный Анализ и Требования / Re: Относится ли данное требование к "нефункциональным"?

« : 23 Октября 2008, 17:59:15 »

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

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

Интерсно было бы услышать обоснование того, почему данное требование является НЕФУНКЦИОНАЛЬНЫМ. Что по этому поводу говорят ваши коллеги?

375

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

« : 22 Октября 2008, 18:07:13 »

Такми образом прослеживаемость может быть разного направления как прямого, так и обратного.

В английском есть два понятия trace to (трассируеся на) и trace from (следует из)
Пример, пусть есть фича (F1) и ВИ (UC1)
Если мы понимаем, что из F1 следуют вариант использования UC1, то мы делаем так:
1. F1 --trace to--> UC1 (говорим: "фича1 трассируется на ВИ1")
2. UC1 <--trace from-- F1 (говорим: "ВИ1 следует из фичи1")

Следовательно, направление трассировки, это лишь правила чтения связей.

ЗЫ Еще не нужно путать зависимости между требованиями с трассировкой