[Подготовка] к семинару "Альтернативные инструменты Управления Требованиями"(Прочитано 58109 раз)
Для показа сравнения СУТ можно взять список критериев и показать как это делается на любом примере:
http://www.paper-review.com/tools/rms/read.php
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Также можно надергать основных фич СУТ из этих Д:
http://wiki.eclipse.org/Requirements_Statement#Additional_suggestions
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Коллеги,

Ну вроде бы все согласны сделать Семинар по предложенному выше плану.
Давайте сделаем:
1. Проведем в апреле Семинар в Москве по 3ем Инструментам
2. Проведем 3 мастер-класса по Инструментам в Минске + после круглый стол по обсуждению

Тем самым Вы обкатаете мастер-классы на семинаре и выступите удачно в Минске.

Для этого на этой неделе нужно выбрать фичи, которые будут демонстрировать СУТ и определиться с датой Семинара в Мск.
Жду реакции докладчиков.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Согласная я, только желательно в конце апреля семинар. У меня ожидается большая запарка на работе на апрель :-(



Ураааааааа, со всеми Докладчиками согласована дата семинара - 9 апреля 2009 года.

Теперь ждем от Иры список Фич, по которым будут показаны инструменты. Далее здесь этот список согласуем.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Вот составил первоначальный набор Фич, которыми должен обладать СУТ. Просьба добавлять\уточнять.
Также прикладываю скрин ментальной карты Функций СУТ и выгрузку пакета из Sparx EA.

Функции СУТ:
1. Сбор Требований
В вод Атомарных Требований                         
Богатое форматирование Текста                     
Загрузка Требований из Файла                     
Шаблоны описания Требований                       
Автонумерация Требований                         
2. Анализ Требований
Формирование структуры проекта                   
Классификация Требований                         
Трассировка Требований                           
Анализ влияния                                   
Анализ покрытия                                   
Трассировка к элементам модели и коду             
Отчетность по требованиям                         
3. Документирование Требований
Наследование (заново использование) Тр           
Поддержка форматов файлов для вывода             
Настройка шаблонов вывода Документов             
Шаблонный вывод Документов                       
4. Проверка Требований
Проверка орфографии                               
Нахождение дупликатов и зависимостей             
5. Управление Требованиями
Атрибуты Требований                               
Версионность Требований                           
История изменения Требований
« Последнее редактирование: 11 Марта 2009, 02:00:42 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Богатое форматирование текста - это зачет :) (по моему мнению форматирования надо не так уж и много)

Формирование структуры проекта  - что под этим подразумевается?

Анализ покрытия - чего покрывали то??

Саш, тут в соседней теме делали требования ИС Аттестации или как то так.

Почему не выделить такую же тему и решать задачу по описанию требований к идеальной СУТ там?

P.S.
где работа с Use Cases и сценариями?
где глоссарий?
если закладываемся на трассировку к элементам модели и кода, то где трассировка к тестам
« Последнее редактирование: 11 Марта 2009, 11:08:40 от Александр Лобач »



Богатое форматирование текста - это зачет :) (по моему мнению форматирования надо не так уж и много)
Но оно нужно! Предложи тогда перевод - Rich Text Editor

Формирование структуры проекта  - что под этим подразумевается?
Это возможность формирования различных подразделов (Глоссарий, Цели и т.д.) и возможность формирования иерархической структуры

Анализ покрытия - чего покрывали то??
То что мы все вышестоящие требования покрыли в более детальных Требованиях.

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

где работа с Use Cases и сценариями?
где глоссарий?
если закладываемся на трассировку к элементам модели и кода, то где трассировка к тестам
1. Имелось в виду в п. "Шаблоны описания Требований", т.е. сценарный шаблон для ВИ. Что-то еще нужно для ВИ в СУТ?
2. А что нам нужно специфического для Глоссария? Кроме отдельного структурного раздела?!
3. Согласен. Трассировка к другим артефактам Разработки (Элементы модели, код, тесты и т.д.)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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

Дословный перевод с английского это зачастую смешно :)

по поводу покрытия: тогда в чем разница между трассировкой и покрытием?

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

еще по поводу требований к сут
- инструмент обсуждения требований с сохранением истории




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



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



Лично меня сейчас очень интересуют вот такие функции инструмента управления требованиями:

- возможность представления "срезов" по определённой функциональности (пример: представить на одной странице всю информацию о требованиях к операции "отмена платежа");

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

- связь требований с релизами (в каком реализовано), тест-кейсами (чем проверяется), тестовыми планами и прогонами (в какой версии протестировано).


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


Трассировка лично у меня ассоциируется с автоматическим изменением статусов: поменял какое-то требование, и это изменение автоматически отразилось на всех связанных объектах (зависимые требования, тест-кейсы).


Сам я в СУТ не силён пока. Постараюсь до семинара освоить OSRMT, чтобы было от чего отталкиваться (собственно, я уже начал).
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Разослал всем Докладчикам ссылку на список фич СУТ. Вроде бы первое приближение получили. На основании выше и лично сказанного подправлю описание Фич и более полно раскрою каждую. К среде должны получить список, на который и должны ориентироваться Докладчики.

Решили заключение Семинара сделать таким:
1. Делаем на доске табличку где по горизонтали идут список Фич, а по вертикале СУТ. По мере доклада Модератор ставит оценку на пересечении каждой Фичи и СУТ. В конце подводим формальный итог.
2. Далее делаем голосование Слушателей - кому какая СУТ больше понравилась и делаем второе Заключение.
3. Если останется время, то Слушатели задают вопросы докладчикам.
4. Все заканчивается миром, дружбой и жвачкой.

Формальная оценка СУТ
К среде мы формируем список ФИЧ, которым должна удовлетворять СУТ, с кратким описанием. На семинаре Докладчик демонстрирует наиболее характерные Фичи для данной СУТ и Модератор проставляет - или + или +\- или ++ на пересечении Фичи и СУТ в таблице. Если Докладчик не успел показать какие-то фичи, то за 5 минут мы проходим по оставшимся и ставим + или - на против этих Фич на основании знаний Докладчика.
Система оценок:
"-"    - СУТ не поддерживает Фичу
"+\-" - СУТ поддерживает Фичу, но не в полном объеме*
"+"    - СУТ поддерживает Фичу в полном объеме*
"++"  - СУТ поддерживает Фичу в полном объеме*, да и еще что-то добавляет сверх описанного в Фиче.
* объем определяется описанием фичи и субъективной оценкой Модератора

Фуф, вроде все :)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Поддерживаю такую схему!
Осталось определиться, кто будет Модератором.
Ну и кто предоставит жвачку для концовки :-)



Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19