Файл: КП базы данных.doc

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

• цель функционирования предприятия;

• краткую историю его развития и его место на рынке аналогичных товаров\услуг;

• все основные виды (направления) деятельности;

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

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

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

1.2. Организационная структура управления предприятием

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

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

2. Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов

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

3. Информационное обеспечение задачи

3.1 Информационная модель и её описание

Методика разработки информационной модели предполагает моделирование нового варианта организации информационной системы предметной области («КАК ДОЛЖНО БЫТЬ»), а именно:

0. полного состава информации, необходимой для решения комплекса задач данного АРМа;

1. отражение этой информации на всех типах носителей;

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

3. состава исходных первичных документов и распределение их по задачам;

4. источники и способы получения первичной информации;

5. состава файлов с первичной, условно-постоянной, промежуточной и результатной информацией;

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

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

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

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

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

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

Правило 1 Модель читается исключительно сверху вниз

Правило 2 У каждого элемента на модели должен быть как вход, так и выход.

Это правило не относится к источникам и получателям информации для моделируемой ИС, так как у них бывает либо выход (у источников), либо вход (у получателей).

Правило 3 Вход обозначается в центре верхней части элемента, а выход – в центре нижней части. Вход и выход у элемента должен быть только 1.

Правило 4 Каждая связь, подходящая на вход элемента, должна подразумевать под собой передачу как минимум одного реквизита информации. Совокупность всех реквизитов информации, передаваемая всеми входящими связями должна давать возможность сделать экземпляр обозначенного объекта (файл, записать в таблице и др.).

