Форум Сообщества Аналитиков
Общий раздел => ПО Аналитика => Тема начата: Trigger от 13 Июня 2013, 12:55:41
-
Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.
Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.
Сейчас используем JIRA + Confluence + SVN.
Требования в виде вордовских файлов хранятся в свн.
По требованиям ставятся задачи в JIRA.
При изменении требований/появлении новых ставятся новые задачи в JIRA, в т.е. на доработку ТЗ/документации.
Confluence используем как дополнительный, справочный материал.
-
сообщение устарело
-
Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.
Ой, как хорошо, наконец-то с кого-то это стали требовать...
Внедрение СУТ ничем не отличается от внедрения другой программы автоматизации или разработки софта на начальном этапе. Поэтому я также рекомендовал бы начать с ЗЛ и проблем.
-
Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.
Чтобы оценить эффект от внедрения количественно, вам необходимо иметь зафиксированные количественные параметры вашего текущего состояния. Т.е. то, с чем вы будете сравнивать эти параметры после внедрения.
Вот так и оцените: было - стало (разница). В этом вообще говоря смысл постановки задачи - не выдвигай непроверяемые требования (см. библию папы нашего Вигерса).
-
ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:
- Какие задачи выбрать для измерения? Они должны быть идентичны.
- На ком проводить измерения? Должны быть одни и те же люди.
- Как определить погрешность?
- Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)
pmle, bus
ЗЛ - руководители проектов (РП), заказчики 100%. Остальные под вопросом, поясню: по идеи все, кто участвует в процессе разработки ПО (аналитики, разработчики, тестеровщики, внедренцы) однако они работают по задачам из JIRA и что будут делать больше/быстрее для этих сотрудников не важно. Если будет удобнее работать, повысится качество, то да.
Провел небольшой опрос ЗЛ, в основном РП, выявил существующие проблемы/хотелки:
- Долгое согласование требований. Например требования еще не согласованы, а работы уже ведутся.
- Необходимость дополнительных систем для согласования требований. Например множество дублей в разных гуглдокс (требование - задача - статус) + это дублируется в жире (согласованно да/нет, основание для оплаты и т.д.)
- Необходимость полностью дублировать хотелки (требования), задачи, баги в issue tracker заказчика. Например заказчик создал десяток новых функциональных требований в своей системе. Мы должны перенести в свою, отработать, проверить, отчитаться в свое, в их, + внести изменения в доки.
- Хотелось бы по описанию задачи, была возможность выполнить поиск по вики, в какой раздел это относится, что бы оперативно внести изменения в нужные места. Трассировка т.е.
- При изменении требований система предлагала перестраивать задачи, связи между задачами, определять сроки, закрывать ненужные задачи. Так называемый интеллектуальный помощник.
p.s.Мне интересно, когда IBM предлагает RequisitePro за несколько килобаксов за 1 лицензию, как они обосновывают бизнесу (топ менеджерам, техническому директору, начальнику отдела анализа), что внедрение даст вам 1, 2, 3 и окупится за N месяцев/лет?
p.p.s.Может ли СУТ проверять атрибуты качества требований? (недвусмысленность, проверяемость, полнота)?
-
Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.
Что-то я не понял перехода — только задумались, а уже надо делать пилотный проект.
Как так? Те, кто задумались, чего ожидают от неё? В чём и почему думают она поможет?
-
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
Вы хотите автоматизировать процесс или операции?
Если процесс, то у процесса можно определить его показатели.
У вас процесс УТ уже есть? Зачем он нужен?
Как вы меряете его эффективность сейчас?
Если не меряете, то зачем асфальтировать дороги, по которым ходят коровы?
Подсказки:
Время согласования требований — это показатель процесса разработки требований, а не управления.
Количество согласований — тоже.
Процент изменённых требований за период — показатель процесса учёта требований.
Процент требований, пропущеных по причине отсутствия централизованного учёта требований — тоже.
Денежные потери, возникшие в результате ошибочных решений о рамках релизов и итераций — вполе себе показатель процесса управления требований.
-
ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:
- Какие задачи выбрать для измерения? Они должны быть идентичны.
- На ком проводить измерения? Должны быть одни и те же люди.
- Как определить погрешность?
- Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)
Эээ, а почему вы задаете эти вопросы на форуме, а не самим себе? ) Вы же инициатор внедрения - значит, вы знаете, какие именно параметры вас не устраивают в текущем состоянии. Если вы не знаете, тогда зачем вам что-то внедрять?
-
Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.
Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.
Судя по комментариям, вы ищете преимущества от внедрения СУТ не столько в управлении, сколько в разработке требований (на что Денис уже указал).
Управление требованиями затрагивает все процессы, связанные с разработкой ПО, и каждый из них нужно оценивать. С требованиями работают, как минимум:
- аналитики, которые их разрабатывают;
- руководители проектов (собственно, управление требованиями - это их задача);
- разработчики, которые их реализуют;
- тестировщики, которые проверяют реализацию.
У всех этих людей свои процессы, а у каждого процесса свои показатели.
В первую очередь внедрение СУТ должно сказаться на качестве. Здесь есть где развернуться с показателями, потому что в области оценки качества их изобретено много. Наверняка у вас какие-то уже есть.
Конечно, для оценки хочется взять цифры "до" и "после" и сравнить. Но на практике, во-первых, чтобы иметь цифры "до", нужно, чтобы какая-то статистика уже была. Если у вас есть какие-то верхнеуровневые показатели, полученные от взаимодействия с заказчиком (количество запросов на изменения, рекламаций на неправильно реализованные или нереализованные требования и т. п.), то имеет смысл их использовать.
А во-вторых, внедрение СУТ может создать новые процессы, показатели эффективности которых просто не с чем будет сравнивать, потому что до внедрения их не было.
Самый очевидный профит от внедрения СУТ получит менеджер проекта (условное название, в разных компаниях это могут быть разные роли), которому управление требованиями даёт в руки множество новых показателей для оценки и управления, например:
- готовности продукта (процент реализованных требований - правда, при условии, что вам удастся полностью покрыть разрабатываемую функциональность документированными требованиями);
- протестированности продукта (процент выполненных тестов - в дополнение к предыдущему условию нужно, чтобы тест-кейсы тоже разрабатывались по требованиям, а не "сами по себе");
- временные оценки на разработку и тестирование - начнут работать после набора более-менее адекватной статистики по оценочной и реальной трудоёмкости работ по разработке, реализации и тестированию требований.
Но все эти показатели будут адекватными реальности только если действительно удастся внедрить управление требованиями во все перечисленные процессы. Все эти люди должны начать действительно использовать СУТ в своей работе.
-
ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:
- Какие задачи выбрать для измерения? Они должны быть идентичны.
- На ком проводить измерения? Должны быть одни и те же люди.
- Как определить погрешность?
- Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)
pmle, bus
ЗЛ - руководители проектов (РП), заказчики 100%. Остальные под вопросом, поясню: по идеи все, кто участвует в процессе разработки ПО (аналитики, разработчики, тестеровщики, внедренцы) однако они работают по задачам из JIRA и что будут делать больше/быстрее для этих сотрудников не важно. Если будет удобнее работать, повысится качество, то да.
Провел небольшой опрос ЗЛ, в основном РП, выявил существующие проблемы/хотелки:
- Долгое согласование требований. Например требования еще не согласованы, а работы уже ведутся.
- Необходимость дополнительных систем для согласования требований. Например множество дублей в разных гуглдокс (требование - задача - статус) + это дублируется в жире (согласованно да/нет, основание для оплаты и т.д.)
- Необходимость полностью дублировать хотелки (требования), задачи, баги в issue tracker заказчика. Например заказчик создал десяток новых функциональных требований в своей системе. Мы должны перенести в свою, отработать, проверить, отчитаться в свое, в их, + внести изменения в доки.
- Хотелось бы по описанию задачи, была возможность выполнить поиск по вики, в какой раздел это относится, что бы оперативно внести изменения в нужные места. Трассировка т.е.
- При изменении требований система предлагала перестраивать задачи, связи между задачами, определять сроки, закрывать ненужные задачи. Так называемый интеллектуальный помощник.
p.s.Мне интересно, когда IBM предлагает RequisitePro за несколько килобаксов за 1 лицензию, как они обосновывают бизнесу (топ менеджерам, техническому директору, начальнику отдела анализа), что внедрение даст вам 1, 2, 3 и окупится за N месяцев/лет?
p.p.s.Может ли СУТ проверять атрибуты качества требований? (недвусмысленность, проверяемость, полнота)?
1. СУТ не предназначена для управления задачами, она позволяет создавать (точнее фиксировать) и эффективно управлять требованиями (и их изменениями)
2. Преимущества СУТ в т.ч. лежат в: возможности проведения анализа влияния (матрицы трассировки требований), быстрая генерация формальной документации требований (с учетом версионирования требований), контроль изменений требований (кто, когда и почему изменил), возможность коллективной работы над требованиями (но это можно решить и с использованием SharePpoint, например). Другой вопрос, как у вас поставлен процесс разработки и управления требованиями ... некоторые преимущества ценны будут для вас, а некоторые - нет. Кроме этого, не следует исключать такой аспект, как повышение уровня зрелости процессов разработки ПО в целом, с использованием СУТ. Как оценить - можно посмотреть посмотреть на ту же goals/practices в CMMI (REQM)
3. Согласовывать имеет смысл не отдельные требования, а требования к конкретному релизу (в совокупности). Это делать проще (согласовать документ и получить по нему замечания). Не думаю, что вы заставите заказчиков использовать СУТ для этого ... хотя бывают исключения.
-
сообщение устарело
-
Юрий, не могу согласиться.
Управлять задачами в СУТ очень удобно. Иллюстрации и пояснения здесь: http://edu.reqcenter.pro/?p=4206
Не впечатлила ссылка. При таком подходе TFS, Jira - тоже СУТ :-).
-
сообщение устарело
-
Не впечатлила ссылка. При таком подходе TFS, Jira - тоже СУТ :-).
TFS - это действительно полноценная СУТ. С управлением требованиями там всё в порядке. ALM Rangers вон целую книгу написали про управление требованиями в TFS http://vsartfsreguide.codeplex.com/
Вот с разработкой требований в TFS не очень, но это решается. Ира Сурова на ЛАФ будет рассказывать, как они скрестили TFS и Enterprise Architecht. Кроме того, ходят упорные слухи, что TFS будет интегрироваться с Borland CaliberRM.
С моей точки зрения, СУТ, не встроенная в ALM, - вещь в себе. Полноценное управление требованиями возможно, только если оно замкнуто на все процессы разработки. То есть СУТ должна быть либо частью системы ALM, либо прозрачно интегрироваться с другими инструментами.
-
более того, скажу вам по секрету, что IBM нашли способ поженить TFS и RRC(rational requisite composer) из их платформы Jazz :)
Штатные средства трассирования TFS - это выгрузка айтемов в excel. как говорится, на безрыбье и рак рыба, но это полный треш.
Для себя я нарисовал такую картину СУТ+TFS:
По факту получаются независимые подсистемы ALM: в СУТ аналитики формализуют, создают и управляют требованиями и делают постановку задачи архитектуре или сразу разработчику(в зависимости от ролей и принятого техпроцесса), а архитекторы, разработчики и тестирование ведут управление заданием уже в TFS. Таким образом аналитик выступает в роли заказчика для архитектуры и разработки(в ролевой модели проекта).
По сабжу,
мы, когда ROI на внедрение СУТ подготавливали у нас отбив стоимости продукта внедрения был 3 года с 30% приростом производительности.
по расчёту ROI в интернете полно информации + Юрий хороший пост написал
-
Странное заключение, которое никак не следует из того, что управлять задачами в Cradle весьма удобно, что и проиллюстрировано по ссылке.
Отношу это исключительно к особенностям форумного общения.
Прошу прощения, я не пояснил и видимо это вызвало некий дискомфорт, выразившийся в вашем постинге. Дело вот в чем, вы предлагаете к рассмотрению топик "удобство или неудобство управления задачами в Cradle", я же говорю о несколько ином - "зачем вообще в СУТ иметь такой функционал как управление задачами", т.е налицо ситуация "я ему о Фоме, а он мне о Ереме" (с). Собственно, исходя из своего посыла я и делаю выводы о релевантности предоставленной ссылки. Кроме этого, возможность управления задачами как-то сильно "out of scope" дисциплины "Разработка и управление требованиями" (в том же SWEBOK). И если аналитиков к этому "припахивают" в конкретных проектах, то это означает ровным счетом то, что в проекте роли распределены несколько специфически, и проектный менеджер перекладывает свою работу на плечи несчастных аналитиков.
-
TFS - это действительно полноценная СУТ. С управлением требованиями там всё в порядке. ALM Rangers вон целую книгу написали про управление требованиями в TFS http://vsartfsreguide.codeplex.com/
Вот с разработкой требований в TFS не очень, но это решается. Ира Сурова на ЛАФ будет рассказывать, как они скрестили TFS и Enterprise Architecht. Кроме того, ходят упорные слухи, что TFS будет интегрироваться с Borland CaliberRM.
С моей точки зрения, СУТ, не встроенная в ALM, - вещь в себе. Полноценное управление требованиями возможно, только если оно замкнуто на все процессы разработки. То есть СУТ должна быть либо частью системы ALM, либо прозрачно интегрироваться с другими инструментами.
Нуууу ... я скажем так, изнутри наблюдаю попытки позиционировать TFS как инструмент для аналитика требований, с полноценной генерацией документации в соответствии с локальными или международными стандартами. Назвать TFS СУТ (скажем, даже если взять за основу основные функции СУТ изложенные тут http://www.uml2.ru/forum/index.php?topic=1116.45) думаю будет очень с натяжкой. Для agile TFS может быть использован ... но не понятно зачем такой тяжелый инструмент тогда в agile?
То что СУТ должна быть интегрирована в АLM - не вызывает вопросов, но то что СУТ должен быть "комбайном", в котором можно и управлять проектом и проектировать - я не соглашусь. Это вызывает устойчивый "когнитивный диссонанс" (с). А чтобы допилить TFS до состояния внятной СУТ - придется потратить приличное кол-во человеко-часов, что не всегда рентабельно.
-
... в СУТ аналитики формализуют, создают и управляют требованиями и делают постановку задачи архитектуре или сразу разработчику ...
Тут тоже есть один момент, который мне не понятен - что есть "постановка задачи"? Вот я как аналитик разработал требование "Система должна иметь возможность расчета X по набору данных Y <при условии Z>". Что должен сделать аналитик, чтобы "ПОСТАВИТЬ ЗАДАЧУ" проектировщику? Для меня "постановка задачи" - это собственно указание проектировщику/разработчику реализовать требование (набор требований)/запрос на изменение .... но это функция менеджера (проекта) вроде как? Или я не прав?
-
сообщение устарело
-
...Возвращаясь к теме. Небольшая статья, иллюстрирующая возможности управления задачами в Cradle, показывает всего лишь то, за что борятся многие системные инженеры - возможность обеспечения сквозной трассируемости проектных данных. Думаю необходимость этого не нужно обосновывать, т.к. об этом написано и в этой ветке тоже (попытки скрутить СУТ, TFS и т.п. относятся именно к этому).
И здесь важно не то, кто управляет задачами (т.к. в разных компаниях процессы разные), а важно то, что у команды есть единое информационное поле. И то, что аналитику не нужно вылазить, например, в MS Project (пусть даже web-access), для того, чтобы посмотреть какие на него назначены задачи и отчитаться по ним. И то, что он имеет возможность тут же связывать с этими задачами требования, модели, другие проектные данные (например, выявленные им риски), является несомненным преимуществом, т.к. экономит прежде всего время дорогостоящих специалистов.
А интеграция с MS Project позволяет руководителю проекта работать в привычной для него среде, радуясь диаграмме Ганта и т.п., в то же время имея все проектные KPI из Cradle, выведенные, например, в SharePoint.
Добавлю также, что разделение деятельности организации на процессы, не должно приводить к искусственной информационной дезинтеграции. Поэтому то, что есть некий выделенный процесс "управление требованиями" не означает, что требования должны храниться отдельно от задач (имеется ввиду в другой системе).
Некоторые комментарии ...
1. Обычно в MS Project гранулярность работ в WBS не столь детальная. В этом случае необходимости частого переключения на Project, чтобы сдвинуть % выполнения работы нет, т.к. в контур задач по управлению проектом скорее всего попадет работа типа "создания ЧТЗ на модуль/подсистему". Для этого достаточно в конце дня отметить прогресс, и то, если есть необходимость ежедневной отчетности. Другой вопрос, когда мы имеем поток запросов на изменение, в рамках поддержки созданной системы, но это уже собственно процесс, а не проект, если конечно набор изменений не трактовать как мини-проект ...
2. Логика любого универсального инструмента заключается в возможности описывать и создавать артефакты (work items в терминах TFS) и иметь возможность их связывания (в том же TFS если мне не изменяет память можно делать именованные связи, и даже их рассматривать как отдельный work item, что иногда несколько усложняет работу по выстраиванию связей). И это позволяет проводить трассировку проектных артефактов м/у собой, что решает задачу сквозной трассируемости: "запрос на изменение-требования-проектные решения-код-тесты".
Эта схема может быть "усложнена" заданиями (tasks, считай, нарядами на работу) и приобрести вид "запрос на изменение-задание на разработку/изменение требований-требование...", что несомненно увеличивает накладные расходы на учет, что не всегда оправдано. Мне лично нравилась идея которая была заложена в Rational Suite, когда в том же Req Pro не было необходимости импортировать таски из ClearQuest, но появление новых артефактов в ReqPro можно было ассоциировать (через интеграцию) с тем или иным запросом на изменение или таском. Что позволяло а) решать вопросы отчетности (в т.ч. автоматически через статус готовности созданного артефакта(ов) внутри ReqPro) б) не "морочить мне как аналитику голову" не нужными мне "work items", которые маячат перед глазами, к тому же еще и в иерархической форме. А что делать, если работа аналитика, это только часть таска :) ?
3. "Информационной дезинтеграции" не будет, но аналитику должно быть удобно работать, решая свои задачи. Усложнять для этого инструмент и создавать "комбайн" тоже смысла нет. Rational же решал этот вопрос вполне эффективно, используя разные инструменты и их интеграцию.
-
сообщение устарело
-
Тут тоже есть один момент, который мне не понятен - что есть "постановка задачи"? Вот я как аналитик разработал требование "Система должна иметь возможность расчета X по набору данных Y <при условии Z>". Что должен сделать аналитик, чтобы "ПОСТАВИТЬ ЗАДАЧУ" проектировщику? Для меня "постановка задачи" - это собственно указание проектировщику/разработчику реализовать требование (набор требований)/запрос на изменение .... но это функция менеджера (проекта) вроде как? Или я не прав?
в контексте моего поста "постановка задачи" - оборот речи. я имел в виду документацию, которая получается в результате работы аналитика, и по которой проектировщик/разработчик может приступать к своей части работы согласно техпроцессу.
Мы с вами об одном пишем, но разными словами. постановка задачи (в классическом понимании) выполняется PMом, но обоснование и оценка требования или CRа - за аналитиком. на основании этой оценки и формализации требования выстраивается техпроцесс разработки ПО и в первую очередь - постановка задачи PMом на разработку артефактов анализа(FSP/SRS/ППР), проектирования(HLA,LLA, Design) и т.д.
(в том же TFS если мне не изменяет память можно делать именованные связи, и даже их рассматривать как отдельный work item, что иногда несколько усложняет работу по выстраиванию связей). И это позволяет проводить трассировку проектных артефактов м/у собой, что решает задачу сквозной трассируемости: "запрос на изменение-требования-проектные решения-код-тесты".
на самом деле именнованные связи имеют небольшое количество стереотипов. линейные связи между айтемами действительно можно отслеживать и типизировать, но, боже мой, как много времени уходит на поддержку этих связей, заведение айтемов и прочего в тфс. и визуализация трассирований оставляет желать лучшего. как ни крути, TFS создан больше для разработчиков, а не для аналитиков. и на данный момент ничего конкурентного для работы с внешним заказчиком, по сравнению с IBM предложить не может.
либо я не обратил на это решение внимания.
pmle,
вы меня извините, но вы чересчур злоупотребляете пиаром Cradle :)
-
сообщение устарело
-
Мухо, готова простить Вас, если Вы поясните, из чего Вы сделали такой вывод :)
Если вы используете chrome - нажмите Ctrl +F и напишите слово Cradle. затем оцените как часто оно встречается в ваших постах ;)
-
сообщение устарело
-
pmle,
вы меня извините, но вы чересчур злоупотребляете пиаром Cradle :)
А если подсчитать частоту упоминания ЕА, Word и Excel, то наверное всех форумчан можно объявить как тайных агентов Sparx Systems или Microsoft ;)
-
Спасибо за подробный ответ.
Я попробую подытожить, если с чем-то не согласны - пишите.
1. Какие бы инструменты не использовались для данных процессов, должна быть обеспечена информационная интеграция.
2. Рассматриваемые нами инструменты позволяют теми или иными усилиями обеспечить такую интеграцию.
Какие-то из инструментов имеют такую интеграцию по умолчанию, какие-то требуют допиливания.
3. Удобство разнесения функций по подсистемам оценивается разными специалистами по-разному, исходя из специфики их работы, привычек и т.п.
4. И что касается темы топика, то здесь, с учетом доступных альтернатив, чем на большее количество подсистем побито информационное пространство, тем ниже ROI, т.к. выше совокупная стоимость лицензий, допиливания, скручивания, обслуживания и т.п.
Основной интерес заключается в осуществлении конкретных вещей:
1. Иметь возможность сквозной трассировки от требований к проектным решениям, коду и тестам в интересах управления изменениями и конфигурацией системы.
2. Иметь возможность осуществления ресурсного и календарного планирования в части проектного управления, при этом получая от команды данные по факту.
3. И чисто для аналитика - иметь возможность генерации документации требований в различных форматах (i.e. требований разных стандартов)
Это может быть реализовано как набором продуктов, интегрированных между собой, так и в рамках одного "комбайна". При этом, следует заметить, что как минимум конфигурационное управление и управление изменениями может быть реализовано очень даже неплохо на бесплатных продуктах, не требующих затрат на лицензирование. Что повлияет положительно на ROI, но TCO нужно будет считать кончено ... но в случае, если я делаю конфигуправление и управление изменениями на знакомых мне инструментах затраты на обслуживание будут не столь велики. В случае расчета ROI, перекладывая на деньги экономию времени, которое тратиться непродуктивно на переключение м/у системами интересно было бы получить оценку этого времени в день. Вы наверняка считали бизнес-кейсы по инструменту и этот бенефит закладывали, приведите пожалуйста ту оценку, которую вы закладываете (?). По моим ощущениям, при необходимости ежедневной отчетности, это время не составит более 5 минут в день (именно ПЕРЕКЛЮЧЕНИЕ, а не сама отчетность по факту выполнения заданий!), интересно узнать вашу оценку.
И некоторые комментарии
А. Возможно идеи, заложенные в Rational Suite были и правильные, но насколько я знаю, полная их реализация там сильно страдала. Что собственно и заставило нас 7 лет назад провести фундаментальное исследование систем, тогда мы и нашли Cradle. Со связкой с ClearQuest я не работала полноценно, с этим работали другие отделы, но связку с Rose знаю неплохо, она меня не устраивала.
Кстати, на тот момент в Cradle также было разделение на модуль управления требованиями и моделирования (как в Rational) и надо сказать, когда 3SL полностью объединил эти два модуля в одной системе, это сняло большой объем рутинных операций. Так что этот комбайн мне очень даже нравится :).
Как пользователь и Requisite и Cradle, могу сказать однозначно - Cradle. И этот выбор был сделан еще в 2006 году (продаем мы его с 2011 года). Там просто несравнимый объем возможностей для аналитиков. Особенно, если они готовы к MBSE.
Но, всем ли нужны возможности такого глубокого анализа и контроля ситуации? Именно поэтому, в начале топика я спрашивала, а какие проблемы хочется решить?
Б. Для того, чтобы не морочить голову ненужными данными, существует система разграничения прав доступа и области видимости, а также визуально настраиваемые запросы и представления.
В. Насчет проблемы с частью таска - проблемы не поняла.
Ок, хотел бы узнать, каким образом осуществляется трассировка в Cradle на исходный код из запросов на изменения (и заданий, созданных на их основе)? При этом очень интересно еще иметь возможность трассировки на определенный релиз, выраженный в исходном коде, некоторого модуля? С трассировками на тест-кейсы более-менее понятно, их можно завести как отдельную сущность и трассировать на них и от них ... Собственно для целей управления конфигурациями интересно понимать, в рамках чего и кем было сделано то или иное изменение.
Кроме этого, как осуществляется генерация документации требований (в т.ч. с возможность получать "дельта" документы на разные релизы)?
По части таска поясняю - таск может быть назначен на группу (аналитик, разработчик, тестер) и как в этом случае Cradle позволяет делать отчет по выполнению работы аналитика, например и в итоге собирать готовность всего таска в целом?
-
А если подсчитать частоту упоминания ЕА, Word и Excel, то наверное всех форумчан можно объявить как тайных агентов Sparx Systems или Microsoft ;)
Ну так-то остальные форумчане EA или Excel не продают. Пора завести, как минимум, специальный бэдж "Это пользователь является продавцом Cradle" и вешать его под аватаркой вместо "Newbie" или "Hero member" :)
-
Ну так-то остальные форумчане EA или Excel не продают. Пора завести, как минимум, специальный бэдж "Это пользователь является продавцом Cradle" и вешать его под аватаркой вместо "Newbie" или "Hero member" :)
Но у нас вообще нет запретов на рекламу, связанную с тематикой форума - раз, pmle - конечно, пропагандирует систему, которую продает, но это нормально, что есть, чем человеку гордиться. Ну и это же не просто рекламный треп.
-
Коллеги, pmle несомненно использует форум как площадку для продвижения Cradle, и это нормально. Мы все это прекрасно понимаем. С моей точки зрения, пока дискуссия носит вполне цивилизованный характер - ничего предосудительного в этом нет. У меня даже появился некоторый интерес в том, чтобы хотя бы поверхностно (и при этом не тратя много времени ;) ознакомиться с возможностями продукта. По "закону жанра", pmle, как грамотный продавец, поделиться парой ссылок на этот счет :).
-
сообщение устарело
-
Pmle, честно говоря я не вполне понял, "что вы таки имели сказать за "жанр" (с). Но если вы зарабатываете на продаже инструмента и консалтинга вокруг него, то будьте готовы к тому, что на ваши сообщения кто-то будет смотреть как на непрямой маркетинг. Думаю, что тут нет ничего предосудительного. Все все понимают. К слову, вам удалось обратить, например, мое внимание на этот инструмент, я даже задал вопрос о некоторых возможностях этого инструмента, и был бы рад услышать ответы. Не думаю, что кто-то здравомыслящий будет игнорировать "факт наличия профессиональной среды", и большинство читателей форума очень даже не против "быть в курсе". Не вполне понятно с чего вы решили, что кто-то "закрывает дорогу другим", с моей точки зрения оснований для подобного вывода явно не достаточно.
К инструменту невозможно относиться с завистью или надеждой ;) .. вот честное слово, не могу себе представить зависть по отношению к топору :). Инструмент либо позволяет решать задачи более эффективно, либо не позволяет.
-
Коллеги, вставлю свои 5 копеек - мы решили, что можем позволить себе выделить некоторое время на "ковыряние" какой-нибудь понравившейся нам СУТ. В итоге имеем пилотное внедрение Девпрома, сейчас планируем запуск "боевого" проекта, но ориентироваться будем только на ощущения команды, ибо снятых метрик у нас нет.
После этого уже будем готовы принимать осмысленное решение об использовании.
Свой опыт описали в виде короткой статьи: http://analyst.by/predposyilki-k-vnedreniyu-devprom-alm-kak-sredstva-upravleniya-trebovaniyami/
-
ориентироваться будем только на ощущения команды, ибо снятых метрик у нас нет.
гагага. Это было очевидно уже по запуску темы.
Дети растут, а грабли все те же.
-
Что делать... СУТ хочется, а метрики за прошлые проекты сделать уже не можется :)