121

Примеры / Re: UML диаграммы по BPMN

« : 09 Сентября 2014, 16:18:01 »

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

Думаю от того, что вы не видите реального смысла за этими квадратиками и стрелочками:)

Давайте начнем с самой, на мой взгляд, известной диаграммы UML - диаграммы вариантов использования.

У вас куча человечков натыкана куда-попало.
Для начала внесите ясность: слева - акторы которые инициируют варианты использования. Справа - которые участвуют пассивно.

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

И подумайте по поводу экстендов и инклюдов. Я бы сделал без них. Кстати в BPMN схеме нет доставки товара. Откуда она взялась и зачем?

Далее, перейдем к диаграмме классов: Разве сроки, расходы, риски, цена, артикуль, количество - это все классы? Разве это не атрибуты классов?

Ну и класс прайс-лист я бы вообще удалил. А может и класс доставки тоже.

Судя по всему, вы используете диаграмму классов не по назначению, а как-то по своему умыслу.
По этому чтобы подобрать нужный инструмент, надо, как верно сказал Леонид, определиться что же вам на самом деле нужно?
Построение UML диаграмм - это ведь не самоцель. Что вы хотите достичь ими?

122

Примеры / Re: UML диаграммы по BPMN

« : 09 Сентября 2014, 08:56:37 »

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

Доброе утро!

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

Что касается последней диаграммы, то есть несколько вопросов:

1. Зачем делать обобщение от менеджера к отделу продаж, если других обобщений нет? Не лучше ли заменить отдел продаж на менеджера и уменьшить количество сущностей?

2. Зачем сделана композиция между  Заказом поставщику и Доставкой? Заказ поставщика может и без доставки иметь связи с другими сущностями, тут имхо уместнее агрегация.

3. И наоборот, почему атрибуты товара показаны агрегацией? Разве они могут жить в отрыве от него? Тут более уместна, на мой взгляд, композиция. И даже больше скажу. Я вообще не вижу смысла выделять атрибуты товара как отдельные классы.

4. Последняя мелочь. Не кажется ли вам, что  "количество" - это атрибут, скорее заказа, чем товара?

123

Книги, статьи и ресурсы / Re: Карл Вигерс - Разработка требований к программному обеспечению (3е издание)

« : 04 Августа 2014, 10:44:36 »

Электронную книгу купил.
На енота сходил.

Все о чем писали в треде - сделал!

124

Теория моделирования и нотации / Re: Какие методологии системного анализа вы используете в своей работе?

« : 09 Июня 2014, 09:02:44 »

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

А ТРИЗ не подойдет?
http://ru.wikipedia.org/wiki/%D2%E5%EE%F0%E8%FF_%F0%E5%F8%E5%ED%E8%FF_%E8%E7%EE%E1%F0%E5%F2%E0%F2%E5%EB%FC%F1%EA%E8%F5_%E7%E0%E4%E0%F7

125

Теория моделирования и нотации / Re: Методологии системного анализа

« : 05 Июня 2014, 15:19:03 »

Посмотрите сверху, я сделал голосовалку. Если что-то из перечисленного явно не методология или явно не системного анализа, то пишите здесь, главное аргументируйте, аргументируйте.

Если бы вопрос стоял "Является ли методологией анализа систем? " я бы выбрал SADT.
А раз сформулировано по другому, надо раскрыть что автор понимает под системным анализом:)

126

Задачи студентов / Re: Диаграмма прецедентов простого антивируса

« : 19 Мая 2014, 10:38:21 »

А что, антивирус только сканирует, делает отчеты и изменяет настройки?
Ни лечит, ни удаляет, ни помещает в карантин, ни обновляется?

И чем отличаются пользователи слева и справа?

127

Для всех / Re: Краш-тест для системного аналитика

« : 05 Мая 2014, 11:02:17 »

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

Я бы в этот список включил еще разоблачающие мнения и мнения в которых IT не считается пупом земли:)

128

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

« : 24 Апреля 2014, 11:46:20 »

IMHO, наиболее ярко продажа пользы описана в книге "Цель-3". Только чего то я ее в продаже не вижу.
Еще можно вот эти две:
"Цель-2" http://www.ozon.ru/context/detail/id/6258664/
"Я так и знал!" http://www.ozon.ru/context/detail/id/5572374/

А первая цель это о том, как сделать чтобы было чего продавать. Т.е. об операционном менеджменте.

Спасибо за подсказку!
Первую цель я как раз читал (для общего развития), а до второй и третьей руки не дошли пока. Теперь точно дойдут:)

Первая цель мне очень понравилось, но мне пока не хватает коммерческого и управленческого опыта чтобы применить знания полученные оттуда к производству ПО.

129

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

« : 22 Апреля 2014, 15:17:19 »

Примерно как везде.
По другому можно, но этому учиться надо. Долго.
Продавать часы сильно не выгодно. Продавать лучше пользу клиента. И именно этому учиться долго.

Спасибо за ссылки.
Может что-нить порекомендуете почитать про продажу пользы?

130

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

« : 22 Апреля 2014, 09:27:57 »

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

Фактически у нас это он и есть.

Только разработчику ее показывать не надо, дабы не срабатывало когнитивное искажение "студенческий синдром".

Ни в коем случае!:)

Если программист дает оценку трудоемкости, то это снижает его производительность примерно на треть.

Никогда об этом не слышал, можно поподробнее?

Оно вам точно надо?

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

131

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

« : 21 Апреля 2014, 17:12:17 »

Не-а. После диалога проблема маскируется. А ситуация ухудшается. Только теперь этого не видно.

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

У нас в компании, срыв сроков происходит обычно по двум причинам:
1. Разработчик думает что знает как сделать за указанное при оценке время.
2. Разработчик не думает при оценке ни о чем кроме решения задачи.

Т.к.  разработчиков у нас не очень много (менее 20 человек), по этому для каждого сотрудника есть поправочный коэффициент.
Т.е. оценка каждого умножается на него. Обычно он где-то в диапазоне 1,2 - 1,5.

132

Примеры / Re: UML диаграмма для сайта-магазина

« : 04 Апреля 2014, 15:37:35 »

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

Отличная идея!

133

Примеры / Re: UML диаграмма для сайта-магазина

« : 04 Апреля 2014, 12:37:56 »

Второй вариант еще хуже:)

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

Так какую диаграмму посоветовал сделать преподаватель? Точно ДВИ?
И что за ДК вы планируете сделать?

134

Примеры / Re: UML диаграмма для сайта-магазина

« : 04 Апреля 2014, 10:48:21 »

Добрый день!

А с какой именно UML диаграммы посоветовал начать преподаватель? Их ведь больше одной.

Что касается данной ДВИ, то для начала сделайте вот что:
1. Перенесите всех акторов влево и перерисуйте их иерархию.
2. Удалите ВИ которые не несут пользы  акторам (например, вход в систему)
3. Добавьте ВИ которые вы забыли (например, регистрация для гостя)

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

135

Вакансии / Re: Нужен Системный аналитик (Санкт-Петербург)

« : 02 Апреля 2014, 14:30:52 »

бедные аналы... если не супер, то не выходит...