316

Сообщество Аналитиков / Re: Чем занимаются аналитики, когда не работают?

« : 14 Марта 2017, 20:46:37 »

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

+1

317

Сообщество Аналитиков / Re: Чем занимаются аналитики, когда не работают?

« : 11 Марта 2017, 21:31:39 »

Живу просто, детей воспитываю, жену люблю, с друзьями общаюсь, родителей навещаю, да много чего еще

318

UML SysML и пр. / Re: Почему Вы используете или не используете UML?

« : 06 Марта 2017, 17:09:19 »

Есть статья британского учёного (тм) с исследованием 2013 года: https://goo.gl/lrDYpw
Если сравнивать, то питерцы из 2008-го очень продвинуты в использовании UML.)
Другая публикация той же свежести посвящена исследованию проиндексированных гуглем EA-проектов. На 121й модели из открытых источников сосчитали частоту использования диаграмм, элементов языка, стереотипов и т. д.: http://subs.emis.de/LNI/Proceedings/Proceedings225/289.pdf
Хороший источник развлекательных вставок в слайды.)

Да, интересно

319

UML SysML и пр. / Re: Почему Вы используете или не используете UML?

« : 05 Марта 2017, 14:26:37 »

В докторской диссертации Д. В. Кознова есть статистика по использованию UML в Питере (правда, собранная в 2008 году).
См. https://disser.spbu.ru/disser2/706/disser/Dissertation_Koznov.pdf стр. 31 и далее.

Интересно бы повторить исследование

320

Идеи и мозговой штурм / Re: Миникомикс или "Мама, забери меня домой!"

« : 05 Марта 2017, 14:25:28 »

Я хотело обратить внимание на курьёз: версии одной и той же диаграммы используются и для того, чтобы указать на бессмысленность диаграмм ВИ, и для того, чтобы обосновать пользу от их рисования.
P. S. Статья по ссылке имеет мало отношения к диаграммам ВИ как таковым. Полагаю, Григорий может пополнить свою коллекцию "смешных диаграмм".

Ясно, спасибо.

321

Идеи и мозговой штурм / Re: Миникомикс или "Мама, забери меня домой!"

« : 05 Марта 2017, 14:23:02 »

https://habrahabr.ru/company/luxoft/blog/312188/

Спасибо

322

Идеи и мозговой штурм / Re: Миникомикс или "Мама, забери меня домой!"

« : 03 Марта 2017, 22:30:57 »

История началась в 1999 году с выходом книги "Программист-прагматик", авторы которой решили поехидничать над диаграммами вариантов использования. На страницы книги они поместили рисуночек usd1.jpg, приписав It seems incredible to us...
Второй эпизод отыграл Алистер Коберн, добавивший цитату из "Программиста-прагматика" в своей книге "Writing Effective Use Cases" в 2000-м: usd2.jpg. "Кто-то думает, что эти 'яйца' и есть ВИ..."
Финал случился в 2016-м. Креативно переосмысленная диаграмма в хабрахабрской статье подкрепляет мысль о пользе рисования диаграмм ВИ: usd3.jpg
 

Прикольно, а какую мысль хотели донести? Да, нельзя ли ссылочку на статью в Хабре?

323

Для всех / Re: Вопрос в тесте

« : 02 Марта 2017, 23:54:39 »

Вы считаете, что после вашего комментария, я брошу учёбу? 

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

324

IDEF ARIS BPMN и пр. / Re: Помощь с диаграммой декомпозиции

« : 26 Февраля 2017, 23:07:31 »

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

Так может надо начать с описания процесса разработки веб-ресурса? Составить хотя бы общее представление об организации процесса разработки?
Что будет начальным этапом, чем все завершится. У вас на диаграмме крайне мало ВХОДОВ, УПРАВЛЕНИЯ, но богато МЕХАНИЗМОВ, это главное в вашей задаче?

Если честно, не понял, что Вы имеете ввиду.

Смотрите у вашей разработки есть заказчик, этот заказчик выдвигает какие-то требования (то что вы ниже называли " пожелания, взгляды, просьбы"). Потому я и спросил, разве в ходе РАЗРАБОТКИ сайта не происходит ПРЕОБРАЗОВАНИЕ ВХОДА=требований заказчика в ВЫХОД= готовый сайт, соответствующий этим требованиям?

Иначе мне приходится читать вашу диаграмму так
на основании(под управлением) ТРЕБОВАНИЙ ЗАКАЗЧИКА функциональный блок РАЗРАБОТКА КОМ. САЙТА преобразует ЗАЯВКУ и ИНФОРМАЦИЮ О ПРЕДПРИЯТИИ в САЙТ и ДОГОВОР (например). Все верно? Требования не претерпевают изменения в ходе вашего процесса, они лишь управляют, ограничивают и т.п.?

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

Тогда вопрос, а откуда берется ТЗ из какого другого процесса, на основании чего создается ТЗ и какие такие правила оно включает?

Если все более менее правильно, как быть дальше?

