91

Обучение / Re: Литература по анализу - а существует ли она?

« : 06 Ноября 2011, 21:27:45 »

Я тут на днях делал подборку рекомендаций книг по требованиям: http://bagcheck.com/bag/1377--

Хорошая подборка. Могу добавить, что упомянутая в ней книга с непривлекательным на первый взгляд названием User Stories Applied полностью называется User Stories Applied for Agile Software Development, что звучит гораздо интереснее. Это действительно "методичка", описывающая полезные практические приемы работы аналитика в Agile проекте.

92

ПО Аналитика / Re: Слоёный WORD или другой инструмент для гибкого изменения спецификаций

« : 06 Ноября 2011, 21:16:27 »

{IF SPE1}
Пользователь вводит данные лимита
{ENDIF}
...
{IF SPE2}
Пользователь даёт команду "Сформировать"
{ENDIF}

Шаблон с полями Word + макрос на VB, который подставляет значения полей из таблицы вида:
(код_версии_требований, название_поля, значение_поля).
(SPE1, РАЗДЕЛ4_П3, Пользователь вводит данные лимита)
(SPE2, РАЗДЕЛ4_П3, Пользователь даёт команду "Сформировать")

93

Для всех / Re: Какие вопросы вы задаёте заказчику?

« : 20 Июля 2011, 22:14:37 »

>> Мне предстоит встреча с этим заказчиком в пятницу и я набросал несколько вопросов для первичного обсуждения.

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

94

Конференции Семинары и Тренинги / Re: Встреча Сообщества по обсуждению чаптера ИИБА, Мск, 14 июля

« : 06 Июля 2011, 20:19:43 »

Место удобное, я бы заглянул, но вот именно в четверг - никак не получается.

95

Идеи и мозговой штурм / Re: О сроках хранения документов

« : 13 Мая 2010, 20:14:22 »

http://www.esar.ru/work/standart/23

96

UML SysML и пр. / Re: usecases. ассоциация актера с актером

« : 22 Апреля 2010, 10:09:50 »

А почему инструмент должен это запрещать?

Power Designer не дает так нарисовать, например.

Actor обычный классифкатор,

Эдуард, поясни плиз, насчет классификатора, не понятно.

Конечно можно (или нужно) включить некую проверку валидности связей на диаграмме,

Может просто в Парадигме можно рисовать все что угодно, но потом положено нажать кнопочку типа Check Model, которая покажет все ошибки?

97

UML SysML и пр. / Re: usecases. ассоциация актера с актером

« : 22 Апреля 2010, 00:04:07 »

Диаграмма была сделана в Visual Parafigm for UML. 

C Visual Paradigm не имел дела. Возможно, авторы Visual Paradigm имеют в голове какое-то расширение семантики ДВИ, если допускают рисование таких ассоциаций. А что написано в парадигмовской документации про такую ассоциацию, какой смысл они в эту черточку вкладывают?

98

Управление Проектом / Re: Управление изменениями в рамках проекта

« : 21 Апреля 2010, 23:59:33 »

НО на деле вылазят различные недочеты модели, доп согласования и пр.

А что мешает включить в проектный план на следующий месяц кроме "новых задач", еще и время на устранение "недочетов модели, доп. согласования и пр."?

99

UML SysML и пр. / Re: usecases. ассоциация актера с актером

« : 21 Апреля 2010, 10:49:31 »

получается Actor ассоциируется с Actor2

Ассоциация на диаграмме вариантов использования означает участие актора в данном ВИ, поэтому может быть только между ВИ и актором. Ни одно нормальное средство моделирования не даст нарисовать такую ассоцицию, как на приведенном рисунке.
Если два актора взаимодействуют при работе с системой, то их взаимодействие - это и есть тот самый сценарий использования системы (овал), с которым ассоциированы оба актора. при этом один из них, как правило, первичный актор (инициирующий взаимодействие), а другой - вторичный.

100

Конференции Семинары и Тренинги / Re: Training Labs 2010 - условно бесплатные билеты

« : 15 Апреля 2010, 18:19:41 »

Я бы сходил. Могу поработать камерамэном при второй камере, кстати, если нужно

101

Варианты Использования (Use Case) / Re: Use cases и модификация стандартных модулей

« : 12 Апреля 2010, 11:18:03 »

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

