481

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

« : 23 Октября 2009, 13:47:19 »

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

по второму согласен, за исключением оговорок сказанных ранее (когда таких данных в природе нет)

482

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

« : 23 Октября 2009, 10:16:45 »

2 div:
да это к слову... в том смысле, что простого можно не ждать, а нужно в любом случае действовать.

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

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

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

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

483

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

« : 22 Октября 2009, 11:48:16 »

1. Вообще то "мотороллер не мой" , т.е. банк не мой, просто попросили проконсультировать как оперативно решить проблему. Через месяц-другой посмотрим, что получится на практике.

Посмотрим-посмотрим. Но пока всё-таки неясно в чем суть проблемы. IMHO кто-то не делает своей части общей работы.

2. Наверное, не так просто на деле "спрямить бизнес-процессы". Вы лично пробовали подойти к хозяину банка - простому миллиардеру и так предложить спрямить ему пару-тройку бизнес-процессов; мол, я вот тебе дам совет, как тебе разбогатеть? Вот я когда то по неопытности, воодушевленный правильными книжками, попробовал...

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

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

А дать одному подразделению права на редактирование данных, за которые ответственно другое подразделение - кто подпишется под этим, если за этим правом КОНКРЕТНАЯ ответственность?

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

3. Основные повседеневные задачи хорошо решаются, система в целом работает хорошо. Но аппетит приходит во время еды - появляются новые потребности, не учтенные в начале. Я думаю, все сталкивались с этим?

Хорошо построенная архитектура даст ответ. Тогда-то и станет ясна разница хорошего и кусочно-лоскутного способа ее построения.

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

Крамолу скажу: Не их дело возражать - их дело работать, как требуется бизнесу. Сложно - учитесь!

4. Немного, это данные типа словарей: редко меняющиеся и небольшие по объему - до нескольких сотен записей.

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

В общем, успехов в большом и трудном деле...

484

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

« : 21 Октября 2009, 18:02:29 »

А насчет этого пассажа - вообще слов нет...

как говорится: "как это нет слов - надо было подготовиться" (с)

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

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

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

Делитесь... раз уж безудержный интерес)))

Вас что-то конкретное интересует или так... безудержный интерес? :о))

485

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

« : 21 Октября 2009, 14:34:17 »

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

кому нужен этот эксель? или у Вас кусочно-лоскутная автоматизация?

486

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

« : 19 Октября 2009, 22:54:02 »

Эээээ, таким макаром Вы никакого OLAP'а не построите. Т.е. конечно, технически систему заставить работать можно (как асфальтоукладчик без асфальта), но вот отчеты с правильными данными, ради которых всё затевается, Вы не получите, пока, собственно, данные, доступные для обработки, не окажутся в хранилище. Скажите об этом своему руководству прямо: так, мол, и так, нет данных - нет и отчетов.

487

Работа / Re: Как надо допрашивать работодателей на собеседовании

« : 16 Октября 2009, 15:22:51 »

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

488

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 15:18:04 »

дайте алгоритмам (включая готовые секретные алгоритмы заказчика) какие-нибудь внятные наименования, можно мнемонические. и используйте при описании прецедентов: "по нажанию кнопки выполняется секретный алгоритм с кодом NSX/RDU-9732948", "результаты работы алгоритма вычисления суммы накладных отображаются в таблице такой-то"

пользовательский интерфейс может быть в значительной мере определен на стадии описания ВИ (да и каркас системы с точки зрения пользователя тоже) и впоследствии будет дополнен при проектировании "внутренних сущностей системы".

489

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 14:00:15 »

накладная - объект предметной области, а не артефакт проектирования.

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

Формулировка Вами связи, через "некую сущность" не вполне понятна. Нельзя просто написать "общую сумму по накладным"? только стоило бы конкретизировать про какие конктретно накладные в этом случае идет речь.

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

490

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 12:51:19 »

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

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

И потом, если заказчик хочет - дайте ему это. Тем более, что в данном случае речь идет о документе.

491

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 12:00:40 »

Копать предметную область смысла нет - в первом сообщений первой строчкой написано, что это пример, кроме того, то, что вы предлагаете копать - я постарался в первом же сообщении указать.

Пример демонстрировал, как сущность предметной области (накладная) неявно участвует в ВИ1 и ВИ3.
Нерешенная мной задача в том, что как указать в ВИ3 факт некого алгоритма по данным, которые задействованы в ВИ1.

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

492

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 11:35:11 »

Водолей,

Специально для Вас перевожу:
Ну не знаю. Не понравились мне эти Иллюстрированные Сценарии Вариантов Использования, они хотят и НеФункциональные Требования и Ограничения засунуть в описание Вариантов Использования, что по моему скромному мнению не совсем верно и Вариант Использования будет перегружен информацией, которую потом будет трудно воспринимать ...

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

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

давайте всё-таки вернемся к исходной теме.

493

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 11:31:19 »

ВИ3. Просмотр остатков на складе.
1. ....
2. ....
3. Пользователь выбирает "просмотр остатков на складе"
4. Система показывает ...

что обычно пишут на месте п.4 ВИ3? Указывают ссылку на раздел, описывающий форму пользовательского интерфейса, где указывается, что будет таблица, с колонками "наименование товара" и "остаток". И в разделе описывающем форму, конкретизируют, что источником данных будет то-то и то-то?

Или в тексте ВИ, как-то пишется, что будут показаны данные, получаемые как результат некого алгоритма по исходным данным введенным при ВИ1 и ВИ2?

или еще каким-то третьим способом?

а как Вы предполагаете выполнять пункт 3? Выбирать по справочнику деталей одну деталь и потом строить отчет? или деталей будет несколько? или будут другие атрибуты например "поступившие до/после", "необходимые для продукции такой-то"?
потом, что Вы будете помещать в этот отчет? только наименование и количество остатка? а будет это достаточно заказчику? а если он это (смотрит остаток) делает в ходе инвентаризации? тогда ему могут быть нужны стоимость? шкафы/стеллажи/полки, где лежат запрошенные детали? или дата, когда поступили, сколько уже лежат, имеется ли их резервирование для какой-то продукции?

на Ваши вопросы ответить-то просто, но я бы порекомендовал помимо этого поглубже узнать предметную область
я предложил бы сделать три шага:
1. ввод условий отбора, перечислить поля/данные, используемые для отбора и т.п. можно приложить картинку интерфейса
2. запрос отчета, грубо говоря действие, выполняемое по кнопке, без описания самого запроса и источников информации, к которым он обращается (т.е. нижнего технического уровня)
3. форма получаемого отчета, колонки, если есть, то формулы, расчеты и т.п. ссылок на БД я бы не рекомендовал бы делать, но описать "своими словами" какая информация будет помещена в соответствующие ячейки отчета.

494

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 10:52:06 »

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

495

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 10:42:42 »

Ну не знаю. Не понравились мне эти ИС ВИ, они хотят и НФТ и Ограничения засунуть в описание ВИ, что ИМХО не совсем верно и ВИ будет перегружен инфой, которую потом будет трудно воспринимать ...

а мне понравилось :о)) "ИС ВИ НФТ в ВИ ИМХО ВИ" что тут трудного - очень хорошее предложение :о))