Автоматизированная система управления бизнес процессом рекламного агентства

Оглавление 
 
 
 

Введение.

     Для проектирования было выбрано средство Rational Rose. Rational Rose – Case-средства фирмы Rational Software Corporation – предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

     Rational Rose поддерживает визуальное объектно-ориентированное моделирование (UML), поддерживает генерацию кода и обратное проектирование  (построение модели по программному коду) для многих языков программирования, позволяет строить объектную модель разрабатываемой программной системой,  определять спецификации классов, объектов, атрибутов и операции. Так Rational Rose обладает всеми необходимыми характеристиками для проектирования архитектуры системы любого масштаба.

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

     Преимущества  от применения Rational Rose:

    • Сокращение цикла разработки приложения «заказчик – программист - заказчик». Теперь заказчику нет необходимости ждать первой альфа-версии, чтобы убедиться, что все делается совсем не так, как он ожидал;
    • Увеличение продуктивности работы программистов. Меньше ручного кодирования – меньше ошибок, меньше ошибок – меньше отладки, меньше отладки – больше продуктивности;
    • Улучшение потребительских качеств создаваемых программ за счет ориентации на пользователей и бизнес;
    • Способность вести большие проекты и группы проектов;
    • Возможность повторного использования уже созданного ПО за счет упора на разбор их архитектуры и компонентов.

Техническое задание.

Содержание

1. Введение

1.1. Наименование  программы

1.2. Назначение  и задачи проектируемой системы

1.3. Наименования организации-заказчика и организаций-участников работ

1.4. Плановые  сроки начала и окончания работы  по созданию системы

1.5. Перечень  нормативно-технических документов, методических материалов, использованных при разработке ТЗ

2. Требования  к программе 

2.1. Требования  к функциональным характеристикам

2.2. Требования  к надежности

2.2.1. Требования  к обеспечению надежного функционирования  программы

2.2.2. Время восстановления  после отказа

2.2.3 Требования к аппаратной части компьютера

3. Условия эксплуатации

3.1. Климатические  условия эксплуатации

3.2. Требования  к квалификации и численности  персонала

3.3. Требования  к информационной и программной  совместимости

3.3.1. Требования  к информационным структурам и методам решения

3.3.1.1. Структура  баз данных

3.3.1.2. Требования  к запросам пользователей данных  из базы

3.3.2. Требования  к исходным кодам и языкам  программирования

3.3.3. Требования  к защите информации и программ

4. Требования  к программной документации

4.1. Предварительный  состав программной документации

5. Технико-экономические  показатели

5.1. Экономические  преимущества разработки

6. Стадии и  этапы разработки

6.1. Стадии разработки

6.2. Этапы разработки

6.3. Содержание  работ по этапам

7. Порядок контроля  и приемки

7.1. Виды испытаний

7.2. Общие требования  к приемке работы

1. Введение

1.1. Наименование программы

     Полное  наименование системы: автоматизированная система управления бизнес процессом рекламного агентства «Best Konsalting».

     Краткое наименование системы: АСУ «Best Konsalting». 

1.2. Назначение и задачи проектируемой системы

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

    Задачи проектируемой системы:

  • ведение автоматизированного контроля над работами по заказам;
  • выполнение оперативного учета;
  • формирование отчетности;
  • взаимодействие с БД.
 
 

1.3. Наименования организации-заказчика и организаций-участников работ

     Заказчиком  системы является ООО «Персонал Консалт».

     Адрес заказчика: Самара, ул. Антонова Овсеенко, д.46

     Разработчиком системы является Смиричевский И.И.

     Адрес разработчика: Самара, ул. Демократическая, д.20, кв. 168.

     Потенциальный потребитель: рекламные агентства. 

1.4. Плановые сроки  начала и окончания  работы по созданию  системы

     Сроки проведения работ: март 2011 – май 2011 года. 

1.5. Перечень нормативно-технических  документов, методических  материалов, использованных при разработке ТЗ

     При разработке автоматизированной системы  и создании проектно-эксплуатационной документации Исполнитель должен руководствоваться  требованиями следующих нормативных  документов:

     – ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;

     – ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение  документов при создании автоматизированных систем.

