Файл: «Проектирование бизнес-процесса «Обеспечение послепродажного обслуживания ПО».pdf

1. цели системы;
2. смежные системы;
3. пользователи системы;
4. границы системы;
5. связи системы со смежными системами;
6. типовые функциональные требования;
7. схема функциональной структуры;
8. связи между подсистемами;
9. описание автоматизируемых функций;
10. нефункциональные требования;
11. печатные документы;

Инструментарием для создания моделей требования в данной курсовой работе является Case средство Enterprise Architect (ЕА).

EA является одним из немногих UML инструментов, который интегрирует этап управления требованиями с другими этапами разработки программного обеспечения, создавая требования непосредственно в модели. Вот некоторые отличительные черты ЕА:

• Возможность создавать и просматривать требования непосредственно в модели
• Возможность детализировать диаграммы Use CASE непосредственно в модели
• Возможность вводить атрибуты для каждого требования , такие как сложность, тип, статус , а также добавлять свои собственные атрибуты
• Возможность трассировать требования с бизнес-правилами и тестами
• Возможность строить матрицу отношений, позволяющую быстро просмотреть влияние изменений в требованиях
• Возможность создавать в WORD- и HTM- документацию.

Для разработки выше перечисленных моделей в браузере ЕА необходимо создать четыре простые области просмотра (simple view) (рис.9):

• цели системы;
• границы системы;
• функциональные требования к системе;
• нефункциональные требования к системе;

Рис. 9. Области просмотра модели в браузере EA

Для разработки модели «Цели системы» используется диаграмма классов (class diagram).

Рис. 10. Модель «Цели системы»

Модель «Цели системы»» используется для отображения бизнес- требований, то есть требований, формулируемых заказчиком разработки системы.

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

Для разработки модели «Пользователи системы» должна использоваться диаграмма функций (use case diagram).

Модель пользователей системы представлена на рис11.

Рис.11. Пользователи системы

Целью разработки модели «Границы системы» является отображение системы и взаимодействующих с ней смежных систем.

Для разработки модели «Границы системы» должна использоваться настраиваемая диаграмма (custom diagram).

Рис. 12. Модель «Границы системы»

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

Целью разработки модели «Типовые функциональные требования системы» является многократное их применения в процессе разработки, внедрения и функционирования системы с целью уменьшения трудоемкости разработки, сроков и затрат на создание системы, ее частей, упрощения процедуры использования системы пользователями.

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

На рис. 13 представлен состав типовых функциональных требований.

Рис.13. Состав типовых функций

На рис.14. показаны используемые печатные формы

Рис.14. Печатные документы

На рис. 15 изображены требования к системе в целом.

Рис.15. Состав требований к системе в целом

Целью разработки модели «Схема функциональной структуры» является отображение функциональных требований к системе.

Для разработки модели «Схема функциональной структуры» используется настраиваемая пользователем диаграмма (custom diagram).

При использовании пакета для изображения подсистемы используется стереотип <<subsystem>>, для изображения модуля – стереотип <<module>> или <<component>>.

Подсистемы системы представлены на рис. 16.

Рис.16. Изображения подсистем

Функциональные требования к подсистеме представлены на рис. 17, 18, 19.

Рис. 17. Изображения требований выдачи заказов

Рис. 18. Изображения требований приема заявок

Рис. 19. Изображения требований формирования отчета

Для разработки модели автоматизируемой функции используется диаграмма деятельности (activity diagram).

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

При разработке описания функции работы пользователя с системой поле диаграммы деятельности разбивается на области ответственности с использованием следующих разделительных линий (SwimLines – в контекстном меню):

• пользователь;
• система;
• экранная форма.

Описание функции представлено на рис. 20 и 21.

Рис.20. Описание автоматизируемых функций

Рис.21. Описание функций с использованием диаграммы деятельности

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

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

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

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

2.3.2. Характеристика базы данных

Систем использует одну базу данных, состоящую из 6 таблиц: Client, Config, Data, Event, Job, Object.

Структурная схема базы данных «Послепродажное обслуживание ПО» представлен на рис. 22.

Рис. 22. Структурная схема БД

User – в данной таблице содержится информация о пользователях, настройках подключения и авторизации в системе, к каждому пользователю создается отдельная строка в таблице с полями: user- (уникальное имя выданное организацией разработчиком и сопроводителем системы), name- ФИО пользователя, tel – телефон пользователя, address –его адрес, далее идет ссылка на object.

Object – ключевое поле таблицы, ключ для каждого из объектов, привязан к ключу в таблице OBJECT, в которое хранится описание объектов (такие как: имя, идентификационный номер заказчика, тип работы и др.).

Рис. 23. Визуализация таблицы.

Event – таблица событий от объектов, выполняет второстепенную роль, служит для хранения информации о событии, т.е. о том, что событие имело место быть и от куда оно получено. Она содержит:

- тип события;

Status – какие события произошли в данном сообщении;

Object- ссылка на структуру объект;

JOB -cсылкa на таблицу.

JOB – системная таблица хранения процедур, использующихся в системе, в настоящее время в таблице храниться только одна процедура – Периодический опрос объектов.

OBJECT – в этой таблице хранится информация о всех объектах, такая как Наименование объекта, телефон, и другие настройки, привязанные к объекту.

Data – основная таблица системы, используется для хранения всех данных, полученных от объектов с GPS – радиостанций, по мере работы база данных увеличивается в размерах, что увеличивает время поиска а так же время ответа БД на запросы. По этой причине производится обрезание базы данных. При увеличении базы данных более чем на 2 Гб, администраторами сервера производится обрезание данных, оставляя в таблице данные за три последних месяца. Остальные данные помещаются в архив. Таблица Data состоит из следующих полей:

GMT – время и дата подачи заявки;

Status – какие события произошли в данном сообщении;

Path – процент выполненной работы;

Moto – предположительное время работы;

Parv – дополнительные параметры, например содержат конфигурацию пользователей и др. параметры

ivent – таблица событий от объектов, выполняет второстепенную роль, служит для хранения информации о событии, т.е. о том, что событие имело место быть и от куда оно получено.

Заключение

Важнейшей задачей для руководства компании в последние годы является повышение её инвестиционной привлекательности. Инвестиционная привлекательность зависит от уровня издержек, оборачиваемости капитала. Поэтому оптимизация потоковых процессов «Обеспечение послепродажного обслуживания» в системе предприятия, в том числе оптимизация закупочной деятельности является объективной необходимостью.

В данной курсовой работе были рассмотрены бизнес-процессы обеспечения послепродажного обслуживания на предприятии, построена модель «AS-IS» в стандарте IDEF0 для объекта «Обеспечение послепродажного обслуживания» для определенного горизонта времени, а также была проанализирована разработанную функциональную модель AS–IS с точки зрения возможности автоматизации функций и разработать требования к будущей автоматизированной системе в виде модели требований в среде Enterprise Architect.

Список использованной литературы

• • • 1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. И доп. – М.: Финансы и Статистика, 2006. – 544 с.
      2. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. – 2-е изд., доп. – М.: Издательство Диалог-МИФИ, 2007 – 400 с.
      3. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с.
      4.  Буч Г. и др. Язык UML. Руководство пользователя/Г. Буч, Дж. Рамбо, А. Джекобсон: Пер. с англ. – М.: ДМК, 2000.
      5.  Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика.
      6. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. Пособие. – М.: Финансы и статистика, 2006.
      7. Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. — М.: Издательский центр «Академия», 2004. — 288 с.
      8. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с.