СОДЕРЖАНИЕ
ВВЕДЕНИЕ...……………………………………………..…….…..... 2
1 ОПИСАНИЕ СИСТЕМЫ….
…………………………….…............ 4
1.1 Описание предметной области ………………….………........ 4
1.2 Виды запросов............................................................................. 5
1.3 Описание входной и выходной информации………….…….. 6
2 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ…….. 9
2.1 Выбор методологии проектирования…………………….….. 9
2.2 Моделирование бизнес-процессов…………………………… 10
2.3 Модель функциональных требований к БД………………….. 13
2.4 Логическая модель базы данных……………………………… 14
3 РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ…………….. 17
3.1 Диаграмма компонентов………………………………………. 17
3.2 Выбор средства реализации…………………………………… 17
ЗАКЛЮЧЕНИЕ……………………………………………………..… 19
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ…………………..… 20
ПРИЛОЖЕНИЕ А……………………………………………………… 22
ПРИЛОЖЕНИЕ Б……………………………………………………… 24
ПРИЛОЖЕНИЕ В……………………………………………………… 34
ВВЕДЕНИЕ
В связи с развитием информационных технологий, они стали активно применятся в различных сферах человеческой деятельности, связанных с обработкой информации и представлением данных.
В современном обществе своевременная обработка информации способствует совершенствованию организации производства, оперативному и долгосрочному планированию, прогнозированию и анализу хозяйственной деятельности. Каждая организация стремиться минимизировать затраты времени, материальных, трудовых ресурсов в ходе своей деятельности и упростить процесс обработки информации. Эти задачи можно решить с использованием информационных систем.
Использование баз данных и информационных систем становится неотъемлемой составляющей деловой деятельности современного человека и функционирования преуспевающих организаций. В связи с этим большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов.
При разработке приложения необходимо также обеспечить выполнение всех требований к системе и налагаемых ограничений. В процессе проектирования основное внимание уделяется логическому решению, обеспечивающему выполнение основных требований.
Центральным элементом деятельности, ведущей к созданию информационной системы, является моделирование. Модели позволяют наглядно продемонстрировать желаемую структуру и поведение системы. Они также необходимы для визуализации и управления ее архитектурой. Модели помогают добиться лучшего понимания создаваемой нами системы, что зачастую приводит к ее упрощению и возможности повторного использования. Наконец, модели нужны для минимизации риска.
Целью данного курсового проекта является проектирование информационной системы проектной организации. Для ее создания необходимо описать всю систему и предъявляемые к ней требования, для этого нужно провести анализ ее предметной области, разбить систему на подсистемы или подразделения, определить входную и выходную информацию.
Решаемые задачи:
· визуализировать систему в ее текущем состоянии;
· определить структуру и поведение системы;
· получить шаблон, позволяющий затем сконструировать систему;
· документировать принимаемые решения, используя полученные модели.
1 ОПИСАНИЕ СИСТЕМЫ
1.1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Проектная организация представлена следующими категориями сотрудников: конструкторы, инженеры, техники, лаборанты, прочий обслуживающий персонал, каждая из которых может иметь свойственные только ей атрибуты. Например, конструктор характеризуется числом авторских свидетельств, техники - оборудованием, которое они могут обслуживать, инженер или конструктор может руководить договором или проектом и т.д. Сотрудники разделены на отделы, руководимые начальником так, что каждый сотрудник числится только в одном отделе.
В рамках заключаемых проектной организацией договоров с заказчиками выполняются различного рода проекты, причем по одному договору может выполняться более одного проекта, и один проект может выполняться для нескольких договоров. Суммарная стоимость договора определяется стоимостью всех проектных работ, выполняемых для этого договора. Каждый договор и проект имеет руководителя и группу сотрудников, выполняющих этот договор или проект, причем это могут быть сотрудники не только одного отдела. Проекты выполняются с использованием различного оборудования, часть которого приписано отдельным отделам, а часть является коллективной собственностью проектной организации, при этом в процессе работы оборудование может передаваться из отдела в отдел. Для выполнения проекта оборудование придается группе, работающей над проектом, если это оборудование не используется в другом проекте.
Для выполнения ряда проектов подрядная организация может привлекать субподрядные организации, передавая им объемы работ.
1.2 ВИДЫ ЗАПРОСОВ
1. получить данные о составе указанного отдела или всей организации полностью, по указанной категории сотрудников, по возрастному составу;
2. получить перечень руководителей отделов;
3. получить сведения об участии указанного сотрудника или категории сотрудников в проектах (договорах) за определенный период времени;
4. получить данные о численности и составе сотрудников в целом и по отдельным категориям, участвующих в указанном проекте;
5. получить данные о численности и составе сотрудников в целом и по отдельным категориям, участвующих в проектах за указанный период времени.
6. получить сведения об использовании оборудования указанными проектами (договорами);
7. получить перечень договоров или проектов, выполняемых в данный момент или в период указанного интервала времени;
8. получить информацию о том, какие проекты выполняются (выполнялись) в рамках указанного договора и какие договора поддерживаются указанными проектами;
9. получить данные об эффективности использования оборудования (объемы проектных работ, выполненных с использованием того или иного оборудования);
10. получить данные о стоимости выполненных договоров (проектов) в течение указанного периода времени;
11. получить перечень и стоимость работ, выполненных субподрядными организациями;
12. получить сведения об эффективности договоров (стоимость договоров соотнесенная с затраченным временем или стоимость с учетом привлеченных людских ресурсов);
13. получить данные о распределении оборудования на данный момент или на некоторую указанную дату;
14. получить сведения об эффективности проектов (стоимость договоров соотнесенная с затраченным временем или стоимость с учетом привлеченных людских ресурсов).
1.3 ОПИСАНИЕ ВХОДНОЙ/ВЫХОДНОЙ ИНФОРМАЦИИ
Данную систему можно разбить на три отдела согласно выполняемым функциям
1. Отдел кадров
2. Отдел учёта выполнения договоров
3. Отдел стоимостного учёта всех выполненных работ
Каждый отдел выполняет определенную задачу в совокупности составляющие информационную систему.
Отдел кадров.
Подчиняется непосредственно руководству организации. При поступлении на работу человека оформляют в этом отделе в качестве сотрудника, какого либо отдела. Принимает на работу или увольняет с работы по приказу руководства. В отделе кадров имеется база данных, где хранятся все данные о сотрудниках, то есть ФИО, место проживания, возраст и прочие данные. Эта база хранится в электронном виде. Для её заполнения требуется сотрудник, который будет заниматься заполнением этих данных. Этот отдел получает данные после запроса в соответствующий отдел о составе данного отдела, также может получить информацию обо всей организации полностью или перечень руководителей отделов. При поступлении запроса на получение данных о сотруднике, группе сотрудников отдел кадров рассматривает этот запрос и при положительном ответе выдаёт эту информацию руководителям других отделов, непосредственному руководству или заинтересованным внешним организациям только с разрешения руководства.
В отделе учёта кадров на входе имеем запрос о получении данных на сотрудника или группу сотрудников, данные сотрудника при поступлении на работу. На выходе ответ на запрос (либо интересующие данные, либо отказ на получение), данные которые хранятся в организации.
Отдел учёта договоров
Этот отдел также подчиняется непосредственно руководству организации. Занимается заключением договоров с различного рода организациями и последующим исполнением проекта по договору. При поступлении заказа составляется договор с заказчиком проекта. В этом договоре указываются номер договора, юридические адресы заказчика и исполнителя, сроки выполнения, стоимость проекта, обязательства сторон. Также отдел может привлекать для выполнения определённого проекта субподрядные организации. В отделе хранятся данные о договорах и проектах, выполняемых в данный момент или в период указанного интервала времени. Отдел получает информацию от руководителя группы специалистов работающих над конкретным проектом или субподрядчиков о том, какие проекты выполняются (выполнялись) в рамках указанного договора и какие договора поддерживаются указанными проектами, получить данные об эффективности использования оборудования (объемы проектных работ, выполненных с использованием того или иного оборудования). При поступлении запроса от руководителя или заказчика на выдачу договора по проекту рассматривает эту заявку и при получении положительного ответа имеет право на выдачу соответствующего договора.
В отделе учёта выполнения договоров и проектов на входе заказ на выполнение проекта, на выходе готовый отчёт о выполнении проекта.
Отдел стоимостного учёта всех выполненных работ занимается стоимостным учётом всех выполненных работ, а также затрат на исполнение данного проекта по договору. Получает данные о стоимости выполненных договоров (проектов) в течение указанного периода времени, перечень и стоимость работ выполненных субподрядными организациями, сведения об эффективности договоров (стоимость договоров соотнесенная с затраченным временем или стоимость с учетом привлеченных людских ресурсов), сведения об эффективности проектов (стоимость договоров соотнесенная с затраченным временем или стоимость с учетом привлеченных людских ресурсов).
В отделе стоимостного учета всех выполненных работ на входе запрос на стоимостную оценку выполненных работ, на выходе отчет о затратах на реализацию конкретного проекта предоставляемая заказчику.
2 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1 ВЫБОР МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ
На начальных этапах создания информационной системы необходимо понять, как работает организация, которую собираются автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия (или его части) необходимо построить модель, которая содержала бы сведения обо всех участниках бизнес-процессов.
Модель предметной области – система, имитирующая структуру или функциональные возможности исследуемой системы является адекватной исследуемой предметной области.
Требования, предъявляемые к модели:
1) формализуемость - позволяет однозначно описать предметную область;
2) понятность для заказчиков и исполнителей;
3) физическая реализуемость;
4) возможность оценки эффективности.
Можно выделить следующие методологии:
1) Методология функционального моделирования работ SADT
2) Методология объектного проектирования на языке UML.
Методология SADT (технология структурного анализа и проектирования) является одной из самых известных и широко используемых методик проектирования. Новое название методики, принятое в качестве стандарта, -IDEF0 (Icam DEFinition) является частью программы ICAM (Integrated Computer Aided Manufacturing - интегрированная компьютеризация производства).
Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации, представление ее в виде модели и уточнение модели. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы.
Методика SADT представляет собой структурный анализ и технический дизайн.
Функциональные методики используются, если организационная структура слабо оформлена. Основное ее отличие – отделение функций от самих данных.
Моделирование предметной области в объектной методике рассматривается как совокупность реально существующих объектов. Целью данной методики является выделение объектов и распределение между ними ответственности.
Объектная методика более устойчива к различного рода изменениям в системе.
В данной курсовой работе при разработке информационной системы проектной организации используется функциональная методика, т.к. она является наиболее распространенной методикой, и мне она показалась более простой и понятной.
2.2 МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
Функциональная модель предназначена для описания существующих бизнес - процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Основными понятиями методологии функционального моделирования работ являются:
Работы (activity) - поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. На диаграмме работы изображаются прямоугольниками.
Вход (Input) - материал или информация, которые используются работой для получения результата (стрелка, входящая в левую грань).
Управление (Control) - правила, стратегии, стандарты, которыми руководствуется работа (стрелка, входящая в верхнюю грань).
Выход (Output) - материал или информация, которые производятся работой (стрелка, исходящая из правой грани). Каждая работа должна иметь хотя бы одну стрелку выхода, так как работа без результата не имеет смысла и не должна моделироваться.
Механизм (Mechanism) - ресурсы, которые выполняют работу (персонал, станки, устройства - стрелка, входящая в нижнюю грань).
Вызов (Call) представляет собой взаимодействие одной модели работ с другой (стрелка, исходящая из нижней грани).
Различают в IDEF0 пять типов связей работ.
Связь по входу (input-output) имеет место, когда выход вышестоящей работы направляется на вход следующей работы.
Связь по управлению (output-control) обозначает ситуацию, когда выход вышестоящей работы направляется на управление следующей работы. Связь показывает доминирование вышестоящей работы.
Обратная связь по входу (output-input feedback) имеет место, когда выход нижестоящей работы направляется на вход вышестоящей.
Обратная связь по управлению (output-control feedback) обозначает ситуацию, когда выход нижестоящей работы направляется на управление вышестоящей. Является показателем эффективности бизнес-процесса.
Связь выход-механизм (output-mechanism) имеет место, когда выход одной работы направляется на механизм другой и показывает, что работа подготавливает ресурсы для проведения другой работы.
Из перечисленных блоков строятся диаграммы работ, описывающие принципы функционирования системы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. Построение модели ИС начинается с описания функционирования предприятия (системы) в целом в виде контекстной диаграммы. В графическом приложении приведена контекстная диаграмма ИС «Проектной организации».
После описания контекстной диаграммы проводится функциональная декомпозиция - система разбивается на подсистемы (цеха, отделы, служба персонала) и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции. В графическом приложении также приводятся и диаграммы декомпозиции.
2.3 МОДЕЛИРОВАНИЕ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К БД
Как дополнение к диаграммам IDEF0 для описания документооборота и обработки информации можно использовать диаграммы DFD. Нотация DFD включает такие понятия, как "внешняя ссылка" и "хранилище данных", что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота.
Потоки данных являются механизмами, использующимися для моделирования передачи информации (или физических компонентов) из одной части системы в другую. Потоки изображаются на диаграмме именованными стрелками, ориентация которых указывает направление движения информации. Стрелки могут подходить к любой грани прямоугольника работы.
DFD – это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах.
DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.
Хранилище данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Для рассматриваемой ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не главный единственный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. В графическом приложении приведена вся иерархия DFD диаграмм.
В соответствии с DFD-диаграммой для размещения информации системы требуются следующие хранилища данных: сотрудники, оборудование, готовые проекты, БД смет затрат.
2.4 ЛОГИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ
В реальной жизни программные проекты чаще всего достаточно сложны, и их декомпозиция – это основная и, наверное, единственная стратегия борьбы со сложностью. Она состоит в разбиении проблемы на мелкие управляемые элементы. До появления объектно-ориентированного подхода во времена господства парадигмы структурного программирования наиболее популярной методологией декомпозиции являлись структурный анализ и проектирование. Этот подход заключается в декомпозиции задачи на функции или процессы, приводящий к созданию иерархии процессов и подпроцессов. Объектно-ориентированный подход предлагает новый мощный способ решения проблемы сложности программ. Вместо того чтобы рассматривать программу как набор последовательно выполняемых инструкций, в ООП программа представляется в виде совокупности объектов, обладающих сходными свойствами и набором действий, которые можно с ними производить.
Первым шагом при построении логической модели БД является построение диаграммы ERD. Эти диаграммы состоят из трех частей: сущностей, атрибутов, и взаимосвязей. ERD-диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации.
Существуют следующие виды логических взаимосвязей, т.е. связей между сущностями:
«один -ко- многим» - один экземпляр первой сущности взаимодействует с несколькими экземплярами другой сущности;
«многие -ко- многим» - экземпляры сущностей могут взаимодействовать с несколькими экземплярами других сущностей.
При создании сущности необходимо выделить группу атрибутов, которые потенциально могут стать первичным ключом. Первичный ключ должен быть таким, чтобы по значениям атрибутов, в него включенных, можно было точно идентифицировать экземпляр сущности, значения атрибутов первичного ключа не должны быть нулевыми и не должны меняться.
В рассматриваемой системе можно выделить следующие классы:
1) Сотрудники;
2) Договор;
3) Заказчик;
4) Оборудование;
5)Смета расходов;
6) Субподрядчики;
7) Подразделения;
8) Проект.
Сотрудники:
1. ФИО
2. Специализация
3. Трудовая книжка
4. Паспортные данные
Договор:
1. Юридический адрес заказчика
2. Юридический адрес организации
3. Банковские реквизиты
4. Обязательства сторон
5. Сроки выполнения
Заказчик:
1. ФИО
2. Адрес
3. Телефон
Оборудование:
1. Серийный номер
2. Наименование оборудования
Смета расходов:
1. Затраты на использование оборудования
2. Затраты на материалы
Субподрядчики
1. Телефон
2. Банковские реквизиты
3. Договор на выполнение работ
4. Юридический адрес
Подразделения
1. Конструкторы
2. Инженеры
3. Техники
4. Лаборанты
Проект
1. Список сотрудников
2. Оборудование
3. Материалы
Логическая модель данных представлена в графическом приложении.
3 РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ
3.1 ДИАГРАММА КОМПОНЕНТОВ
Диаграмма компонентов показывает, как выглядит модель на физическом уровне. На ней изображаются компоненты программного обеспечения системы и связи между ними. При этом выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.
У каждого класса имеется свой собственный заголовочный файл и файл с расширением *.СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Например, класс Client преобразуется в два компонента: client.h и client.cрp. Вместе эти компоненты представляют тело и заголовок класса Client. Компонент Hotel.exe представляет поток обработки информации (thread of processing). В данном случае поток обработки — это исполняемая программа.
3.2 ВЫБОР СРЕДСТВА РЕАЛИЗАЦИИ
При создании информационной системы разработчику придется подумать о средствах реализации своей системы и об интерфейсе, удобном для пользователя. В объектно-ориентированной операционной системе Windows интерфейс пользователя представляет собой целостную систему различных элементов (окна, меню). Основной задачей проектирования интерфейса пользователя является разработка целостной системы управления множеством состояний программного продукта.
Access позволяет создать удобный и понятный интерфейс пользователя для работы с данными при помощи форм. Формы используются в приложении для ввода и отображения данных. Формы содержат так называемые элементы управления, с помощью которых осуществляется доступ к данным в таблицах.
Функция окна описывает реакцию окна на поступающие сообщения. Она от обычных функций отличается тем, что имеет стандартные тип возврата и список формальных параметров и вызывается только операционной системой.
В объектно-ориентированном программировании методы изменения параметров состояния объекта обычно описываются отдельно. Функция окна реализует единственный метод для изменения всех параметров состояния окна.
Поэтому, я думаю, что для создания данной информационной систему можно воспользоваться средствами объектно-ориентированного программирования (например, язык программирования С++) и СУБД Access.
ЗАКЛЮЧЕНИЕ
Целью данной курсовой работы является изучение особенностей современных методов и средств проектирования информационных систем.
В процессе создания ИС была использована функциональная методология проектирования SADT, были построены полные и непротиворечивые функциональные и информационные модели.
Для построения различных диаграмм модели использовался набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область в соответствии с информационными потребностями пользователей. В процессе выполнения данной работы мы познакомились со специализированными программами такими, как BpWin, ErWin, UMLEditor.
В результате выполнения данной работы был сделан вывод о том, что сегодня внедрение информационных систем может способствовать:
• получению более рациональных вариантов решения управленческих задач за счет внедрения математических методов и интеллектуальных систем и т.д.
• освобождению работников от рутинной работы за счет ее автоматизации;
• обеспечению достоверности информации;
• замене бумажных носителей данных на магнитные и оптические, что приводит к более рациональной организации переработки информации на компьютере и снижению объемов бумажных документов;
• уменьшению затрат на производство продуктов и услуг.
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
1. Черемных С. В. Структурный анализ систем: IDEF-технологии / С.В. Черемных, И. О. Семенов, В. С Ручкин— М.: Финансы и статистика, 2003. —208 с.
2. Вендров, А. М. Проектирование программного обеспечения экономических информационных систем / А.М. Вендров— М.: Финансы и статистика, 2006. — 544 с.
3. Макконел С. Профессиональная разработка программного обеспечения / С. Макконел — СПБ: Символ-Плюс, 2007. — 240 с.
4. Никитин П.М. Методология функционального моделирования / - Москва ИПК, Издательство стандартов.
5. Маклаков С.В. Создание информационных систем с AllFusionModelingSuite./ С.В. Маклаков– М.: ДИАЛОГ – МИФИ, 2002. – 224с.
6. Маклаков С. В. BPWIN и ERWIN: CASE-средства для разработки информационных систем / С. В. Маклаков— М.: Диалог-МИФИ, 2000. — 295 с.
7. Бек К. Шаблоны реализации корпоративных приложений / К. Бек— М.: Вильямс, 2006. — 176 с.
8. Фаулер М. UML: Основы / М. Фаулер, К.Скотт— СПБ: Символ-Плюс, 2002. — 192 с.
9. Буч Г. Язык UML. Руководство пользователя / Буч Г., Д. Рамбо, А. Джекобсон — СПБ: Питер, 2003. — 432 с.
10. Ларман К. Применение UML 2.0 и шаблонов проектирования / К. Ларман— М.: Вильямс, 2007. — 736 с.
11. Федорова Д.Э. CASE-технологии. / Д.Э. Федорова, Ю.Д. Семенов, К.Н. Чижик - М.: Вильямс, 2003 – 378с.
12. Цикритизис Д. Модели данных. / Д. Цикритизис, Ф. Лоховски– М.: Финансы и статистика, 1985. – 344 с.
13. Раскин, Д. Интерфейс: новые направления в проектировании компьютерных систем / Д.Раскин — СПБ: Символ-Плюс, 2005. — 272 с.
14. Костерин В.Н. Построение диаграмм / В.Н. Костерин –М.: ПравдаТим, 2008 – 589с.
15. Курочкин Р.Р. Моделирование с ноля. / Р.Р. Курочкин – СПб,: Новый век, 2005 –234c.
ПРИЛОЖЕНИЕ А
1. Полное наименование системы
Информационная система проектной организации.
2. Назначение системы
Система предназначена для учета выполнения проектов по договорам и их стоимостной оценки.
3. Цели создания системы
Разработанная система должна производить учёт заключения договор, учёт выполняемых проектов по договорам, учет стоимостной оценки выполненных проектов; по учету движения кадров.
Цели систему будут считаться достигнутыми, если на производстве не происходит застоев по причине несвоевременного получения ответа на запросы к базам данных системы и вся информация в базах данных является максимально полной и актуальной.
4. Требования к системе в целом
- Система должна быть надежной. Полная или частичная потеря данных может нанести большой вред как заказчику, так и всей проектной организации.
- Система должна быть безопасной. Возможный вред при хищении или преднамеренном изменении информации может привести к большой путанице.
- Для хорошей работоспособности системы в каждом отделе должна находится база данных для ведения учёта договоров, проектов, смет расходов, учёта сотрудников.
- В системе также должна функционировать система безопасности, защищающая все конфиденциальные данные от вторжения извне и не дающая доступа к данным некомпетентным лицам. Также должна быть обеспечена сохранность всей информации при авариях, то есть через определенный промежуток времени должно производится создание резервной копии всех баз системы предприятия.
5. Требования к способам и средствам связи для информационного обмена между компонентами системы
Для связи между узлами в пределах одного помещения вполне подойдет витая пара. Связь между компонентами системы можно осуществить посредством телефонной линии в качестве экономии на затраты прокладки выделенных каналов связи.
6. Требования к программному обеспечению системы
Серверные части в случае использования MySQL могут вполне функционировать на базе Linux систем. При использовании MicrosoftSQLServer без ОС Windows не обойтись. Клиентская часть может функционировать опять же на нескольких платформах, но проще ее реализовать для среды Windows.
7. Требования к техническому обеспечению
Так как основная нагрузка приходится на серверную часть, то необходимо подобрать подходящую конфигурацию оборудования, которая будет отвечать мощности запросов.
|