2. Требования к программе

 

2.1. Требования к функциональным  характеристикам

     Программа должна обеспечивать возможность выполнения перечисленных ниже функций: 
2.1.1. Разделение пользователей: 
2.1.1.1. Бухгалтер 
2.1.1.2. Директор 
2.1.1.3. Сотрудник  
2.1.2. Возможность поиска по базе данных информации по услугам 
2.1.3. Возможность поиска по базе данных информации по клиентам 
2.1.4. Возможность ведения базы данных о заказах  
 
 

2.2. Требования к надежности

2.2.1. Требования к обеспечению  надежного функционирования  программы

     Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:  
а) организацией бесперебойного питания технических средств;  
б) использованием лицензионного программного обеспечения;  
в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;  
г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

2.2.2. Время восстановления  после отказа

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

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

2.2.3 Требования к аппаратной части компьютера.

    В качестве клиентского  рабочего места можно использовать:

    • компьютер под управлением Windows 2000/XP/Vista.;
    • оперативная память не менее 256 Mб RAM (512 MB рекомендуется);
    • Мышь или другое координатно-указательное устройство.

3. Условия эксплуатации

 

3.1. Климатические условия  эксплуатации

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

3.2. Требования к квалификации  и численности  персонала

     Минимальное количество персонала, требуемого для  работы программы, должно составлять не менее 3 штатных единиц — сотрудник директор и бухгалтер.

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

д) поддержание  работы сайта компании. 

3.3. Требования к информационной  и программной  совместимости

3.3.1. Требования к информационным  структурам и методам  решения

База данных работает под управлением Borland Delphi.  
 
 
 
 
 
 

3.3.1.1. Структура баз  данных

    Логическая  структура базы данных:

    1. Клиенты
    №
 Имя поля
    Тип
    Назначение 
    1
    fir
    string
    Фирма – заказчик
    2
    vzr
    string
    Вид заказанной рекламы
    3
    vrp
    string
    Вид рекламируемой продукции
    4
    d
    string
    Дата  заказа
    5
    so
    string
    Срок  оплаты
    6
    sfo
    string
    Срок  фактической оплаты
    7
    kol
    integer
    Количество 

 
    1. Перечень  услуг
    №
    Имя поля
    Тип
    Назначение 
    1
    vr
    string
    Вид рекламы
    2
    c
    real
    Цена 

 
    1. Курс валют
    №
    Имя поля
    Тип
    Назначение 
    1
    data
    string
    Дата 
    2
    kurs
    real
    Курс  валют 

 
    1.  Сотрудники 
    №
    Имя поля
    Тип
    Назначение 
    1
    Id_sotr
    string
    Идентификатор
    2
    fio
    string
    ФИО
    3
    pasp
    string
    Паспортные  данные

 

    3.3.1.2. Требования к запросам  пользователей данных  из базы

     Администраторы  системы должны иметь возможность редактировать таблицы БД.

     Пользователи  системы должны иметь возможность производить поиск по таблицам БД, просматривать детальную информацию по каждому результату выборки. 

3.3.2. Требования к исходным  кодам и языкам  программирования

     Дополнительные требования не предъявляются. 

3.3.3. Требования к защите  информации и программ

     Требования  к защите информации и программ не предъявляются.

4. Требования к программной  документации

 

4.1. Предварительный  состав программной  документации

     Состав  программной документации должен включать в себя:  
4.1.1. техническое задание; 
4.1.2. программу и методики испытаний; 
4.1.3. руководство оператора;

5. Технико-экономические  показатели

 

5.1. Экономические преимущества  разработки

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

6. Стадии и этапы  разработки

 

6.1. Стадии разработки

     Разработка  должна быть проведена в три стадии:  
1. разработка технического задания;  
2. рабочее проектирование;  
3. внедрение. 

6.2. Этапы разработки

     На  стадии разработки технического задания  должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.  
