Формирование требований на основе структурных проблем предприятия

 

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

На диаграмме  вариантов использования разрабатываемого проекта отображаются все возможные  варианты использования и актеры. Диаграмма вариантов использования  представлена на рисунке 3.

 

Рисунок 3 - Диаграмма вариантов использования

 

Анализ вариантов использования

1. Оформление заказа на покупку товара.

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

Основной  поток:

Данный  вариант использования начинает выполняться, когда клиент совершает заказ

1. Покупатель оформляет заказ.
2. Менеджер принимает заказ.
3. Продавец заключает с покупателем договор об оплате.
4. Соответствующая запись заносится в базу заказов.

Предусловия:

Клиент  должен войти в систему.

Постусловия:

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

2) Технологическая  проработка заказа.

Данный  вариант использования описывает  процесс технологической проработки заказа в технологическом отделе.

Основной  поток:

Данный  вариант начинает выполняться, когда  информация о заказе поступила к  дизайнеру-технологу.

1. Дизайнер прорабатывает заказ.
2. Составляет список необходимых материалов, который отправляется на склад.

Альтернативный  поток:

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

Предусловия:

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

Постусловия:

Если  вариант использования успешно выполнен, то заказ направляется в мастерскую для выполнения.

3. Доставка материала со склада

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

Основной  поток:

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

1. Составляется запрос на доставку необходимых материалов.
2. Со склада доставляются требующиеся материалы.

Альтернативный  поток:

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

Предусловия:

Модель  заказа должна быть проработана дизайнером-технологом.

Постусловия:

Если  вариант использования выполнен успешно, то в мастерской приступают к непосредственному выполнению заказа.

4. Выполнение заказа.

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

Основной  поток:

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

1. Мастер выполняет заказ.
2. Составляется отчет о проделанной работе и израсходованных материалах.

Альтернативный  поток:

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

Предусловия:

Запрашиваемые материалы должны быть доставлены со склада.

Постусловия:

Если  вариант использования выполнен успешно, то готовый заказ передается отделу доставки.

5. Доставка заказа.

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

Основной  поток:

Данный  вариант начинает выполняться, когда  завершено выполнение заказа в мастерской.

1. Водитель передает товар покупателю.
2. Клиент выплачивает деньги по счету.
3. Составляется окончательный отчет о проделанной работе.

Альтернативный  поток:

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

Предусловия:

Изготовление  заказа должно быть полностью завершено.

Постусловия:

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

 

Проектирование  системы

 

В данной работе рассматриваются следующие  классы:

1. Магазин.
2. База заказов.
3. Контроллер.
4. Склад.
5. Мастерская.
6. Отдел доставки.
7. Дизайнер.

 

1) Магазин.

Данный класс взаимодействует  с классом «Контроллер».

Класс имеет следующие атрибуты:

– ФИО заказчика.

– Адрес заказчика.

– Выбранная комплектация.

Класс выполняет следующие операции:

– Ввести данные о заказе.

– Считать информацию.

– Оформить документы на получение заказа.

2) База заказов.

Данный класс взаимодействует  с классом «Контроллер».

Класс имеет собственные атрибуты:

– ФИО заказчика.

– Адрес заказчика.

– Выбранная комплектация.

– Дата заключения договора.

– Квантор готовности.

Класс выполняет следующие операции:

– Создать запись.

– Изменить квантор готовности.

– Удалить запись.

3) Контроллер.

Это управляющий класс, который  контролирует деятельность всей системы.

4) Дизайнер.

Данный класс взаимодействует  с классом «Контроллер».

Класс имеет собственные атрибуты:

– Информация о наличии материала.

Класс выполняет следующие операции:

– Проработка модели.

5) Склад.

Данный класс взаимодействует  с классом «Контроллер».

Класс имеет собственные атрибуты:

– Инвентарные номера материалов.

– Список материалов.

Класс выполняет следующие операции:

– Подать запрос на материалы.

6) Мастерская.

Данный класс взаимодействует  с классом «Контроллер».

Класс имеет собственные атрибуты:

– Оборудование.

– Список операций.

Класс выполняет следующие операции:

– Получить информацию о заказе.

– Уведомить о готовности.

7) Отдел доставки.

Данный класс взаимодействует  с классом «Контроллер».

Класс имеет собственные атрибуты:

– Список доставки с реквизитами.

– Транспорт.

Класс выполняет следующие операции:

– Получить документы на заказ.

5.7     Диаграмма классов

 

Диаграмма классов ИС предприятия показа на рисунке 4.

Рисунок 4 - Диаграмма классов

5.8     Диаграмма взаимодействия

 

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

 

Рисунок 5 Диаграмма взаимодействия

 

5.9    Диаграмма деятельности

 

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

На рисунке 6 представлена диаграмма деятельности мебельного цеха.

 

Рисунок 6 – Диаграмма деятельности

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ

 

Анализ  и сбор требований  - работа аналитика  системы которая занимается анализом и составлением требований. Аналитик должен:

• Уметь анализировать проблему;
• Понимать потребности закащика и пользователя;
• Определять функции системы и требования к ним;
• Управлять контекстом проекта и изменениями требований.

Сбор  требований -  под процесс в  формировании требований. Источником о требованиях могут быть:

• Цели и задачи системы которые формулирует закащик,  для однозначного их понимания, разработчику необходимо осмыслить и согласовать с закащиком  цели и задачи системы;
• Действующая система или коллектив, выполняющий её функции.

 

Требования формируются исходя из:

• Знаний закащика относительно предметной области;
• Ведомостных стандартов и требований к среде функционирования будущей системы её исполнительных возможностей.

Методы  сбора ПО

Методами  сбора требований являются:

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

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

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

Задачей проектирований является преобразование требований к системе, проектных  решений, требования к ПО и построение архитектуры системы. Проектирование архитектурной системы проводится разными способами основанные на известных подходах (структурированный, объектно- ориентированный, компонентный и другие). Каждый подход предлагает свой путь решения, включая соответствующие  им конструктивные элементы и методы задания структуры модели системы.

 

 

 

 

 

 

 

 

ЗАКЛЮЧЕНИЕ

 

 

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

Так же была разработана модель ИС мебельного цеха. Были созданы основные диаграммы  в пакете Rational Rose.

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