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

×


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

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


Сообщения - bas

4186
Записали на видео, качество будет не супер, но как говориться чем богаты ....
Видео выложено будет чуть попозже.

4187
Это достаточно большая задача, на прошлой работе я как раз занимался этим и строил похожую систему. Резюме аналитика в двух словах быть не может. Если Вы только начали заниматься данной темой, то вам будет очень не просто. Сформулируйте пока цели проекта и основные возможности системы в виде каждого отдельного пункта, предложите на базе какой архитектуры будете это делать и оформите в виде документа - Vision. Потом начертите какие по вашему мнению есть бизнес объекты, потом можно накалякать СДВИ (только правильно,если не знаете как, то лучше просто детализируйте каждую фичу) и каждый ВИ распешите в виде сценария. Вот пока ближайшее ваши действия. Я могу накалакать основные БО, какие должны быть в системе, и помочь вам в описании требований, но это уже получиться прямое решение вашей проблемы, которе за бесплатно не делается. Если хотите бесплатных советов, то спрашивайте конкретно, и я вам отвечу.

4188
Это не система, а всего лишь маленький, но важный, кусок большой программы.
Вам что надо??? Разграничить доступ клиента к фин. инструментам и счетам? или что??

4189
Данная модель служит для:
1. Хранения самой структуры всех фин. инструментов и их тикеров
2. По каждому Фин. Инструменту в зависимости от типа можно хранить и изменять статические параметры этих инструментов: name, lot size, min lot, maturity, strike etc.
3. По каждому тикеру (Contract) можно хранить и изменять динамические параметры: last price, ask, bid and their volume

Данная схема является базовым элементом для расширения в любой трейдинговой системе: заявки/сделки, хранение истории котировок и т.д.
Здесь специально не указаны атрибуты сущностей, чтобы человек тупо не передирал эту схему, а немного подумал...

4190
Еще акцентирую внимание на следующем:

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

2. Нет четкого планирования:
2.1. Нет плана разработки - что за чем идем и кто что контролирует. Т.е. програмеров контролируют тестеры, а кто контролирует аналитиков и архитекторов?. Нужен общий план/методология разработки ПО
2.2. Нет плана всех работ. Если бы он был, то лекго было бы сказать/понять при поступлении нового проекта - усе мощностей уже нет.
2.3. Нет детального плана на следующие пару итераций/недель. С этим и свзяано хаотичное перебрасование с одной задачи на другую.
2.4. Нет контроля - ну не сделал и хай с ним, сделал - хорошо.

3. Многие идеи Agile, которые я изложил здесь, можно лекго начать применять практически везде.

4191
UML SysML и пр. / Re: FAQ - UML
« : 27 Марта 2007, 23:21:52 »
На что я должен обратить внимание, когда выбираю UML средство для моделирования?

Предварительный ответ:
http://www.developer.com/design/article.php/1593811

4192
Нашел достаточно большой список вопросов и ответов для подготовки на сертификацию по UML:
http://www.allenpitts.com/UML/UML_fund_070215.html

4193
Коллеги!

Т.к. область знаний, о которой расказывает наш ресурс, сильно расширилась, надо бы выработать новую концепцию нашего ресурса. Предлагаю оставить 3 слова слогона в ней -- Use-Model-Lead, остальное поменять.

Во-первых, предложу старый вариант:

Цитировать
По сути, это первый сайт на русском языке, на котором объединены материалы по первым стадиям разработки программных продуктов - сбор требований, бизнес и системный анализ, проектирование. Естественно, на каждой из этих стадий может и  должен использоваться UML как наиболее удобное и современное средство моделирования.

На Форуме сайта  в разделе Примеры Вы всегда сможете найти проекты, сделанные  с использованием UML и других технологий проектирования. Планируется каждый месяц обсуждать новый пример.

В разделе Консалтинг Вы найдете описание платных услуг по разработке небольших моделей на UML и проектированию сложных программных продуктов в соответствии с методологией RUP.

Девиз нашего сайта:
2 Use      - используй Материалы и Форум на нашем сайте.
2 Model  - моделируй, делай сам, выкладывай на Форум свои проекты и тебе помогут.
2 Lead    - лидируй, будь первым, зная передовые технологии проектирования.

Надеюсь, Вам понравится здесь, и Вы найдете много полезного для себя.

Огромное спасибо за большой вклад в создании сайта galogen.

С уважением, Б.А.С.





4194
Так в этом и есть основной вопрос, камера как я понимаю у многих есть, а вот времени .... Приноси, заснимем, если всем будет некогда, тогда выложим в сыром виде, разрезаную на куски.

4196
kidman,
Да, этот вопрос поднимался, если один человек будет, то удасться записать семинар на видео.

4197
Один из способов -- в п.2.2. должны быть фичи, а в п 3.2 фичи делализируются конкретными требованиями (и группируются по фичам). Так легче контролировать scope, гогда он "облюжен" фичами.

Модератор: Пожалуйста, пишите нормальными словами, или поясняйте значения сленга...
Немного поясню:
Фича или feature или характиристика - это основные функции или хар-ки, которые система должна делать.
Scope или масштаб - это описание границ проекта.

Т.е. переведя на русский, получается:
Хар-ки Системы описываются в п.2.2., а в п 3.2 они детализируются требованиями (и группируются по хар-кам Системы)
Если известны основные хар-ки Системы, то легче контролировать масштаб проекта и не вылезать особенно в сторону за рамки проекта, когда фантазия клиента сильно разыграется.

4198
Если не затруднит вас - ознакомтесь и выскажитесь.

Вот что приходит на ум:
1. Какие документы можно использовать для формализации пользоват. требований?
2. Что дальше? Когда можно остановиться на пользоват. требованиях, а когда надо продолжить
3. Не описан метод выявленения ВИ или хотя бы ссылки на документы. Будут все до функций декомпозировать ВИ
4. Не сказано, что требования - это все же что делает пользователь с системой, а не как, т.е. сценарий не первичен.
5. Нет методики выявления пользоват. требований: анкеты, методы и т.д.
6. Нет других представлений польз. тр. Не сказано, когда лучше/можно не создавать польз. тр.
7. Все же название статьи должно быть не "ВИ", а "Польз. тр." или "Представление польз. тр. в виде ВИ"

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

4199
Эд, я думаю ты пошел немного не в том направлении. Коберн хотел показать статическую структуру, что у кого есть, а не как во что преаобразуется.

Вот посмотрим на диаграмму 2, она наиболее простая:
Основоной Актер имеет какие-то цели, каждая цель представляется одним или несколькими ВИ, каждый ВИ имеет некую ответсвенность. Что такое SuD - я не понял.

В принципе все Д очень информативны и представляют собой правильную структуру. Возможно их можно как-то использовать для дальнейшей автоматической гененрации - надо подумать.