Заменить Посмотреть Заявку на Управлять Заявкой и будет все ок.

Было:


Стало:

комМерческого...

И тут возникает вопрос — нафига это всё было нужно, если можно было написать:

Клиент:

• Ознакомиться с каталогом
• Заказать и получить товар
• Узнать статус заявки

?

А написать это всё можно было, проговорив 1 раз с Заказчиком весь сценарий работы Клиента?

Я понимаю, что все это было можно так написать и сделать. Понимаете, что в этом я практически полный ноль и поэтому наверное так все и получилось. Рад любым комментариям и учту это все на будущее. Как никак это учебный все-таки проект.

И тут возникает вопрос — нафига это всё было нужно, если можно было написать:

Согласно широкомасштабным исследованиям Тони Бьюзена, 95% респодентов разных национальностей, рас и принадлежностей к странам используют в своей работе:
сплошной текст
список
сложный иерархический список

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

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

Конечно это не означает, что использовать список не следует, но и говорить, что список лучше и проще, чем например таже диаграмма, не совсем очевидно

Я разделяю мысль Дениса, что ДВИ вряд ли дает что-то, особенно на начальных стадиях, естественнее использовать просто список. А лучше интеллект-карты. Результатом использования интеллект-карты может быть и ДВИ как, скажем, ее подмножество.

Т.е. чем картинка лучше просто текста:
1. картинка дает образ - гештальт, а человек все-таки мыслит образами.
2. картинка дает общий взгляд
3. картинка задействует творческую половину мозга
4. в картинке проще увидет нелогичность или проблемы
5. картинка интереснее чем текст, а значит интерес будет пробуждать и внимание. правда подобного эффекта можно добиться также цветом в тексте...

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

Диаграммы, которые здесь могут быть полезны:
* Контекстная диаграмма бизнеса
* Диаграмма бизнес-процессов VAD
* Концептуальная диаграмма предметной области (без атрибутов)
* Диаграмма содержания деятельности eEPC
* Контекстная диаграмма системы

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

1. C Galogen полностью согласен - нас даже по курсу Проектирование Информационных систем - все стадии проектировании (обследование, построение диаграмм UML, написание ТЗ, ИО, ПЗ и так далее) просят изобразить в виде ТСП (Технологическая сеть проектирования), которая сама по себе конечно не является каким-то рисунком, но очень четко позволяет понять что делать, как делать, какие для этого нужны данные, и что мы получаем на выходе.
2. На счет ДВИ, которая у меня получилась в конце - может конечно это нецелесообразно было, но в бакалврской работе у меня есть четкая структура, по которой и требуется изобразить диаграммы и тут уж никуда не деться.
3. Хотелось бы еще задать вопрос. В проектировании своей системы по ВКРБ я использую технологию моделирования RUP - можете посоветовать какие-нить книжки, которые, как Вам кажутся наиболее точно описывают и помогут разобратсья и провести проектирование. Да и времени остается мало на изучение огромных томов Буду рад любым высказываниям и предложениям. Заранее спасибо.

В проектировании своей системы по ВКРБ я использую технологию моделирования RUP - можете посоветовать какие-нить книжки, которые, как Вам кажутся наиболее точно описывают и помогут разобратсья и провести проектирование. Да и времени остается мало на изучение огромных томов

RUP — это не технология моделирования. Это методология организации процесса разработки ПО.

По дисциплине технического (не интерфейсного) проектирования хороша книга Крэга Лармана — «Применение UML2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку».

Только напоминаю, что проектирование должно производиться на основе требований. У вас их пока нет.

Требования на систему автоматизации бизнеса создаются на основе изучения бизнес-процессов — у вас их тоже пока нет.

Присоединясь к Денису, могу порекомендовать книгу  Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование.

Хотя эта книга не по RUP процессу, но между UP и RUP много общего. К тому же книга написана так, что как раз занятому может помочь быстро понять.

Кроме того, воспользуйтесь ресурсом Wikipedia. Там есть краткое описание RUP-процесса и методологии

Следует принимать так же тот факт, что будучи фреймвёрком разработки ПО, RUP достаточно адаптивен. Т.е. нужно и можно использовать только то, что Вам действительно требуется.

Если в качестве подхода, Вы избрали разработку по вариантам использования, то здесь можно придерживаться такой концепции (кстати еще вспомнил посмотрите учебник Вендрова. Проектирование ПО для ЭИС):

1.Бизнес-моделирование. Поскольку у Вас несложная в целом система, то его можно свести к созданию Domain Model. Для учебных целей, конечно, можно было бы описать ряд бизнес-процессов. Я, например, со своими бакалаврами делаю примерно так:
   глава анализ предметной области - в начале некое самое общее описание объекта автоматизации: организационная структура, выделение основных действующих лиц, описание их задач, описание алгоритмов их задач в виде диаграмм деятельностей. Вполне подойдут и другие нотации. Здесь же описывает модель бизнес-объектов в стиле RUP: человечки, классы сущностей, бизнес-уокеры. Минимум атрибутов, упор на структурные связи и общий контекст

2.далее формулируются требования в виде вариантов использования + дополнительная спецификация - причем тут полная свобода - главное использования принятых стандартов. Не хочешь ВИ, пиши ГОСТ...

3. Далее анализ ВИ, построение аналитических моделей. Т.е. реализация ВИ в виде: аналитической модели классов (начиная с VOPC - т.е. обзор только классов -непосредственных участников с разделением по RUP на граничные(интерфейсные), сущностные(по сути бизнес-объекты или производные от них) и управляющие - хотя бы один на один вариант использования), диаграмм последовательностей. Ясно что всего этого в работе не покажешь, потому просто избирается какой-то наиболее важный ВИ и по нему расписывается, ну и приводится окончательный результат

4. Далее уже принимается решение об архитектуре, классы группируются в пакеты, уточняются, добавляются классы в соответствии с принципами GRASP

5. Реализация включает описание БД и всего с нею связанного (это классы-сущности в основном), а функционирование системы прорабатывается с использованием проектных и программных классов, с привязкой к билиотекам классов и компонентов

Естественно реализовать все это в рамках бакалаврского проекта сложно и нецелесообразно. Потому важно показать наиболее важные артефакты

Всем большое спасибо за ссылки и за рекомендации. Можно я буду по ходу выполнения работы задавать вопросы?

Всем большое спасибо за ссылки и за рекомендации. Можно я буду по ходу выполнения работы задавать вопросы?

А кто же вам не позволит

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

А первый этап: бизнес-моделирование мы используем для того, чтобы построить модели, отображающие суть дел "как есть" на предприятии? У меня просто проблема - что есть реальное предприятие, реальный отдел "коммерческий отдел", но у меня как таковых нет материалов не по орг. структуре предприятии, не должностных инструкций сотрудников отдела. Как в этом случае поступают? Строят модель так как кажется нужным самому?

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

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

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