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

×


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

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


Сообщения - Denis Beskov

1876
Проектирование / Re: Базы данных
« : 19 Июля 2007, 22:29:55 »
Jem, тут всё очень просто.

С какой-то точки зрения, системы бывают более трансформационными (трансформирующими) или более реактивными (интерактвными).

Первые были известны раньше и для их моделирования использовались нотации, основанные на парадигме преобразования потока и смены состояний - IDEF0, IDEF1, DFD, Finite Automata (функциональная парадигма).

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

Несмотря на большую распространённость реактивных систем, трансформационные тоже до сих пор встречаются и умеют своё достойное место.

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

В качестве лакмусовой бумажки - почему если UML существует с 1997 года, такие монстры как Oracle, SQL Server и Sybase не используют его в своих средствах моделирования и выполнения миграции данных (Oracle Warehouse Builder, MS SQL Data Transformation/Integration Services, Sybase Power Designer Information Liquidity Model)? Да просто потому, что UML плохо подходит для этой задачи.

Ну т.е. можно конечно попытаться поискать UML Profile для данного класса задач, но я не думаю, что овчинка будет стоить выделки, если речь идёт об обучении.

Если так уж хочется моделировать - используйте нотации DFD, BPMN. Если целевая БД - Oracle, Sybase, SQL Server - то лучше сразу упомянутые мной инструменты.

Кстати, следует переименовать тему в что-то типа "Моделирование системы одноразовой миграции и консолидации данных".

1877
Ну, МГТУ в ДВОЙКУ ведущих вузов не входит, факт.

Работодатель ищет прежде всего тех людей, чей менталитет ему ближе - немудрено, что ребята из МГУ и МФТИ ориентируются на свой вуз.

1878
Компании, занимающейся разработкой перспективных веб-стартапов, требуется бизнес-аналитик.

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

Требования к кандидатам:
- отличные аналитические способности;
- любовь к русскому языку, к работе со словом, умение писать тексты доступным языком и без грамматических ошибок;
- способность читать тексты на английском языке без затруднений;
- умение работать с большими объемами информации;
- владение интернет-терминологией.

Желательно:
- выпускник или студент последнего курса одного из ведущих вузов страны (МГУ, МФТИ);
- глубокие и обширные знания российского и мирового интернет-рынка (компании, проекты, технологии, тенденции);
- отличная память;
- инициативность;
- разговорный английский.

Условия:
- талантливый коллектив опытных разработчиков, дружеская обстановка;
- атмосфера стартапа;
- поощрение любознательности, семинары/конференции/обучение;
- песпективы карьерного роста;
- медицинская страховка;
- уровень оплаты: от 40000 руб. по результатам собеседования.

Писать сюда.

1879
Да не боком оно относится, а самым прямым. Просто каждый круг специалистов тянет терминологию на себя - дескать, это мы и есть.

Business Intelligence - это вид деятельности, технологии и инструменты, связанные с анализом деятельности предприятия, чаще всего вне контекста рассмотрения рынка вокруг. Технологически обеспечиваются средствами OLAP, Data Mining, Knowledge Discovery. Другие специалисты под BI понимают конкурентную разведку (т.е. фокус - не на предприятие, а на среду), промышленный шпионаж. Методы здесь соответствующие - сбор и анализ разнородной неструктурированной информации, прослушивания, вторжения и т.д.

Competive Intelligence - это где-то на стыке упомянутых двух пониманий BI - т.е. мы хорошо знаем свои проблемы, сильные стороны и возможности, а также аналогичные хар-ки наших конкурентов, постоянно ведём управление бизнесом в их контексте, строим прогнозы, анализируем перспективы и целесообразность тех или иных изменений.

Knowledge Management - есть распространённый штамп, что сейчас всё больше основной ценностью предприятий являются не физические и не столько финансовые активы, сколько персонал и знания (Особенно с этим носится IBM). Соотв. тут возникают задачи того, как накапливать знания, как организовывать доступ к ним, как порождать новые знания, как избегать их утечки, как эффективно ими распоряжаться.

Business Analysis - ну под этим вообще до фига чего может пониматься, имхо, начиная со стратегического анализа, анализа конкурентой среды, финансового анализа, анализа бизнес-процессов и т.д. Вот только наши друзья из IIBA упорно хотят под этим понимать нечто вроде Enterprise Requirements Engineering.

1880
Boatman, мне Стас Калханов что-то говорил про бизнес-дисциплину "управление по целям" (если не ошибаюсь), дескать там всё обсуждается и раскрывается. Если не найдёшь, можешь попробовать до него добраться через МойКруг.

Юра, ты похоже в своём "консалтерском" сленге скоро совсем перестанешь говорить по-русски) Как только тебя заказчики понимают )

Бенефиты, вэлью, косты, перформанс, скоуп ))) Обычно этим люксофтовцы грешат, оказывается, не они одни )

