1

Управление Проектом / Re: Расчет стоимости проекта

« : 14 Марта 2017, 09:31:00 »

Интересное решение.
Я пытался EA освоить глубже, чем просто рисование моделей, но пока далеко не продвинулся.

Странно, что нету готовых инструментов, при всей нужности и важности таких расчетов по проекту.
Вы сами для себя сделали решение, я тоже что-то сделал, выше писали: Люксофт сделал это в Excel...
С чем это связано?

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

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

Для меня EA удобен тем, что мне все равно для оценки проекта нужно рисовать UC. И обосновывать стоимость разработки, опираясь на UC, уже согласованные с заказчиком проще.

2

Управление Проектом / Re: Расчет стоимости проекта

« : 13 Марта 2017, 15:49:44 »

Я вот этой технологией пользуюсь.

http://www.uml2.ru/forum/index.php?topic=6474.msg39645#msg39645

После нескольких применений научаешься формировать UC так, что расчеты дают адекватные результаты

3

Вакансии / Re: Приглашаем Бизнес-аналитик (Qlik) Москва. kkosti1973@yandex.ru

« : 13 Марта 2017, 13:32:14 »

С общепринятой точки  Ваша вакансия не является вакансией бизнес-аналитика

https://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7

Бизнес-анализ (англ. business analysis) — дисциплина выявления деловых потребностей и нахождения решений деловых проблем. Решения часто включают компонент разработки систем, но могут также состоять из усовершенствования процессов, организационных изменений или стратегического планирования и разработки политики.

Есть даже общепризнанный свод знаний по бизнес-анализу - BABOK

http://www.iiba.org/babok-guide.aspx

Нет там ни ETL, ни 1-2 языков программирования

Ваша же вакансия содержит обычные требования к BI разработчику

4

Теория моделирования и нотации / Re: Множественные вх. / вых. объекты деятельности

« : 29 Января 2017, 20:12:51 »

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

А так подход простой - если по БП документы обрабатываются по разному, то можно объеденить их все в пакет и описать в одном месте. Если по БП документы из пакета обрабатываются по разному, то и описывать их надо по отдельности.

Иначе потом срез по документу не сделаешь

5

Sparx / Re: Нужны примеры описания API в UML

« : 26 Декабря 2016, 22:57:31 »

Стоит ли вообще делать описание API в UML?

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

6

Для всех / Re: Реализация и документы

« : 24 Декабря 2016, 00:11:41 »

Объясните пожалуйста: я делаю uml диаграмму и мне сказали что акт выполненных работ не бывает односторонним, что это значит? Что включает в себя процесс реализации?
И как можно назвать процесс в idef0 на картинке (вместо формирование базы 1с)?

1) Акт выполненных работ не выдается - он подписывается исполнителем и заказчиком. При этом не очень понятно, откуда он на этой ДВИ  взялся - производства на ней нет
2) Реализация продукции - превращение товаров в деньги

3) Похоже на налоговый учет, но как то криво...

Вы видимо в корне не понимаете сути юзкейсов. Вы пытаетесь юзкейсами описать процесс, т.е. по сути показать динамику. Хотя юзкейсы показывают статику.

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

В чем статика?

7

Проектирование / Re: IDEF0 реализация продукции

« : 16 Декабря 2016, 22:15:32 »

окей, спасибо за материал. выписка соответственно как внешний вход?

Да.

8

Проектирование / Re: IDEF0 реализация продукции

« : 16 Декабря 2016, 21:08:39 »

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

Рекомендую прокачать скилы по бухучету и двойной записи

http://helpme1c.ru/osnovy-buxgalterskogo-uchyota-dlya-programmistov-1s

Я бы блок оплаты не декомпозировал. На входе выписка , заказ и счет на заказ, на выходе оплаченный заказ.

9

Проектирование / Re: IDEF0 реализация продукции

« : 16 Декабря 2016, 20:15:30 »

Совершенно не понял какой отчет...

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

10

Проектирование / Re: IDEF0 реализация продукции

« : 16 Декабря 2016, 19:35:14 »

Терминология:
Не формирование договора, а заключение договора
Вход во второй процесс называется заявка (неподтвержденный заказ)
Не карточка заказа (это отображение заказа в информационной системе), а заказ

Как правило заказ оформляется следущим образом :

1) Клиент присылает заявку
2) Поставщик оформляет заказ и счет на оплату заказа
3) Оплата клиентом счета на заказ означает согласие с заказом

Оформление счета на заказ является частью активности оформления заказа, а не оплаты

Третью активность я бы назвал Оплата заказа или Оплата счета на заказ. Она вообще совершенно непонятная

С точки зрения хлебопекарни процесс выглядит так:

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

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


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

11

Для всех / Re: Трассируемые документы.

« : 16 Декабря 2016, 08:25:05 »

Отдельный вопрос - как КТ-178В (или другой стандарт) связать с ЕСПД, чтобы не возникало никаких вопросов (наш заказчик требует следования ЕСПД). Состав документов ведь разный. Да и жизненный цикл, как я понимаю, предполагается разный. Или тут я зря беспокоюсь?

Совершенно правильно беспокоитесь. Именно так - и состав документов разный , и жизненный цикл разный. Тут приходится выбирать - или госты 19 серии или ГОСТ 51904-2002.

Такая же история с 19 гостом и 34 - либо один, либо другой. Причем всю разработку вы можете вести по 34 госту, а составную часть по 19 му. И наоборот. Подозреваю и тут так же.

12

Для всех / Re: Трассируемые документы.

« : 16 Декабря 2016, 03:11:27 »

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

Я стараюсь разделять структуру системы на функциональную и системную. На уровне ТЗ фиксировать функциональную структуру не в виде подсистем или компонент, а в виде групп функциональных требований. Требования к составу предьявять по минимуму и только те, которые реально необходимы.

При проектировании АСУ есть такая болезнь - определять состав компонент в соответствии с организационной структурой. Очень тяжело потом сдавать ...

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

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

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

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

13

Для всех / Re: Трассируемые документы.

« : 14 Декабря 2016, 22:11:39 »

Некоторое время работал кодировщиком в организации, где использовался стандарт КТ-178B, но погружен в эти вопросы был только менеджмент. Планировал пока что опираться на него, как хоть немного знакомый. Или этот стандарт "из другой оперы"?

Под этот стандарт уже есть модель трассировки

http://saturs.ru/index.php?r=block%2Fplain&label=do178

Ну и в фейсбуке сформировалась инициативная группа разработки модеи под 34 ГОСТ.

14

Для всех / Re: Трассируемые документы.

« : 13 Декабря 2016, 22:47:50 »

Идею обратиться к Мадорской по поводу трассировки полностью поддерживаю. Есть правда шансы после этого начать считать, что 3sl cradle лучший в мире инструмент аналитика, но в этом ничего плохого нет

15

Проектирование / Re: IDEF0 реализация продукции

« : 13 Декабря 2016, 09:31:56 »

Спасибо.
А если не согласован договор, тогда что? Или для таких целей idef 0 не предназначена?

Idef0 не предназначен. Он для отражения взаимозависимости функций. Нет там конструкций ЕСЛИ.

Для событий, условий и т.д - epc или bpmn