Выполнение примера описания требований для ИС "Аттестации Студентов"(Прочитано 191130 раз)
Я так понимаю, что Вы не так понимаете :о)) Или у нас сильно разное представление о справочниках. Я, например, могу предположить, что в справочниках ведется перечень кафедр, список преподавателей, групп, предметов и т.п.
Как я уже сказал, без них было бы сложно представить полноценную систему. Но, поверьте, при повышении актуальности, достоверности и своевременности данных об успеваемости студентов они играют не самую основную роль. Здесь важнее так называемые транзакционные данные, т.е. данные о полученных студентами отметках, выполненных заданиях и контрольных мероприятиях и т.п.
Аналогично по другим целям.

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

Хотя это был лишь совет, безусловно, можете делать по своему...

Лью воду...



Водолей, согласна с Вами  :)

Но как бы мы ни выясняли, задание менеджера было пока описать ВИ Управлять справочниками.

1.   Наименование ВИ: Управлять справочниками
2.   Цель ВИ: Создать, заполнить и содержать в актуальном состоянии справочники данных, необходимые для проведения аттестации студентов.
3.   Краткое описание ВИ: Сотрудники ВУЗа, имеющие определенные пользовательские права, добавляют, редактируют, удаляют справочники деканатов, кафедр, дисциплин, преподавателей, студентов.
4.   Описание сценариев:
1)   Основной сценарий:
1.1.   Сотрудник ВУЗа, имеющий соответствующие  права, создает справочник.
Вариант А:
1.2-А. Сотрудник ВУЗа заполняет справочник данными.
Вариант Б:
1.2-Б. Сотрудник ВУЗа, создавший справочник передает его для заполнения его данными другим Сотрудникам ВУЗа.
1.3. Сотрудник ВУЗа, имеющий необходимые права, вносит изменения (добавляет или удаляет данные) в справочнике.
1.4. Сотрудник ВУЗа удаляет справочник.
2)   Альтернативный сценарий:
2.1.   Сотрудник ВУЗа открывает справочник.
2.2.   Сотрудник ВУЗа просматривает необходимые ему данные.
2.3.   Сотрудник ВУЗа закрывает справочник.

Вопрос:
1. нужно ли описать в спецификации перечень справочников?
2. должна ли быть действующим лицом сама Система?


Не ошибается тот, кто ничего не делает.



Раз уж я встрял - отвечу от себя.

0. Я бы предложил построить ВИ работы со справочниками по-другому, но это вообще-то дело Вашего менеджера. Так как в приведенном виде этот ВИ, по-моему, бесполезен.
1. В любом случае (вне зависимости от формы описания ВИ) в спецификации должен быть перечень справочников. т.е. ответ "ДА"
2. Тоже "ДА". Она [система] ведь тоже что-то делает (правда, это еще придется запрограммировать, но тем не менее ее действия должны быть понятны пользователю.

Вопросы по ходу:
1. А справочники Вы будет создавать с помощью системы? И как часто нужна будет эта функциональность, например, для справочника предметов?
2. Что значит "заполняет справочник данными"? Какими? Как?
3. Зачем удалять справочник? А что произодет с транзакционными данными прошлого года обучения, при создании которых он использовался?
Любимый вопрос: С чего начинается работа со справочником? Чем заканчивается? (это, кстати, насчет структуры описания ВИ)

Лью воду...



1)   Основной сценарий:
1.1.   Сотрудник ВУЗа, имеющий соответствующие  права, создает справочник.
Вариант А:
1.2-А. Сотрудник ВУЗа заполняет справочник данными.
Вариант Б:
1.2-Б. Сотрудник ВУЗа, создавший справочник передает его для заполнения его данными другим Сотрудникам ВУЗа.
1.3. Сотрудник ВУЗа, имеющий необходимые права, вносит изменения (добавляет или удаляет данные) в справочнике.
1.4. Сотрудник ВУЗа удаляет справочник.
2)   Альтернативный сценарий:
2.1.   Сотрудник ВУЗа открывает справочник.
2.2.   Сотрудник ВУЗа просматривает необходимые ему данные.
2.3.   Сотрудник ВУЗа закрывает справочник.
veta, нужно еще писать действия системы. Т.е пользователь что-то делает, а система на действие всегда отвечает неким откликом. Иначе у вас получается не взаимодействие Пользователь - Система, а монолог по типу "Пользователь кидает камушки в пропасть"
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Я бы предложил такой бы формат:
Цитировать
1. Наименование ВИ
2. Цель ВИ
3. Действующие Лица
4. Предварительные условия
5. Основной сценарий
5.1. ....
5. Альтернативные сценарии
5.1. АС 1
5.1.1. ...
5.2. АС 2
5.2.1. ....
6. Исключения
6.1. И1
6.1.1. ...
6.2. И1
6.2.1. ...
7. Пост условия
Подразумеваем, что уровень ВИ по Коберну - это уровень целей пользователей.

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