...
15. Фоторедактор перемещает и масштабирует карту так, чтобы в окне находился нужный ему район.
16. По завершении перемещения/масштабирования Система отрисовывает попадающие в окно фототочки и группы, раскрывает/формирует группы согласно правилу 4 (Отображение групп), перезапрашивает в качестве изображения фото для ленты те фото, точки которых попадают в окно ^*.
17...
..
___сноска________
^* <Вместо стандартного> Модуль gmaps перезапрашивает для ленты фото текущей коллекции, находящиеся в раскрытых группах.

 

102

Варианты Использования (Use Case) / Re: Use cases и модификация стандартных модулей

« : 08 Апреля 2010, 17:08:07 »

Возможен вариант, который написал 474. Это минимизирует трудозатраты Аналитика и увеличит понимание разработчиков. Но в данном случае будет не понятен бизнес-пользователям.

  Это и наблюдается сейчас.

С другой стороны Вы ИМХО путаете понятие Пользовательских требований и постановка задачам разработчикам. Это две разные вещи. Пользовательские требования должны включать все ВИ, которые хочет пользователь. Постановка задачи может включать в себя, только то, что нужно доработать.

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

103

Варианты Использования (Use Case) / Use cases и модификация стандартных модулей

« : 08 Апреля 2010, 13:39:37 »

  Решил попробовать с помощью use cases описать требования к сайту, создаваемому на платформе CMS Drupal. Drupal - это типичный фрисофт модульной конструкции. То есть есть компактное ядро, к которому друпалеры разрабатывают модули для реализации конкретного функционала и выкладывают в общий доступ. Постепенно в сообществе накапливаются сотни модулей на все случаи жизни. Несколько десятков из этих модулей настолько популярны, что их функционал и поведение известны всем разработчикам, и они являются de facto стандартными.
  Естейственно, при разработке хотя бы чуть-чуть специфического сайта возникает необходимость кастомизации (модификации поведения) некоторых модулей. Технически это не вызывает никаких проблем, т.к. все модули в комментированных исходниках, надо просто переписать соответствующие места в шаблонах PHP или переопределить функции javaScript.
На начальном этапе все выглядело неплохо: я написал пользовательские истории (пользовательские use cases), они на ура были согласованы с заказчиком; специалист по Друпалу подобрал состав модулей, наиболее близко обеспечивающих нужное поведение.
 
  Далее возникло следующее противоречие.
  С одной стороны, детальное описание юз кейзов, реализуемых системой, достаточно бессмысленно. Все равно 95% поведения системы определено стандартными модулями, и совершенно нецелесообразно как что-то в этом поведении менять, так и документировать его. Документировать стандартное поведение представляется нецелесообразным, т.к. эта документация не нужна ни разработчикам (уже все разработано), ни тестировщикам (уже протестировано), ни пользователям (они считают стандартное поведение само самим разумеющимся). НО! Надо описать, в чем должны состоять ОТЛИЧИЯ требуемого поведения ОТ СТАНДАРТНОГО. То есть напрашивается некая диаграмм вариантов использования с зависимостями не типа <<include>>, а что то вроде <<replace>>.
То есть описание может выглядеть как-то так: "При просмотре новостей пользователь работает с сайтом в соответствии со стандартным сценарием просмотра новостей с использованием модуля view, за исключеним того, что в главном потоке ВМЕСТО стандартной последовательности действий системы при щелчке по заголовку новости  в списке новостей делается то-то и то-то...

  С другой стороны, стандартное поведение модулей Drupal все же не так известно людям, как стандартное поведение компонентов UI Windows. И если я с чистой совестью могу при описании Windows-приложения сослаться на то, что поведение компонентов должно соответствовать  UX Interactions Guidelines, то при ссылке на стандартное поведение модулей Drupal я рискую получить полное непонимание некоторых читателей документации (уже получаю).

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

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

104

Сообщество Аналитиков / Re: Перевод BABOK

« : 30 Марта 2010, 11:23:34 »

Сделал пример с Vision, так подойдет?

Мне кажется, нормально. Попробую на досуге описать первые попавшиеся в BABoK термины, может еще какие идеи появятся.

105

Другие Методологии / Re: Уровни метамодели базы данных

« : 29 Марта 2010, 18:31:09 »

Это abstract статьи?