Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - bas

4171
Изучил:
Разработка типовой АИС регламентации проектной деятельности на примере ФЦП"Электронная Россия" в рамках создания единой государственной системы управления и передачи данных

Не впечатлило. Упор делался на дизайн, что в ТЗ не должно быть, а требования почему-то выненесены в приложение. Моделирование "as is" и "to be" вообще поразило: оказался пункт "as is" вообще отсутсвует. Ну и в довершение ко всему Задачи зачем-то были засунуты в раздел "2.2 Цели создания системы".

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

4173
ВИ: Получить доступ к торгам
Мне кажется очень обширное понятие. ИМХО, лучше написать: "Войти в Систему"

- Брокер должен авторизовать клиента и обеспечить соблюдение других правил
- Другие клиенты ????? (хотят видеть, кто сейчас находится в системе??)
Брокером в данном случае являемся мы или Система. Если ты о внешнем Брокере, то тут при Логине заинтересованности внешнего Брокера никакой нет.
Др. Клиенты ничего тоже не хотят. Если только Админ хочет видеть все сессии в системе.

Постусловие:
Постусловие ИМХО лучше писать после ветки событий


1. Клиент идентифицирует себя
Как он себя идентифицирует с функц. точки зрения???????

З.Ы. Ну зачем изобретать велосипед??? Наберите в гугле Use Case Login .....

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

"Большое количество разных иконок", "небольшая стоимость продукта", "невозможно править нескольким участникам" - это свойства конкретного инструмента, а не метода. Я говорил про то, что этот метод не требователен к инструментарию - можно рисовать в бесплатном фримайнде, можно маркером на доске, можно мелом на асфальте :)
Я что не видел, чтобы документы сейчас писались от руки ....

"Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования" - это типичная ошибка формулировки проблемы как отсутствия некоторого свойства одного из возможных решений имеющейся задачи. Шаблоны сами по себе - не самоценность, они нужны для чего-то (выявления требований в нашем случае). Если это что-то достижимо другими методами, то это не значит, что эти методы ущербны. Всё равно что предъявлять претензии автобусу, что у него нет пантографа. Обычно такие ошибки совершают приверженцы какого-либо продукта.
Я больше имел ввиду мысль emanaev

4175
пробный шар:

Войти в систему:
Вот вам эталон: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=197.msg1798#msg1798
Вам нужно гонять шарик м/у актером и Сиситемой и все, никике детали про Сервере не нужны ...

Имеет ли смысл составлять Activity Diagram если сценарий довольно прост и легко воспринимается из текстового попунктного описания?
Нет, не имеет. Если сценарий сложный, то можно пояснить диаграммой.

4176
У ВИ "Войти в систему" - одна большая цель - получить доступ к контексту Системы, не сделав этого он не может ничего делать дальше.

Теперь расписывайте каждый ВИ в виде сценария.

4177
Вот что получилось:

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

4179
Ну да, что-то я перепутал группу с факультетом ...

4180
Через кого Вы будете торговать, имя?? Т.е. протокол patsystem API к кому будет идти от вас.
Мне кажется Вы путаете понятия. Вообще процесс идет так:
Брокер->Биржа (или даже скорее ECN, а потом уже биржа)   - выставление ордера
Брокер->Клиринг - сообщить все ордера, какие были выполнены на Бирже за промежуток времени (день, час ...)
Клиринг->Биржа  - сверить полученный список отправленных и реально исполненых на Бирже
Клиринг->Брокер - сообщить какие Ордера реально исполнены, а какие нет. Это происходит раз в день

Причем этот процесс делают только прайм Брокеры. А подброкеры просто все отправляют прайм прокеру:
Брокер -> Прайм Брокер -> Биржа (или даже скорее ECN, а потом уже биржа)

Вы что реально хотите клиерить ордера или просто отправлять их на Биржу??

4181
Так, уже лучше. Т.е.:
Предоставить новый сервис/возможность для 10.000 Клиентов одновреммной торговли на Биржах (каких? всех? какими инструментами?).
Контролировать процесс торговли Клиентами.
Далее ....

