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

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

Довольно интересная точка зрения.
Тут все зависит от того что считать "анализом".
Ведь на входе у аналитика ни требования, ни ВИ и не диаграммы деятельности.

Это не точка зрения. Это использование терминологии, связанной с некоторыми технологиями.
Аналитик не является участником анализа ни в RUP, ни в Open UP. Аналитик занимается работой с требованиями.
То, что Вы называете анализом в рамках указанных технологий называют работой с требованиями. Анализом там является моделирование эскизной архитектуры. Только и всего.

Насчет книги. Она не случайно называется системный анализ и проектирование с припиской с помощью UML. Т.е. тут описаны процессы системной инженерии, а UML лишь приложение. Может потому у Вас возник определенный диссонанс?

Эдуард, выше в ответе davvol я указал, анализ RUP -- это не анализ требований, а архитектурный анализ и эскизная реализация ВИ.
Если вернуться к книге, то, как я теперь вижу, анализом, а точнее аналитическим моделированием там назван не процесс, а фаза жизненного цикла.

Постарайтесь обойтись вообще без ромбов. Они загромождают диаграмму, все необходимое можно отразить на дугах.

Если позволите... С точки зрения практики, это разумный, дельный совет.
С формальной точки зрения можно указать пример, когда два фрагмента будут неэквивалентны.
Фрагмент1:

Фрагмент2:

В случае не исключающих друг друга сторожевых условий guard1 и guard2 в 1-м фрагменте можем получить два параллельных потока, если условия истинны одновременно. Во втором фрагменте в тех же условиях будет единственный поток -- либо верхний, либо нижний, выбранный случайным образом.
Первому фрагменту полностью эквивалентен 3-й:

Эдуард, выше в ответе davvol я указал, анализ RUP -- это не анализ требований, а архитектурный анализ и эскизная реализация ВИ.

Что же является предметом анализа в «архитектурном анализе»?

Что же является предметом анализа в «архитектурном анализе»?

RUP есть в онлайне: http://students.mimuw.edu.pl/~zbyszek/posi/ibm/RUP_Eval/process/activity/ac_arcan.htm

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

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

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

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

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

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

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

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

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

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

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

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

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

Денис, по моему спор о том что такое "анализ" бессмысленный.

Разговор был не об анализе как таковом, а о названии этапов/процессов/работ. Я утверждаю, что деятельность без заданных входов (объект анализа) и результатов (результат анализа) не является определённой и как раз слово «анализ» в отвязке от них — малополезно.

Один из плюсов методологии типа RUP, использование общей терминологии.

Популярное явление — не значит эффективное. Чего стоит терминология в которой «аналитик не занимается анализом»?

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

Стандарт на ЖЦ ПО 12207, CMMI и стандарт инженерии требований 29148-2011 разделяют процессы:
1. Определения (разработки) требований ЗЛ
2. Анализа требований ЗЛ
3. Архитектурного проектирования

Что, как мне кажется, немногим лучше RUP'а. Также меня вполне устраивает терминология ГОСТ 19/34.

Я все таки решил оставить мою диаграмму, вск таки она более подходит для меня.
Сейчас я перешел ко 2 заданию, use case diagram. И под пунктом этого задания определить main use cases
Как я понял в моем случае это:
1. Получение карты студенту/сотруднику
2. Использование карты для доступа
3. Запись и отправка отчета для анализа

Ниже я привел actors для этой диаграммы. Как вы считаете, я что то упустил?

Ниже я привел actors для этой диаграммы. Как вы считаете, я что то упустил?

А какой смысл в actors без вариантов использования?

А те предложения, которые вы записали возможных main use cases, почему вы считаете, что это ВИ? Что вы понимаете под ВИ?

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

Не, не думаю, что жаль. Найти ответ Вам не составит труда.

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

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

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

Это как-то связано с моими пояснениями? Я запрещаю кому-либо использовать слово "анализ" в определённых словосочетаниях или смыслах? Вопросы риторические.

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

Любая технология определяет процесс или деятельность не только давая ему/ей название. Что фазу так называть не стоит, согласен.

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

Интересная мысль. Правильно ли я понимаю, что Вы полагаете архитектурный анализ в RUP беспредметным, на основании этого умозаключения?

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

Я лишь дал пояснение. Вас не затруднит указать, где и с чем я спорю? Как мне кажется, спор пытаетесь раздуть Вы, оспаривая терминологию установившуюся в рамках определённой технологии сравнительно давно.

Я утверждаю, что деятельность без заданных входов (объект анализа) и результатов (результат анализа) не является определённой и как раз слово «анализ» в отвязке от них — малополезно.

Входы и выходы в архитектурном анализе, о котором Вы спрашивали меня, в технологии определены.

«аналитик не занимается анализом»

Подмётные цитаты в ход пошли.

Подмётные цитаты в ход пошли.

…Аналитик не является участником анализа ни в RUP, ни в Open UP …

Может ли аналитик заниматься анализом, не являясь его участником? Думаю, ответ понятен.

Ок, с человеком, который не отвечает на заданные вопросы и врёт мне общаться не интересно.