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

×


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

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


Сообщения - Андрей Сенченко

Страницы: 1 2 3 4 5 6 »
1
Если SQL-сервер накатывался установщиком самой Бизаги, то логин и пасс

SA
Bizagi10GO

это есть в мануале

2
Григорий, спасибо.
Гуглом только платные нашёл.

Закрывайте тему.

3
Коллеги, добрый день.

Ищется текст ISO/IEC/IEEE 29148:2011 Requirements engineering

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

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

4
Коллеги,
Это первый вообще мой опыт использования Диаграммы размещения.
Контекста применения системы специально не привожу.

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

PS.
Эдуард,
да, это связано с нашей перепиской на ФБ.

5
1. С формальной точки зрения, процесс заключения договора и процесс контроля реализации исполнения, находятся за рамками предметной области процесса "Реализация продукции"
2. Обработки заказов точно нет никакой ? То есть клиент, независимо от наличия договора, приезжает когда хочет и берёт всё, что сможет ?
3. "Погрузка" - точно будет автоматизируемой функцией ? То есть вот прямо в момент погрузки будет использоваться какое-то устройство типа сканера/тсд с передачей каких-то данных ?


6
Mixailo

Моё знакомство с Ахапкой закончилось достаточно давно, ещё во времена 3й версии, так что точно сказать не могу, но ...
что-то мне подсказывает, что  Item Vendor - это не собственно ракурс Поставщика, а скорее ссылочная таблица для записи данных о конкретной партии (поставке, документе ...).

Пример. На основе реального.
Есть производитель. У него по России N заводов.
Есть сеть магазинов. У неё по всей стране N+1 магазинов
Так вот, поставщиком для этих N+1 магазинов будет не сам производитель. Это не оправдано никак с точки зрения логистики.
Поставщиков будет несколько - обычно вокруг каждого завода определяется регион, в котором некий местный поставщик будет приводить товар в местные магазины.
Товар один и тот же по факту. Разве что штрих-коды отличаться будут.

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

Смотрите сами короче.


7
Mixailo

Сбоку и не об этой модели...

У Вас имеется ошибка ещё на уровне предметной области, а соответственно и архитектуры.
Поставщик - это поставщик. Юридическое лицо или ИП со своим набором свойств и методов.
Товары же, поставляемые одним поставщиком стоит выносить в отдельную сущность - "Спецификация" (прайс-лист, контракт, как угодно). В реальности у Вас с одним поставщиком может быть один договор на одно Ваше юр.лицо, а в этом договоре - несколько спецификаций на разные случаи жизни, в которых встречается один и тот же товар).

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

8
Просто ТЗ которые составляются в моей организации не такие "расписанные"

Юлия, а много ли Вы видели ТЗ "других" организаций ? Почему Вы решили, что они какие-то "расписанные" ? На форумах об этом пишут ?
Не верьте.
Процентов 70, если не больше, заданий у меня в отделе - не более 2 страниц содержательной части.
Крупные, подробные описания - только на абсолютно новую функциональность.

9
Я в общем соглашусь с Сергеем.
Часто реальные цели внедрения (в основном это конечно касается ERP-систем, но иногда относится и к не очень объемным задачам) лежат далеко за пределами стандартных формулировок "оптимизировать" "сократить" "улучшить" и не оглашаются. И речь вовсе не об "откатах".

10
Добрый день.
А что Вас смущает ?

То, что у Кокберна написано не тащить интерфейсы в юзкейс?
Не будьте в плену предрассудков. Кокберн имел в виду разработки с нуля.
Если Ваша разработка идёт внутри уже работающей системы с устоявшимся UI, который Вы не планируете ломать - добавляйте в кейсы пользовательского уровня элементы интерфейса. Получите пользовательский мануал. Сразу. Что вроде бы и требуется.
Нужно только предусмотреть 2 варианта визуализации кейса, с картинками и без. Если это позволяет инструмент.

Расшифрую.
Цитировать
Раньше писали требования "на естественном языке", в виде текста вперемешку с картинками. Заказчиков, это, в принципе, всегда устраивало.

А теперь начните писать не просто текст с картинками, а юзкейс с картинками.
Чем отличается юзкейс от простого текста Вы хорошо понимаете ? Правильно, алгоритмичностью. Что позволяет лучше видеть явные пропуски и альтернативы в планируемой разработке. И соответственно уменьшить количество "не учли" и "не подумали" в продуктиве.

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

В итоге всё-равно окажетесь в плюсе за счёт более чёткой постановки задачи и сокращения времени на выход в прод.

11
Для всех / Re: Объект обследования
« : 27 Марта 2016, 10:50:53 »

По hard system - да, согласен.

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

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

Если уж все хорошо понимают Activity - значит им не составит труда понять State Machine, которая является фактически изнанкой  Activity и как раз подходит под Ваши условия (аннулирование сущности - это одно из финальных состояний)

13
Для всех / Re: Объект обследования
« : 23 Марта 2016, 15:34:22 »
Допустим есть цех 1 и цех 2. Из цеха 1 доставляют изделия в цех 2. Доставляет человек на тележке.
Доставка изделий является бизнес-процессом?

Всё довольно просто.
Воспринимайте Бизнес-процесс как законченный, повторяемый набор действий для достижения результата, имеющего конкретную измеримую ценность для организации.
Доставка изделий из цеха 1 в цех 2 - набор действий законченный и повторяемый. Но он не имеет самостоятельной ценности для организации. Более того, он может не принести ценность, а нанести вред в случае если доставка проводится в направлении, обратном от технологического потока.
Это означает, что данный набор действий является Задачей внутри какого-то Бизнес-процесса. Чтобы понять какого именно процесса - нужно рассмотреть параметризацию этой задачи. Задача "доставить изделия из цеха 1 в цех 2" является бессмысленной без ключевых параметров:
1. Номенклатура изделий.
2. Количество изделий.
3. Срок погрузки.
4. Срок доставки.
А вот та область деятельности, где эти параметры определяются - уже может являться Процессом. А может не являться. Если также не несёт ценности.

14
Я бы попробовал выкрутиться через элемент "Artifacts - Document", который позволяет затянуть в схему RTF-файл
А уже в RTF отлично вставляются копипастом схемы из Visio.

Ну так себе решение, но за не имением гербовой ...

15
Это ?

Страницы: 1 2 3 4 5 6 »