TFS – это инструмент командной работы. Его интеграция с инструментом разработки требований типа EA позволяет всем участникам процессов разработки получать требования в виде, пригодном для использования в их процессах, и автоматически фиксировать результаты их труда в тех самых «статусах».

Да, примерно так. К тому же далеко не все в ЛК используют для разработки требований EA, кому-то достаточно Notepad, а кто-то пишет их прямо в TFS. Но в конечном итоге под учет все ставится в TFS-е.

Речь о том, что коллеги из Лаборатории Касперского используют TFS для управления версиями требований/моделей, поскольку Sparx этого не позволяет. Т.е. это вынужденная интеграция.
Если бы Sparx позволял управлять версиями требований и моделей - им бы для этого [управления версиями требований и моделей] TFS не нужен был.

Нет, конечно же нет. TFS поддерживает весь цикл разработки - от привязки Change Request'ов и багов к коммитам в исходники, и до сборки билдов.

Humbert,

обратите, пожалуйста, внимание, в контексте чего ведется обсуждение.

Целиком и полностью согласен, что Cradle - это первый продукт, который следует рассмотреть для решения задачи топикстартера. Помимо всего прочего, Cradle предполагает предварительную фиксацию технологии по работе с требованиями, а тто уберегает от множества ошибок, по сравнению с рисовалками. 

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

Я так вообще не фанат никакого ПО (а скорее открытых систем как класса)

Денис, а можете поподробнее рассказать, почему?

Всем привет!

Присоединяюсь к дискуссии.

Спасибо Леониду и Грише - полностью согласна с тем, что голова первичней, чем инструмент. Имея опытную голову и понимая свои потребности, в инструменте можно построить то, что нужно.

На встрече 31 марта мы будем рассказывать про инструменты в контекстах наших проектов (продуктовых, in-house, сервисных/инфраструктурных). Как уже сказал Дима DIV, далеко не все аналитики в ЛК используют EA, а вот TFS использует весь R&D, это был проект внедрения на весь департамент.
С удовольствием расскажу, как было на самом деле, чтоб не приходилось гадать, что там вынужденное, что к чему прикручивали и т.д.

Интересующие вопросы можно задать здесь, постараемся учесть при подготовке к встрече.

Humbert, если нужна какая-то дополнительная информация для сравнения, обращайтесь, буду рада помочь.

Сразу замечу, что на оба инструмента в связке на этой встрече рассказывать не планируем, так же как и про версионирование, так как это отдельные большие темы, обсудить которые мы не успеем за 1 встречу.

Рекламы инструментов не будет. Общий стиль: потребности - способ их удовлетворения - реализация в инструменте. Если при таких же потребностях используете выбранный способ удовлетворения в другом инструменте или подскажете подходящий другой способ удовлетворения тех же потребностей, будет здорово

С уважением,
Ирина Сурова

На встрече 31 марта мы будем рассказывать про инструменты в контекстах наших проектов (продуктовых, in-house, сервисных/инфраструктурных). Как уже сказал Дима DVI, далеко не все аналитики в ЛК используют EA, а вот TFS использует весь R&D, это был проект внедрения на весь департамент.
С удовольствием расскажу, как было на самом деле, чтоб не приходилось гадать, что там вынужденное, что к чему прикручивали и т.д.

Интересующие вопросы можно задать здесь, постараемся учесть при подготовке к встрече.

Надеюсь записи встречи будут, ведь аналитики не только в Москве водятся.
А тема действительно интересная

Надеюсь записи встречи будут, ведь аналитики не только в Москве водятся.
А тема действительно интересная

