Анализ и моделирование требований

 

Модели, созданные на этапе определения требований необходимы для того, чтобы:

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

- модели служат тем исходным материалом, на котором базируется дальнейшее проектирование приложения.

При этом диаграммы выступают как важный иллюстративный материал к требованиям.

В данном случае опять целесообразно использовать BPWin и методологию IDEF0 (Приложение 8). Так, будем использовать ее и при декомпозиции процесса подбора персонала для конкретной заявки. (Приложение 9). Для некоторых процессов необходимо использовать диаграммы IDEF3, чтобы отразить альтернативные сценарии развития. Например, при декомпозиции процесса проведения собеседования (Приложение 10)

Спецификация и аттестация требований

 

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

Существует ряд методов аттестации требований, которые можно использовать совместно или каждый и отдельности.

1. Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать CASE - средства для проверки непротиворечивости моделей.

2.  Обзор требований. Требования системно анализируется рецензентами.

3. Генерация тестовых сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить проблемы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть.

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

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

Бизнес-моделирование и анализ требований к системе играет важную роль при создании программного обеспечения. Это объясняется тем, что без проведения бизнес-моделирования и анализа требований к информационной системе нет смысла создавать программное обеспечение, так как это может привести к тому, что заказчику будет представлено то программное обеспечение, которое он фактически не заказывал. Поэтому это необходимо учитывать и при разработке программного обеспечения необходимо подходить с особым вниманием и осторожностью, чтобы удовлетворить все требования заказчика.

Результатом данной стадии проектирования должно явится создания технического задания для КА «Фактор». (Приложение 11)

Выбор методологии проектирования информационной системы

 

В настоящее время в области разработки и реализации информационных систем существует несколько методологий проектирования:

- методология функционального моделирования работ SADT;

- методология объектно-ориентированного анализа и проектирования на языке UML;

Для проектирования информационной системы была выбрана методология функционального моделирования работ SADT.

Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

ЗАКЛЮЧЕНИЕ

 

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

СПИСОК ЛИТЕРАТУРЫ

 

1. А.М. Вендров CASE-технологии. Современные методы и средства проектирования информационных систем [Электронный документ]

2. Бизнес. Карьера. Успех. Настольная книга руководителя. Ростов-на-Дону, «Альтаир», 2006, с. 32

ПРИЛОЖЕНИЕ 1

 

ПРИЛОЖЕНИЕ 2

 

ПРИЛОЖЕНИЕ 3

 

ПРИЛОЖЕНИЕ 4

 

ПРИЛОЖЕНИЕ 5

 

ПРИЛОЖЕНИЕ 6

 

ПРИЛОЖЕНИЕ 7