`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Дмитрий Зиновьев

Управление большими объемами требований в BI-проектах – 2

+33
голоса

Наиболее разумным шагом на старте проекта будет разделение требований на некоторое логическое количество типов со своим атрибутным составом. Для каждого типа необходимо настроить в расширениях модели собственный стереотип. Довольно полезным является создание отдельного стереотипа для группировки требований. Такой стереотип необходим, поскольку существующий механизм использования пакетов в модели недостаточно гибок. Особенно когда необходимо систематизировать требования в иерархиях. Например, разделить показателей на группы по предметным областям или направлениям анализа. (Прим. первая часть текста).

Управление большими объемами требований в BI-проектах – 2

Рисунок 3. Пример настройки типов требований и их атрибутов

Первичная обработка и ввод собранных у Заказчика требований, как правило, происходит определенными наборами. Источником могут послужить опросные листы, интервью или заранее подготовленные наборы требований, которые подаются аналитикам проекта. На этом этапе можно легко обойтись без монотонного ручного набора текста, воспользовавшись инструментом импорта данных из формата XLS. Необходимо отметить, что это универсальный интерфейс, который позволяет импортировать данные в виде объектов, в том числе и в виде связей между объектами, любого типа в любой вид модели. Настройка импорта не составляет особой сложности и при необходимости может быть сделана для нескольких файлов по одному шаблону, что также положительно сказывается на производительности труда аналитиков.

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

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

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

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

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

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

Когда спецификация требований подходит к концу, встает вопрос – в каком виде эти требования согласовывать с заказчиком? В PowerDesigner существует несколько механизмов для формирования выходной документации. Прежде всего, это могучий, но далеко не самый простой в понимании и использовании генератор отчетов.

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

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

За всеми этими настройками и операциями в инструменте есть один существенный вопрос – кто это все должен делать? Исходя из своего опыта – могу сказать: бизнес-аналитики существа возвышенные и достаточно далекие от скрипто-писательства или сложных настроек в моделях. Поэтому для эффективной работы с расширением возможностей PowerDesigner в команде необходим человек с техническим бекграундом, например, системный аналитик или архитектор, который хорошо владеет или способен в короткие сроки разобраться со спецификой системы. Без такого человека вряд ли удастся гибко подстраивать методологию и технологию работы команды под возникающие в проекте изменения и вызовы.

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+33
голоса

Напечатать Отправить другу

Читайте также

Существенный вопрос не в том, кто это должен делать, а в каком объеме. Все эти системы enterpise управления проектами не позволяют использовать их "по частям". Надо либо весь проект от ушей и до кончика хвоста делать в нем, либо не заморачиваться.

А кто запрещает использовать одни модели PowerDesigner'а и не использовать другие? Наличие только физической модели данных, если у Вас в проекте база данных является заметной частью системы, уже серьезно упрощает жизнь, особенно когда Вы занимаетесь не только первоначальной разработкой, но и сопровождением.
Или я не правильно понял что имелось ввиду под «не позволяют их использовать по частям».

Объем задействования автоматизированных средств проектирования и разработки определяется целесообразностью. Если весь проект заключается в перегрузке трех таблиц и построении одного отчета - естественно, для таких целей комплексные средства с мощным инструментарием избыточны как в плане инвестиций в дорогостоящее ПО, так и трудозатрат на подготовку и наполнение соответствующих моделей. Аналогична ситуация и в случае, если нужно просто "нарисовать" несколько процессов и диаграмм, в этом случае можно обойтись блокнотом и карандашом.
Использование таких средств, как PowerDesigner или упомянутый ниже Enterprise Architect от Sparx необходимо в тех случаях, когда проект нацелен на реализацию большого количества взаимосвязанных требований, которые для своей реализации повлекут необходимость в системе основанной на сложной архитектуре или модели данных.
При этом я считаю, что не обязательно делать весь проект от и до в одном автоматизированном средстве. На каждом этапе и для каждого вида работ нужно четко понимать, что даст применение этого инструмента. В качестве примера можно привести проект, в в котором для создания ETL-процедур используются специализированные средства, таких производителей как Informatica, Oracle, IBM и им подобные. В этом случае проектировать ETL имеет смысл прямо в этих средствах, не тратя время на прорисовку детальных меппингов или формирование Data Movement Diagram в PowerDesigner.
Что же касается проблемы представления Заказчику итоговых документов, то возможности систем уровня обсуждаемого инструмента делают вопрос по трудозатратам не то что второстепенным, а абсолютно несущественным. В качестве примера могу привести трудоемкость размещения диаграммы Application Architecture из PowerDesigner в документ MS Word (или Visio) - в самом простом варианте она равняется времени, которое нужно что бы нажать ctrl+c и ctl+v.

Я веду речь только о таких проектах. У нас других нет.

Использование таких средств, как PowerDesigner или упомянутый ниже Enterprise Architect от Sparx необходимо в тех случаях, когда проект нацелен на реализацию большого количества взаимосвязанных требований, которые для своей реализации повлекут необходимость в системе основанной на сложной архитектуре или модели данных.

Просто производители этих энетрпрайз арихитектов настаивают на обратном. И очень неохотно допускают внутрь чужие инструменты. Да и "итоговыми" документы бывают чрезвычайно редко. 3-5 кругов проходит запросто и копипаст картинок весьма мешает ревьювить и править спеки. Вот и приходишь к выводу, что лучше генерить доки как задумал вендор той или иной энтерпрайз приблуды. А это тянет за собой необходимость реверсинжиниринга для отражения сделанных изменений в коде/базе/итп. А это тянет за собой то, о чем я и написал - либо все, либо непонятно что с ним делать.
А если вас еще, не дай бог, сертифицировали по CMMI5, то все штатные шаблоны не подходят, и начинаются пляски с бубнами по "приведению в соответствие" :(
Нет, я не спорю, что все эти инструменты вещь, видимо очень полезная, но пока не получилось сделать хоть один проект так, как задумывалось изготовителями EA.

Вообщем, излил душу :)

Ну, у производителя задача такая - рассказывать, что инструмент нужен всем и всегда, а у потребителя задача потратить минимум денег с максимальным эффектом.
Что же касается ситуации с обратной связью с заказчиком в проекте, то по моему опыту наиболее эффективной работа получается когда люди участвующие в создании спецификаций непосредственно вовлечены в процесс и дают свои комментарии на этапе проработки отдельных элементов, а не большого, полностью собранного документа. Соответственно и особых проблем с генерацией нескольких версий документа и учета правок я не привести не могу. Тем не менее, в профессиональных инструментах для работы с требованиями возможность хранить и обрабатывать объекты требований прямо в документе Word появилась довольно давно, например в Rational RequisitePro еще за долго до того, как она стала IBM.

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

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

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

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

Похоже неправильно. Дело ведь не в разнообразии изобразительных средств в виде моделей. Картинки красивые или BPMN диаграммы быстрее в том же бесплатном yEd рисовать. Или StarUML. Кто к чему привык за долгие годы.
Использование таких enterprise "помощников" предопределят, что весь life cycle проекта будет проходить только в нем любимом и нигде иначе. Уже попробовали. Надо все, абсолютно все, начиная от требований и дизайнов, до рефакторинга кода, переводить на эти рельсы. Иначе весь смысл теряется. Использовать PD или там EA, просто в качестве рисовалки диаграмм или хранения DDL - выброшенные деньги.
Там где проектик маленький, на 1000-1500 мд, и нет никакой предыстории/предыдущих релизов - вообще нет смысла в таких инструментах, на мой взгляд.
В длительных и масштабных проектах - больше будет зависеть от взаимодействия с другими подсистемами компании и с подсистемами заказчиков. Ведь если заказчик потребует предоставлять ему (и выдавать вам обратно) документацию сделанную, например, в Визио, больше времени потраться на конвертацию туда-сюда.

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

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT