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

 

4.  Сотрудники 

№	Имя поля	Тип	Назначение
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 

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

 

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

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

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