Странное заключение, которое никак не следует из того, что управлять задачами в 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, как грамотный продавец, поделиться парой ссылок на этот счет .