1

ПО Аналитика / Re: Управление изменениями требований

« : 13 Апреля 2016, 19:57:43 »

В какую неожиданную сторону развилась тема!
Про ИИ хочу добавить (не в рамках рекламы, а в качестве распространения информации от IEEE):
В рамках 24th IEEE International Requirements Engineering Conference Sept. 12–16, 2016, Beijing, China (http://www.re16.org/)
состоится
Monday, September 12th, 2016:
WS01. AIRE: 3rd Intl Workshop on Artificial Intelligence for Req. Eng.
      http://re.cs.depaul.edu/aire16/
Вероятно, если покопаться, то можно найти материалы предыдущих workshop'ов. В принципе, в рамках RE предыдущих годов возникали доклады на эту тему, если реально будут желающие, могу попробовать найти.

2

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 14:58:20 »

При просмотре не покидал вопрос: а так ли ценен документ как структура хранения требований, что за него нужно бороться?   
Можно ли разрабатывать требования не ставя в качестве конечной цели получение документа?

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

3

ПО Аналитика / Re: Управление изменениями требований

« : 05 Апреля 2016, 16:55:13 »

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

4

ПО Аналитика / Re: Техническая сторона интеграции EA и TFS Лаборатории Касперского

« : 28 Марта 2016, 00:02:49 »

А, ты имеешь в виду, что акт экспорта полностью интерактивен и контролируется пользователем? Или вы используете средства automation в ЕА?

Акт экспорта полностью интерактивен, контролируется пользователем

5

ПО Аналитика / Re: Техническая сторона интеграции EA и TFS Лаборатории Касперского

« : 23 Марта 2016, 00:00:09 »

Ира, а как он указывает? Через тэгированные значения? Или какие-то другие трюки?

Мышкой. На пакет, на выделенный набор в ProjectBrowser'е или на диаграмме, на текущий элемент, все, что нам потребовалось

6

ПО Аналитика / Re: Техническая сторона интеграции EA и TFS Лаборатории Касперского

« : 22 Марта 2016, 13:33:29 »

Аналитик на диаграмме или в ProjectBrowser указывает, что он хочет экспортировать. Экспортируются UseCase, Requirement. Экспорт без передаточных таблиц.

7

ПО Аналитика / Re: Управление изменениями требований

« : 22 Марта 2016, 13:25:06 »

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

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

8

ПО Аналитика / Re: Техническая сторона интеграции EA и TFS Лаборатории Касперского

« : 22 Марта 2016, 10:08:18 »

Humbert, встреча будет 31 марта

Ответ на вопрос: любые требования до TFS предварительные? Нет, не так.
 
Картинка, на которую разработчик может глянуть, отдельно от требований  - достаточно редкий случай, но в определенном контексте бывает.
Обычно это список формализованных требований, а вот аттачем к требованию может быть и картинка (ну например, элемент, описывающий Usecase (сценарий), а к нему аттачем добавлена диаграмма последовательности или состояний, другой популярный вариант входной информации: doc-отчет из EA. Т.е. сформированный по конкретному бизнес-требованию SRS|ТЗ

9

ПО Аналитика / Re: Управление изменениями требований

« : 22 Марта 2016, 10:00:51 »

Всем привет!

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

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

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

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

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

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

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

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

10

Работа / Re: Работа для тех, кто только закончил ВУЗ (начало карьеры)

« : 22 Января 2015, 14:22:07 »

А у нас в Москве есть младший системный аналитик, да еще и стажер-аналитик

11

ПО Аналитика / Re: Комплекс ПО для начинающего специалиста. Рекомендации.

« : 01 Февраля 2013, 09:52:32 »

Про EA - легкий вход - дистрибутив 30 метров, ставится очень просто, можно быстро начать работать. Про материалы на русском копирую свое сообщение 2008 года (надо же, пригодилось :
Официального мануала на русском нет. Но обычно на вопросы здесь можем ответить, также можно faq на сайте почитать + в качестве шпаргалки можно использовать нашу с Эдом презентацию с TrainingLabs - http://luxoft.ru/downloads/edu/surova_galiaskarov.rar , в файловом архиве uml2.ru есть перевод доки по особенностям размещения EA при коллективной работе.

12

Идеи и мозговой штурм / Re: Личности в дисциплине разработки и управления требованиями

« : 05 Декабря 2012, 22:45:28 »

Я не знаю там за мир во всем мире и дисциплину разработки и управления требованиями, но по мотивам треда вспомнилась мне лучшая книжка по использованию  UML в процессе разработки, которая объяснила мне полностью логику построения кросс дисциплинарных моделей на UML (от бизнеса до диаграмм классов для кода) - Рамбо, Блаха "Uml2.0. Объектно-ориентированное моделирование и разработка"

13

Поздравления / Re: Поздравляем Эда - Galogen'а с днем рождения!

« : 14 Июня 2012, 14:53:58 »

Присоединяюсь!

Спасибо, что ты есть, наш аксакал!

14

Sparx / Re: Работа с требованиями в ЕА

« : 02 Мая 2012, 17:30:49 »

Коллеги, подскажите, пожалуйста, в какой версии ЕА лучше работать с требованиями?
На данный момент у меня стоит версия 8.0  Понятно, что при загрузке столбец "TagValue_Логическое обоснование" игнорируется.

Что вы понимаете под "работать с требованиями"?
Если на странице http://www.sparxsystems.com/products/ea/index.html - тыкнуть на Compare Edition, то можно сравнить функционал разных редакций.

Про TagValues - в списке полей на глаз такого нет, возможно поможет хелп EA тема CSV Specifications
А вот если это разные элементы, то тут еще сложнее. Т.е. если это требование поступило от нескольких департаментов, то выгрузка в эксель требуется уже иерархической структуры, по умолчанию так просто не получится. А для чего вообще нужна выгрузка в эксель?

15

Системный Анализ и Требования / Re: Обеспечение повтороного использования требований - кому это надо?

« : 29 Сентября 2011, 21:54:30 »

Мои ответы на вопросы Ichy:
1. Я бы не стала надеяться на то, что консервация возможна и на это будет выделено время. В моей практике просто стараюсь сразу писать требования так, чтоб они были понятны не только мне, и их можно было переиспользовать без дальнейшей доточки. (т.е. все работы по причесыванию лучше делать при рождении требования). Соблюдение при этом кучи правил, например, 10 из указанной статьи, не всегда возможно, иногда я сознательно делаю по-другому (например, далеко не всегда соблюдаю атомарность, если потребителям это будет мешать)
2. Самостоятельно провести ревью своих требований - сложно, у меня это нормально получается через определенный период времени, когда  уже работаю на другом проекте. В этом случае эти требования как чужие, читаю, как в первый раз. Когда есть возможность, с удовольствием даю требования на ревью коллегам. Но в любом случае мои  требования будут читать согласанты - бизнес, разработчики, архитекторы, иногда тестеры. Большую часть ошибок они найдут.
Мотивировать другого аналитика на ревизию требований - имхо - должен начальник аналитиков, который отвечает и стремится к повышению квалификации своих сотрудников и обмену информацией по функциональным областям. (т.е. 2 цели - повысить качество требований и распространить знания в команде)
3. При эволюционном развитии продуктов   - правильно! это позволяет закрыть большие дыры в описании системы там, где есть унаследованный функционал