Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: splu от 08 Октября 2009, 00:27:46
-
Всем добрый вечер. Передо мной стоит задача формирования задания на разработку OLAP-отчета.
Задача для меня новая, поэтому у меня возникли сложности при подготовке вопросов для выявления требований к отчету, и, соответственно, при формировании технического задания: нет четкого представления о содержимом этого документа.
К сожалению, примеров документов по подобной задаче мне найти не удалось :(
Отсутствие шаблона документа ставит меня в тупик при формировании перечня открытых вопросов, а также определении состава необходимых для формирования задания исходных данных.
Наставьте на путь истинный, подскажите, пожалуйста, примерный состав ТЗ на разработку OLAP-отчета (в т.ч. каком виде следует описывать требования к измерениям и показателям, кроме указания их названия, источника...).
-
Я выскажу некие свои мысли, если неправ, пускай знающие поправят.
Во-первых, нужно чётко определить бизнес-пользователя, то есть кто будет использовать результыты. Далее, для каких целей, к примеру, для поддержки принятия оперативного решения будет весьма критично время. Далее, вопрос источников информации - если есть хранилище данных - это одно, если нет, то возникает вопрос сбора, консолидации, очистки данных и регламента этих процессов. То есть, это всё в первую очередь.
ИМХО.
-
... Далее, вопрос источников информации - если есть хранилище данных - это одно, если нет, то возникает вопрос сбора, консолидации, очистки данных и регламента этих процессов. То есть, это всё в первую очередь.
ИМХО.
Тут STUTK абсолютно прав. Если Вы делаете то что вы называете OLAP-отчет не над готовым хранилищем, то я Вам не завидую, ибо инфу надо собрать сконсолидировать, проверить целостность и т.п. Тогда задача построения отчета перерастает совсем в другую задачу!!!
я так понимаю что OLAP отчет отличается от просто отчета гибкостью представления данных. т.е. в отличии от обычного отчета форма которого более менее жестко задана внешнее представление OLAP отчета не может и не должно быть жестко регламентировано. Если Вы вкладываете в термин OLAP отчет чтото еще напишите - интересно..
Поэтому при описании таких отчетов мне кажется надо описывать какие факты и в каких размерностях будут отображаться. Ну еще может возникнуть требования к хранилищу - если то что нужно для такого отчета не хранится в нем, а считать налету дорого... Можно еще описать дефолтный вид отчета при открытии..
-
Раз задача для Вас новая, возможно Вы некорректно ее формулируете. Что значит для Вас "разработка OLAP-отчета"?
Вам нужно отдельный отчет разработать в имеющейся OLAP-системе? или саму OLAP-систему?
Хранилище есть? Там есть первичные данные для Вашего отчета? или Вам нужно эти данные еще и собрать? (впрочем коллеги об этом уже спросили).
P.S. В качестве простейшего и одного из доступных OLAP-средств посмотрите сводные таблицы (pivot table) Excel. Если у Вас есть хранилище, то можно попробовать смоделировать Ваш отчет в нем. Так Вы лучше поймете, что должно быть в ТЗ с предметной точки зрения.
-
Передо мной стоит задача формирования задания на разработку OLAP-отчета.
Задача для меня новая
Какая задача для Вас новая, написание ТЗ на OLAP, или вообще работа с OLAP? Вряд ли можно написать ТЗ, не имея личного опыта работы с OLAP в конкретных практических целях.
-
Не могу не согласиться со всеми высказанными замечаниями по поводу некорректности формулировки задачи.
Раз задача для Вас новая, возможно Вы некорректно ее формулируете. Что значит для Вас "разработка OLAP-отчета"?
Несмотря на то, что мне приходилось иметь дело с OLAP-отчетами, у меня действительно сейчас есть пробелы как в терминологии, так и в понимании этой области, устранение этих пробелов - одна из моих первоочередных задач на данный момент. Может быть, кто-нибудь подскажет толковую книгу по этой тематике?
Вам нужно отдельный отчет разработать в имеющейся OLAP-системе? или саму OLAP-систему?
Хранилище есть? Там есть первичные данные для Вашего отчета? или Вам нужно эти данные еще и собрать? (впрочем коллеги об этом уже спросили).
Хранилища данных как раз и нет, мне необходимо сформулировать требования как к хранилищу данных, так и к необходимым представлениям.
Тут STUTK абсолютно прав. Если Вы делаете то что вы называете OLAP-отчет не над готовым хранилищем, то я Вам не завидую, ибо инфу надо собрать сконсолидировать, проверить целостность и т.п. Тогда задача построения отчета перерастает совсем в другую задачу!!!
В этом вопросе коллеги обещали в некоторой степени помочь.
Во-первых, нужно чётко определить бизнес-пользователя, то есть кто будет использовать результыты.
Именно этим и планирую заняться в ближайшее время: выявить всех заинтересованных лиц и определить их запросы, отсюда получить перечень необходимых измерений и показателей. Разработкой самой OLAP-системы (если с термином опять не путаю) будет заниматься сторонняя организация, для которой, собственно, и необходимо подготовить ТЗ. В связи с этим, как мне кажется, возникает задача формулирования источника этих измерений и показателей (предполагаю, что на уровне конкретных запросов к БД). Поправьте меня, если я ошибаюсь.
Далее, для каких целей, к примеру, для поддержки принятия оперативного решения будет весьма критично время.
Очень интересное замечание.
Всех благодарю за ответы, появилось много мыслей и вопросов (!), что, несомненно, большой шаг вперед при изучении новой области. Так что работать, работать и снова работать.
-
Вряд ли можно написать ТЗ, не имея личного опыта работы с OLAP в конкретных практических целях.
тут Вы неправы, иначе бы ни одной системы нельзя было бы создать в принципе, опыта работы с отсутствующей системой-то тоже не было бы :о))
-
тут Вы неправы, иначе бы ни одной системы нельзя было бы создать в принципе, опыта работы с отсутствующей системой-то тоже не было бы :о))
Каждая новая система нова только максимум на 5%. Чтобы написать на нее ТЗ надо досконально знать остальные 95%. А на 100% новую систему именно в принципе нельзя создать. Иначе почему бы было не начать создавать OLAP системы на следующий день после ввода в эксплуатацию ЭВМ ENIAC в 1946 году?
Может быть такая аналогия поможет: представьте себе человека, пишущего ТЗ на текстовый редактор, и никогда не работавший с MS Word или его функциональными аналогами, только с Notepad. Представили себе это ТЗ?
Чтобы что-то требовать, надо знать достигнутые на сегодня горизонты, и понимать, какие проблемы возникают у пользователя именно на этом горизонте.
-
Несмотря на то, что мне приходилось иметь дело с OLAP-отчетами, у меня действительно сейчас есть пробелы как в терминологии, так и в понимании этой области, устранение этих пробелов - одна из моих первоочередных задач на данный момент.
Если задача действительно важна для Вашего руководства, то рекомендую потребовать отправить Вас на курсы, причем именно по той платформе, которая у вас будет использоваться. Сэкономите себе и конторе массу времени и денег.
-
Каждая новая система нова только максимум на 5%. Чтобы написать на нее ТЗ надо досконально знать остальные 95%. А на 100% новую систему именно в принципе нельзя создать. Иначе почему бы было не начать создавать OLAP системы на следующий день после ввода в эксплуатацию ЭВМ ENIAC в 1946 году?
Может просто потому, что в ней на тот момент не было необходимости?
-
Каждая новая система нова только максимум на 5%. Чтобы написать на нее ТЗ надо досконально знать остальные 95%. А на 100% новую систему именно в принципе нельзя создать. Иначе почему бы было не начать создавать OLAP системы на следующий день после ввода в эксплуатацию ЭВМ ENIAC в 1946 году?
Может быть такая аналогия поможет: представьте себе человека, пишущего ТЗ на текстовый редактор, и никогда не работавший с MS Word или его функциональными аналогами, только с Notepad. Представили себе это ТЗ?
Чтобы что-то требовать, надо знать достигнутые на сегодня горизонты, и понимать, какие проблемы возникают у пользователя именно на этом горизонте.
в общем, я с Вами не согласен.
первичным вижу всё-таки потребности предметной области, а не существующие технические возможности.
В свою очередь напомню про покорение космоса, создание атомной бомбы и другие прорывные проекты в областях о которых было довольно смутное представление. Я конечно не отрицаю пропагандируемый Вами подход мелких шажков при реализации проектов, но с точки зрения рассматриваемого вопроса (разработка ТЗ) он неверен.
-
Разделяю точку зрения Водолея. Верхнеуровневые требования к OLAP системе (или репорту на ее основе) МОЖНО писать понимая только бизнес и его потребности. Но чем ниже уровень требований, т.е чем дальше отходите от чисто бизнесовых требований к реализации, тем сложнее общаться с архитектором системы (в данном случае с внешней компанией) и разработчиками. Знания же платформы на которой строят вашу OLAP систему можно ограничить пониманием концепции ее построения
-
В свою очередь напомню про покорение космоса, создание атомной бомбы и другие прорывные проекты в областях о которых было довольно смутное представление.
Рискую уйти в офтопик, но оба приведенные Вами примера знакомы мне не из художественной литературы, а по прошлой специальности. Уверяю, там все проекты шли именно мелкими шажками, которые пропустили, когда снимали про это кино ;) Никакого смутного представления о том, чего нужно достигнуть, перед каждым новом шагом не было - было чрезвычайно конкретное ТТЗ Миноборны, невыполнение которого жестко наказывалось.
Да, эти мелкие шажки делались очень быстро, но Вы бы тоже быстро делали софт, если бы от этого зависела ваша жизнь и свобода Вашей семьи.
Типичный этап (от ТТЗ до натурных испытаний) занимал в разгар этих проектов около месяца, так что эти проекты можно считать первыми проектами, проведенными по Agile методологии, а их проджект-менеджера (Л.П.Берию) - первым Agile-гуру.
-
Всем добрый вечер. Передо мной стоит задача формирования задания на разработку OLAP-отчета <...> нет четкого представления о содержимом этого документа<...>
Начните с того, на какие вопросы хочет получить ответ пользователь при помощи "OLAP-отчётов". Дальше, если нужны именно отчёты, согласовать с заказчиком список и содержание отчётов. Возможно "OLAP" и "ad-hoc" на самом деле не нужно, а нужно ввести пару параметров в условии фильтрации, вывести таблицу и строчку "итого". Это и опишите.
Если заказчику непременно хочется именно слова "OLAP" - предложите ему SAS или Business Objects в качестве средства реализации. Дорого. А "восстанавливать" UC существующих платформ для построения "OLAP" - дело неблагодарное. В т.ч. потому, что приведёт к написанию собственного велосипеда.
-
Обобщая тему интересно было бы услышать о
1 особенностях работы аналитика/постановшика в DW/OLAP проектах
2 наборе документах создаваемых для таких проектах
на основе своего опыта или ссылки на статьи...
-
Полностью присоединяюсь к предыдущему оратору :)
К слову добавлю, что сама задача, мягко говоря, несколько осложнилась: как выяснилось, необходимые для создания хранилища данные, содержащиеся в существующих АС, во-первых, далеко не всегда отражают действительность (т.е. некорректны), и, во-вторых, их явно недостаточно для получения тех отчетов, которые хочет видеть руководство.
Так что пока я нахожусь на стадии выявления проблем (таких проблем, влияющих прямо или косвенно на задачу разработки OLAP-системы, уже накопилось немало), их причин и т.п., чувствую, что до описания требований к "написанию собственного велосипеда" мне еще далеко... Но замечание учту.
-
Эээээ, таким макаром Вы никакого OLAP'а не построите. Т.е. конечно, технически систему заставить работать можно (как асфальтоукладчик без асфальта), но вот отчеты с правильными данными, ради которых всё затевается, Вы не получите, пока, собственно, данные, доступные для обработки, не окажутся в хранилище. Скажите об этом своему руководству прямо: так, мол, и так, нет данных - нет и отчетов.
-
Хранилища тоже бывают разными, может быть хватит какой-нить а-ля федеративной архитектуры, то есть некой надстройки над уже существующими хранилищами. А так же важно учесть необходимость (будет ли она вообще) масштабирования всей системы, может быть нужны такие отчёты, которые с высокой долей вероятности не притерпят изменений, то есть не потребуются дополнительные данные из другиз ИС или изменения формы и принципа построения. И исходя из требований бизнеса нужно строить информационную основу. Но в любом случае, как было уже сказано коллегами, отчёты, основанные на некорректных и неактуальных данных - нафиг никому не нужны. =)
ИМХО.
-
как выяснилось, необходимые для создания хранилища данные, содержащиеся в существующих АС, во-первых, далеко не всегда отражают действительность (т.е. некорректны), и, во-вторых, их явно недостаточно для получения тех отчетов, которые хочет видеть руководство.
Как раз на прошлой неделе обдумывали схожую ситуацию в одной банковской системе. Одному департаменту (1) нужны отчеты, данные для которых вводятся в другом департаменте (2). бОльшую часть данных департамент (2) вводит исправно. Но есть небольшая, нужная только для этих конкретно отчетов, часть данных, наличие которых для сотрудников департамента (2) в системе не важно. Поэтому они их, естественно, не вводят (экономят свое время), и административное давление не помогает.
Посмотрели, как сейчас делают отчеты в (1) - выуживают из плохо структурированных документов недостающие данные, хранят в Экселе или на бумаге и подставляют их во вручную в Экселе изготавливающиеся отчеты.
Рекомендовали - полностью довбить сотрудникам (1) эти данные в Эксель, сделать эту Эксель таблицу дополнительным источником для хранилища (наряду с основной банковской БД), взять департаменту (1) на себя поддержку ее актуальности. После этого банковские айтишники легко могут сделать автоматическую генерацию нужных отчетов, т.к. в хранилище появляется нужная достоверная информация.
-
2 div:
Чего-то я не совсем понял. Получилось в итоге, что для (1) существует экселевкая табличка, в которую сотрудники этого же (1) вносят данные вручную? И так же сами и вручную следят за её актуальностью? А отчёты строятся путём обработки данных находящихся как в хранлище, так и в этом экселевском файле?
-
действительно, в чем проблема:
а) спрямить бизнес-процесс, спроектировав движение данных от их появления до итогового отчета, а потом докрутить систему, тем более при наличии крутейших банковских айтишников.
б) или уж в крайнем случае тупо дать департаменту (1) кусок системы департамента (2), чтобы первые вводили нужные им данные прямо в систему.
кому нужен этот эксель? или у Вас кусочно-лоскутная автоматизация?
-
Вообще тут речь идёт о хранилище, поэтому поток данных должен быть направлен именно в хранилище, иначе подобные лоскуты и костыли будут плодиться и дальше, а хранилище теряет смысл. И вообще, создание дополнительного источника данных в обход хранилища для отчётов, да ещё в виде ручного экселя - это вообще ересь, если нет каких-то неозвученных особенных факторов.
ИМХО.
-
2 STUTK, Водолей
Чего на человека набросились - он же написал "..сделать эту Эксель таблицу дополнительным источником для хранилища (наряду с основной банковской БД).."
"или у Вас кусочно-лоскутная автоматизация?" А насчет этого пассажа - вообще слов нет... В теории она не очень конечно хороша, на практике от нее никто не уходит.... И кстати одна из задач варехауса - интеграция данных из множества источников, что косвенно подразумевает наличие разных информационных систем на предприятии
-
2 KIRILLSS:
Побойтесь Бога, никто на человека не набрасывался! Просто безудержный интерес к теме накладывает эмоциональный отпечаток на стиль изложения. =)
Что касается интеграции данных из множества источников, косвенно подразумевающей наличие разных ИС на предприятии, то спасибо за очевидное, об этом то речь, особенно в свете разговоров о ХД, которое и выполняет функции консолидации данных со всех источников... в теории.
-
ну хоть в теории сошлись... :)))))))
а как на практике ? Делитесь... раз уж безудержный интерес)))
-
А насчет этого пассажа - вообще слов нет...
как говорится: "как это нет слов - надо было подготовиться" (с)
возможный негативный оттенок приведенной формулировке не в том, используется эксель или нет, а в том как используется. если есть система, решающая задачу, но просто кому-то не с руки вводить данные для другого департамента, то очевидно, что проблема не в системе, а в головах. кто-то ведь определял задачи этим департаментам, кто-то закупал, устанавливал и обслуживал эту систему.
потом этим же банковским айтишникам будет сложно и дорого управлять множеством задач, решаемых экселем при наличии систем нужного назначения. они же сами не смогут выбить средства на что-то нужное.
я уж не говорю про организацию совместной работы с данными, набитыми в экселевских файлах. интересно сколько их за год накопится?
Делитесь... раз уж безудержный интерес)))
Вас что-то конкретное интересует или так... безудержный интерес? :о))
-
2 Водолей
Моя фраза, процитированная Вами относилась к лоскутной автоматизации. Я с некоторых пор перестал воспринимать этот термин как однозначно ругательный. Иногда такая автоматизация - зло, иногда - экономически оправдана. По имеющейся от div информации трудно определить что имеет место в данном случае..
Что касается безудержного интереса - то вопрос, как нетрудно восстановить из двух предыдущих постов, относился к "функции консолидации.." хранилища
-
1. Вообще то "мотороллер не мой" ;), т.е. банк не мой, просто попросили проконсультировать как оперативно решить проблему. Через месяц-другой посмотрим, что получится на практике.
2. Наверное, не так просто на деле "спрямить бизнес-процессы". Вы лично пробовали подойти к хозяину банка - простому миллиардеру и так предложить спрямить ему пару-тройку бизнес-процессов; мол, я вот тебе дам совет, как тебе разбогатеть? Вот я когда то по неопытности, воодушевленный правильными книжками, попробовал...
А дать одному подразделению права на редактирование данных, за которые ответственно другое подразделение - кто подпишется под этим, если за этим правом КОНКРЕТНАЯ ответственность?
3. кто-то ведь определял задачи этим департаментам, кто-то закупал, устанавливал и обслуживал эту систему.
Основные повседеневные задачи хорошо решаются, система в целом работает хорошо. Но аппетит приходит во время еды - появляются новые потребности, не учтенные в начале. Я думаю, все сталкивались с этим?
В то же время, эксплуатационщики будут вполне обоснованно возражать, если им предложат немного покурочить хорошо работающую систему, под тем предлогом, что надо к ней привернуть какую то редко используемую деталь. Как известно - не надо трогать то, что работает.
4. я уж не говорю про организацию совместной работы с данными, набитыми в экселевских файлах. интересно сколько их за год накопится?
Немного, это данные типа словарей: редко меняющиеся и небольшие по объему - до нескольких сотен записей.
-
ну хоть в теории сошлись... :)))))))
а как на практике ? Делитесь... раз уж безудержный интерес)))
Так вот в этом то и вся фишка и корень, так сказать, безудержного интереса...)) Теория то есть, а вот как и почему не получается на практике, и где, как, почему люди уходят с пути истинного (с теории). =)
2 Водолей
Моя фраза, процитированная Вами относилась к лоскутной автоматизации. Я с некоторых пор перестал воспринимать этот термин как однозначно ругательный.
Посмею вмешаться, лично я вообще никогда не воспринимал лоскуты как однозначное зло. Встречается даже в некой классификации вид информационной архитектуры в предприятии - "Лоскутное одеяло", имеющий право на жизнь. =) Так что всё зависит от конкретики. Но всё же в банке, моё глубокое имхо, увы, не основанное на практике, лоскутов быть не должно... может я неправ.
-
1. Вообще то "мотороллер не мой" ;), т.е. банк не мой, просто попросили проконсультировать как оперативно решить проблему. Через месяц-другой посмотрим, что получится на практике.
Посмотрим-посмотрим. Но пока всё-таки неясно в чем суть проблемы. IMHO кто-то не делает своей части общей работы.
2. Наверное, не так просто на деле "спрямить бизнес-процессы". Вы лично пробовали подойти к хозяину банка - простому миллиардеру и так предложить спрямить ему пару-тройку бизнес-процессов; мол, я вот тебе дам совет, как тебе разбогатеть? Вот я когда то по неопытности, воодушевленный правильными книжками, попробовал...
А в пути никто кормить не обещал. Однозначно и не скажешь "просто будет спрямить бизнес-процессы или сложно". И сложность здесь не технического порядка - вряд ли будет просто уговорить перераспределить функции между депаратаментами, ведь от этого зависит значимость их руководителей. Кто ж за так свою власть отдавать будет? Но с другой стороны задача вполне решаемая, если решать ее на правильном уровне, но это опыт надо иметь и выход на этот уровень. Предположительно этого выхода (или понимания, где этот выход находится) у Вашего знакомого нет.
Да, и не надо ходить к хозяину банка за такой мелочевкой - не барское это дело, в процессах-то ковыряться. Вот если бы Вы ему денег предложили бездвоздмездно, т.е. даром...
Чем дело-то кончилось? Сказал "мальчик, иди отсюда, здесь большие дяди работают"?
А дать одному подразделению права на редактирование данных, за которые ответственно другое подразделение - кто подпишется под этим, если за этим правом КОНКРЕТНАЯ ответственность?
Очевидная вещь - у них нет владельцев данных и владельцев процессов (в крайнем случае формальные, что погоды не делает). Поэтому такого рода решения протаскиваются в обход существующих процедур.
Судя по приведенному выше решению, права на редактирование данных уже даны (департамент 1 сам вводит данные и отслеживает их корректность, а департамент 2 ничего не делает). Теперь вопрос в инструменте, который может решиться (а может и не решиться) в зависимости от значимости айтишников и занимаемого ими места в этом банке.
3. Основные повседеневные задачи хорошо решаются, система в целом работает хорошо. Но аппетит приходит во время еды - появляются новые потребности, не учтенные в начале. Я думаю, все сталкивались с этим?
Хорошо построенная архитектура даст ответ. Тогда-то и станет ясна разница хорошего и кусочно-лоскутного способа ее построения.
В то же время, эксплуатационщики будут вполне обоснованно возражать, если им предложат немного покурочить хорошо работающую систему, под тем предлогом, что надо к ней привернуть какую то редко используемую деталь. Как известно - не надо трогать то, что работает.
Крамолу скажу: Не их дело возражать - их дело работать, как требуется бизнесу. Сложно - учитесь!
4. Немного, это данные типа словарей: редко меняющиеся и небольшие по объему - до нескольких сотен записей.
вообще в непонятках, вроде выше было написано, что по этим данным строятся отчеты.
В общем, успехов в большом и трудном деле...
-
Но всё же в банке, моё глубокое имхо, увы, не основанное на практике, лоскутов быть не должно... может я неправ.
насколько я с ними (банками) сталкивался - лоскутов у них вполне хватает
Ну понятно, главная система - АБС. Сталкивался с ситуацией когда в банке стоила не одна АБС а две!! И не просто на переходный период а на постоянной основе. Просто западный банк работающий здесь - одна АБС - корпоративный стандарт, одна АБС - для нашей действительности. Как правило, отдельные системы - учет ОСов банка, системы дилинга и риск менеджмента, обслуживание пластиковых карт, иногда ритейловые системы выносятся за пределы общей АБС. Так что там тоже все непросто...
-
А в пути никто кормить не обещал.
Нет уж, извините. Мне в пути детей кормить надо, поэтому туда, где в пути не кормят, меня не интересует. Я просто работаю, а не занимаюсь пламенной революционной борьбой.
Кто ж за так свою власть отдавать будет? Но с другой стороны задача вполне решаемая, если решать ее на правильном уровне, но это опыт надо иметь и выход на этот уровень. Предположительно этого выхода (или понимания, где этот выход находится) у Вашего знакомого нет.
А стоит ли начальнику департамента автоматизации встревать в борьбу между двумя другими начальниками? Его задача - чтобы айти в банке работало. Тогда его влияние будет возрастать. А в каком из департаментов будут за эти данные отвечать - ему то какая разница? Ему надо просто понять, в (1) или (2) будут вводить этих данные аккуратнее, чтобы меньше тратить своих сил на контроль и принуждение, и продумать механизм консолидации этих данных.
Наверное, мы слишком удалились от темы. А мне, тем не менее, бы было интересно послушать мнения по поводу имеющейся практики формирования требованиям к отчетам в условиях, описанных топикстартером, т.е. когда данные для отчетов на момент формирования требований пока еще отсутствуют в базах.
-
2 div:
да это к слову... в том смысле, что простого можно не ждать, а нужно в любом случае действовать.
не хотелось бы вдаваться глубоко в политические игры того банка, тем более что информации у нас об нет, лишь Ваша интерпретация. могу сказать одно, что в организации должен быть четко идентифицирован владелец (по сути тот, кому в итоге эти данные предназначены) для любых данных, а "главный айтишник" один из управляющих этими данными, так что ему должно быть важно что, кем и почему не вводится. в конце концов от этого зависит его результативность и, соответственно, рост всего остального. да, и о совсем незрелых организациях, думаю, говорить совсем не стоит.
возвращаясь к топику, скажу, что тут возможны две ситуации:
- запрашиваются немыслимые отчеты, для которых данных нет в природе
- на необходимые исходные данные просто кладут (т.е. они могли бы собираться, но не собираются)
первый случай не имеет практического интереса в нашем случае - чистая политика, соответственно, и решаться он должен соответствующими методами.
а во втором, я бы начал с форм отчетов, затем проследил бы откуда и какие данные им нужны (в конечном счете они должны опираться на какую-то первичку), каковы реальные маршруты существующих данных, и что будет стоить "ввод" отсутствующих. причем смотреть это надо не только в технологическом смысле (как в приводившемся примере, "пусть вводят в эксель"), но и в организационном (кто, когда, в каком объеме будет вводить, что ему для этого нужно - люди, например, или время), и в процессном (что с этими данными будет дальше происходить, будут ли они связываться с чем-то еще или нет).
проблема может возникнуть, когда обсуждение необходимых отчетов с заказчиком заканчивается вопросом "мы тебе всё рассказали, теперь скажи нам, когда это будет готово?". самое время ответить "в существующей ситуации - никогда". разумеется, нужно быть готовым подкрепить фактами, и иметь возможность предлагать варианты решений.
-
То что написал Водолей, насколько я понимаю, поможет нарисовать картинку to-be. Поскольку вроде упоминалась еще и некая существующая система то полезно понять и картинку as-is. Имея их обе можно понять что делать с уже существующей - выбросить или доделать
PS ..бы было интересно послушать мнения по поводу имеющейся практики формирования требованиям к отчетам в условиях, описанных топикстартером, т.е. когда данные для отчетов на момент формирования требований пока еще отсутствуют в базах.
Мне кажется требования к отчетам можно и нужно формировать не дожидаясь наличия данных
-
практиццки так.
одна тонкость - перед тем как понять "что делать с уже существующей" нужно будет оценить что выгоднее, причем не только в терминах денег, но и некоторых других категориях.
по второму согласен, за исключением оговорок сказанных ранее (когда таких данных в природе нет)
-
Мне кажется требования к отчетам можно и нужно формировать не дожидаясь наличия данных
Мне тоже так казалось до некоторых пор, но столкнувшись пару раз с тем, что не можешь выполнить требования, из-за того, что поля данных на практике заполняются пользователями не так, как предполагалось разработчиком, я теперь стараюсь не подписываться под обязательства в таких ситуациях.
То есть предпочитаю сначала получить значимую выборку реально введенных при промышленной эксплуатации пользователями данных, и только убедившись, что по вводимым на практике данным ( а не по тем, которые теоретически должны вводиться), можно получить требуемый отчет, соглашаться включать его в требования.
Естейственно, речь идет о ситуации, когда отчетная система делается к уже работающей базе, как у топикстартера.
Конечно, если сам делаешь и базу и отчеты, то приходится требования к отчетам формировать сразу и потом мучиться.
-
2 div
Я настаиваю на том что требования по отчетам должны формироваться на этапе проектирования OLAP решения или DW (т.е. когда не то что данных в OLAP системе нет - еще самих систем то нет). Невозможно понять какие витрины, какие факты и по каким разрезам (т.е. какие кубики) строить если нет понимания требований к отчетам. Другое дело на каком уровне определять эти требования.
Детализировать описание отчетности до уровня полей на этапе подписания обязательств (тут я может Вас не понял) - в век Agile както вот странно!!!!
PS а вы отчетность на чем делаете? В смысле на какомто продукте или сами кодируете?
-
Детализировать описание отчетности до уровня полей на этапе подписания обязательств - в век Agile както вот странно!!!!
Как жаль, что заказчик этого не знает! ;)
PS а вы отчетность на чем делаете? В смысле на какомто продукте или сами кодируете?
Дык, мотороллер же не мой, не спрашивал.
-
если мотороллер не ваш, то откуда вы знаете что знает заказчик а что нет?
-
если мотороллер не ваш, то откуда вы знаете что знает заказчик а что нет?
Приятель жаловался.
ЗЫ: диалог в этой ветке ушел ИМХО от конструктива.