Основные достоинства языка SQL заключаются в следующем:

- стандартность - как уже было сказано, использование языка SQL в программах стандартизировано международными организациями;

- независимость от конкретных СУБД - все распространенные СУБД используют SQL, т.к. реляционную базу данных можно перенести с одной СУБД на другую с минимальными доработками;

- возможность переноса с одной вычислительной системы на другую - СУБД может быть ориентирована на различные вычислительные системы, однако приложения, созданные с помощью SQL, допускают использование как для локальных БД, так и для крупных многопользовательских систем;

- реляционная основа языка - SQL является языком реляционных БД, поэтому он стал популярным тогда, когда получила широкое распространение реляционная модель представления данных. Табличная структура реляционной БД хорошо понятна, а потому язык SQL прост для изучения;

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

- возможность программного доступа к БД - язык SQL легко использовать в приложениях, которым необходимо обращаться к базам данных. Одни и те же операторы SQL употребляются как для интерактивного, так и программного доступа, поэтому части программ, содержащие обращение к БД, можно вначале проверить в интерактивном режиме, а затем встраивать в программу;

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

- возможность динамического изменения и расширения структуры БД - язык SQL позволяет манипулировать структурой БД, тем самым обеспечивая гибкость с точки зрения приспособленности БД к изменяющимся требованиям предметной области;

- поддержка архитектуры клиент-сервер - SQL - одно из лучших средств для реализации приложений на платформе клиент-сервер. SQL служит связующим звеном между взаимодействующей с пользователем клиентской системой и серверной системой, управляющей БД, позволяя каждой из них сосредоточиться на выполнении своих функций [16].

В настоящее время язык SQL поддерживается многими десятками СУБД различных типов, разработанных для самых разнообразных вычислительных платформ, начиная от персональных компьютеров и заканчивая мейнфреймами.

2.2 Разработка базы данных проектируемого программного средства

В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни ее архитектуры. Распространены два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий".

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

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

Таким образом, для проектирования базы данных необходимо использовать "нисходящий" подход, содержащий ряд этапов:

- анализ предметной области. На основе анализа предметной области получают описание внешнего уровня БД, являющееся исходными данными для следующего этапа;

- разработка инфологической модели (ИЛМ). По полученному на предыдущем этапе описанию строится модель данных использующая модель "сущность-связь";

- разработка даталогической модели (ДЛМ). На основе ИЛМ предметной области строится ДЛМ БД;

- нормализация. Этап представляет собой нормализацию полученной модели;

- формирование физической модели БД на языке описания данных СУБД. На заключительном этапе проектирования строится физическая модель данных с учетом особенностей используемой СУБД.

2.2.1 Формализованное описание предметной области

Формализованное описание предметной области содержит описание классов объектов (сущностей), выявленных на этапе анализа предметной области и связей (отношений) между ними. Оно необходимо для того, чтобы определить, какие данные будут в таблицах разрабатываемой БД, а также логические ограничения полей этих таблиц [18].

Формализованное описание предметной области представлено в таблице 2.2

Таблица 2.2 - Формализованное описание предметной области