На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

    1. разработка  программы;  
    2. разработка программной документации;  
    3. испытания программы.

     На  стадии внедрения должен быть выполнен этап разработки подготовка и передача программы. 

6.3. Содержание работ  по этапам

     На  этапе разработки технического задания должны быть выполнены перечисленные ниже работы:  
1. постановка задачи;  
2. определение и уточнение требований к техническим средствам;  
3. определение требований к программе; 
4. определение стадий, этапов и сроков разработки программы и документации на неё;  
5. согласование и утверждение технического задания.

     На  этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.

     На  этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации.  
          На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:  
1. разработка, согласование и утверждение и методики испытаний;  
2. проведение приемо-сдаточных испытаний;  
3. корректировка программы и программной документации по результатам испытаний.

     На  этапе подготовки и передачи программы  должна быть выполнена работа по подготовке и передаче программы и программной  документации в эксплуатацию на объектах Заказчика.

7. Порядок контроля  и приемки

 

7.1. Виды испытаний

     Приемо-сдаточные  испытания должны проводиться на объекте Заказчика в оговоренные  сроки.

     Приемо-сдаточные  испытания программы должны проводиться  согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний.

     Ход проведения приемо-сдаточных испытаний  Заказчик и Исполнитель документируют  в Протоколе проведения испытаний 

7.2. Общие требования  к приемке работы

     На  основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

8. Структура предприятия 

    8.1 Структура предприятия:

      

    

    

      

      

    

    

      

    

    

      
 

Рис. 1 Схема организационной структуры предприятия 

    8.2 Схема документооборота аптечного предприятия:

    

Рис. 2 Схема  документооборота предприятия

Процесс разработки автоматизированной системы в Rational Rose.

Диаграмма вариантов использования.

 

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

 

 

Рис. 3 Use case Diagram

 

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

 

     Этот  тип диаграмм включает в себя диаграммы  последовательностей (Sequence diagram).

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

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

     Стрелки на данной диаграмме соответствуют  сообщениям, передаваемым между действующим  лицом и объектом или между  объектами для выполнения требуемых  функций.

     На  диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

     Каждое  сообщение изображается в виде стрелки  между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на диаграмме (сверху вниз).

 

     

     

Рис. 4 Sequence Diagram – диаграмма последовательности

Обработка заказа

 

      

Рис. 5 Sequence Diagram – диаграмма последовательности

Оплата договора

 

Рис. 6 Sequence Diagram – диаграмма последовательности

Формирование  отчетности 

    Диаграмма состояний

 

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

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

Рис. 7 Activity Diagram – диаграмма деятельности

Формирование  заказа 

Диаграммы сотрудничества (Collaboration diagram)

 

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

      По  причине того, что диаграммы Sequence и Collaboration являются разными взглядами  на одни и те же процессы, Rational Rose позволяет  создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

      

Рис. 8 Collaboration Diagram – диаграмма сотрудничества

Оплата договора 
 

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

 

     Это основная диаграмма для создания кода приложения. При помощи ее создается внутренняя структура системы, описывается наследование и взаимное положение классов друг относительно друга. Здесь описывается логическое представление системы. Именно логическое, так как классы – это лишь заготовки, на основе которых затем будут определены физические объекты.

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

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

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

Рис. 9 Logical view

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

Диаграмма компонентов

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

     На  диаграмме изображены компоненты программного обеспечения и связи между  ними. В среде Rational Rose каждый класс модели преобразуется в компонент исходного кода. Созданные компоненты сразу добавляются к диаграмме компонентов. Затем указываются зависимости между отдельными компонентами, соответствующие зависимостям на этапе компиляции или выполнения программы.

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

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

     

Рис. 10 Component view – диаграмма компонентов

 -компонент, обозначающий программу.

 - заголовочный файл с расширением   *.pas 

Диаграмма размещения

 

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

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

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

Автоматизированная система управления бизнес процессом рекламного агентства 📙 Курсовая → 🆔 2354

Автоматизированная система управления бизнес процессом рекламного агентства 📙 Курсовая → 🆔 2354

Автоматизированная система управления бизнес процессом рекламного агентства