Не уверена, что запись будет, так как это решаю не я. Но если тема реально интересна, то мы можем поговорить об этом на ЛАФ. (http://conf.uml2.ru/)

Поскольку со стороны участников дискуссии имеются нарушения правил данного форума будет не лишним их повторить. Прочитайте их пожалуйста и сверьте свое поведение на форуме: Правила форума.

В частности прошу обратить внимание на следующее:

Запрещается:
 - Публикация грубых, оскорбляющих и унижающих сообщений. Ненормативная лексика разрешена только в исключительных случаях, когда изъятие нецензурных слов из предложения полностью изменяет смысл сообщения. В случае употребления нецензурных слов, бОльшая часть слова должна быть замаскирована спецсимволами. Оскорбительные высказывания в адрес любой страны, государства, народа и отдельных личностей нежелательны, а в отношении Российской Федерации, ее исторических предшественников и исторических личностей запрещены.
  - Публикация сообщений с использованием широкоизвестного приема демагогии под названием "Переход на личности". 

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

Хочу отметить, что публикации pmle не противоречат этим правилам.

Будьте вежливы и терпимы друг к другу. Ведите дискуссию в конструктивном русле.

Надеюсь записи встречи будут, ведь аналитики не только в Москве водятся.
А тема действительно интересная

присоединяюсь к пожеланию

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

Из своего опыта могу сказать след.:

1. Качество проработки изменения напрямую зависит от ваших знаний о системе, в которую изменения вносятся. Если не знаете систему, то первой обязанностью является изучать её на высоком уровне, а только потом изменять. В реальной ситуации может не быть возможности достаточно глубоко погрузиться (особенно в начале проекта),  но держать в голове приоритет изучения системы нужно всегда.

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

(Немножко оффтоп) 2.1 Купер сравнивает изменения ПО с рубцом после операции. Большое количество рубцов приводит к потере гибкости и хрупкости организма. Хорошо проработанные изменения отличаются не только полным описанием влияния, но и тем, что они стремятся к уменьшению количества рубцов в перспективе. Я не могу сказать, что всегда получается этому следовать, но держать это в голове тоже стоит.         

3. Изменения в больших системах подразумевает правку кода в куче мест сразу. Поэтому, на большие изменения можно писать отдельный документ. Может не всегда нужно это делать, но если не уверены в качестве анализа влияния, то можно подсунуть команде на ревью.
Я видел ситуации, когда даже сами разработчики затрудняются оценить последствия изменения для системы. Это вполне может встретиться на больших проектах.  Я никогда не видел ситуации, чтобы команда ругала отдельный документ на большие изменения. Кажется, он всем нравится. В любом случае, документ - это выражение вашей осмысленной работы над изменением.
Есть другой вариант. Если все спецификации содержатся в одном большом документе, то в качестве документа об изменении можно использовать diff версий(например - tfs + share point.wiki).  Если по проекту несколько спецификаций, то нужно обеспечит так, чтобы изменения во всех документах можно было просмотреть в одном месте. Не следует разработчикам заставлять лазить по куче разрозненных документов. Велика вероятность, что кто-нибудь что-нибудь да пропустит ...
Лично мне нравится для изменения дополнительно описывать причину, источник, и ещё пару параметров. 
Ещё мне нравится CR(change request) из той же самой DOORS. Видео можно на youtube найти.

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

5. Нужно выбросить из головы идею о том, что какой-либо инструмент когда-нибудь защитит от "человеческого фактора на 100%"  в плане анализа влияния изменений. Дело в том, что человеческий фактор начинается с момента внесения требований в это самый инструмент. Если внесены кривые, неполные и неактуальные требования, то  инструмент не поможет в любом случае.

6. Иногда изменения затрагивают большое количество чужих подсистем. Для таких случаев полезно иметь актуальные dfd или деплоймент диаграммы или диаграммы компонентов или спеки по интеграции. В любом случае, если вы знаете что, с вашей системой / подсистемой связана другая чужая, то всегда следует проверить возможное влияние на ней.     

Я умышленно ушел в сторону от вопроса инструментов. Считаю, что начинающий аналитик должен работать над содержанием и пониманием. Выработать свой стиль изложения и понять что хорошо, а что плохо. Для этого ворд подходит лучше. Он не создает рамок. Инструменты загоняют в рамки различных best practice. Само по себе это не плохо, но всему свое время. Надо научиться видеть картину сверху, чтобы потом суметь адаптировать свой подход  к изменениям в любой команде и к любому инструменту. Кажется, это будет универсально. 
Обещать не буду, но может поищу материалы, которые сойдут за гайдлайны по изменениям. 

Простите если кого утомил. многобуков. Не сдержался 

Я умышленно ушел в сторону от вопроса инструментов. Считаю, что начинающий аналитик должен работать над содержанием и пониманием. Выработать свой стиль изложения и понять что хорошо, а что плохо. Для этого ворд подходит лучше.

А почему ворд? Давайте уж сразу - чернила и бумага . А лучше пергамент. Но не перебарщивать - заставлять новичков высекать диаграммы на скалах не будем. Но вменим в обязанность непременное изучение каллиграфии. Годам к 150 из них получатся отличные аналитики. Жаль только не каждый доживет до момента принесения практической пользы....

Он не создает рамок. Инструменты загоняют в рамки различных best practice.

Инструменты ориентированы на методологии. Чтобы обьяснить тот же IDEF0 при формировании функциональных требований достаточно один раз нарисовать процесс на бумаге - если попытаться применить эту технологию на практическом примере,  аналитик тупо упрется в недостаток времени на разработку любых моделей кроме наивных.

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

Антон, конечно, Вы можете иметь свое мнение от прочитанной Вами дискуссии. Только мне, например, совершенно непонятно откуда возник этот тезис о первичности инструмента или о том, что существует инструмент, который решает все ваши проблемы волшебным образом. Если такой инструмент появится, то и специалист в этой области не понадобиться. Будем надеяться, что этого не случиться. Хотя искусственный интеллект развивается

А почему ворд?

"дабы дурь каждого видна была" (c)

Давайте уж сразу - чернила и бумага.

И так бывает. Не сказать, чтобы редко. Общаться езжу обычно с блокнотиком или вообще налегке - лист бумаги и ручку найти не проблема где угодно.

А лучше пергамент.

А где взять?

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

Правильно. Ни к чему их под Административный Кодекс подводить.

Но вменим в обязанность непременное изучение каллиграфии.

Кстати, многие японцы, посвятившие жизнь боевым искусствам, параллельно ей занимаются. Ибо много общего.

Годам к 150 из них получатся отличные аналитики. Жаль только не каждый доживет до момента принесения практической пользы....

Другое дело какой-нибудь ЕА: скачал, поставил - и сразу же твори нетленку.

. . .

Извините, не смог пройти мимо без шутки. )