Объект	Ключ	Физические характеристики	Обязательность значения	Логические ограничения	Процессы
ПОМЕЩЕНИЕ
ID помещения	УК, ПК	Целое 5	непустое	>0	Г, Пр
Имя		Символьное 30	непустое		Вв,Пр,У
Номер		Символьное 4	непустое	>0	Вв,Пр,У
Этаж		Целое 1	непустое	>0	Вв,Пр,У
ID типа помещения		Целое 5	непустое	>0	Пр
ТИПЫ ПОМЕЩЕНИЙ
ID типа помещения	УК, ПК	Целое 5	непустое	>0	Г, Пр
Тип		Символьное 30	непустое		Вв,Пр,У
Описание		Символьное 10	непустое		Вв,Пр,У
ОБОРУДОВАНИЕ
ID оборудования	УК, ПК	Целое 5	непустое	>0	Г, Пр
ID типа оборудования		Целое 5	непустое	>0	Пр
ID помещения		Целое 5	непустое	>0	Пр
Инвентарный номер		Символьное 10	непустое	>0	Пр
Объект	Ключ	Физические характеристики	Обязательность значения	Логические ограничения	Процессы
Серийный номер		Символьное 10	непустое	>0	Пр
Ввод в эксплуатацию		Дата	непустое	дд.мм.ггг	Вв,Об,Пр,У
Имя		Символьное 30	непустое		Вв,Пр,У
ТИП ОБОРУДОВАНИЯ
ID типа оборудования	УК, ПК	Целое 5	непустое	>0	Г, Пр
Тип оборудования		Символьное 30	непустое		Вв,Пр,У
Описание		Символьное 100	непустое		Вв,Пр,У
КЛАССЫ ОБОРУДОВАНИЯ
ID класса	УК, ПК	Целое 5	непустое	>0	Г, Пр
Класс оборудования		Символьное 30	непустое	>0	Вв,Пр,У
Описание		Символьное 100	непустое		Вв,Пр,У
ПОЛЬЗОВАТЕЛИ
ID пользователя	УК, ПК	Целое 5	непустое	>0	Г, Пр
ID типа пользователя		Целое 5	непустое	>0	Пр, Об
Объект	Ключ	Физические характеристики	Обязательность значения	Логические ограничения	Процессы
Логин		Символьное 20	непустое		Вв,Об,Пр,У
Пароль		Символьное 20	непустое		Вв,Об,Пр,У
Фамилия		Символьное 30	непустое		Вв,Об,Пр,У
Имя		Символьное 20	непустое		Вв,Об,Пр,У
Отчество		Символьное 20	непустое		Вв,Об,Пр,У
Инициалы		Символьное 20	непустое		Г
ТИП ПОЛЬЗОВАТЕЛЯ
ID типа пользователя	УК, ПК	Целое 5	непустое	>0	Г, Пр
Тип пользователя		Символьное 15	непустое		Вв,Пр,Об,У
ЗАЯВКИ
ID заявки	УК, ПК	Целое 5	непустое	>0	Г, Пр
ID пользователя		Целое 5	непустое	>0	Пр, Об
ID помещения		Целое 5	непустое	>0	Пр, Об
ID устройства		Целое 5	непустое	>0	Пр, Об
Объект	Ключ	Физические характеристики	Обязательность значения	Логические ограничения	Процессы
ID класса устройства		Целое 5	непустое	>0	Пр, Об
Дата создания		Дата	непустое	дд.мм.ггг	Вв,Об,Пр,У
Дата выполнения		Дата	непустое	дд.мм.ггг	Вв,Об,Пр,У
ID статуса		Целое 5	непустое	>0	Пр, Об
СТАТУС ЗАЯВКИ
ID статуса	УК, ПК	Целое 5	непустое	>0	Г, Пр
Статус		Символьное 15	непустое		Вв,Пр,Об,У

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

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

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

Существующие типы связей:

- первый тип - связь один-к-одному (1:1). В каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В;

- второй тип - связь один-ко-многим (1:М). Одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В, но каждому представителю сущности В может соответствовать только один представитель из А. Связь один-ко-многим является самой распространенной для реляционных баз данных, она позволяет моделировать иерархические структуры данных;

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

Связи между сущностями, их тип и описание связи отражены в таблице 2.3.

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

Таблица 2.3 - Связи между сущностями

Название связи	Тип связи	Сущность 1	Сущность 2
соответствует	М:1	Помещение	Определенному типу помещения
соответствует	М:1	Тип оборудования	Определенному классу оборудования
соответствует	М:1	Пользователь	Определенному типу пользователя
соответствует	М:1	Оборудование	Определенному помещению
соответствует	1:М	Пользователь	Различное множество заявок
соответствует	М:1	Оборудование	Определенному типу оборудования
соответствует	1:М	Помещение	Различному множеству заявок
имеют	М:1	Заявки	Определенный статус
соответствует	М:1	Заявки	Определенное оборудование

2.2.2 Разработка инфологической модели БД

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

ИЛМ предметной области представлена в виде ER-диаграммы предметной области, построенной по методологии Ричарда Баркера. Основные элементы ER - модели в методологии Ричарда Баркера: сущность, атрибуты, уникальные идентификаторы, опциональность атрибутов, связи, опциональность и переносимость связей, уникальность объекта из связи, супертипы, подтипы, арки.

ER-диаграмма - четырехугольник с закругленными углами. В нем описан класс объектов - это значимая вещь, о которой предприятие должно хранить информацию со свойствами - качественное или количественное описание класса объекта. Значение свойства может быть обязательным или необязательным. Такая характеристика свойства называется опциональностью свойства. ER-диаграмма по методологии Ричарда Баркера показана на рисунке 2.2.

Рисунок 2.2 - Инфологическая модель БД

Обязательность свойства помечается "*". Необязательные значения свойства помечается "о".

Уникальный идентификатор (УИ) - любая комбинация свойств и связей, используемых для однозначной идентификации объекта. Количество УИ в классе объектов может быть каким угодно. На диаграмме идентификатор обозначается "#", если УИ несколько, порядок обозначается числом в скобках.

Обязательная связь помечается сплошной линией, необязательная - пунктирной. Тип (мощность) связи "один" помечается линией, "много" - "вороньей лапой".



2.2.3 Разработка даталогической модели БД

После построения ИЛМ предметной области согласно этапам нисходящего проектирования проектируется даталогическая (ДЛМ) модель БД. Основным элементом структуры данных в ДЛМ является реляционное отношение. Существует несколько видов представления реляционного отношения: таблица, математическая запись, графическое изображение.

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

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

Рисунок 2.3 - Даталогическая модель реляционной БД

2.2.4 Нормализация отношений

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

Нормализация выполняется поэтапно.

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