Остальное вроде сказали.

Водолей,
Предлагаю описывать ВИ в последовательности написанной Эдом, потом протрассируем ВИ к Целям и поймем в чем мы были неправы. Это же учебный проект, хотя ваша последовательность действий более правильная в боевом применении.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



не вопрос.

Но о сказанном про удаление все-таки подумайте. Я до сих пор в ярких красках помню реакцию одного заказчика при упоминании термина "удаление данных" :о))
Лью воду...



Всем комментирующим спасибо!
Замечания учла, буду работать. Постараюсь к завтрашнему полудню выложить более содержательную версию.
Не ошибается тот, кто ничего не делает.



Раз мы описываем сценарий для ВИ Управлять элементами справочника, значит должен быть где-то ВИ Создать справочник, правильно? Нужно ли его ставить в предусловие для этого ВИ?

Удаление решила все-таки оставить, нужная операция, не весь же мусор хранить в справочниках. В идеальной системе его, конечно, нет, но на практике чего только не насоздают  :)


Сценарий ВИ для добавления элемента справочника.
Не ошибается тот, кто ничего не делает.



Veta,

Мои замечания:

1. Разве так назывался ВИ на ДВИ?

2. Не понятно назначение предусловия по наличию справочников. У нас же есть ДБО, там все сказано - какие сущности должна содержать система
Кстати, можно уже Добавлять атрибуты в сущности на ДБО

3. "1.4.2.   Система открывает окно Справочника, отображает его элементы."
Я бы сказал так: 1.4.2.   Система открывает окно Справочника, отображает список элементов Справочника.

4. Какие поля в Справочнике Пользователь заполняет? Должна быть ссылка на БО или описание формы

5. 1.4.8. - где описана проверка? нужна ссылка на БПравило

6. 1.4.11 - 1.4.113 - должно быть вынесено в отдельный поток исключения

7. "1.5.1.3.   Сотрудник ВУЗа выбирает функциональность «Редактировать элемент в Справочник»."
1.5.1.3.   Сотрудник ВУЗа выбирает необходимый элемент из списка и выбирает функциональность «Редактировать элемент в Справочник».

8. "1.5.1.4.   Система показывает форму редактирования элемента в соответствии с правами доступа пользователя к Справочнику:"
1.5.1.4.   Система показывает форму редактирования элемента в соответствии с правами доступа пользователя к Справочнику с заполненными значениями в полях выбранного элемента
9. А нужен ли п. 1.5.2., может его совместить с фильтром и сортировкой?

По п. 3-8 см. по всем сценариям.

З.Ы, С понедельника я в отпуске на 2 недели, поэтому пишите спеки по остальным ВИ и выкладывайте, м.б .кто-то будет проверять и выставлять замечения.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Ну что, все всё бросили?
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Ну что, все всё бросили?
Саша, люди в отпуске - на каникулах. А потом, имхо, все так затянулось. Правда можно проверить терпимость и целеустремленность:)

Еще мне думаетс, что-то мы где-то не так делаем. Я тут обчитался Унифицированным процессом от Трех Амиго, и подумал, что мы не совсем корректно ведем бизнес-моделирование, да и начала не особо верное взяли



