1
ПО Аналитика / Re: Помощ в установке bizagi studio
« : 27 Января 2017, 14:59:14 »
Если SQL-сервер накатывался установщиком самой Бизаги, то логин и пасс
SA
Bizagi10GO
это есть в мануале
SA
Bizagi10GO
это есть в мануале
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
2
Для всех / Re: ISO/IEC/IEEE 29148:2011 Requirements engineering - есть ли в свободном доступе.
« : 11 Октября 2016, 18:22:06 »
Григорий, спасибо.
Гуглом только платные нашёл.
Закрывайте тему.
Гуглом только платные нашёл.
Закрывайте тему.
3
Для всех / ISO/IEC/IEEE 29148:2011 Requirements engineering - есть ли в свободном доступе.
« : 11 Октября 2016, 16:58:46 »
Коллеги, добрый день.
Ищется текст ISO/IEC/IEEE 29148:2011 Requirements engineering
Интерес абсолютно абстрактный, просто решил ознакомиться с документом.
168 швейцарских франков за документ с печатями мой интерес однозначно не стоит.
Если кто-нибудь встречал текст в бесплатном доступе - буду признателен за ссылку.
Русский язык не принципиален, тем более что перевода скорее всего нет.
Ищется текст ISO/IEC/IEEE 29148:2011 Requirements engineering
Интерес абсолютно абстрактный, просто решил ознакомиться с документом.
168 швейцарских франков за документ с печатями мой интерес однозначно не стоит.
Если кто-нибудь встречал текст в бесплатном доступе - буду признателен за ссылку.
Русский язык не принципиален, тем более что перевода скорее всего нет.
4
Примеры / Deployment Diagram. Первый блин. Просьба покритиковать.
« : 28 Сентября 2016, 18:24:14 »
Коллеги,
Это первый вообще мой опыт использования Диаграммы размещения.
Контекста применения системы специально не привожу.
Просьба посмотреть диаграмму и ответить - хоть кто-то что-то понял или мне идти учебник перечитывать ?
PS.
Эдуард,
да, это связано с нашей перепиской на ФБ.
Это первый вообще мой опыт использования Диаграммы размещения.
Контекста применения системы специально не привожу.
Просьба посмотреть диаграмму и ответить - хоть кто-то что-то понял или мне идти учебник перечитывать ?
PS.
Эдуард,
да, это связано с нашей перепиской на ФБ.
5
Примеры / Re: use-case. Реализация продукции хлебопекарни.
« : 26 Сентября 2016, 15:15:52 »
1. С формальной точки зрения, процесс заключения договора и процесс контроля реализации исполнения, находятся за рамками предметной области процесса "Реализация продукции"
2. Обработки заказов точно нет никакой ? То есть клиент, независимо от наличия договора, приезжает когда хочет и берёт всё, что сможет ?
3. "Погрузка" - точно будет автоматизируемой функцией ? То есть вот прямо в момент погрузки будет использоваться какое-то устройство типа сканера/тсд с передачей каких-то данных ?
2. Обработки заказов точно нет никакой ? То есть клиент, независимо от наличия договора, приезжает когда хочет и берёт всё, что сможет ?
3. "Погрузка" - точно будет автоматизируемой функцией ? То есть вот прямо в момент погрузки будет использоваться какое-то устройство типа сканера/тсд с передачей каких-то данных ?
6
Проектирование / Re: Моделирование отношений между таблицами БД
« : 22 Сентября 2016, 19:35:09 »
Mixailo
Моё знакомство с Ахапкой закончилось достаточно давно, ещё во времена 3й версии, так что точно сказать не могу, но ...
что-то мне подсказывает, что Item Vendor - это не собственно ракурс Поставщика, а скорее ссылочная таблица для записи данных о конкретной партии (поставке, документе ...).
Пример. На основе реального.
Есть производитель. У него по России N заводов.
Есть сеть магазинов. У неё по всей стране N+1 магазинов
Так вот, поставщиком для этих N+1 магазинов будет не сам производитель. Это не оправдано никак с точки зрения логистики.
Поставщиков будет несколько - обычно вокруг каждого завода определяется регион, в котором некий местный поставщик будет приводить товар в местные магазины.
Товар один и тот же по факту. Разве что штрих-коды отличаться будут.
И вот на случай списания или возврата товара поставщику и может пригодиться ссылка на поставку.
Смотрите сами короче.
Моё знакомство с Ахапкой закончилось достаточно давно, ещё во времена 3й версии, так что точно сказать не могу, но ...
что-то мне подсказывает, что Item Vendor - это не собственно ракурс Поставщика, а скорее ссылочная таблица для записи данных о конкретной партии (поставке, документе ...).
Пример. На основе реального.
Есть производитель. У него по России N заводов.
Есть сеть магазинов. У неё по всей стране N+1 магазинов
Так вот, поставщиком для этих N+1 магазинов будет не сам производитель. Это не оправдано никак с точки зрения логистики.
Поставщиков будет несколько - обычно вокруг каждого завода определяется регион, в котором некий местный поставщик будет приводить товар в местные магазины.
Товар один и тот же по факту. Разве что штрих-коды отличаться будут.
И вот на случай списания или возврата товара поставщику и может пригодиться ссылка на поставку.
Смотрите сами короче.
7
Проектирование / Re: Моделирование отношений между таблицами БД
« : 22 Сентября 2016, 09:54:02 »
Mixailo
Сбоку и не об этой модели...
У Вас имеется ошибка ещё на уровне предметной области, а соответственно и архитектуры.
Поставщик - это поставщик. Юридическое лицо или ИП со своим набором свойств и методов.
Товары же, поставляемые одним поставщиком стоит выносить в отдельную сущность - "Спецификация" (прайс-лист, контракт, как угодно). В реальности у Вас с одним поставщиком может быть один договор на одно Ваше юр.лицо, а в этом договоре - несколько спецификаций на разные случаи жизни, в которых встречается один и тот же товар).
О диаграмме.
На диаграмме классов Вы пишете связи между сущностями. Вы уверены, что на ней же нужно обозначать ограничения?
Проверка условий при удалении - это уже одно из действий метода класса. Зачем её наверх тащить ?
Сбоку и не об этой модели...
У Вас имеется ошибка ещё на уровне предметной области, а соответственно и архитектуры.
Поставщик - это поставщик. Юридическое лицо или ИП со своим набором свойств и методов.
Товары же, поставляемые одним поставщиком стоит выносить в отдельную сущность - "Спецификация" (прайс-лист, контракт, как угодно). В реальности у Вас с одним поставщиком может быть один договор на одно Ваше юр.лицо, а в этом договоре - несколько спецификаций на разные случаи жизни, в которых встречается один и тот же товар).
О диаграмме.
На диаграмме классов Вы пишете связи между сущностями. Вы уверены, что на ней же нужно обозначать ограничения?
Проверка условий при удалении - это уже одно из действий метода класса. Зачем её наверх тащить ?
8
Работа / Re: Можно ли найти работу удаленно аналитиком на начальном этапе
« : 29 Июня 2016, 14:26:07 »Просто ТЗ которые составляются в моей организации не такие "расписанные"
Юлия, а много ли Вы видели ТЗ "других" организаций ? Почему Вы решили, что они какие-то "расписанные" ? На форумах об этом пишут ?
Не верьте.
Процентов 70, если не больше, заданий у меня в отделе - не более 2 страниц содержательной части.
Крупные, подробные описания - только на абсолютно новую функциональность.
9
Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением
« : 16 Мая 2016, 14:20:36 »
Я в общем соглашусь с Сергеем.
Часто реальные цели внедрения (в основном это конечно касается ERP-систем, но иногда относится и к не очень объемным задачам) лежат далеко за пределами стандартных формулировок "оптимизировать" "сократить" "улучшить" и не оглашаются. И речь вовсе не об "откатах".
Часто реальные цели внедрения (в основном это конечно касается ERP-систем, но иногда относится и к не очень объемным задачам) лежат далеко за пределами стандартных формулировок "оптимизировать" "сократить" "улучшить" и не оглашаются. И речь вовсе не об "откатах".
10
Системный Анализ и Требования / Re: Согласование Вариантов использования (Use case): подводные камни и обходные пути
« : 07 Мая 2016, 14:13:17 »
Добрый день.
А что Вас смущает ?
То, что у Кокберна написано не тащить интерфейсы в юзкейс?
Не будьте в плену предрассудков. Кокберн имел в виду разработки с нуля.
Если Ваша разработка идёт внутри уже работающей системы с устоявшимся UI, который Вы не планируете ломать - добавляйте в кейсы пользовательского уровня элементы интерфейса. Получите пользовательский мануал. Сразу. Что вроде бы и требуется.
Нужно только предусмотреть 2 варианта визуализации кейса, с картинками и без. Если это позволяет инструмент.
Расшифрую.
А теперь начните писать не просто текст с картинками, а юзкейс с картинками.
Чем отличается юзкейс от простого текста Вы хорошо понимаете ? Правильно, алгоритмичностью. Что позволяет лучше видеть явные пропуски и альтернативы в планируемой разработке. И соответственно уменьшить количество "не учли" и "не подумали" в продуктиве.
Как результат.
Вы сохраните очевидные минусы в скорости разработки документации, связанные с необходимостью прорабатывать элементы интерфейса на ранних стадиях.
Вы сохраните плюсы в виде заказчиков, которые видят постановку в привычной форме, только лучше.
Вы получите новые плюсы в виде готовых пользовательских мануалов.
В итоге всё-равно окажетесь в плюсе за счёт более чёткой постановки задачи и сокращения времени на выход в прод.
А что Вас смущает ?
То, что у Кокберна написано не тащить интерфейсы в юзкейс?
Не будьте в плену предрассудков. Кокберн имел в виду разработки с нуля.
Если Ваша разработка идёт внутри уже работающей системы с устоявшимся UI, который Вы не планируете ломать - добавляйте в кейсы пользовательского уровня элементы интерфейса. Получите пользовательский мануал. Сразу. Что вроде бы и требуется.
Нужно только предусмотреть 2 варианта визуализации кейса, с картинками и без. Если это позволяет инструмент.
Расшифрую.
Цитировать
Раньше писали требования "на естественном языке", в виде текста вперемешку с картинками. Заказчиков, это, в принципе, всегда устраивало.
А теперь начните писать не просто текст с картинками, а юзкейс с картинками.
Чем отличается юзкейс от простого текста Вы хорошо понимаете ? Правильно, алгоритмичностью. Что позволяет лучше видеть явные пропуски и альтернативы в планируемой разработке. И соответственно уменьшить количество "не учли" и "не подумали" в продуктиве.
Как результат.
Вы сохраните очевидные минусы в скорости разработки документации, связанные с необходимостью прорабатывать элементы интерфейса на ранних стадиях.
Вы сохраните плюсы в виде заказчиков, которые видят постановку в привычной форме, только лучше.
Вы получите новые плюсы в виде готовых пользовательских мануалов.
В итоге всё-равно окажетесь в плюсе за счёт более чёткой постановки задачи и сокращения времени на выход в прод.
11
Для всех / Re: Объект обследования
« : 27 Марта 2016, 10:50:53 »По hard system - да, согласен.
Ну и по точкам зрения можно тоже расширить.
Если смотреть на перевозку деталей из цеха в цех с точки зрения перехода мат.ответственности например, а не с точки зрения производственной или сбытовой цепочки, тогда - да. Это выделенный процесс. На тему "бизнес-" ли это процесс - предлагаю копья не ломать, есть ощущение, что автору это пока рановато.
12
Примеры / Re: Аннулирование сущности в любой момент времени. Как отобразить?
« : 27 Марта 2016, 10:44: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
Sparx / Re: Формирование схемы деления ГОСТ 2.711 в EA
« : 04 Марта 2016, 12:17:40 »
Я бы попробовал выкрутиться через элемент "Artifacts - Document", который позволяет затянуть в схему RTF-файл
А уже в RTF отлично вставляются копипастом схемы из Visio.
Ну так себе решение, но за не имением гербовой ...
А уже в RTF отлично вставляются копипастом схемы из Visio.
Ну так себе решение, но за не имением гербовой ...