Никакую из систем управления базами данных (СУБД) не удовлетворяет только 1НФ, так как в этом случае необходимо определить большое число полей, многие из которых остаются в основном пустыми. Избыточные данные могут послужить причиной проблем целостности и снижение эффективности при внесении изменений, поэтому подобных решений при проектировании баз данных необходимо избегать.

Вторая нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен. 2НФ позволяет удалить большую часть повторяющихся данных, которые часто остаются после первого этапа нормализации. Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ [20].

Еще существует 3НФБК, 4НФ и 5НФ, но для большинства существующих СУБД необходимо представить проект базы данных в ЗНФ, так как этого вполне достаточно практически для всех обычных приложений.

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

- структура БД находится в первой нормальной форме, так как все таблицы являются плоскими и не содержат повторяющихся групп;

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

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

2.2.5 Физическая модель БД

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

Основная единица данных в физических структурах - хранимая запись. Она представляет собой совокупность связанных элементов данных (атрибутов), которая соответствует одной или нескольким логическим записям, она содержит все необходимые указатели, длину записи и некоторые дополнительные данные, а также схему кодирования для символьного представления [21]. Под хранимой записью в СУБД PostgreSQL понимается таблица со своими атрибутами.

2.2.5.1 Техническое описание объектов БД

Техническое описание проектируемых объектов БД на языке определения данных СУБД PostgreSQL можно представить в виде таблиц и операторов на языке DDL.

Далее в таблицах 2.4-2.12 идет техническое описание атрибутов, по каждой таблице представлен оператор описания на языке DDL.

Таблица 2.4 - Описание атрибутов класса DeviceClasses

Field	Type	Length	Default	Not Null	Index	Auto_increment
Idclass	int	10	null	+	primary	+
class	varchar	30	null	+	-	-
description	text	255	null	-	-	-

Оператор:

CREATE TABLE "DeviceClasses"

(

idclass integer NOT NULL,

description text,

"class" character varying(30),

CONSTRAINT "PK_КлассыОборудования" PRIMARY KEY (idclass)

)

WITH (

OIDS=FALSE

);

ALTER TABLE "DeviceClasses" OWNER TO postgres;

Таблица 2.5 - Описание атрибутов класса DeviceTypes

Field	Type	Length	Default	Not Null	Index	Auto_increment
Idtype	int	10	null	+	primary	+
device	varchar	255	null	+	-	-
description	text	255	null	-	-	-

Оператор:

CREATE TABLE "DeviceTypes"

(

idtype integer NOT NULL,

device character(255) NOT NULL,

description text,

idclass integer NOT NULL,

CONSTRAINT "PK_СправочникТипаОборудования" PRIMARY KEY (idtype)

)

WITH (

OIDS=FALSE

);

ALTER TABLE "DeviceTypes" OWNER TO postgres;

Таблица 2.6 - Описание атрибутов класс Users

Field	Type	Length	Default	Not Null	Index	Auto_increment
id	int	3	null	+	primary	+
login	varchar	20	null	+	-	-
pas	varchar	20	null	+	-	-
Surname	varchar	30	null	+	-	-
Name	varchar	30	null	+	-	-
FName	varchar	30	null	+	-	-
shortName	varchar	20	null	+	-	-
Id_type_user	int	2	null	+	-	-

Оператор:

CREATE TABLE "Users"

(

"login" character varying(20) NOT NULL DEFAULT NULL::character varying,

pas character varying(20) NOT NULL DEFAULT NULL::character varying,

"Surname" character varying(30) NOT NULL DEFAULT NULL::character varying,

"Name" character varying(20) NOT NULL DEFAULT NULL::character varying,

"FName" character varying(20) NOT NULL DEFAULT NULL::character varying,

"typeUser" integer NOT NULL,

"shortName" character(20) NOT NULL,

id bigint NOT NULL DEFAULT nextval('"Users_Id_user_seq"'::regclass),

CONSTRAINT "PK_Пользователь" PRIMARY KEY (id),

CONSTRAINT "FK_Id_type" FOREIGN KEY ("typeUser")

REFERENCES "TypeUsers" ("typeUser") MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION

)

WITH (

OIDS=FALSE);

ALTER TABLE "Users" OWNER TO postgres;

Таблица 2.7 - Описание атрибутов класса TypeUsers

Field	Type	Length	Default	Not Null	Index	Auto_increment
typeUser	int	2	null	+	primary	+
name	varchar	15	null	+	-	-

Оператор:

CREATE TABLE "TypeUsers"

(

"typeUser" integer NOT NULL,

"name" character(15) NOT NULL,

CONSTRAINT "PK_ТипПользователя" PRIMARY KEY ("typeUser")

)

WITH (

OIDS=FALSE

);

ALTER TABLE "TypeUsers" OWNER TO postgres;

Таблица 2.8 - Описание атрибутов класса devices

Field	Type	Length	Default	Not Null	Index	Auto_increment
iddevice	int	20	null	+	primary	+
nameDevice	varchar	30	null	+	-	-
inventorynumber	varchar	30	null	+	-	-
idtype	int	10	null	+	-	-
idroom	int	10	null	+	-	-
exploitation date	datetime	0	null	+	-	-