"дабы дурь каждого видна была" (c)

В модельках она еще лучше проявляется:)

И так бывает. Не сказать, чтобы редко. Общаться езжу обычно с блокнотиком или вообще налегке - лист бумаги и ручку найти не проблема где угодно.

Это ж интервьюирование - совсем другая тема. Тут любые средства хороши для получения информации - и блокнотик, и пассатижи...

 

Кстати, многие японцы, посвятившие жизнь боевым искусствам, параллельно ей занимаются. Ибо много общего.

И я про то. Если стоит задача организовать тоталитарную секту аналитиков, то только каллиграфия. Никаких компьютеров

Другое дело какой-нибудь ЕА: скачал, поставил - и сразу же твори нетленку.

Не вижу я ничего плохого в том, что bizagi не даст пустить поток сообщений внутри пула, Bpwin проверит декомпозицию, а EA не позволит соединить что-угодно с чем угодно. От каких то грубых ошибок инструмент убережет срозу, от ошибок потоньше уберегут шаблоны , примеры и модели коллег.

Другое дело, что наличие инструмента совершенно никак не влияет на необходимость собственно обучения . Причем у рабочего наставника. И с этой точки зрения лучше наставник с вордом, чем такой же новичек с EA.

В модельках она еще лучше проявляется:)

Мне текст больше нравится. Половина "аналитегов" по одной-две ошибки на предложение лепят. Ну а чо, и так же все понятно? Это не говоря уже об осмысленности написанного. А вот модельки не так очевидны. Спасибо инструментарию, который не дает сразу выстрелить себе в ногу.

Это ж интервьюирование - совсем другая тема. Тут любые средства хороши для получения информации - и блокнотик, и пассатижи...

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

Не вижу я ничего плохого в том, что bizagi не даст пустить поток сообщений внутри пула...

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

Выложены материалы со встречи про инструменты в Лаборатории Касперского https://www.facebook.com/kaspercareer/posts/1288178701196559