Ничего собственно не изменилось, поскольку принципиально вы ничего не изменили. Нет точки зрения (неявно вы мне сигнализируете что она ваша, а вы кто? я же не знаю кто вы, 570326, что вы есть и какова ваша точка зрения.
Задача ваша разработать веб-ресурс (а почему не сайт?) - ну так разрабатывайте, какое отношение к этому имеете ваша контекстная диаграмма IDEF0? Ее цель какая? Зачем вы ее делаете?

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

А проверка простая.
1 вы смотрите выходы - это результат вашего функционального блока, анализируете всели придуманные вами выходы одного масштаба и действительно выходы
2 для каждого выхода смотрите что нужно для его получения, т.е. если ли входы
 например
список паролей, как я представляю нет смысла писать пустой список паролей, но есть смысл иметь список сотрудников и их пароль на вход в ком.сайт (я уже не говорю о ролях, которые эти сотрудники выполняют внутри сайта), но откуда я возьму список сотрудников - я не вижу, если он в ТЗ, то почему ТЗ не на входе? ведь список сотрудников в ТЗ преобразуется в список сотрудников с паролями, а известно что управление не превращается в выход, оно инициирует, управляет, ограничивает, но не превращается в выход. Уловили идею?

325

IDEF ARIS BPMN и пр. / Re: Помощь с диаграммой декомпозиции

« : 26 Февраля 2017, 00:13:16 »

Добрый день.

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

Вопрос:
разве не требования заказчика входе разработки сайта не преобразуются в этот самый сайт?

Как соотносятся ТЗ и требования заказчика - они не зависимы?

Приказы и распоряжения, а также НПД не очень понятно зачем тут нужны.

326

Примеры / Re: Use Case мобильного приложения

« : 24 Февраля 2017, 20:27:40 »

6000 сообщений! 
Реплика бессодержательная, извините, но как тут пролететь мимо.

Да, уж, кругленькое число

327

Примеры / Re: Use Case мобильного приложения

« : 22 Февраля 2017, 23:50:59 »

1. C этим видимо погорячился, но хотел я показать что эти две подсистемы связаны. В последнем варианте сделал обобщение и все равно возникают какие то сомнения.

Опять погорячились. Уже отметил НЛО, что у вас что-то не так с направлением. Т.е. Это организатор может расширять возможности участника, т.е. правильнее говорит специализирует, а участник обобщает. Т.е. стрелка наоборот.

2. Я так понимаю расширение применяется когда один вариант использования включает функциональные возможности другого при определенных условия, и получается что вариант "Управление услугой" включает функциональные возможности:  Добавить мероприятие, Удалить мероприятие, Редактировать контент т.е. если изменились какие то данные по мероприятию организатор Управляет услугой в частности Редактирует контент. Эм, или это все-таки "включить" или в принципе вариант использования Управление услугой здесь будет лишним.

Extend и Include - это две стороны одной медали. Include скажем так включение без условий, Extend - включение по условию. Отсюда сразу начинаем думать. Смотрим в админку - а если В Управлять мероприятием ничего не включится вдруг (ну нет подходящего истинного условия), что будет такое Управлять мероприятием?

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

Соглашусь с НЛО, сложно рассуждать о диаграмме, не имея иной информации

328

Примеры / Re: Use Case мобильного приложения

« : 21 Февраля 2017, 14:37:38 »

Для начала просто несколько вопросов

1 что такое связь админка - включает - пользовательский интерфейс? в стандарте такого нет в принципе да и смысл реально не очень ясный. в лучшем случае Организатор обобщается (наследует его возможности) в участнике мероприятия, и то думать надо
2. поясните что вы имеете в виду в тех случаях, где используете отношение расширения - Управление мероприятием - расширяет - добавление мероприятия (и т.д. во всех таковых случаях)?
3. что означает включения Просмотр информации о мероприятии - включает - дата мероприятия - что вы имеете в виду в данном случае?

Общее замечания в рамках одной модели принято формулировать use case в едином стиле или Разместить заказ блюд (или заказать блюда) или Размещение заказа блюд или просто Заказ (в смысле заказывание) блюд.

329

Для всех / Re: Как добраться до составления сценариев использования?

« : 15 Февраля 2017, 22:02:51 »

Буду рад, волне аргументированной критике.

В книге Дж. Рамбо и М. Блаха - UML2.0 Объектно - ориентированное моделирование и проектирование достаточно точно и ясно описан процесс проектирования по мнению авторов.

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

ФТ хорошо получать из описания бизнес-процесса (бизнес-процессов), одни или несколько шагов БП могут стать вариантом использования.

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

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

В реальности мы используем одновременно оба подхода. НО если вы используете объектно-ориентированный подход, то в большей части идете по второму подходы, т.е. описываете систему как некоторую совокупность взаимодействующих объектов, которые выполняют требуемые функции и проявляют требуемое качество

Ориентация на use cases тоже по сути подход снизу вверх, в котором определяются действующие лица (т.е. окружение системы) и определяются сценарии использования ими системы.

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

Далее для каждого такого действующего лица определяем эти сценарии использования (т.е. задачи). В результате получим кусочки функциональности, которыми должна обладать ИС ОТдел кадров:

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

330

IDEF ARIS BPMN и пр. / Re: Определить чертежи idef

« : 15 Февраля 2017, 21:42:33 »

Всем доброго вечера, изучаю idef. Помогите пожалуйста определить где на какой картинке, какой idef. idef0 и тд. Совсем в ступоре..

2-4 картинки -это IDEF0. Первая представляет собой оргструктуру,