61

Теория моделирования и нотации / Кратность полюсов ассоциации. Различие 1--1 и 1--0..1

« : 21 Мая 2014, 23:06:47 »

Коллеги, добрый вечер!

Раньше не предавал этому большого значения и старался всегда использовать связи 1--0..1 между классами вместо 1--1. Сейчас же решил разобраться в отличии этих видов ассоциаций, но, к сожалению, не смог обнаружить чёткого ответа на возникший вопрос. Прошу помочь.

Насколько я понимаю "1" возле одного класса говорит о том, что перед созданием второго класса уже должен быть создан объект первого. "0..1" не устанавливает такого требования, то есть при создании объекта второго класса объект первого класса может не существовать. Таким образом никаких вопросов по сути связи "1--0..1" у меня не возникает.
Вопрос возникает когда я пытаюсь осмыслисть связь "1--1". Насколько я понимаю объект первого класса не может быть создан без существующего объекта второго класса. Аналогичное правило действует и в обратном направлении. Вопросы такие:

• Как тогда можно создать объект одного из классов если они не могут "жить" друг без друга?
• Как трактовать связь "1--1" с однонаправленной ассоциацией? Как это будет выглядеть в коде приложения?

62

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 21 Мая 2014, 12:34:21 »

Формулировки потребностей и возможностей (need и feature) довольно близки. При изучении этой темы (на практике), часто возникают разногласия . Хотя и поясняется, что потребность - это пожелание, которое может остаться мечтанием или превратится в требование, фича - уже требование, то чему должна соответствовать система (иметь свойства). Возможно я дую на воду, но предполагал, что есть какие-то маркеры позволяющие
а/ различать потребности и фичи
б/ корректно их формулировать чтобы не путать в последствие, ну хотя бы в рамках одной группы

Для того чтобы ощутить различия я обычно рассматриваю следующие свойства NEED и FEATURE:
- Удовлетворение NEED способствует решению проблемы (PROBLEM) или реализации возможности (OPPORTUNITY) при помощи набора FEATURE и прочих решений (вне АС).
- FEATURE обязана быть направлена на решение проблемы (PROBLEM) или реализацию возможности (OPPORTUNITY).
- Одна NEED может быть удовлетворена за счёт одной или нескольких FEATURE.
- Одна FEATURE может удовлетворять несколько NEED.
- Иногда NEED может быть удовлетворена без автоматизации и для неё не будет существовать ни одной FEATURE.
- Иногда NEED может быть вообще проигнорирована, если её удовлетворение не критично. Тогда соответствующая ей FEATURE будет иметь низкий приоритет, может быть исключена из текущего скоупа, оставлена с пометкой COULD (MoSCoW) или запланирована на будущие релизы.
- Иногда NEED не может быть удовлетворена за счёт автоматизации (или это дорого) и требуются другие решения (вне АС).

Коллеги, прошу дополнить/поправить если вы считаете что упущено что-то важное или что-то категорически не соответствует вашим представлениям.

63

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 17 Мая 2014, 23:15:38 »

Спасибо, интересное и похожее прочтение. Правда, что такое Opportunity

Opportunity - возможность, предоставляемая бизнесу рынком, новыми технологиями, законодательством и т.п. К примеру технологии бесконтактных банковских карт типа PayPass позволяют организациям повысить скорость оплаты товаров и услуг, снизив издержки. Также, к примеру, общественный транспорт может отказаться от биллинга собственных транспортных карт и соответствующей инфраструктуры, потому что стоимость проезда будет списываться напрямую с банковских карт. Это возможность, предоставляемая новыми технологиями. Она по аналогии с problem statement должна быть описана в коцепции/Vision.

