Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
если мотороллер не ваш, то откуда вы знаете что знает заказчик а что нет?Приятель жаловался.
Детализировать описание отчетности до уровня полей на этапе подписания обязательств - в век Agile както вот странно!!!!Как жаль, что заказчик этого не знает!
PS а вы отчетность на чем делаете? В смысле на какомто продукте или сами кодируете?Дык, мотороллер же не мой, не спрашивал.
Мне кажется требования к отчетам можно и нужно формировать не дожидаясь наличия данныхМне тоже так казалось до некоторых пор, но столкнувшись пару раз с тем, что не можешь выполнить требования, из-за того, что поля данных на практике заполняются пользователями не так, как предполагалось разработчиком, я теперь стараюсь не подписываться под обязательства в таких ситуациях.
А в пути никто кормить не обещал.Нет уж, извините. Мне в пути детей кормить надо, поэтому туда, где в пути не кормят, меня не интересует. Я просто работаю, а не занимаюсь пламенной революционной борьбой.
А стоит ли начальнику департамента автоматизации встревать в борьбу между двумя другими начальниками? Его задача - чтобы айти в банке работало. Тогда его влияние будет возрастать. А в каком из департаментов будут за эти данные отвечать - ему то какая разница? Ему надо просто понять, в (1) или (2) будут вводить этих данные аккуратнее, чтобы меньше тратить своих сил на контроль и принуждение, и продумать механизм консолидации этих данных.
Кто ж за так свою власть отдавать будет? Но с другой стороны задача вполне решаемая, если решать ее на правильном уровне, но это опыт надо иметь и выход на этот уровень. Предположительно этого выхода (или понимания, где этот выход находится) у Вашего знакомого нет.
, т.е. банк не мой, просто попросили проконсультировать как оперативно решить проблему. Через месяц-другой посмотрим, что получится на практике.кто-то ведь определял задачи этим департаментам, кто-то закупал, устанавливал и обслуживал эту систему.Основные повседеневные задачи хорошо решаются, система в целом работает хорошо. Но аппетит приходит во время еды - появляются новые потребности, не учтенные в начале. Я думаю, все сталкивались с этим?
я уж не говорю про организацию совместной работы с данными, набитыми в экселевских файлах. интересно сколько их за год накопится?Немного, это данные типа словарей: редко меняющиеся и небольшие по объему - до нескольких сотен записей.
как выяснилось, необходимые для создания хранилища данные, содержащиеся в существующих АС, во-первых, далеко не всегда отражают действительность (т.е. некорректны), и, во-вторых, их явно недостаточно для получения тех отчетов, которые хочет видеть руководство.Как раз на прошлой неделе обдумывали схожую ситуацию в одной банковской системе. Одному департаменту (1) нужны отчеты, данные для которых вводятся в другом департаменте (2). бОльшую часть данных департамент (2) вводит исправно. Но есть небольшая, нужная только для этих конкретно отчетов, часть данных, наличие которых для сотрудников департамента (2) в системе не важно. Поэтому они их, естественно, не вводят (экономят свое время), и административное давление не помогает.
В свою очередь напомню про покорение космоса, создание атомной бомбы и другие прорывные проекты в областях о которых было довольно смутное представление.Рискую уйти в офтопик, но оба приведенные Вами примера знакомы мне не из художественной литературы, а по прошлой специальности. Уверяю, там все проекты шли именно мелкими шажками, которые пропустили, когда снимали про это кино
Никакого смутного представления о том, чего нужно достигнуть, перед каждым новом шагом не было - было чрезвычайно конкретное ТТЗ Миноборны, невыполнение которого жестко наказывалось. Несмотря на то, что мне приходилось иметь дело с OLAP-отчетами, у меня действительно сейчас есть пробелы как в терминологии, так и в понимании этой области, устранение этих пробелов - одна из моих первоочередных задач на данный момент.Если задача действительно важна для Вашего руководства, то рекомендую потребовать отправить Вас на курсы, причем именно по той платформе, которая у вас будет использоваться. Сэкономите себе и конторе массу времени и денег.
тут Вы неправы, иначе бы ни одной системы нельзя было бы создать в принципе, опыта работы с отсутствующей системой-то тоже не было бы :о))Каждая новая система нова только максимум на 5%. Чтобы написать на нее ТЗ надо досконально знать остальные 95%. А на 100% новую систему именно в принципе нельзя создать. Иначе почему бы было не начать создавать OLAP системы на следующий день после ввода в эксплуатацию ЭВМ ENIAC в 1946 году?
Передо мной стоит задача формирования задания на разработку OLAP-отчета.Какая задача для Вас новая, написание ТЗ на OLAP, или вообще работа с OLAP? Вряд ли можно написать ТЗ, не имея личного опыта работы с OLAP в конкретных практических целях.
Задача для меня новая
Логическая модель БД в ErWin будет, по-моему, будет такой:
Суть в том.Если их компания рухнет ,то нам конец.Очень печальная ситуация. Скорее всего документация, полученная у них, поможет не сильно.
Поэтому руководство создать документацию о системе.
А мне интересен выше указанный вопрос.
И вообще реально что-то у них вытащить?
