Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Humbert

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
211
Для всех / Re: Разработки
« : 18 Марта 2016, 20:18:24 »

Это у продвинутых аналитиков профессиональная деформация и по три названия на одинаковые с виду кубики. :)


Да каких же продвинутых ? Блок-схемам любых айтишнегов годов с 60х учили до ООП(http://www.pntd.ru/19.701.htm). Еще тогда понятия аналитик не было - они постановщиками назывались.

Потом UML стали учить. Но все равно любой айтишнег не спутает описание процесса с описанием структуры.
Что до UML, что после...

То есть топикстартер не шарит ни в UML, ни  в том, что было до UML.

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

Пусть матчасть поучит, прежде чем лезть в светочи, uml2 и в аналитики.

212
Для всех / Re: Разработки
« : 17 Марта 2016, 00:24:33 »

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

Давайте дружить и продвигать знания и прогресс в Госдепартаменты!

Зачем считывать информацию с печатей штампов при сканировании?
Если это обработка внутренних документов, то гораздо проще использовать штрихкод .
https://ru.wikipedia.org/wiki/QR-%D0%BA%D0%BE%D0%B4

Если документы внешние, то что нужно сделать?
Извлечь ЮЛ и его реквизиты? Проверить соответствие печати содержимому?

Бизнес цель этого считывания позволит более точно дать рекомендацию

Один из мировых лидеров в области OCR - компания abbyy. Помимо ширпотребовского FineReader у них еще куча продуктов в области обработки документов вплоть до построения онтологий.

http://www.abbyy.ru/flexicapture/#home-page-leaders


 

213
Для всех / Re: Разработки
« : 16 Марта 2016, 23:54:54 »
У них нет организационной структуры департамента, более того никто не знает, как разработать структуру в виде блок-схемы.

Стесняюсь спросить, а как разработать структуру в виде блок-схемы?

Блок-схемой описывается алгоритм или процесс (behavior diagrams), оргструктура  - structural diagrams...

Или Вы блок-схемой любые схемы с блоками (кубиками) называете?

214

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.

Правильно делают, что не читают. Вместе с тем 200+ элементов - это фактически учебная задача. ER простенькой системы  - это 500-700 сущностей, более-менее детальное описание логистического процесса 500 и более активностей. В САП около 100 000 таблиц
 
Больших слонов едят по частям - сделать что-то полезное с таким количеством элементов и их связей человек с нормальной психикой просто не в состоянии. Поэтому у аналитика и есть инструментарий с репозитарием , который позволяет работать не со всей моделей на ватмане, а с отдельной проекцией, помещая в фокус именно ту часть модели, которая необходима для принятия решения.
 

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

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


215
Это если есть возможность создавать свою структуру БД. В нашем случае нужно эти сущности реализовывать на базе архитектуры имеющейся системы управления задачами, довольно жёсткой.

Вот о том и речь . 1:1 как правило в результате допиливаний и появляются

216
В этой же системе с каждым требованием может быть связан один или несколько вариантов решения (вторая сущность). На определённом этапе одно из решений должно быть выбрано, и дальше требование рассматривается с выбранным решением как единое целое.


Я бы выбранное решение описал как отдельную сущность, связанную с требованием и решением.
Унарные связи - зло. Как правило это заплатка

217
Про компонентные диаграммы я в курсе.
Речь идет  о техническом вопросе - графическая нотации uml не соответствует ГОСТ.

Компонентная диаграмма может замечательно отражать ваше видение и даже быть понятной заказчику. Но ГОСТ требует наличия именно схемы деления,  а нормоконтроль требует соблюдения стандарта ее оформления


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

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

219
А в чем выгода от объединения и сложность синхронизации?

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

220
Сравнивать BPMN c точки зрения трассировки требований IDEF0 бесмысленно. Одна из ключевых задач трассировки - это трассировка нефункциональных требований к функциональном, у BPMN, насколько я знаю, просто нет выразительных средств для этого, в то время как для IDEF0 это просто "нативное" состояние.

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

Безусловно BPMN не является средством конфигурационного управления, как IDEF0. Тем не менее ровно настолько BPMN является процессной нотацией и позволяет зафиксировать в процессе контекст взаимодействия пользователя с системой, настолько мы можем осуществить трассировку.

И IDEF0 и BPMN требуют зафиксировать границы процесса и цель моделирования. Управление viewpoint в BPMN не такое явное, как в IDEF0, но тем не менее свои критерии детализации описания тоже присутствуют.

Для каждой activity на BPMN диаграмме можно указать исполнителя, для процесса целиком желательно выделить его владельца. На схемке во вложении мы зафисировали активность , ассоциированную с Системой.

Смысл стрелок в BPMN и IDEF0 разный (в BPMN это поток управления, а в IDEF все определяется тем , куда пришла стрелка). То , для чего в IDEF0 отведено три типа входящих стрелок и один исходящий в BPMN отражается только направленной и ненаправленной ассоциацией.

Тем не менее связь системы как с активностью, ее ассоциациями, так и с процессом в целом устанавливается. А если есть связь, значит возможна и  трассировка. 

Несомненным преимуществом IDEF0 является жесткость декомпозиции. Все связи декомпозируемого процесса необходимо пробросить вниз (или наоборот вытащить наверх из декомпозиции) или осуществить туннелирование.
Естественно BPMN не заставляет так строго работать с ассоциативными связями - декомпозиция осуществляется только относительно потока управления.

Поэтому как только мы зафиксировали факт взаимодействия с системой в BPMN мы тут же вынуждены менять нотацию и само это взаимодействие описывать через use case или другими видами поведенческих диаграмм.

В IDEF0 необходимости менять нотацию нет .

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

Вышесказанное является моей сугубо личной точкой зрения, ни на научность подхода, ни на методологическую чистоту не претендую :)

