Форум Сообщества Аналитиков
Дисциплины => Обучение => Конференции Семинары и Тренинги => Тема начата: bas от 26 Января 2009, 17:44:01
-
Поговорил я тут недавно со Стасом Калкановым (http://kalkanov.moikrug.ru/) и оказалось, что компания Люксофт хочет вывести свой продукт LUXProject (http://www.luxoft.ru/luxproject/) на массовый рынок. Данный продукт основан на продуктах Confluence (Wiki) (http://www.atlassian.com/software/confluence/), Jira (Task tracker) (http://www.atlassian.com/software/jira/) и др. от компании Atlassian, и, как сказано в презентации, является также полноценной Системой Управления Требованиями (СУТ).
В связи с этим решено сделать семинар, на котором Стас (или кто-то еще) расскажет и ПОКАЖЕТ LUXProject (с упором на УТ) + хотим сделать еще один доклад по другой альтернативной СУТ.
У кого какие есть идеи по второму докладу? Кто хочет выступить?
З.Ы. Семинар планируется на конец февраля, начало марта.
-
Насколько я помню прошлый доклад Стаса то LUXProject не столько среда управления требованиями сколько управления проектами по разработке.
То есть она не является СУТ, а имеет в своем составе данный функционал.
какая цель еще одного доклада по альтернативной СУТ?
-
Ну в общем-то да. ЛюксПроджект - это продукт, который в принципе призван закрыть нишу инструментов по поддержке всего цикла разработки ПО (ALM - Application Lifecircle Management).
М.б. действительно расширить тему?! Не просто СУТ, а рассказать про Системы ALM?!
-
ЛюксПрожект - это действительно инструмент для управления разработкой ПО, а не собственно СУТ.
-
А кому и зачем может быть интересен сейчас LUXProject?
-
Ну например мне, п.ч. мне интресены все альтернативные не дорогие средства управления всем циклом разработкой ПО, в т.ч. и СУТ.
-
Кто сказал, что LuxProject будет недорогим??? Как минимум нужно купить Jira и Confluence + их добавленная стоимость. Кроме этого -- LuxProject заточен под Люксофт и их особенности ведения проектов. Думаю его можно было попытаться предложить в контору, в которой Андрей Бобылев работает - они насколько я знаю боготворят Люксофт :-).
-
Стас описал ценовую политику покупки\внедрения LUXProject'а:
http://sepg.livejournal.com/21969.html
-
В связи с этим решено сделать семинар, на котором Стас (или кто-то еще) расскажет и ПОКАЖЕТ LUXProject (с упором на УТ) + хотим сделать еще один доклад по другой альтернативной СУТ.
У кого какие есть идеи по второму докладу? Кто хочет выступить?
Я могу выступить, рассказать и показать альтернативу - DEVPROM (ALM класс).
Вот здесь очень кратко написано про управление требованиями в этом инструменте - http://www.devprom.net/co/tour.php?page=1017.
Ценовой порядок совершенно другой: на команду до 5ти человек - бесплатно, дальше по 9 тыс за лицензию.
Устанавливается вместе с начальной настройкой примерно за 10 минут.
Насколько интересно было бы послушать и посмотреть?
-
Ценовой порядок совершенно другой: на команду до 5ти человек - бесплатно,
Вот это очень интересно. Мне как раз нужен инструмент управления тестами. Я пытаюсь использовать testlink. Но возможно ваш инструмент круче и удобнее? Команда у меня небольшая, как раз до 5 человек. Можно ли как-то попробовать Вашу систему?
-
Насколько интересно было бы послушать и посмотреть?
Супер Дмитрий. Мне кажется этот продукт тоже заслуживает внимания. Если Вы готовы рассказать и показать этот инструмент в деле, то я договариваюсь о дате семинара со Стасом. Скорее всего семинар пройдет на территории главного офиса Люксофта (http://luxoft.ru/contact/contact.html).
-
Можно ли как-то попробовать Вашу систему?
Самый простой способ - создать свой тестовый проект на http://devprom.net и попробовать систему в действии там.
Если понравится, тогда скину почтой инсталлятор для установки на ваш локальный сервер (официально с сайта он будет доступен для скачивания в середине марта).
-
Дмитрий Вы готовы прочитать свой доклад и показать DEVPROM на семинаре на территории главного офиса Люксофта в середине\конце марта?
-
Да, готов, можно назначать дату проведения. (сорри, что-то мой предыдущий ответ вам не добавился)
-
Самый простой способ - создать свой тестовый проект на http://devprom.net и попробовать систему в действии там.
Если понравится, тогда скину почтой инсталлятор для установки на ваш локальный сервер (официально с сайта он будет доступен для скачивания в середине марта).
спасибо, надо попробовать
-
А никто не хочет сделать Доклад про Sparx EA и показать инструмент в деле?
-
А никто не хочет сделать Доклад про Sparx EA и показать инструмент в деле?
А когда планируется семинар?
И какие функции интересуют? Имею в виду, что интересно наверно будет сравнить, как одни и те же функции/процедуры управления требованиями реализуются в различных инструментах. А если каждый расскажет про разное, сравнить плохо получится.
-
Примерная дата - середина, конец марта.
О чем рассказать - скорее об опыте работы в данном инструменте и функция по поддержке управления требованиями + ответить на интересующие вопросы, типа - А вот это он умеет, а это?? и т.д.
-
а по времени мы уложимся? Это ж уже 3й инструмент в семинар, если не четвертый. + в каком режиме: с показом инструмента или как обычно, презенташка и махание руками?
-
На каждую презентацию 40 минут + 20 минут обсуждения и 5 минут перерыв после каждой презентации. Всего 3 презентации на 3,5 часа.
Лучше конечно показать на реальном примере, чем просто показывать на слайдах. Хотя возможен и вариант с презентацией.
-
На каждую презентацию 40 минут + 20 минут обсуждения и 5 минут перерыв после каждой презентации. Всего 3 презентации на 3,5 часа.
Лучше конечно показать на реальном примере, чем просто показывать на слайдах. Хотя возможен и вариант с презентацией.
Интересно было бы в каждой презентации демонстрировать решение одной и той же задачи в рамках одного и того же проекта. Тогда реально можно будет используемые модели, базовые функции и, возможно, какие-то "фенечки".
-
Было бы интересно, но требует синхронизации и взаимной подготовки. Я не готов сейчас этим заниматься.
-
Было бы интересно, но требует синхронизации и взаимной подготовки. Я не готов сейчас этим заниматься.
Так для того и форум.
Имеем три инструмента:
- LUXProject
- DEVPROM
- Sparx EA
Можно выбрать небольшую конкретную задачу и проиллюстрировать, как управлять требованиями в динамике.
Я могу предоставить обрывки требований по какой-нибудь "живой", конкретной операции из наших проектов - use case, ограничения, статьи из глоссария. Было бы очень интересно посмотреть, как это всё ляжет на конкретные инструменты.
Всё, что мне нужно, - подтверждение экспертов по СУТ о готовности работы по такому сценарию. Если они не боятся. ;)
-
Гриша, я с тобой!
Считаю твой вариант лучшим при подготовке семинара
-
Так я понял, ты, Ира, готова быть докладчиком по Sparx EA?
-
Да, вы меня уговорили :-)
-
Ира, в том, что ты не испугаешься, я и не сомневался. :) Тем более что эту идею ты первой и высказала. Представляя Sparx, ты выступаешь с позиций эксперта и аналитика - тебе не нужно "защищать" этот конкретный инструмент.
C LuxProject и Devprom, как я понимаю, ситуация несколько иная, и поэтому принципиально важно согласие экспертов именно по этим инструментам.
-
В целом, идея с конкретной задачей выглядит интересно.
Но есть одно но - поскольку в большинстве проектов процессы работы с теми же требованиями различаются, решение вашей частной задачи может оказаться:
а) немного "однобоким", не показывающим все возможности инструментов
б) немного неинтересным публике, которая, например, работает с требованиями по другому сценарию
и ей интересны были бы другие возможности систем
-
Дмитрий,
Как сказал Гриша:
Так для того и форум.
-
Но есть одно но - поскольку в большинстве проектов процессы работы с теми же требованиями различаются, решение вашей частной задачи может оказаться:
а) немного "однобоким", не показывающим все возможности инструментов
Вот именно, что для презентаций часто выбирают такие примеры, которые иллюстрируют отличительные особенности именно этого конкретного инструмента.
б) немного неинтересным публике, которая, например, работает с требованиями по другому сценарию
и ей интересны были бы другие возможности систем
Обычно неинтересны как раз "взятые с потолка" абстрактные примеры. У вас уже есть предположения о том, какие примеры будут использоваться на презентации? Можно ли их здесь представить?
Я, конечно, осознаю, что сравнение инструментов на одном примере может быть некорректным по следующим причинам:
- Инструменты могут быть предназначены для разных типов проектов и разных классов задач. Тогда эти типы и классы желательно обрисовать заранее.
- Целью представления инструментов на бесплатном семинаре может быть "промоушен", а явное сравнение с альтернативным продуктом-конкурентом противоречит этой цели. В этой цели самой по себе нет ничего зазорного. Я именно поэтому и говорю: принципиально важно согласие экспертов, представляющих инструменты. Если идея сравнения "в лоб" противоречит целям презентации, то лучше отказаться от идеи, чем от презентации.
Но мне, например, как потенциальному потребителю, было бы интересно именно сравнение продуктов. Всё равно человек, делающий выбор, неизбежно будет заниматься сравнением. А производителям, на мой взгляд, всегда лучше руководствоваться принципом "если пьянку сравнительную экспертизу нельзя предотвратить, то её надо возглавить". ;)
-
Для показа сравнения СУТ можно взять список критериев и показать как это делается на любом примере:
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. Управление Требованиями
Атрибуты Требований
Версионность Требований
История изменения Требований
-
Богатое форматирование текста - это зачет :) (по моему мнению форматирования надо не так уж и много)
Формирование структуры проекта - что под этим подразумевается?
Анализ покрытия - чего покрывали то??
Саш, тут в соседней теме делали требования ИС Аттестации или как то так.
Почему не выделить такую же тему и решать задачу по описанию требований к идеальной СУТ там?
P.S.
где работа с Use Cases и сценариями?
где глоссарий?
если закладываемся на трассировку к элементам модели и кода, то где трассировка к тестам
-
Богатое форматирование текста - это зачет :) (по моему мнению форматирования надо не так уж и много)
Но оно нужно! Предложи тогда перевод - Rich Text Editor
Формирование структуры проекта - что под этим подразумевается?
Это возможность формирования различных подразделов (Глоссарий, Цели и т.д.) и возможность формирования иерархической структуры
Анализ покрытия - чего покрывали то??
То что мы все вышестоящие требования покрыли в более детальных Требованиях.
Саш, тут в соседней теме делали требования ИС Аттестации или как то так.
Почему не выделить такую же тему и решать задачу по описанию требований к идеальной СУТ там?
Так тут как раз говорим о тех ф-ях, которые ребята будут демонстрировать в своих Инструментах.
где работа с Use Cases и сценариями?
где глоссарий?
если закладываемся на трассировку к элементам модели и кода, то где трассировка к тестам
1. Имелось в виду в п. "Шаблоны описания Требований", т.е. сценарный шаблон для ВИ. Что-то еще нужно для ВИ в СУТ?
2. А что нам нужно специфического для Глоссария? Кроме отдельного структурного раздела?!
3. Согласен. Трассировка к другим артефактам Разработки (Элементы модели, код, тесты и т.д.)
-
надо каждый пункт из твоего списка немного детализировать или описать словами, а то появляются вопросы.
(хотя может это я такой)
Дословный перевод с английского это зачастую смешно :)
по поводу покрытия: тогда в чем разница между трассировкой и покрытием?
Глоссарий я понимаю только в одном виде чтобы один раз вбил термин, а потом везде в тексте при наведении показывалось определение.
еще по поводу требований к сут
- инструмент обсуждения требований с сохранением истории
-
Браво!
Спасибо Сашам за список тем и дискуссию!
Присоединюсь к вопросу "в чем разница между трассировкой и покрытием".
И еще: меня терзают смутные сомнения, что в полчаса не получится качественно уложить демонстрацию реализации всех этих красот в 1 инструменте. С учетом того, что семинары в Москве проводятся в будний день вечером - это будет сложно...
-
И еще: меня терзают смутные сомнения, что в полчаса не получится качественно уложить демонстрацию реализации всех этих красот в 1 инструменте. С учетом того, что семинары в Москве проводятся в будний день вечером - это будет сложно...
Тогда нужно выбрать наиболее хорошо реализованные функции в СУТ, а по остальным сказать - есть или нет.
-
Лично меня сейчас очень интересуют вот такие функции инструмента управления требованиями:
- возможность представления "срезов" по определённой функциональности (пример: представить на одной странице всю информацию о требованиях к операции "отмена платежа");
- множественные представления одного и того же требования для разных условий - клиентов, проектов (пример: есть один "общий" вариант чека операции "продажа" и его модификации для отдельных клиентов);
- связь требований с релизами (в каком реализовано), тест-кейсами (чем проверяется), тестовыми планами и прогонами (в какой версии протестировано).
Кроме того, интересно посмотреть на реализованные модели жизненного цикла требований (перечень и диаграмма статусов), насколько они гибки и адаптируемы к разным типам проектов и ролей.
Трассировка лично у меня ассоциируется с автоматическим изменением статусов: поменял какое-то требование, и это изменение автоматически отразилось на всех связанных объектах (зависимые требования, тест-кейсы).
Сам я в СУТ не силён пока. Постараюсь до семинара освоить OSRMT, чтобы было от чего отталкиваться (собственно, я уже начал).
-
Разослал всем Докладчикам ссылку на список фич СУТ (http://www.uml2.ru/forum/index.php?topic=1116.msg12916#msg12916). Вроде бы первое приближение получили. На основании выше и лично сказанного подправлю описание Фич и более полно раскрою каждую. К среде должны получить список, на который и должны ориентироваться Докладчики.
Решили заключение Семинара сделать таким:
1. Делаем на доске табличку где по горизонтали идут список Фич, а по вертикале СУТ. По мере доклада Модератор ставит оценку на пересечении каждой Фичи и СУТ. В конце подводим формальный итог.
2. Далее делаем голосование Слушателей - кому какая СУТ больше понравилась и делаем второе Заключение.
3. Если останется время, то Слушатели задают вопросы докладчикам.
4. Все заканчивается миром, дружбой и жвачкой.
Формальная оценка СУТ
К среде мы формируем список ФИЧ, которым должна удовлетворять СУТ, с кратким описанием. На семинаре Докладчик демонстрирует наиболее характерные Фичи для данной СУТ и Модератор проставляет - или + или +\- или ++ на пересечении Фичи и СУТ в таблице. Если Докладчик не успел показать какие-то фичи, то за 5 минут мы проходим по оставшимся и ставим + или - на против этих Фич на основании знаний Докладчика.
Система оценок:
"-" - СУТ не поддерживает Фичу
"+\-" - СУТ поддерживает Фичу, но не в полном объеме*
"+" - СУТ поддерживает Фичу в полном объеме*
"++" - СУТ поддерживает Фичу в полном объеме*, да и еще что-то добавляет сверх описанного в Фиче.
* объем определяется описанием фичи и субъективной оценкой Модератора
Фуф, вроде все :)
-
Поддерживаю такую схему!
Осталось определиться, кто будет Модератором.
Ну и кто предоставит жвачку для концовки :-)
-
Открыта регистрация на Семинар Системы Управления Требованиями (http://luxoft.ru/edu/seminarinfo.html?id=113).
-
Открыта регистрация на Семинар Системы Управления Требованиями (http://luxoft.ru/edu/seminarinfo.html?id=113).
Саш, пусть ошибку исправят.
От регистрации на livents они отказались? ИМХО намного удобнее видеть список зарегистрировавшихся, чем отправлять письмо неизвестным "нашим специалистам" с непонятной обратной связью. :(
-
Исправил описание Фич, просьба посмотреть и откомментировать.
Функции СУТ
1 Сбор Требований
1.1 Ведение Глоссария
· Поддержка ведения отдельного раздела Глоссария проекта (межпроектный глоссарий)
· Автоматическая ссылочность термина в Требовании на нужное определение в Глоссарии (один раз вбил термин, а потом везде в тексте при наведении показывалось определение)
1.2 Работа с Атомарными Требованиями
Возможность ввода\редактирования\удаления\ просмотра атомарных Требований
1.3 Богатое форматирование Текста
· Возможность редактирования и хранения текста Требования в формате Rich Text
· Возможность добавлять картинки в текст Требования
· Возможность добавлять веб ссылки
1.4 Загрузка Требований из Файла
· Возможность автоматизированной загрузки набора Требований из файла (MS Excel, Word, HTML, XML, ...)
· Возможность поддержки round-trip выгрузки\загрузки Требований из Файла в Инструмент и обратно
1.5 Шаблоны описания Требований
· Поддержка основных шаблонов описания Требований: Проблемы, Цели, ВИ со сценариями, ФТ, НФТ и т.д.
· Возможность модификации шаблонов и создания новых
1.7 Автонумерация Требований
· Автонумерация Требований в зависимости от типа
· Иерархическая автонумерация, поддержка перенумерации дочерних Требований при удалении (изменении номера) родительского Требования
1.8 Обсуждение Требований
Возможность обсуждения Требований
2 Анализ Требований
2.1 Формирование структуры проекта
· Автоматическое формирование структуры проекта (разделы Анализа, Проектирования и т.д.) по шаблону известных методологий
· Настройка собственного шаблона проекта
· Возможность посмотреть примеры применения шаблона структуры проекта
2.2 Классификация Требований
Поддержка различных типов Требований и настройка ЖЦ каждого типа Требований
2.3 Трассировка Требований
· Возможность связывать Требования между собой
· Возможность связывать часть текста Требований (пункт Сценария ВИ например) с другим Требованием прямо из текста
2.4 Анализ влияния
Возможность построения отчета по всем связанным Требованиям с данным Требованием
2.5 Анализ покрытия
Возможность показать все верхоуровневые требования, которые не детализированы (не покрыты) Требованиям более низкого уровня.
2.6 Трассировка к др. Артефактам разработки
Возможность трассировать Требования к:
· Элементам модели
· Тестовым сценариям
· Коду
· Задачам и плану
2.7 Отчетность по требованиям
Возможность получения отчета по требованиям в разных разрезах:
· возможность представления "срезов" по определённой функциональности (пример: представить на одной странице всю информацию о требованиях к операции "отмена платежа")
· возможность формирования "срезов" по атрибутам Требований (тип, статус, ...)
· фильтрация и поддержка пользовательских выборок
· построение графиков по выборке
3 Документирование Требований
3.1 Наследование (заново использование) Тр
Возможность наследования (заново использования) Требований в разных проектах
3.2 Поддержка форматов файлов для вывода
Выгрузка в:
· RTF
· DOC
· EXCEL
· PDF
· XML
· HTML
3.3 Настройка шаблонов вывода Документов
Возможность настройки и создания своих шаблонов для результирующих Документов
3.4 Шаблонный вывод Документов
· Возможность вывода результирующих Документов (ТЗ, ТП и т.д.) в определенном шаблоне
4 Проверка Требований
4.1 Проверка орфографии
Проверка орфографии на русском и др. языках
4.2 Нахождение дубликатов и зависимостей
Возможность нахождения дубликатов (похожих) Требований
5 Управление Требованиями
5.1 Атрибуты Требований
· Возможность задания атрибутов у Требований
· Возможность поддержки и настройки ЖЦ Требования
· Возможность фильтрации Требований по Атрибутам
5.2 Версионность Требований
· Возможность указать\получить описание Требований к определенной версии ПО
· Возможность формирования результирующих Документов для определенной версии ПО
· Возможность связываниям Тр с тестовыми планами и прогонами в конкретной версии ПО (в какой версии протестировано)
·
5.3 Изменения Требований
· Хранение истории изменении требований
· Возможность отката к любому изменения Требований
· Поиск по изменениям
· Возможность указания причины изменения
· Возможность оповещения рабочей группы об изменениях
5.4 Одновременный доступ к Требованиям
· Поддержка многопользовательского доступа к репозиторию Требований
· Возможность доступа через веб интерфейс
5.6 Управление правами на работу
Разделение прав на работу с Требованиями между Пользователями в разрезе проектов, типов Требований и их аттрибутов
5.7 Работа с несколькими проектами
· Поддержка ведения репозитория Тр для нескольких проектов
· Возможность использования и трассировки Требований из разных Проектов
· Множественные представления одного и того же требования для разных условий - клиентов, проектов (пример: есть один "общий" вариант чека операции "продажа" и его модификации для отдельных клиентов);
5.8 Способ хранения Требований
· В каком виде и в каком формате может хранится репозиторий Требований
· Возможность сырого доступа к репозиторию (БД, формат файлов)
6 Другие условия
6.1 Документация
· Пользовательская Документация в т.ч. на русском
· Примеры
6.2 Расширения
· Поддержка plug-in, add-on, расширений и т.д.
· Кол-во уже имеющихся на рынке расширений
· Простота написания собственных расширений
6.3 Цена
Ценовое предложение по продаже Инструмента
В приложении картинки и выгрузка пакета для ЕА
-
Регистрация открыта и на ресурсе livents.ru (http://livents.ru/event/2009/04/09/sistemi-upravlenija-trebovanijami/)
-
Кто смог бы написать отзыв о семинаре?
-
Саша, а почему на этот семинар не пригласили выступить ребят из бывш. Telelogic, ныне IBM? Думаю гораздо интереснее было бы чем про DEVPROM слушать. Просто название семинара не совсем согласуется с контентом ... тогда уж про "малобюджетные" или альтернативные системы говорили бы ...
-
Так в описании Семинара (http://livents.ru/event/2009/04/09/sistemi-upravlenija-trebovanijami/) так и написано:
... Будут рассмотрены коммерческие системы бюджетного сегмента.
-
Возможно нужно сделать отдельный Семинар по продуктам IBM Rational & Telelogic
-
В описании то написано ... но вот в названии .... "Системы управления требованиями"
-
Отвечая на
Исправил описание Фич, просьба посмотреть и откомментировать.
Функции СУТ
1 Сбор Требований
1.1 Ведение Глоссария
· Поддержка ведения отдельного раздела Глоссария проекта (межпроектный глоссарий)
· Автоматическая ссылочность термина в Требовании на нужное определение в Глоссарии (один раз вбил термин, а потом везде в тексте при наведении показывалось определение)
1.2 Работа с Атомарными Требованиями
Возможность ввода\редактирования\удаления\ просмотра атомарных Требований
[skipped]
В приложении картинки и выгрузка пакета для ЕА
предлагаю вернуться к моей исходной идее - рассмотреть 5-7 наиболее типичных проблем, возникающих при управлении требованиями исключительнов в Word + Excel и как их закрывают автоматизированные системы.
А большую таблицу с фичами (она действительно хороша) можно заполнить в качестве домашнего задания и потом обсудить в конце семинара.
Времени на подробное прохождение по всем фичам не будет. А если проходить их по верхам - презентации получатся в стиле marketing bullshit. Хотелось бы этого избежать. Выступления должны носить практическую направленность.
Примеры типичных проблем тех, кто работает только с Word и Excel, которые изящно решаются автоматизированными системами:
1. Трейсибилити
2. Распределенная работа над требованиями в команде
3. Версионирование и бейзлайнинье
4. Управление изменениями
5. Отслеживание изменений в документах (своевременное информирование заинтересованных лиц об изменениях).
6. Автоматизация ревью и схемы утверждения док-ов
7. Автоматизация управления коммитментами (в т.ч. протоколами и решениями и пр.)
-
Согласен со Стасом. Мой список очень большой и его можно заполнить до Семинара дома докладчикам.
К проблемам Стаса я бы добавил Гришин интерес:
- множественные представления одного и того же требования для разных условий - клиентов, проектов (пример: есть один "общий" вариант чека операции "продажа" и его модификации для отдельных клиентов);
Т.е. есть у нас ядро Программного продукта, есть требования к нему и есть множество клиентов, и некоторые требования для конкретных Клиентов отличаются. Еще возможен вариант реализации какого-то требования для конкретного КЛиента, а потом это требование сливается в основную ветку Требований в ядро Программы.
- ведение Глоссария проекта и межпроектного Глоссария.
Еще бы детализировал бы Трассировку как:
1. Трассировка Требований между собой
2. Трассировка Требований с элементами модели
3. Трассировка к коду
4. Трассировку к тестам и их прогонам для конкретной версии.
-
Поддерживаю
-
Фуф, все вроде бы согласны.
Подытоживаю:
1. Докладчики дома готовят презентацию инструментов по описанным Стасом и мной проблемам:
http://www.uml2.ru/forum/index.php?topic=1116.msg13137#msg13137
http://www.uml2.ru/forum/index.php?topic=1116.msg13138#msg13138
Естественно презентацию лучше не показывать на слайде а проводить в живую на примере с помощью представляемого Инструмента.
ИМХО нужно иметь еще запасной вариант, если сломается свой ноут или Инструмент не захочет работать.
2. Докладчики дома оценивают представляемый Инструмент по списку критериев:
http://www.uml2.ru/forum/index.php?topic=1116.msg13096#msg13096
3. Придя на семинар за 15 минут до начала Докладчик проверяет настроенный Инструмент на проекторе.
4. Проводим семинар в следующем порядке:
18:00-18:40 - Мастре класс по LUXProject (30 минут) и ответы на вопросы (10 минут)
18:40-18:45 - Перерыв
18:45-19:25 - Мастер класс по ЕА (30 минут) и ответы на вопросы (10 минут)
19:25-19:30 - Перерыв
19:30-20:10 - Мастер класс по DEVPROM (30 минут) и ответы на вопросы (10 минут)
20:10-20:15 - Перерыв
20:15-21:00 - Обсуждение выше представленных Инструментов
5. На обсуждение будет сделаны оценки Инструментов как описано выше (http://www.uml2.ru/forum/index.php?topic=1116.msg13082#msg13082) и будут заданы все интересующие вопросы.
Остались вопросы:
1. Кто и на чем будет показывать свой Инструмент. Т.е. на своем ноутбуке или нужно будет установить что-то на ноут, который будет в зале?
вроде все :)
-
Отчет о Семинаре можно посмотреть в соседней ветке (http://www.uml2.ru/forum/index.php?topic=1235.0).
Там же просьба задавать вопросы и оставлять отзывы.