31

Примеры / Re: Нет ни малейшего понимания.

« : 08 Октября 2016, 20:54:45 »

А разработчикам то что надо сделать? Что с этой сущностью дальше происходит?

32

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 03 Октября 2016, 14:29:53 »

цель автоматизация

Автоматизация процесс.  Он не может быть целью.

Википедия :

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

33

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 03 Октября 2016, 13:47:29 »

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

А цели разработки информационный системы определены? Если этого не сделать, описание предметной области и  разработка требований   к системе будет трудно отделить друг от друга.

34

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 02 Октября 2016, 16:46:40 »

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

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

35

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 02 Октября 2016, 15:46:34 »

Критерий этого лучше/хуже неясен.

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

36

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 02 Октября 2016, 14:05:41 »

Назрел ещё вот такой вопрос. Можно ли делать так с экстендами, как показано на диаграмме?

"Так" - это как?

В данном случае гораздо важнее "зачем".

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

На вашем примере акторы не связаны, общих use case у них нет, через extend и include вы пытаетесь отразить вызовы подпроцессов, выполняемых  другими акторами. Для отражения взаимодействий есть interaction diagram.

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

37

Бизнес-анализ и Целеполагание / Re: Как перейти из основн сценария об общих полях к сценарию о заполнении уникальных

« : 30 Сентября 2016, 15:15:08 »

А зачем так все усложнять? Здесь очень простой ВИ напрашивается:
...
А дальше прикрепляете к ВИ табличку (Data Dictionary), где описываете список всех возможных полей и проставляете обязательность их заполнения в зависимости от типа авто.

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

Для разработчика такой формат предпочтительнее, дабы не превращать сценарий в анекдот про 26 бакинских комиссаров или 300 спартанцев

http://www.anekdot.ru/id/-472200019/ 

38

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 30 Сентября 2016, 11:44:00 »

Переделал схему, но всё таки кажется чего то не хватает. Не могу никак полностью осознать саму суть use-case диаграмм, отсюда и проблемы со связями функций и актеров, может чего то не хватает, или где то что то не связанно?

Мне понравился такой образ: диаграмма вариантов использования - это кладбище  сценариев Яйцо - памятник, сам сценарий под ним, акторы - связанные между собой родственники

Суть ДВИ - не более чем отражение связей акторов и сценариев между собой.

Если брать Вашу ДВИ я бы сделал следущие изменения:

1) Использовал бы Boundary для группировки UC . Например Фирма, или Автоматизированная система для того чтобы отделить UC которые происходят внутри них или за их границами
2) Развел бы акторов по разным сторонам диаграммы. Работники фирмы налево, клиенты и  прочие внешние сущности направо
3) Ввел бы актора Сотрудник, остальных акторов , кроме клиента наследовал бы от него. А может быть вообще ввел актора Лица.

39

Бизнес-анализ и Целеполагание / Re: Простой бизнес-процесс в BPMN 2.0 - прошу покритиковать

« : 20 Сентября 2016, 17:35:42 »

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

http://mainthing.ru/ru/item/403/

40

Бизнес-анализ и Целеполагание / Re: Простой бизнес-процесс в BPMN 2.0 - прошу покритиковать

« : 20 Сентября 2016, 17:10:57 »

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

Почитайте про понятие токена в BPMN, прогоните его по вашему процессу.

Есть  формальные ошибки , которые не позволяют дальнейший анализ описания на предмет правильности:

1) Входящие и исходящие развилки каждого типа всегда парные
2) В Request update непонятно, что за объекты по которым идет цикл
3) В Team members вы шлете сообщения в цикле, а получаете его только один раз

Между bpmn и uml существенная интерпретационная разница. Попробуйте посмотреть   

http://www.bpmnforum.ru/
http://bpmntraining.ru/
http://mainthing.ru/ru/tag/pattern/

Там довольно много полезных паттернов

41

Работа / Re: Начало карьеры

« : 31 Августа 2016, 20:52:38 »

Давайте проверим. Идем на HH.ru, смотрим вакансии системных аналитиков — 219 штук в москве.
Смотрим, в каком количестве вакансий системных аналитиков упоминается слово "гост" — 35.

Это 16%, одна шестая рынка.

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

42

Работа / Re: Начало карьеры

« : 31 Августа 2016, 18:39:27 »

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

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

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

43

Работа / Re: Начало карьеры

« : 31 Августа 2016, 14:44:05 »

Ниже пример структуры реального ТЗ без воды.

ТЗ с такой структурой прекрасно пишется и по 19 и по 34 серии. Все страхи ГОСТ связаны с тем есть категория заказчиков и аналитиков , которые не имеют опыта их применения. Там, где есть культура использования ГОСТ и заказчиком, и исполнителем подобных проблем не существуют. Проблемы появляются там, где заказчик пытается использовать ГОСТы не как язык взаимодействия с исполнителем, а только из страха перед проверками. 

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

Терминологические отличия необходимо исследовать при освоении любой нотации или методологии - например при изучении UML приходится соотносить Actor и User, Концепции по ГОСТ в большей мере соответствует BRD, а не Vision, Vision при этом реализуется  в форме НИР, требования к безопасности определяются в 34 ГОСТ, который предусматривает материальную составляющую, причем совершенно необязательно в форме серверной и рабочей станции.

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

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




 

44

Примеры / Re: На сколько правильный пример диаграммы?

« : 31 Августа 2016, 13:46:36 »

Диаграмно тоже можно.

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

45

Работа / Re: Начало карьеры

« : 31 Августа 2016, 09:19:07 »

Не надо разрабатывать по ГОСТам ТЗ на блог. Блог – это не программное изделие (тьфу, слово-то какое). Технико-экономическое обоснование, требования к макировке и упаковке – вам это всё надо?

И тем более блог не автоматизированная система, прости господи.

Личный блог вообще вещь специфическая. Не сказал бы, что применить BRD удастся без натяжек. 

ГОСТ умер, не надо тащить этот труп в интернет-проекты.

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