Оператор:

CREATE TABLE devices

(

idtype integer NOT NULL,

idroom integer NOT NULL,

inventorynumber character(30) NOT NULL,

serialnumber character(255) NOT NULL,

exploitation date NOT NULL,

"nameDevice" character(30) NOT NULL,

iddevice bigserial NOT NULL,

CONSTRAINT "PK_Устройства" PRIMARY KEY (iddevice),

CONSTRAINT "FK_idroom" FOREIGN KEY (idroom)

REFERENCES "Rooms" (idroom) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION,

CONSTRAINT "FK_idtype" FOREIGN KEY (idtype)

REFERENCES "DeviceTypes" (idtype) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION

)

WITH (

OIDS=FALSE

);

ALTER TABLE devices OWNER TO postgres;

Таблица 2.9 - Описание атрибутов класса Status

Field	Type	Length	Default	Not Null	Index	Auto_increment
idstatus	int	1	null	+	primary	+
statusname	varchar	15	null	+	-	-

Оператор:

CREATE TABLE "Status"

(

idstatus integer NOT NULL,

statusname character varying(15) NOT NULL,

CONSTRAINT "PK_Справочник_статусов" PRIMARY KEY (idstatus)

)

WITH (

OIDS=FALSE);

ALTER TABLE "Status" OWNER TO postgres;

Таблица 2.10 - Описание атрибутов класса Demands

Field	Type	Length	Default	Not Null	Index	Auto_increment
iddemand	int	20	null	+	primary	+
Field	Type	Length	Default	Not Null	Index	Auto_increment
iddevice	varchar	20	null	+	-	-
Description	text	500	null	+	-	-
Id_user	int	3	null	+	-	-
datetimeCreat	datetime	0	null	+	-	-
datetime	datetime	0	null	+	-	-
idstatus	int	1	null	+	-	-
idroom	int	10	null	+	-	-



Оператор:

CREATE TABLE demands

(

"Id_user" bigint NOT NULL,

idtypedem integer NOT NULL,

idroom integer NOT NULL,

iddevice bigint NOT NULL,

"datetimeCreat" timestamp with time zone NOT NULL,

datetime timestamp with time zone NOT NULL,

idstatus integer NOT NULL,

iddemand bigserial NOT NULL,

description text NOT NULL,

CONSTRAINT "PK_Заявка" PRIMARY KEY (iddemand),

CONSTRAINT "FK_Id_user" FOREIGN KEY ("Id_user")

REFERENCES "Users" (id) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION,

CONSTRAINT "FK_idstatus" FOREIGN KEY (idstatus)

REFERENCES "DemandStatus" (idstatus) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION,

CONSTRAINT "FK_idtypedem" FOREIGN KEY (idtypedem)

REFERENCES "TypeDemands" (idtypedem) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION

)

WITH (

OIDS=FALSE

);

ALTER TABLE demands OWNER TO postgres;



Таблица 2.11 - Описание атрибутов класса RoomTypes

Field	Type	Length	Default	Not Null	Index	Auto_increment
idtype	int	10	null	+	primary	+
type	varchar	30	null	+	-	-
description	text	255	null	-	-	-

Оператор:

CREATE TABLE "RoomTypes"

(

idtype integer NOT NULL,

"type" character(30) NOT NULL,

description text,

CONSTRAINT "PK_Тип помещений" PRIMARY KEY (idtype)

)

WITH (

OIDS=FALSE

);

ALTER TABLE "RoomTypes" OWNER TO postgres;

Таблица 2.12 - Описание атрибутов класса Rooms

Field	Type	Length	Default	Not Null	Index	Auto_increment
idroom	int	10	null	+	primary	+
name	varchar	30	null	+	-	-
number	varchar	4	null	+	-	-
storey	int	1	null	+	-	-
idtype	int	10	null	+	-	+

Оператор:

CREATE TABLE "Rooms"

(

"name" character(30) NOT NULL,

"number" character(4) NOT NULL,

storey smallint,

idtype integer NOT NULL,

idroom bigserial NOT NULL,

CONSTRAINT "PK_Помещения" PRIMARY KEY (idroom),

CONSTRAINT "FK_idtype" FOREIGN KEY (idtype)

REFERENCES "RoomTypes" (idtype) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION

)

WITH (

OIDS=FALSE

);

ALTER TABLE "Rooms" OWNER TO postgres;

2.2.5.2 Реализация ограничений целостности БД

Создаваемая и эксплуатируемая реляционная база данных должна быть целостной и надежной. Поддержка целостности реляционной БД рассматривается в трех аспектах.

Целостность таблицы. Обязательно должны поддерживаться:

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

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

Эти ограничения реализуются в командах создания и модификации таблиц. Например, в языке SQL это команды Create Table, Alter Table. В этих командах для описания полей - первичных ключей используется конструкция Primary Key, для описания полей - уникальных ключей конструкция Unique, обязательность значений полей задается конструкцией Not Null.