Правило 5 Если в рамках работы информационной системы происходит изменение состояния объекта (файла, таблицы, справочника), то это должно быть обозначено любым из символов ( «`», «!», «@», «#», «^», «&», «*» ). Под изменением, например, могут пониматься добавление записи в таблицу (insert), изменение записи в таблице (update), изменение любого байта в уже существующем файле.

При работе ИС все внешние источники и получатели информации (обозначаются символом «Terminator» ) можно условно разделить на следующие группы, с каждой из которых наша ИС может взаимодействовать различными способами:

• внешние информационные системы или технические средства

  • сигналы от любых датчиков или любого оборудования («Direct data» )

  • файлы, которые были экспортированы какой-то ИС (модулем нашей ИС) и которые мы будем импортировать ( )

  • мы напрямую получаем доступ к таблицам БД внешней ИС ( )

  • мы получаем доступ к файловому хранилищу ИС, работающей в рамках архитектуры файл-сервер ( )

  • взаимодействие по какому-либо прикладному протоколу по сети ( , где название – это название или код сообщения в соответствии с прикладным протоколом)

• пользователь (человек)

  • вводит какой-либо документ, регламентируемый законодательством РФ, международным законодательством, внутренней учётной политикой в целях бухгалтерского и налогового учёта (НК РФ, ПБУ, 129-ФЗ «О бухгалтерском учёте»), иной внутрикорпоративной документацией («Document» )

  • вводит данные во внутреннюю экранную форму, не являющуюся формой ввода документа из п. 1 («Display» )

• собственно сама моделируемая ИС или её модули (в случае если информационная модель строится отдельно для подсистем ИС работающих по отдельности)

  • получает доступ к своим таблицам ( ), справочникам ( ), файлам ( ).

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

1. источники информации ;

2. первичные документы или файлы ;

3. таблицы с первичными документами ;

4. таблицы с промежуточной информацией ;

5. таблицы с результатной информацией ;

6. результатные документы или файлы ;

7. получатели информации .

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

Область 1 отображает процесс конфигурирования ИС в части ввода пользователей ИС, которые необходимы в рамках задачи для того, чтобы можно было зафиксировать информацию о принявшем платёж сотруднике. Форма «Управление пользователями» предполагает выполнение двух видов операций:

• редактирование справочника прав пользователей (ролей);

• редактирование справочника пользователей.

При этом, в ИС предполагается, что каждый пользователь может иметь строго одну роль, что отображено входящей связью из «Спр* «Права польз.»» в «Спр* «Пользователи»».

Область 2 отображает то, что из базы ИС в рамках моделируемой задачи используются два справочника и три таблицы. (Под справочником мы понимаем обычную таблицу, которая содержит условно-постоянную информацию).

Область 3 отображает собственно процесс ввода платежа. Проектировщики предполагают, что ввод будет состоять из следующих этапов:

• сначала делается запись (либо производится обновление записи) в справочнике клиентов. Под клиентом понимается ФИО плательщика и какие-либо его данные (например паспортные данные).

• затем делается запись, отражающая факт совершения платежа. В рамках задачи предполагается два варианта его совершения:

  • платёж принимается без открытия счёта;

  • платёж выполняется с какого-либо счёта; (связь со справочником лицевых счетов при изменении «Т* «Проводки»»);

• в любом случае платёж должен поступить какому-либо оператору, что отражается связью со справочником «Спр «ОператорыМобСв»», откуда получается номер его счёта.

• третьим этапов будет изменение остатков по лицевым счетам по факту выполнения проводки. (данное действие как раз отображает пример логического уровня 4 из информационной модели).

Область 4 отображает то, что моделируема ИС предоставляет на выходе:

• клиент получает результатный документ, содержащий параметры совершённого платежа и являющийся его подтверждением.

  • Из справочника «Спр «Клиенты»» используем текстовое наименование клиента;

  • Из справочника «Спр «ОператорыМобСв»» получаем текстовое наименование оператора-получателя

  • Из таблицы «Т «Проводки»» остальные реквизиты платежа.

• клиент (в случае, если у него открыт счёт) может получить выписку по нему:

  • «Т «Остатки по л\счетам»» необходим, чтобы привести входящий и исходящий остатки на период выписки

  • «Спр «Лицевые счета»» - получение наименование счёта и срока его действия

  • «Т «Проводки»» - собственно операции

• оператор мобильной связи по окончании какого-либо периода получает от банка файл(реестр) платежей. Его, в целом, интересует только сумма платежа и номер за которой он осуществлён.

  • из «Спр «ОператорыМобСв»» получаем номер счёта оператора;

  • из «Т «Проводки»» - собственно операции

3.2. Используемые классификаторы и системы кодирования

Необходимо дать краткую характеристику используемым для решения данного комплекса задач (задачи, АРМа) классификаторам и системам кодирования. Состав кодовых обозначений объектов должен быть оформлен в виде таблицы с таким содержанием граф: наименование кодируемого множества объектов (например, кодов подразделений, табельных номеров и т.д.), длина кода (требуемое количество знаков), мощность кода (количество возможных комбинаций), система кодирования (серийная, порядковая, комбинированная), система классификации (иерархическая, многоаспектная или отсутствует), вид классификатора (международный, отраслевой, общесистемный и т.д.).

Используемые системы кодирования

Далее:

• производится описание каждого классификатора;

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

• приводятся фрагменты заполненных классификаторов.

3.3. Характеристика нормативно-справочной, входной и оперативной информации

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

• при описании входных документов необходимо:

  • привести в приложении формы(макеты) документов и экранные формы для их ввода в систему;

  • привести перечень содержащихся в них первичных показателей;

  • привести источник получения документа;

  • описать структуру документа, число строк, объемные данные, частоту возникновения документа;

• при описании входных файлов необходимо:

  • привести перечень содержащихся в них первичных показателей;

  • привести источник получения файла;

  • описать структуру файла, объемные данные, частоту поступления файла;

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

• при описании справочников необходимо:

  • построить сводную таблицу, содержащую:

    • название справочника;

    • ответственного за его ведение;

    • средний объём справочника в записях;

    • среднюю частоту актуализации;

    • средний объем актуализации (в записях или в процентах);

  • по каждому справочнику необходимо описать его реквизитный состав.

3.4 Характеристика результатной информации

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

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

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

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

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

Для результатных файлов описывается:

• их структура и реквизитный состав;

• частота их формирования;

• на основе каких таблиц они формируются;

• каким способом доставляются до ИС – получателя файла.

4. Программное обеспечение задачи

4.1.Общие положения (дерево функций и сценарий диалога)

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

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

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