А что мы не так сделали?
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



А что мы не так сделали?
процессы не выявили и не описали.



процессы не выявили и не описали.
Так мы это сделали в виде интересов ЗЛ
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Так мы это сделали в виде интересов ЗЛ
Может я и ошибаюсь, но предлагаю прочитать часть книги Унифицированный процесс, в которой рассказывается о бизнес-моделировании.
Стр. 144 русскоязычного издания
Несмотря на различие отправных точек, существуют шаги, которые можно сделать в большинстве случаев. Это позволяет нам предложить типовой рабочий процесс.
Такой рабочий процесс включает в себя следующие шаги, которые обычно не выполняются по отдельности
О Перечисление возможных требований.
О Осознание контекста системы.
О Определение функциональных требований.
О Определение нефункциональных требований.
....
Осознание контекста системы. Множество людей, вовлеченных в развитие программного обеспечения, являются  специалистами в вопросах, имеющих отношение к программному обеспечению. Однако чтобы верно определить требования
и правильно сформировать систему, ключевые разработчики — в частности, архитектор и некоторые старшие аналитики — должны понимать контекст, в котором работает система.
Имеется по крайней мере два подхода к описанию контекста системы в форме, доступной для разработчиков программ: моделирование предметной области и бизнес-моделирование. Модель предметной области описывает важные понятия контекста как объекты предметной области. Предметная область при этом связывает эти объекты друг с другом. Идентификация и наименование этих объектов помогают нам разработать словарь терминов, который поможет каждому, кто работает над системой, лучше ее понимать. Впоследствии, когда мы будем проводить анализ и проектирование нашей системы, объекты предметной области помогут нам распознать некоторые классы. Как мы увидим далее, бизнес-модель может быть представлена как надмножество модели предметной области. Она содержит доменные объекты, и не только их.
Цель бизнес-моделирования состоит в описании процессов — существующих или воспринимаемых — для того, чтобы понять их. Бизнес-моделирование — единственная часть бизнес-инжиниринга, которую мы будем использовать в этой книге
[39]. Удовлетворимся замечанием, что бизнес-инжиниринг очень похож на бизнес-моделирование, но имеет своей целью также улучшение бизнес-процессов организации. Когда аналитики моделируют бизнес, они получают обширную информацию
о контексте программной системы и отражают ее в бизнес-модели. Бизнес-модель определяет, какие бизнес-процессы должна поддерживать система. Кроме идентификации вовлеченных в бизнес бизнес-объектов или объектов предметной области, бизнес-моделирование также устанавливает компетентности, необходимые для процессов: работников, их обязанности и действия, которые они должны выполнять.
Это знание является определяющим при идентификации вариантов использования.
Мы вскоре обсудим этот вопрос. Фактически подход бизнес-инжиниринга для определения требований при разработке бизнес-приложений является наиболее системным [39].
Архитектор и руководитель проекта совместно решают, ограничиться ли моделью предметной области или идти до конца и разрабатывать полную бизнес-модель, а может быть, не строить никакой модели вообще.

Понимание контекста системы с помощью бизнес-модели

Бизнес-моделирование — это способ разобраться в бизнес-процессах организации. Но что если вы работаете с системой, которая не имеет никакого отношения к тому, что большинство людей понимает под словом «бизнес»? Например, что мы
должны делать при разработке сердечного электростимулятора, антиблокировочной системы торможения для автомобиля, контроллера фотоаппарата или системы беспроводной связи? В этом случае мы по-прежнему можем создавать бизнес-
модели этих систем, определяющие программную систему, которую мы собираемся разрабатывать. Эта система (часть человеческого органа, часть автомобиля, фотоаппарата, переключатель) — будет «бизнес-системой» для встроенного программного обеспечения. Это будет заметно по высокоуровневым вариантам использования системы, которые мы кратко рассмотрим. Наша цель — выделение вариантов использования программного обеспечения и бизнес-сущностей, которые будут поддерживаться программным обеспечением. Для того чтобы сделать это, мы должны углубиться в моделирование ровно настолько, насколько нужно, чтобы разобраться в контексте. Результатом этой деятельности будет модель предметной области, порожденная нашим пониманием функционирования изученной «бизнес-системы».
Технически бизнес-моделирование поддерживается двумя типами моделей UML: моделью вариантов использования и объектной моделью [57]. Обе они определены в бизнес-расширении UML.

