Слушайте, а кто-нибудь когда-нибудь оценивал время на проект по BI? О кого-нибудь когда-нибудь менеджеры требовали цифры по оценке трудозатрат?

Вот есть задача, сделать проект. Масштаб проекта - три области (FI, CO, LO). То есть, нужно будет спроектировать кубы, ODS, вероятно расширить некоторые экстракторы или даже написать парочку своих.

Дальше написать порядка 24 отчётов, запросы плюс VBA в готовые формы.

Вопрос - как оценить трудоёмкость такого проекта? Если у вас есть опыт внедрения подобных объёмов, напишите.

Вопрос оч живой. Требуют постоянно.
http://sql.ru/forum/actualthread.aspx?tid=772315
По своему опыту знаю, что в разрез Вашим подобные оценки даются "независимыми экспертами". От балды и по настроению. Что типа "я делал что то похожее за 8 месяцев". Или возьмем средний срок разработки и помножим на ПИ..
Смешного вообщем то мало. Могу лишь сказать, что субъективную оценку разработчиком любого проекта можно смело умножить на 2 и это будет очень оптимистично.

У нас обычно выслушивается мнение разработчика и сказанное им умножается на 3 - как правило вписываемся впритирку

Я - разработчик и есть

Сейчас озвучивают срок - через 3 месяца должно готово быть.

Я за месяц сделал треть модели данных и один отчёт, ну, на 90 процентов готово. Без документации.

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

Второй вопрос - а кто как готовит документацию? Тут говорят, что документация должна быть готова до отчёта. По-моему, бред, легче реализовать модель, а потом уже описать, чем наоборот. Конечно, мост сперва проектируют а потом строят, но програмный продукт типа BI - всё-таки, другое...

Смотря какая документация. Если проектное решение с методологией и альбомом стандартных отчётов - то до. Если детальный "реестр настроек и разработок" - явно после.

Вот что такое - проектное решение?

Что в нём должно быть, если, условно, есть техническое задание на отчёт с описанием из какой таблицы в какую клеточку на экране как должны попасть данные?

Из опыта что вообще в виденных мной ПР по BW.
1. Подробное описание бизнес-процессов со схемами to be (as is - опционально при наличии времени), в разрезе функций, которые будут выполняться. Напр., "Система "Бюджетирование" - подсистемы "Годовое планирование", "Ежеквартальное уточнение планирования", "Исполнение и анализ", "Прогнозирование", далее описание, что и на каком этапе происходит, пошагово и детально - "Финансовый директор издаёт приказ о начале планирования; отделы заполняют и присылают заявки по установленной форме; отдел планирования проверяет заявки; и т.д.". Не забыть про оргструктуру.
2. Модель данных - большая красивая схема с "кубиками" и "потоками данных". Она потом может и поменяться (и меняется, если обследование было недостаточным по времени) но приблизительно, чтобы заказчик понимал куда и что "побежит"; привязать к п.1. Прописать "методологическое" НСИ.
3. Формы ввода(если есть)-вывода данных. С внешним видом те, которые заказчик хочет кровь из носу видеть именно такими, а не иначе, остальные перечнем по характеристикам с указанием "форматы будут уточнены позднее" или нарисовать, но с припиской, что формы могут измениться. Мало ли что - заказчик внезапно захочет минимизировать Excel, а в отчётах была ставка на мега-VBA.
4. Всякая организационная "вода" - общие сведения, требования к системе, к ПО, к безопасности, краткие регламенты проведения тестирования-сдачи и т.д. и т.п.

А если есть ТЗ на каждую клеточку - то как оно получилось, без ПР-то?

Вот, скажем.



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



Вот вы мне скажите, действительно проще сначала сделать схему, а потом реализовать на практике?

Потому что мне проще сначала реализовать, ведь в системе она практически "рисуется". При этом тут же и пробуется.

То есть, я понимаю, когда мы строим например, мост или дом. Это - дорого. Если мы что-то неправильно сделаем - то очень много придётся тратить денег на переделку. Поэтому всё расчитывают на моделях. И то, кстати, не всегда удачно.

А построить схему в BW вообще проще, чем нарисовать её в VISIO, например. И если что-то неправильно спроектировали, то общая схема потоков данных в VISIO всё равно не поможет, она же не может сама себя протестировать.



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



Очень просто - есть функциональщики, они пишут что-то. Оно как раз потом войдёт в проектное решение. Кстати, тоже самое - постоянно уточняется в процессе работы.

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

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

Простите, вы разработки ведёте сразу в продуктивной системе? Нет, правда?

У меня, вообще-то, такой порядок. Ведётся разработка в разрабоческой системе, где данных, ну, один процент от тех что есть в компании вообще. Скажем, за один месяц, только по одной БЕ, или как-то так. Или, может, искусственно набиты.

Если что-то не так - да, берутся и все данные удаляются, потом заново. Это занимает пятнадцать минут.

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

Знаете, мне это напоминает середину 90х, когда в Россию хлынули компьютеры. Тогда все кричали громкое слово "мультимедиа", а некоторые даже на американский манер "малтимэдиа". Я пытался в двух словах спрашивать, что это такое. Все задумчиво произносили что-то, ну, можно википедию процетировать. "Одновременное использование различных форм представления информации и ее обработки в едином объекте-контейнере". Что это? Пока непонятно. Когда разберёшься, что под это подходит (любая игра) - непонятно что под это не подходит. Когда разберёшься, что не подходит (текстовый файл) - задаешься вопросом, зачем вообще придумали этот термин?

Потом, с опытом пришло сакральное знание. "Малтимэдиа" это когда у компьютера есть звуковая карта и CD-ROM, всё. Так и писали, "мултимедиа - 190$", а потом не стало компьютеров без звуковой карты и CD-ROM, и термин отмер, почти.

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

Но полдня уточнений, и выясняется что там связь не "многие ко многим" а всё же "один ко многим" - и можно ограничится атрибутом с промежуточными DSO. Просто методолог не понимает, что связь "многие ко многим" реализуется в BW сложно. Это как раз тот момент на живом проекте, который нельзя предусмотреть в какой-то методологии, а влияние на модель данных - очень значительное.

Но пока не начнёшь реализоваывать всё это - такой вопрос не всплывёт, вот о чём я.

Yanvladimirovich
Самая обычная, и содержится ровно то, что я описала. Должно содержаться. Потому что иначе вместо системы получается г*внография, ЕВПОЧЯ.
Потому что, ещё раз - методолог помощник консультанта по BW в написании документов. А не методолог пишет документы за консультанта. И до этого на обследование они должны ходить в паре.

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

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

Я хочу понять - какой смысл переводить бумагу? Что это даёт?

Чем вариант "сделать в разработческой системе, продумать всё как следует, удалить всё что не нужно, удалить всё и сделать всё заново" плох, если он объективно проще?



Во-первых, прежде чем перенести в продуктив, проект будет доведён до некокоторого состояния, до достаточной степени готовности.

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

Да всё тоже самое там будет.

2Yanvladimirovich

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