221
Я о том, что ко мнению оргконсультантов в части неприменимости IDEF0 надо относится крайне осторожно. Если обычные бизнес-аналитики еще выполняют техническую функцию посредника между бизнесом и IT , то у  оргконсультантов вообще чистая политика. Им просто не до нотаций...

Если брать мое мнение, то IDEF0 вполне может вернуться. Сейчас его практически вытеснил BPMN.  BPMN  отличная нотация и для as is, и для to be, и прототипирование на BPMS возможно, но в качестве нотации для выявления и фиксации функциональных и нефункциональных требований не подходит так, как IDEF0.

С другой стороны вклинивание  IDEF0 между описанием БП as is в BPMN и моделированием поведения системы в UML - это серьезное усложнение технологии.

222
У организационных консультантов, которые работают с собственниками и руководителями малого и среднего бизнеса основная проблема в том, что собственники и руководители малого и среднего бизнеса не особо то с ними и работают.

В принципе. А не потому, что они пользуются или не пользуются какой-то там нотацией

223
Хорошо, пусть будет "Цели владельцев предприятия". И цели прочих заинтересованных лиц. Эти цели хорошо разобраны в книге "Цель-2".

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

Хотя владельцам компании приятно слышать как можно чаще, что они самые главные :) 

224
Слово функционал , приведенное в тексте, имеет несколько другое значение

Цитировать
1. Математическое понятие, возникшее в вариационном исчислении для обозначения переменной величины, заданной на множестве функций, т.е. зависящей от выбора одной или нескольких функций.
2. Гомосексуалист, не образовывающий пары. Имеет очень много гомосексуальных партнеров и мало сексуальных проблем. Как правило, это лица более молодого возраста.»

https://toster.ru/q/14928

При написании ТЗ уместнее говорить о функциональных  требованиях.

Если хотите повысить шансы на прохождение теста:

1) Стуруктурируйте текст в соответствии с ГОСТ

http://protect.gost.ru/document.aspx?control=7&id=155153
http://protect.gost.ru/document.aspx?control=7&id=139096

Строго соблюдать не требуется, но если Вас попросили сделать именно ТЗ, а не BRD или FT, надо делать именно ТЗ

2) Разделите функциональные, нефункциальные требования, бизнес-правила и требования к интерфейсу

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

В остальном полностью присоединяюсь к Денису

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

Задать вопрос - кажется самым простым способом. Но зачастую не самым эффективным. В 90% процентов случаев контактное со стороны заказчика лицо не сможет на него ответить, а если ответит, то не факт, что ответит правду. Причин этому множество, и прежде все потому , что раскрытие сути IT проекта  может  раскрывать инфу о каких-то долгосрочных планах организации, которые не всегда компания хочет раскрывать. Например, небольшая розничная  компания неожиданно захочет внедрить САП или построить дорогостоящую систему бизнес-аналитики. Это может быть связано например с планируемым захватом рынка с привлечением инвестиций. Раскрытие этой информации конкурентам даст им возможность сильно осложнить этой компании достижение ее целей.

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

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

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

Что в этой ситуации делать БА на стороне исполнителя?

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

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »