121

Примеры / Re: СКУД в школе

« : 08 Ноября 2013, 09:59:50 »

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

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

Я понимаю под main use cases, те "варианты использования" которые бы описывали сценарий и без которых выполнение сценария не возможна.

Под main use cases видимо подразумеваются наиболее часто используемые. Возможно есть какие-то более чёткие критерии отделения "main" от "не main". Я бы уточнил у преподавателя.

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

Я бы выделил следующие ВИ:
1. Открыть проход
2. Ведение свайп-карт (CRUD)
3. Ведение считывателей (CRUD)
4. Рассылка отчёта

Сейчас попробую накидать диаграмму

Возникли следующие комментарии:
1. См. список ВИ выше.
2. Не нужно выделять два разных ВИ с разными именами ("create swipe card")
3. Не нужно выделять Student Service Center и HR. На самом деле это одна и та же роль типа "Администратор". Если правами доступа будет управлять кто-то другой типа начальника охраны, то нужна отдельная роль.
4. Первичных экторов принято указывать слева от ВИ, а вторичны справа.
5. Неверное использование "extend" ("формирование отчёта" не расширяет функционал "получить доступ") и "include" (Нельзя использовать функциональную декомпозицию).
6. CardReader и DataBase это не экторы, а часть системы. Их нужно удалить.
7. Нового и старого сотрудника/ученика выделять не нужно. Они будут отличаться только наличием свайп-карты, а роль одна и та же.
8. Зачем разделять сотрудников и учеников? Они будут как-то по разному взаимодействовать с системой?
9. Сотрудники/ученики не будут взаимодействовать с системой при получении/замене свайп-карты. Они будут взаимодействовать только с администратором.

122

Примеры / Re: СКУД в школе

« : 07 Ноября 2013, 19:55:57 »

Виктор, вы не ответили на мой вопрос, жаль.

По приведённой ссылке — не фаза ЖЦ проекта и не процесс проекта, а деятельность — понятие меньшего масштаба, чем первые 2.

Вне зависимости от RUP/неRUP анализ встречается в следующих работах:

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

Таким образом, анализ — крайне неудачный термин для обозначения фазы или сквозного процесса без уточнения объекта и цели анализа, т.к. аналитическую деятельность выполняют разные проектные роли с разной целью и над разными объектами. Даже сам аналитик делает как минимум 2 разных вида анализа — входной информации и своих артефактов. «Системный анализ» — тоже ещё тот термин — какую систему анализировать, если никакой системы ещё нет?

Но вы конечно можете продолжать спорить о том, сколько чертей уместится на острие иглы, то бишь что и как называется в RUPe. Если кому-то это позволит сдать зачёт, потому что он ответит именно то, что от него ожидает препод — ну и слава богу.

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

123

Примеры / Re: СКУД в школе

« : 06 Ноября 2013, 07:44:59 »

хм, что то типо
При поступлении получить свайп карту в своем центре выдачи
Получить доступ к помещению? что то не очень понимаю как из такого текста последовательность сделать. Еще более менее понятно с use cases specifications, там уже сами действия описываешь. Но тут другая ситуация

DEEPshadow, я считаю было бы правильно если бы вы временно забыли о существовании диаграмм и последовали совету коллег. Сценарий использования описывается в виде последовательности шагов. Сценарий описывает получение эктором какого-то одного полезного результата (услуги). Каждый шаг описывает либо воздействие эктора на систему, либо реакцию системы на это воздействие. Такая последовательность шагов описывается в документе, который называется use-case specification. В принципе не важно как документ будет называться. Можете назвать его по своему вкусу если название будет соответствовать содержимому документа.

124

ПО Аналитика / Re: Оптимальный инструмент для описания безнес-процессов и разработки требований

« : 24 Октября 2013, 10:41:35 »

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

Требования это не только UML, но и текст. Его можно писать как в инструменте типа Enterprise Architect, так и в ворде или в каком-нибудь вики-подобном средстве. Еще выбор инструмента, как и методологии, зависит от масштабов проекта.

125

ПО Аналитика / Re: Оптимальный инструмент для описания безнес-процессов и разработки требований

« : 24 Октября 2013, 10:32:53 »

Коллеги, звучит банально, но SPARX Enterprise Architect тоже ничего, только платный немного... Там есть нотация BPMN, поддерживает также TOGAF, если описываете, к примеру, бизнес-архитектуру.
Т.к. у Вас принято моделирование в UML, думаю, можно выделить средства на сей замечательный tool. Хотя можно ограничиться и Visio, ИМХО.

Рисовать можно хоть на бумажке. Если один раз нарисовать, обсудить и выкинуть, то это самый эффективный способ. Если диаграммы нужно хранить и пересылать в электронном виде, то можно использовать какой-нибудь starUML или что-то подобное. Если же нужна удобная совместная работа, трассировки, кодогенерация и прочее, тогда уже можно заплатить за Enterprise Architect. Главное понимать как потом эти рисунки использовать.

126

ПО Аналитика / Re: Помогите с выбором инструмента для описания БП

« : 26 Августа 2013, 20:47:34 »

РроjjДа, но это же я могу сделать и в ЕА и делать выборки в бд для анализа.
Но ЕА немного тяжеловат и поэтому я спрашиваю что ещё есть.

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