З.Ы. Все таки предлагаю отказаться от термина clearing firms, если Вы не вкладываете что-то еще в это понятие кроме Брокера.
З.З.Ы. Выложите диаграмму в формате Розы, я подправлю.

4182
Я бы еще добавлил Студент -- Курс -- Группа

4183
Жаль, что никто не поддержал мою идею выписать на доске все + и - такого подхода, или области применимости/не_приминимости.

Помогу Денису и напишу здесь:

Плюсы и область применения:
  • Маленький (возможно средний) проект с небольшим кол-вом требований и аналитиков
  • Хорошая наглядность (видна не противоречивость) и лекго/быстро можно набросать несколько 10ов требований
  • Если есть куча муккулатуры, называемая ТЗ, то можно лекго вычленить требования и их структурировать
  • Небольшая стоимость продукта (MindMap)
  • Легкий импорт/экспорт в Excel/Word/Project
  • Больщое кол-во разных доп. иконок, связей и т.д.

Минусы и область слабого применения:
  • Не возможно управлять большим кол-вом требований
  • Не поддерживается версионность
  • Не возможно править одновременно несколькими участниками
  • Не возможность синхронизирования с Excel/Word/Project, т.е. экспортнули в Проджект там что-то попроавили и обратно
  • Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования

Дополняйте ....

4184
Денис, отличный доклад, новые свежие идеи - это всегда супер.
Хотя многие придя на семинар, ожидали другого, и я в том числе, но мне понравилось. Интересно как ожидания других участников скорелировали с тем, что они получили?!

4185
Цели проекта:
Создать программу для онлайн торговли фьючерсами и опционами на биржах.
Нужна цель Разработки или Системы:
Цитата: ГОСТ 34.602-89
2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.


Возможности системы:
-   Получать данные с внешних источников (clearing firm, новостные сайты, другие провайдеры)
Что за данные?[/i]
-   Отсылать ордера в clearing firm.
Я бы называл clearing firm - брокером. Разница огромна. Вам же не нужно осуществлять clearing как таковой?[/i]
-   Редактировать ордера.
Я бы сказал в первую очередь выствить ордера и только потом редактировать[/i]
-   Менять и запоминать layout клиентской программы.
-   Менять и запоминать цвета форм, шрифты клиентской программы.
-   Экспортировать формы и таблицы клиентской программы.
В один пункт, да и то я бы это опустил[/i]
-   Предоставлять графики.
В пукнт с данными[/i]
-   Распечатывать ордера.
Только ордера?? Это не та важно[/i]
-   Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
-   Возможность у клиента иметь несколько accounts.
-   Управление accounts для админа.
-   Отчеты по account – для админа и клиента.
Входит в управление[/i]
-   Размещение ордера админом для клиента.
В п. размещение ордера[/i]
-   Клиентская программа ведет лог событий.
Не так важно[/i]
-   События сопровождаются звуками.
Не важно[/i]
-   Авто обновление компонентов клиентского приложения.
-   Управление margins клиентов админом.
А это огромный пукнт, Вы сами не знаете еще на что подписались[/i]

Реализация программ планируется на C#  DOT.NET.
В качестве протокола для связи с clearing firm используется patsystem API.
Связь клиентского приложения и сервера через remoting.
Можно БД и ОС указать

Можно выделить два актера
 - Админ
 - Клиент
А Брокера или Поставщика данных куда дели??

Пользователь:
-   Разместить ордер
-   Редактировать ордер
-   Создавать отчет
-   Экспортировать данные
-   Распечатать ордер
Это не ВИ - это функции. ВИ должен нести цель для актера. Какая цель у ВИ "Распечатать ордер"?

Админ:
-   Размесить заказ для клиентов
-   Управление пользовательским эккаунтом
-   Управление margins клиентов
Вот это больше похоже на ВИ. Но если Вы пишите все в глаголах, то так и пишите, н-р, "Управлять ...."

но не все, например
Многие ваши ф-ии, войдут в ВИ как составная часть

Как оформляются такие вещи в документации?
Какие??