Как разработать бизнес-модель

Бизнес-модель разрабатывается в два приема. Это происходит следующим образом.
1. Разработчики бизнес-модели должны создать бизнес-модель вариантов использования, идентифицирующую актантов, и бизнес-варианты использования, в которых участвуют эти актанты. Эта бизнес-модель вариантов использования позволит разработчикам модели лучше понять, какой результат приносит бизнес его участникам.
2. Разработчики модели должны разработать объектную бизнес-модель, состоящую из сотрудников, бизнес-сущностей и рабочих модулей, которые совместно реализуют бизнес-варианты использования^ С этими объектами связываются бизнес-правила и другие нормы бизнеса. Цель этого шага состоит в том, чтобы создать сотрудников, бизнес-сущности и рабочие модули, которые реализуют бизнес-варианты использования настолько эффективно, насколько это возможно — то есть быстро, точно и недорого.
Бизнес-моделирование и моделирование предметной области похожи друг на друга. Фактически, мы можем считать моделирование предметной области упрощенным вариантом бизнес-моделирования, в котором мы сосредоточиваемся исключительно на «предметах», то есть классах предметной области или бизнес-объектах, с которыми работают сотрудники. Это означает, что классы предметной области и бизнес-объекты — очень близкие понятия, и мы будем использовать попеременно то один из этих терминов, то другой.
Однако между бизнес-моделированием и моделированием предметной области имеются серьезные различия, которые говорят в пользу выполнения более формальной процедуры бизнес-моделирования:
О Классы предметной области возникают из базы знаний, составленной несколькими специалистами по проблемной области, или просто из общих соображений (например, из знания о других классах предметной области, спецификации требований и т. п.), относящихся к похожим на нашу системам. Бизнес-объекты же выделяют путем опроса клиентов бизнеса, вычленения бизнес-вариантов использования и последующего выбора объектов. При подходе, используемом в бизнес-моделировании, включение сущности в бизнес-модель должно оправдываться использованием этой сущности в бизнес-варианте использования.
Эти различные подходы обычно приводят к разным наборам классов, ассоциаций, атрибутов и операций. При моделировании предметной области можно проследить путь от классов назад к опыту специалистов по проблемной области. При бизнес-моделировании можно проследить потребность в каждом элементе модели назад к клиентам.
О Классы предметной области содержат множество атрибутов, но обычно содержат мало операций или не содержат их вовсе. Для бизнес-объектов это не так. Бизнес-моделирование позволяет идентифицировать не только сущности, но и всех сотрудников, которые участвуют в реализации бизнес-варианта использования, используя эти сущности. Кроме того, при бизнес-моделировании мы определяем способы использования сотрудниками этих сущностей посредством операций,
которые должна позволять выполнять каждая сущность. Эти операции также будут получены из требований и могут быть отслежены до клиентов.
О Список сотрудников, обнаруженных при бизнес-моделировании, используется как исходная точка для определения первоначального набора актантов и вариантов использования для информационной системы, которую мы создаем. Это позволяет нам отслеживать каждый вариант использования в информационной системе через сотрудников и бизнес-варианты использования назад, до клиентов.
Мы займемся этим в главе 7. Кроме того, как было описано в главе 3, каждый вариант использования может быть прослежен до составляющих систему элементов. Итак, мы можем заключить, что комбинация бизнес-моделирования и подхода к разработке программного обеспечения, предлагаемого Унифицированным процессом, позволят нам непрерывно отслеживать потребности клиента—в бизнес-процессах, сотрудниках и вариантах использования и коде программы.
При использовании же одной модели предметной области нет никаких очевидных способов отследить требования в промежутке между моделью предметной области и вариантами использования системы.
« Последнее редактирование: 19 Августа 2009, 21:04:55 от Galogen »