Моя (черновая диаграмма) во вложении (:

Эдуард, вы не могли бы привести примеры для каждого класса сущностей? Без них сложно понять модель.

64

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 17 Мая 2014, 01:08:28 »

И нарисовать вашу модель трассировки?

Как то так. Эдуард, Леонид, прошу высказать Ваше мнение.

Примерно. Но лучше сформулировать фичу как "Система держит Вас в курсе финансового состояния". Или ".. позволит иметь показатели под рукой в любой момент". Маркетологи придумают и получше.

Можно попробовать объяснить так: "Потребности - то, что желает потребитель. Фичи - то, что может система. Так выпьем же за то..."

Есть ещё такой пример:
http://www.samsung.com/ru/consumer/mobile-devices/smart-phones/samsung-galaxy/SM-G900FZKASER-features
Закладка с говорящим названием "Возможности". У потребителя есть потребность использовать смартфон в сырую погоду, а также в пыльных местах, и не бояться поломки. В этом ему поможет фича "защита от пыли и влаги".

65

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 16 Мая 2014, 14:20:00 »

Диаграмма будет позже.

66

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 16 Мая 2014, 14:18:51 »

Сергей, спасибо за ответ и интерес к теме.

Можно тогда дать определения бизнес-проблемы и бизнес-возможности? И нарисовать вашу модель трассировки?

Я думаю что будет лучше привести шаблоны для формулировки:
Бизнес-проблема может быть сформулирована примерно как Problem statement из RUP:

• Проблема [описание проблемы]
• оказывает влияние на [заинтересованные лица, на которых влияет проблема и её решение]
• результатом чего является [какое бизнес-воздействие оказывается проблемой]
• Проблема будет решена успешно, если [список ключевых измеряемых бизнес-преимуществ успешного решения]

Бизнес-возможность по аналогии примерно так:

• Банк имеет возможность [краткое описание возможности]
• для [целевой пользователь/клиент]
• ощущающего необходимость в   [краткая формулировка потребностей]
• В результате, [какие бизнес-цели могут быть достигнуты если удастся воспользоваться предоставляемой возможностью]

67

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 16 Мая 2014, 00:50:31 »

Эдуард, приветствую!

Для случая потребностей, вероятно, можно начинать фразы с "желательно, нужно, хотелось бы"

Потребности заинтересованных лиц я формулирую примерно так: "[Заинтересованному лицу 1] нужно...". А далее описание полезного бизнес-результата, который поможет решить проблему из Problem statement или воспользоваться бизнес-возможностью.
А слова "желательно, хотелось бы" лучше не использовать, потому что приоритет может меняться. Лучше использовать приоритеты типа MoSCoW.

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

Я бы сказал что возможность это не высокоуровневое требование, а удобный для обсуждения и планирования способ группировки системных требований. Их часто пишут на коробках ПО в виде списка возможностей. Также они перечисляются в списках "улучшений" в Release notes. К примеру для EA: http://www.sparxsystems.com/products/ea/history.html

Кроме того, хотелось бы узнать, какие типы связей вы предполагаете между этими понятиями?
Заинтересованные лица <имеют> потребности, которые <реализуются> через возможности, которые <детализируются, специфицируются> через системные требования ... ?

Я понимаю так:
Проект существует ради решения БИЗНЕС-ПРОБЛЕМ(Ы) или для того чтобы воспользоваться БИЗНЕС-ВОЗМОЖНОСТЬЮ(ЯМИ). Заинтересованные лица как часть бизнес-системы участвуют в решении БИЗНЕС-ПРОБЛЕМ и использовании БИЗНЕС-ВОЗМОЖНОСТЕЙ (не фичи). Решение БИЗНЕС-ПРОБЛЕМ и использование БИЗНЕС-ВОЗМОЖНОСТЕЙ невозможно без удовлетворения возникающих ПОТРЕБНОСТЕЙ заинтересованных лиц. ВОЗМОЖНОСТИ (фичи) удовлетворяют ПОТРЕБНОСТИ заинтересованных лиц и специфицируются системными требованиями.

68

Работа / Re: Работодатель по Вигерсу

« : 24 Апреля 2014, 07:46:21 »

Коллеги, всем приятного времени суток!

Перечитываю Вигерса (новое третье издание от Майкрософт пресс), и в голове возник следующий вопрос:
Знаете ли вы компании (работодателей), в которых аналитики работают максимально "по Вигерсу" ? Можете ли вы поделиться контактами?

P.S исходя из своего небольшого опыта работы у себя в регионе, все чаще нужны системные аналитики в интеграции.
Хочется попробовать себя немного в другом направлении.

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

69

Примеры / Re: Диаграмма классов и сообщений проверить

« : 15 Апреля 2014, 07:30:18 »

Добрый день.

1. Как Ваше описание предметной области связано с вопросом, заданным в конце? Для чего приведено описание?
2. Очевидно, проектное моделирование это создание какой-то модели в рамках проектной деятельности. Мне почему-то кажется, что вы хотели бы получить другую информацию. Тогда нужно уточнить вопрос.

70

Системный Анализ и Требования / Re: Cценарии версионирования/бейсланирования документов требований

« : 05 Апреля 2014, 13:22:51 »

Сергей, главное, на наш взгляд, чтобы полезно оказалось

Дмитрий, ваш подход мне кажется действительно правильным.

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

71

Системный Анализ и Требования / Re: Cценарии версионирования/бейсланирования документов требований

« : 04 Апреля 2014, 17:47:15 »

Коллеги, спасибо вам за кейсы, мы их учли и выпустили новую версию Devprom ALM 3.2,

Хитро.

72

ПО Аналитика / Re: Подскажите с помощью какого ПО сделана анимация???

« : 21 Марта 2014, 18:13:46 »

http://www.concerthotels.com/100-years-of-rock  - после загрузки страницы начинается анимация. По окончании можно выбирать отдельные блоки, при этом будут визуально выделяться связи с другими блоками.
Как такое сделать не владея flash-инструментами ?

Я предлагаю прежде чем переходить к реализации определиться с требованиями:)

73

Sparx / Re: Поделитесь опытом использования ЕА и SVN

« : 10 Марта 2014, 16:16:21 »

Сергей, возможно, я разленился или просто сильно перегружен, но я что-то не совсем понимаю, какие действия следует выполнить.
Что сделано
1. установлен svn клиент - sliksvn
2. на code.google - создан проект - структура аналогичная
3. с использованием TortoiseSVN выполнен check out

Что еще? Где и что апдейтится и коммитится, как при этом используется внешний svn и TortoiseSvn?

Может Вы просто опишите свои действия? Спасибо

Эдуард, дальше конфигурируется сам EA для работы через EA:
http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/projects_and_teams/usingversioncontrol.html

1. Запускаем EA и загружаем проект, который хотим поставить под версионный контроль.
2. Создаём новую конфигурацию SVN в Project | Version Control | Version Control Settings
3. Ставим под версионный контроль любой из пакетов из Project Browser. Контекстное меню пакета | Package Control | Configure ...

74

Sparx / Re: Поделитесь опытом использования ЕА и SVN

« : 09 Марта 2014, 15:29:36 »

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

Нужно группа должна работать над одним ЕА проектом. Предполагается, что будет использован code Google. На машинах предполагается использование TortoiseSVN. Как я понял, ЕА может работать с клиентским SVN, который следует установить. А TortoiseSVN только для облегчения некоторых действий, не более.

Эдуард, добрый день! У меня без проблем получилось по официальной инструкции http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/projects_and_teams/create_a_subversion_environmen.html
Что именно не получается?

75

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 06 Марта 2014, 22:19:36 »

Дискуссия пошла в какой-то этап взаимных упреков.

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

Не могу понять, почему понимание и умение использовать технологию сценариев - убого и вредно. Можно говорить об ограниченности метода.

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