2806

Sparx / Re: Enterprise Architect: Проблема с генерацией отчетов

« : 17 Декабря 2009, 13:10:47 »

Отправил запрос

2807

Sparx / Re: Как задать стартовую модель

« : 17 Декабря 2009, 13:00:16 »

start page все равно открывается
Дефолтовая диаграмма открывается тоже, и закладка с ней становится активной..
А вот от start Page избавиться никак ?

А чем смущает стартовая страница?

2808

Sparx / Re: Enterprise Architect и управление требованиями

« : 16 Декабря 2009, 23:31:12 »

Эд, тебе для развития или для работы?

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

И для работы - говорил же, у нас приняли предварительно решение использовать ЕА в качестве инструмента фиксации требований. Не уверен, что именно им все будем управлять, о есть такая к этому тенденция. ПМ активно формирует модель - нашей системы (нашего видения задачи) и модель нашего очччень важного клиента. Продвинулся далеко. Меня приглашал для рецензирования. Именно я высказал ему мысль, что использования пакетов для группировки целесообразней вложения одних требований в другие. ПМ досадовал, что при переносе иерархически связанных требований на диаграмму не появляются связи агрегации. Я высказал идею, что и не должно, т.к. все-таки агрегация не подразумевает обязательной иерархии, а иерархии агрегацию. Хотя тут вопрос спорный, типично иметь has-a Иерархию и is-a ирерахию. Но имеет ли место быть тут именно это?

Если для работы, то может стоит сначала задать вопрос "а для чего все это нужно"?

Ответил?

Скажу по себе
1. Пакеты использую для группировки по предметным областям или типам. В зависимости от ситуации

Хорошо, тип понятно но какой тип? А что значит группировка по предметным областям?

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

И какая семантика иерархии - простая организация? От общего к деталям? Можешь примерчик дать?

3. Связь реализации появляется при привязывании требований к вариантам использования через свойства последних

Да согласен, а как ты назовешь связи между бизнес-целями и детализирующими их требованиями? Зависимости?
Мы правда не пользуемся ВИ, как я не пытаюсь пропагандировать этот подход - говорят нецелесообразно

4. Все возможные выборки и по типам и по другим признакам настраиваются во View в виде фильтров. Их удобно использовать для различных группировок и управления требованиями

Эти вещи понятны, я их привел для общности картины, если что

Может кто-то дополнит. Вообще каждый для себя сам определяет как уобней, чтобы не делать лишней работы и экономить время и силы. Как говорит Саша Юняев (ака bustor)

Удобство для себя не означает удобство для других. Я не однократно сталкивался с этим, и тут трудно что-то поделать, приходится либо смирится либо доказать, что твоя классификация лучше.

Все таки меня волновала связь владения owns и связь агрегации (composed of , part of), Правда присмотревшись внимательно обнаружил, что обе эти связи обозначаются совершенно одинаково. Т.е. можно утверждать, что это одно и тоже. Жаль что в ЕА не автоматизирована визуализация связей таких вложенностей явно, хотя может и правильно...

В общем я предлагаю в этой теме дискутировать по поводу применимости ЕА для управления требованиями, как? Если нет - убью тему...

2809

Sparx / Re: Enterprise Architect и управление требованиями

« : 16 Декабря 2009, 23:10:48 »

Я тебе один умный вещь скажу, только ты не обижайся.
Ты сам - модератор!

Вай дарагой, а не модератор, понимаешь, я это администрация:) А модераторы тут bas, да Irr:)

2810

Sparx / Re: Enterprise Architect и управление требованиями

« : 16 Декабря 2009, 19:58:55 »

А что никто не ответит? Глупость сморозил, удалить? Эй модераторы!!!

2811

Sparx / Re: Enterprise Architect: Трассировка требований

« : 16 Декабря 2009, 19:57:01 »

Сплошные воркэраунды и костыли.
Не дозрел еще EA до управления требованиями