1881
Только это не FAQ, т.е. это не часто задаваемые вопросы.
Понятно, что FAQ - это совсем на обязательно в буквальном смысле то, о чём кого-то постоянно спрашивают. Скорее, это рекомендация к FAQ, "о чём бы я спрашивал, будь я на твоём месте".

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

Саша, возьми типы требований из Вигерса, плиз. Сгруппируй по категориям, исправь языковые ошибки. Функциональные требования не описывают функции в современном понимании, они описывают требуемое поведение. Набор требований определяется не на стадии анализа. Когда формировать требования - это уже методика организации процесса, мы до неё просто не добрались.

1882
Евгений, также как и я до последнего момента, не мог нормально зайти на форум. Вот его презентация.

1883
Q. Автоматизированная информационная система (АИС)?
A. Автоматизированная информационная система - ИС, в которой процесс ведения модели автоматизирован за счёт использования информационных технологий и устройств, их реализующих.

В состав АИС традиционно включают:
  • методическое обеспечение (МО) - описывает принципы, законы, правила и регламенты ведения информационной модели, функционирования АИС;
  • программное обеспечение (ПО) - реализует операции по ведению информационной модели за счёт предоставления интерфейсов взаимодействия с системой и выполнения алгоритмов реагирования/поведения, подчинённых МО;
  • лингвистические средства (лингвистическое обеспечение, ЛО);
  • информационные ресурсы (информационное обеспечение, ИО) - чаще всего выражено в виде различных описаний конфигураций и БД;
  • вычислительное и коммуникационное оборудование (техническое обеспечение, ТО).

1884
Q. Что такое Автоматизированная Система (АС)?
A. Автоматизированная система - система, предназначенная для автоматизации какой-либо деятельности, процесса.

1885
Q. Что такое Информационная модель?
A. Информационная модель - совокупность описаний какой-либо системы (объекта), отражающая наиболее существенные (в данном контексте рассмотрения) закономерности её структуры и процесса функционирования, зафиксированная на некотором языке или в другой форме. Модель может быть представлена текстом, аналитическими выражениями, таблицами, диаграммами и т.д.

1886
Q. Что такое Информационная Система (ИС)?
A. Информационная система - система, предназначенная для ведения информационной модели другой системы, чаще всего физической, но не обязательно (см. Игры). Исторически в качестве таковых выступали различные конторские книги, дневники, журналы учёта. В настоящее время ИС часто называют автоматизированные информационные системы.

1887
... и ни одной собственно диаграммы ВИ с разбором почему надо рисовать так а не иначе.
Упс, а тут скорее всего типичное предубеждение :)

ВИ - это сценарий. Диаграмма ВИ - это заголовки сценариев. Вся соль - в сценариях.

То, что не хватало картинок и конкретики - это да. Но на картинке было бы 1-2 эллипса и всё (если не рисовать диаграмму деятельности или последовательности).

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

1888
Важно, никто не спорит.
Но всегда ли мы пишем и цели и задачи? Как правило что-то одно. И всегда ли мы управляем целями и делаем их декомпозицию? А всегда ли это нужно? Просто в теории все хорошо получается, особенно в книжке когда рассмотрен один аспект, а на практике сталкиваемся со многими НО. Поэтому я и говорю, что смешивание уровней целей (читать как смешивать цели и задачи) не является большой ошибкой
Саша, по мне так это некий императив аналитика - если некое множество имеет критерий для различения, надо этот критерий использовать - divide et impera. А уж для "смешивать" для аналитика - страшный грех :)

Т.е. у тебя аргументация такая - смешивать цели и задачи - небольшая ошибка, т.к. на практике есть какие-то НО. Какие НО? Какой один аспект рассмотрен в книжке?

Если ты согласишься, что неправильно поставленные и не скорректированные цели могут с большой вероятности привести к неуспеху проекта, то как же может быть небольшой ошибкой смешение?

1889
ИМХО важно не только формировать цели списочным образом, но и указывать как они между собой взаимосвязаны, в частности, если одни подчинены другим. До сих пор как-то механизмы такой увязки не обсуждались, обычно увязка получалась через функциональную декомпозицию (типа у головной функции есть цель, а у подфункции - подцели и иерархия целей-задач увзывается через структуру функций). Но Якобсон (в книге Aspect oriented programming) указал, что так можно поступать не всегда: есть цели которые могут реализоваться функциями, уже подчиненными другим целям. Т.е. важен не только список целей и задач, но и как они взимосвязаны.
Угу, я систематически прошу ПМов, которые мне приносят эти 2 списка, либо перегруппировать задачи по целям, если у них отношение 1:N, либо нарисовать диаграмму зависимостей. Не рисуют ) Похоже, это какая-то системная прошивка - "это мы не проходили, это нам не задавали, в PMBOKе и  шаблонах документов этого нет" )