Ссылочная целостность. Каждая таблица проектируемой БД должна быть связана с другими посредством соответствующих первичных и внешних ключей. Назначение внешнего ключа - связывать каждую строку дочерней таблицы с соответствующей строкой родительской таблицы. Значение внешнего ключа может иметь и пустое значение (Null), если он реализует необязательную связь, выявленную в предметной области. В качестве значения внешнего ключа может выступать значение и любого уникального (потенциального) ключа [22].

Декларативные ограничения данных. Так называют ограничения реляционной базы данных, объявленные предметной областью и выявленные в ходе её анализа. Задача проектировщика БД - адекватно отобразить их в БД.

Самые распространенные ограничения предметной области - это ограничения на свойства объекта предметной области, далее атрибута отношения или поля таблицы:

- обязательность значения поля;

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

Такие ограничения могут быть заданы в командах создания и модификации таблиц - Create Table, Alter Table при описании поля таблицы.

Ниже рассмотрена реализация ограничений целостности БД на примере таблица "Status":

CREATE TABLE "Status"

(

idstatus integer NOT NULL,

statusname character varying(15) NOT NULL,

CONSTRAINT "PK_Справочник_статусов" PRIMARY KEY (idstatus)

)

WITH (

OIDS=FALSE

);

ALTER TABLE "Status" OWNER TO postgres;

Такие записи как NOT NULL, character varying(15) обеспечивают поддержку ограничений предметной области, запись PRIMARY KEY (idstatus)обеспечивают поддержку ограничений первичного ключа.

Реализация ограничений целостности БД аналогична для остальных таблиц.

2.3 Разработка программного средства автоматизации обслуживания заявок

Разработка велась согласно следующей модели жизненного цикла [23], представленной на рисунке 2.4.

Рисунок 2.4 - Поэтапная модель жизненного цикла

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

В ходе беседы с пользователями и сотрудниками ОИТ были определены следующие функции программы:

- подача и принятие заявок на обслуживание и установку компьютерной оргтехники;

- осуществление контроля над исполнением заявок;

- генерирование отчетов.

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

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

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

Создание диаграммы вариантов использования имеет следующие цели:

- определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

- сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

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

На диаграмме изображено два актера:

- администратор;

- пользователь.

Актеры между собой взаимодействуют с помощью четырёх вариантов использования:

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

- просмотреть свои заявки. Данный вариант использования позволяет пользователю просматривать свои заявки, поданные ранее;

- просмотреть текущие заявки. Этот вариант использования подразумевает просмотр имеющихся заявок администратором БД, при желании он может их удалять и менять их статус;

- подать новую заявку. Этот вариант использования позволяет пользователю подавать новые заявки;

Готовая диаграмма вариантов использования изображена на рисунке 2.5.

Рисунок 2.5 - Диаграмма вариантов использования

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

Поведение проектируемого программного средства описывается следующими состояниями. Авторизация/регистрация - состояние, которое в свою очередь делится на два состояния: ввод данных для регестрации и ввод данных для авторизации. При успешной авторизации возможны следующие состояния: для актера "администратор": просмотр данных о правах пользователей, подача новой заявки, просмотр текущих заявок; для актера "пользователь": подача новой заявки, просмотр текущих заявок.

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



Рисунок 2.6 - Диаграмма состояний

Приступая к этапу реализации программного средства, следует помнить, что оно является большой программной системой, поэтому целесообразно принять меры для его упрощения, разделив весь процесс на отдельные модули [26]. Такое разбиение позволит:

а) упростить их разработку и реализацию;

б) облегчить чтение программы;

в) упростить настройку и модификацию;

г) облегчить работу с данными, имеющими сложную структуру;

д) избежать чрезмерной детализации алгоритмов;

е) обеспечить более выгодное размещение программ в памяти ЭВМ.

Модуль -- фрагмент программного текста, являющийся строительным блоком для физической структуры системы. Как правило, модуль состоит из интерфейсной части и части-реализации [27].

Модульная структура разрабатываемого автоматизированного средства по обслуживанию заявок отображена на рисунке 2.7.

Рисунке 2.7 - Модульная структура автоматизированного средства

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

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

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

Модули доступа к таблицам БД выполняют соединение с базой данных и выборку полей из соответствующих таблиц.

Модуль добавления заявки в БД выполняет соединение с базой данных и обновление полей таблицы заявок.

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

Листинг данных модулей представлен в приложении Б.

На этапе тестирования было сделано следующее: на одном из компьютеров ОИТ был установлен сервер приложений Tomcat и развернута созданная база данных. Далее на этот же компьютер было установлено спроектированное программное средство. После чего пользователем была отправлена заявка на установку проектора (мультимедиа оборудование). Она прошла успешную обработку и в последующем удалена из БД. Необходимо отметить, что процесс обработки заявки в очереди проводился при 100% загрузке пользователями базы данных. Все испытания прошли успешно, недостатков и ошибок не было выявлено.

Во втором разделе проведена следующая работа:

- представлено обоснование выбора и описание инструментальных средств: языка программирования, СУБД, языка запросов;

- представлено описание принципов работы Java web-приложения;

- проанализирована архитектура АСУОД Tandem, функционирующая в Филиале;

- разработана БД проектируемого средства;

- разработано программное средство автоматизации обслуживания заявок пользователей ЛВС Филиала.

3. Технико-эксплуатационный раздел

3.1 Руководство для пользователей

Взаимодействие пользователя с программным средством осуществляется через веб-интерфейс. Для запуска необходимо указать в адресной строке обозревателя путь к программному средству (http://localhost:8080/request) После запуска приложения необходимо пройти авторизацию, либо зарегистрироваться для дальнейшей работы. На рисунке 3.1 представлена страница авторизации пользователя.

Рисунок 3.1 - Страница авторизации пользователя

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



Рисунок 3.2 - Страница регистрации пользователя

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

Рисунок 3.3 - Успешная регистрация

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

Рисунок 3.4 - Меню пользователя

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

Рисунок 3.5 - Меню выбора действия

Для внесения изменений в данные о правах пользователей необходимо перейти по ссылке "Пользователи" из меню пользователя, после чего откроется страница, изображенная на рисунке 3.6. При нажатии на ссылку "НЕТ" её значение изменяется на противоположное, что означает присвоение прав администратора данному пользователю. Так же изменяется значение типа пользователя в базе данных.

Рисунок 3.6 - Меню управления пользователями

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



Рисунок 3.7 - Меню выбора периода заявок

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

Рисунок 3.8 - Страница просмотра заявок на мультимедиа оборудование

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

Рисунок 3.9 - Страница ошибки

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

Рисунок 3.10 - Подача новой заявки

Каждому классу оборудования соответствует определенный тип оборудования. Они не должны пересекаться между собой. Для класса печатающие устройства:

- многофункциональное устройство (МФУ);

- принтер;

- плоттер.

Для класса компьютерное оборудование:

- персональный компьютер;

- монитор;

- клавиатура;

- компьютерная мышь;

- 3G модем;

- USB-флеш-накопитель;

- сервер;

- сетевой кабель;

- ноутбук.

Для класса мультимедиа-оборудования:

- проектор;

- веб-камера;

- устройства вывода звука (колонки).

3.2 Руководство для серверной части

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

Tomcat7 позволяет запускать веб-приложения, содержит ряд программ для самоконфигурирования. Он используется в качестве самостоятельного веб-сервера, в качестве сервера контента в сочетании с веб-сервером Apache HTTP Server, а также в качестве контейнера сервлетов в сервере приложений JBoss.

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

- CATALINA_HOME должна указывать на каталог с установленным Tomcat;

- JAVA_HOME должна указывать на каталог с SDK.

Эти переменные прописываются в свойствах системы в переменных среды как показано на рисунке 3.11.

Рисунок 3.11 - Окно настройки переменных среды

При неверной установке этих переменных Tomcat выводит сообщение об ошибке.

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

%CATALINA_HOME%\bin\tomcat.exe

-install Apache-Catalina %JAVA_HOME%\jre\bin\server\jvm.dll -DJava.class.path=%CATALINA_EOME%

\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar

-Dcatalina.home=%CATALINA_HOME% %CATALINA_OPTS% -Xrs

-start org.apache.catalina.scartup.BootstrapService -params start

-stop org.apache.catalina.startup.BootstrapService -params stop

-out %CATALINA_HOME%\logs\stdout.log

-err %CATALINA_HOME%\logs\stderr.log

Эта команда последовательно указывает:

- имя сервиса, которое будет отображаться в оснастке Services Windows. Имя сервиса используется также для создания имени ключа реестра, поэтому пробелов там быть не должно;

- ссылку на библиотеку Java-машины с рядом необходимых параметров. Среди которых параметры, указанные в переменной catalina_opts . Собственно эта библиотека и будет загружена как сервис;

- на методы запуска и остановки сервиса, также с необходимыми параметрами;

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

После чего сервер Tomcat появится в службах Windows как показано на рисунке 3.12. Через службы можно настроить его на автозапуск. Так же можно остановить, либо перезапустить сервер.

Рисунок 3.12 - Окно настройки служб Windows



3.3 Руководство администратора

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

Этапы установки сервера Tomcat:

- распаковать архив с дистрибутивом в каталог c:\Tomcat;

- загрузить актуальную версию java JDK;

- установить переменные окружения и выполнить настройку, как было писано в главе 3.2;

- удалить каталог c:\Tomcat\work;

- удалить содержимое каталога c:\Tomcat\webapps;

- поместить в каталог webapps файлы разработанного программного средства (каталог webapps на момент размещения должен быть пустым);

- запустить сервис Tomcat.

Далее в браузере необходимо набрать следующий адрес: http://localhost:8080/. В результате этого откроется страница начальной работы с сервером, изображённая на рисунке 3.13 Открытие этой страницы означает успешную установку и настройку сервера.

Рисунок 3.13 - Тестовая страница сервера приложений Tomcat



3.4 Руководство программиста

Разработанное программное средство состоит из 15 фрагментов: login.java, reg.java, DAOdemands.java, DAOusers.java, DAODevices.java, DAODeviceClasses.java, DAODeviceType.java, DAORoomTypes.java, DAORooms.java, AddDemand.java, AdmAccept.java, AdmUser.jsp, submitDemand.jsp, DAORequest.java, SelRequest.java.

Страница submitDemand.jsp содержит форму для оформления заявки; ссылку "Отправить заявку", ссылающуюся на сервелет AddDemand.java; ссылку на index.html

Страница index.html - содержит ссылки "Добавить заявку" на submitDemand.jsp и "Просмотреть заявки" на showRequest.html

Страница showRequest.html содержит ссылки на сервлеты: TodayRequest, TomorrowRequest, EndWeekRequest, WeekendRequest, TimeIntervalRequest и ссылку на index.html.

Обработка всех JAVA-сервлетов осуществляется сервером Tomcat, который является контейнером сервлетов. Все SQL-скрипты обрабатываются СУБД PostgreSQL.

Подготовка локальной вычислительной сети к работе заключается в проверке соединений командой ping. Конечный адрес 127.0.0.1. Окно ввода команды ping показано на рисунке 3.14.

В результате выполнения данной команды появится окно обмена пакетами с адресом 127.0.0.1. При правильной настройке ЛВС обмен пакетами закончится успешно.



Рисунок 3.14 - Проверка соединений командой ping

В третьем разделе проведена следующая работа:

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

- разработано руководство для серверной части проектируемого модуля. В нем описан метод настройки сервера Tomcat;

- разработано руководство администратора. В нем показаны процесс установки сервера Tomcat и тестирование его работы;

- разработано руководство программиста, в котором описаны фрагменты, ссылающиеся на другие компоненты спроектированного программного средства, и тем самым осуществляющие логическую связь. Так же показана подготовка ЛВС к работе средства.

4. Обоснование экономической эффективности проекта

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

4.1 Расчет трудоемкости разработки программного продукта

Расчет затрат времени на разработку программного обеспечения охватывает работы выполняемые специалистами на стадиях представленных в таблице 4.1 [28].

Таблица 4.1 -Стадии разработки программного обеспечения

Обозначение	Стадии разработки
ТЗ	Техническое задание
ЭП	Эскизный проект
ТП	Технический проект
РП	Рабочий проект
В	Стадия внедрения

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

- количество разновидностей форм входной информации;

- количество разновидностей форм выходной информации;

- степень новизны комплекса задач;

- сложность алгоритма;

- виды используемой информации;

- сложность контроля входной и выходной информации;

- использование типовых проектных решений.

Предусматривается четыре степени новизны разрабатываемых задач, которые представлены в таблице 4.2.

Таблица 4.2 - Степени новизны разрабатываемых задач

Обозначение	Степень новизны
А	Разработка комплекса задач, предусматривающая применение новых методов разработки, проведения научно-исследовательских работ
Б	Разработка решений задач и систем, не имеющих аналогов
В	Разработка решений задач и систем, имеющих аналогичное решение
Г	Привязка типовых проектных решений

Сложность алгоритма представлена тремя группами в таблице 4.3.

Таблица 4.3 - Группы сложности алгоритмов

Обозначение	Виды алгоритмов
С1	Алгоритмы оптимизации и моделирования систем и объектов
С2	Алгоритмы учета и отчетности, статистики, поиска
С3	Алгоритмы, реализующие стандартные методы решения, а также не предусматривающие применение сложных численных и логических методов

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

Таблица 4.4 - Виды используемой информации

Обозначение	Виды информации
ПИ	Переменная информация
НСИ	Нормативно-справочная информация
БД	Базы данных
РВ	Режим работы в реальном времени
ТОУ	Телекоммуникационная обработка данных и управление удаленными объектами

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



Таблица 4.5 - Группы сложностей организации контроля входной и выходной информации

Обозначение	Группа сложности
11	Входные данные и документы разнообразного формата и структур (контроль осуществляется перекрестно)
12	Входные данные и документы однообразной формы и содержания (осуществляется формальный контроль)
21	Печать документов сложной многоуровневой структуры, разнообразного содержания
22	Печать документов однообразной формы и содержания, вывод массивов данных на машинные носители

Далее в справочных таблицах 4.6-4.11 представлены затраты времени при выполнении различных работ на разных стадиях процесса разработки программного продукта.

Таблица 4.6 - Затраты времени при выполнении работ на стадии технического задания (дни)

Комплекс задач подсистемы	Степень новизны
	А	Б	В	Г
1	2	3	4	5
Перспективное планирование, размещение и развитие отрасли; управление проектируемым капитальным строительством; технико-экономическое планирование; ценообразование	79	57	37	34
Управление материально - техническим снабжением; сбытом продукции; управление комплектации импортными и экспортными поставками	105	76	42	30
Управление бухгалтерским учетом, финансовой деятельности предприятия	103	72	30	35
Управление организацией труда, зарплата, кадры, нормы и нормативы, охрана труда	63	46	30	19
Учет пенсий, пособий и страховых операций	79	55	36	26
Статистические задачи	129	111	61	38
Управление транспортными перевозками, техобслуживанием. Вспомогательными службами и электроснабжение	91	66	43	26
Управление научно - технической информацией. Совершенствование документооборота и контроль исполнения документа. Управление охраной природы и окружающей среды	50	36	24	15
Задачи расчетного характера	92	69	47	2
Управление качеством продукции, технологическими процессами производства, стандартизации, технической подготовкой производства	64	47	31	22

Таблица 4.7 - Затраты времени при выполнении работ на стадии эскизного проекта (дни)

Комплекс задач	Степени новизны
	А	Б	В	Г
Перспективное планирование, размещение и развитие отрасли; управление проектируемым капитальным строительством; технико-экономическое планирование; ценообразование	175	117	77	53
Управление материально - техническим снабжением; сбытом продукции; управление комплектации импортными и экспортными поставками	115	79	53	35
Управление бухгалтерским учетом, финансовой деятельности предприятия	166	112	67	57
Управление организацией труда, зарплата, кадры, нормы и нормативы, охрана труда	151	101	67	44
Управление качеством продукции, технологическими процессами производства, стандартизации, технической подготовкой производства	157	99	67	44
Управление транспортными перевозками, техобслуживанием. Вспомогательными службами и электроснабжение	170	100	70	45
Управление научно - технической информацией. Совершенствование документооборота и контроль исполнения документа. Управление охраной природы и окружающей среды	151	101	67	46
Учет пенсий, пособий и страховых операций	103	70	45	36
Статистические задачи	103	70	45	49
Задачи расчетного характера	103	70	45	41

Таблица 4.8 - Поправочные коэффициенты (К₁, К₂, К₃) для определения трудоемкости работ на стадии технического проекта

Вид используемой информации	Степень новизны
	А	Б	В	Г
ПИ, К1	1,7	1,2	1	0,5
НСИ, К2	1,45	1,08	0,72	0,43
БД, К3	4,37	3,12	2,08	1,25

Таблица 4.9 - Поправочные коэффициентами (К₁, К₂, К₃) определения трудоемкости работ на стадии рабочего проекта

Вид используемой информации	Группа сложности алгоритма	Степень новизны
		А	Б	В	Г
ПИ, К1	С1	2,27	1,62	1,2	0,65
	С2	2,02	1,44	1,1	0,58
	С3	1,68	1,2	1	0,48
НСИ, К2	С1	1,36	0,97	0,65	0,4
	С2	1,21	0,86	0,58	0,34
	С3	1,01	0,72	0,48	0,29
БД, К3	С1	1,14	0,81	0,54	0,32
	С2	1,05	0,72	0,48	0,29

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

Сложность контроля входной информации	Сложность контроля выходной информации
	21	22
11	1,16	1,07
12	1,08	1

Таблица 4.11 -Поправочные коэффициенты для определения трудоемкости работ на стадии технического и рабочего проектов, внедрения

Стадия разработки	Вид обрабатываемой информации	Степень новизны
		А	Б	В	Г
ТП	РВ	1,67	1,45	1,26	1,1
	ТОУ	1,75	1,52	1,36	1,15
РП	РВ	1,75	1,52	1,36	1,15
	ТОУ	1,92	1,67	1,44	1,25
В	РВ	1,6	1,39	1,21	1,05
	ТОУ	1,67	1,45	1,26	1,1

Общая трудоемкость разработки программного продукта рассчитывается по формуле

(4.1)

где - затраты труда на стадии технического задания (в днях);

- затраты труда на стадии эскизного проекта (в днях);

- затраты труда на стадии технического проекта(в днях);

- затраты труда на стадии рабочего проекта (в днях);

- затраты труда на стадии внедрения (в днях).

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

Общая трудоемкость разработки программного продукта с учетом поправочных коэффициентов рассчитывается по формуле

(4.2)

где - затраты труда на стадии технического проекта с учетом поправки;

- затраты труда на стадии рабочего проекта с учетом поправки;

- затраты труда на стадии внедрения с учетом поправки.

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

где m - количество наборов данных ПИ;

n - количество наборов данных НСИ;

p - количество наборов данных БД.

Для расчета затрат труда на стадии технического проекта с учетом поправки по формуле 4.1 и на основе справочной таблицы 4.8, рассчитаем поправочный коэффициент на использование разных видов информации Теперь с учетом поправки на использование различных видов информации и на основе справочной таблицы 4.11, вычислим затраты труда на стадии технического проекта с учетом поправки

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

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

Для расчета затрат труда на стадии внедрения используются поправочные коэффициенты из справочных таблиц 4.10 и 4.11

дней.

Таким образом, общие затраты труда на разработку программного продукта с учетом поправочных коэффициентов составят

дней.

4.2 Расчет себестоимости программного продукта