Ну это ведь какова стратегия у ЕА. Имхо они как СУБД, а приложение им корректно управляющее пишите мол сами:)

2812

Sparx / Re: Enterprise Architect: Проблема с генерацией отчетов

« : 16 Декабря 2009, 19:55:53 »

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

2813

Обучение / Re: Системный аналитик с нуля!

« : 16 Декабря 2009, 19:53:58 »

Тут неплохо бы определиться что понимать под термином "системный анализ"!!!

мы уже определялись на заре возникновения форума. поищите в разделе Системный анализ

2814

ПО Аналитика / Re: Группировка тем.

« : 16 Декабря 2009, 19:53:11 »

Я имею в виду вот это меню и вот такие выпадающие списки.

ААААА

2815

ПО Аналитика / Re: Группировка тем.

« : 16 Декабря 2009, 19:44:42 »

Ссылка на карту форума появилась внизу, в подвале рядом с копирайтом (ни слова о юзабилити!)
Выпадающие списки тем видны на главной странице форума (кнопка "Начало" в меню форума).

Гриша ты чудо! Кстати чтобы не ворчали по юзабилити можно смонтировать так как сделано в forum.joomlaportal.ru. Новости по форуму мы не ведем, так вот в этом блоке вполне можно выводить ссылки на самые важные моменты:)

Забыл, а в опере при наведении на начало ничего нет

2816

Sparx / Enterprise Architect и управление требованиями

« : 14 Декабря 2009, 20:31:06 »

Если не приживется убьем!

Для начала хочу задать несколько вопросов по организации группировок требований и связей.

Итак, ЕА позволяет нам группировать требования разным способом:
1. Пакеты - пакеты классические элементы группировки и ограничения поля внимания.

Вопрос такое: в каком случае целесообразно использовать именно пакеты? Или, что лучше выбрать за элемент классификации. Пакеты это иерархическая, строгая, но не гибкая классификация.

2. Вложенность - т.е. требование можно вложить в другое требование. В ЕА это связь владения, она никак графически не отображается, но проявляется в виде иерархии.

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

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

4. Группировка по типу требований - это сквозная группировка и тут, кажется, все понятно.

5. Зависимости - наверное просто показывает влияние одних от других и к группировке не относится.

6. Группировка по тегированным значениям - позволяет группировать требования по различным условиям (дата, проект, что-то еще)

7. Еще можно выделить ассоциации - можно ли считать это тоже своего рода группировками? Когда работают ассоциации?

8. Могут ли требования находится в отношении реализации? И может ли это являться также группировкой?

2817

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 14 Декабря 2009, 19:04:50 »

В Microsoft Office Document Image Writer тоже все заработало, все в цвете и в ажуре!

Ну вот все оказалось гуд.

2818

Sparx / Re: Добавление атрибутов требований

« : 14 Декабря 2009, 18:53:31 »

... Возможность менять значения атрибутов только для отдельных элементов очень нехорошо

Возможно ты и прав. Правда не нарушает ли это принципы ревью и принятия (одобрения) требования. Т.е. каждое требование должно быть рассмотрено и одобрено. Если есть возможность сделать это скопом - не потенциальная ли это лазейка для включения не проверенных требований?

Кстати в ЕА есть система скриптинга, не может ли данная фича помочь в изменении атрибутов скопом? Поизучай?

Ветку или даже подраздел в ветке, коли это будет возможно.

2819

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 14 Декабря 2009, 17:39:27 »

Проверил на Microsoft Office Document Image Writer - а у меня - Ч/Б...

Имхо дело в чем-то другой

2820

Консалтинг и Внедрение / Re: Бесплатная, многофункциональная, сетевая CRM система - A-Number CRM

« : 14 Декабря 2009, 08:35:00 »

Виталий, а какое отношение это имеет к нуждам бизнеса. Чуть меньше, чем немного больше нуля?

Сергей, а уменьшение стоимости операций, трудозатрат и трудоемкости операций не имеет никакого значения?
Я понимаю ты фанат теории ограничений - ну и что?