Автоматизация деятельности фармацевтических компаний на примере ООО "Шексна-Фарма"

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

Для организации данных на компьютере клиента более всего подходит технология ADO (от англ. ActiveX Data Objects - «объекты данных ActiveX») - интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде. Технология ADO позволяет работать с базами данных Access, кроме того, поддержка компонентов ADO включена в Windows 2000/XP по умолчанию. (Что избавляет от установки дополнительного программного обеспечения, на подобие BDE).

Организация локальной базы данных для хранения и обработки информации на машине клиента.

После конвертации текстовых таблиц (файлов с именами вида ANY_NAME.TXT) в формат Access, возникает файл базы данных Access с именем Price.mdb, содержащий таблицы, имена которых совпадают с именами текстовых файлов (если отбросить расширение «.TXT»). Кроме этого, в файл Price.mdb добавляется таблица ORDERS.

Описание таблиц данных.

PRICEI - самая объемная таблица. Содержит информацию о товаре (собственно прайс). На данный момент насчитывает 28601 записей. Их количество склонно к увеличению.

Структура таблицы PRICEI представлена в табл. 4.2.

Таблица 4.2 Структура таблицы PRICEI

Имя поля	Тип и размер	Назначение
NOMER_I	INTEGER	Код позиции в прайсе, первичный ключ.
NAIM	VARCHAR(40)	Наименование товара
KOLVO	INTEGER	Количество на остатке
N_ISG	SMALLINT	Код изготовителя. Внешний ключ.
TMC	SMALLINT	Код группы ТМЦ. Внешний ключ.
STUP	VARCHAR(10)	Стандартная упаковка.
COUNTRY	VARCHAR(15)	Страна изготовителя.
GODEN	DATE	Срок годности.
SERIA	VARCHAR(15)	Серия товара.
IMPORT	VARCHAR(1)	Признак импортного товара.
REGN	VARCHAR(10)	Регистрационный номер.
SKLAD	SMALLINT	Код места размещения. Внешний ключ.
CNP	CURRENCY	Отпускная цена.
CENAGR	CURRENCY	Цена гос. реестра.
DTPOST	DATE	Дата прихода товара на склад.
NEW	VARCHAR(1)	Признак товара-новинки на фарм. рынке
CERT	VARCHAR(1)	Признак отсутств. сертификата на товар
ORD	INTEGER	Порядковый номер в прайсе.
TOVVID	VARCHAR(1)	Признак нетоварного вида упаковки.
PROVIDER	SMALLINT	Поставщик товара. Внешний ключ.

ISG - справочник изготовителей (см. табл. 4.3). Содержит только код и наименование изготовителей. На данный момент насчитывает 4374 записей.

Таблица 4.3 Структура таблицы ISG

Имя поля	Тип и размер	Назначение
NOMER	INTEGER	Код изготовителя. Первичный ключ.
NAIM	VARCHAR(30)	Наименование изготовителя.

TMC - справочник групп товарно-материальных ценностей (см. табл. 4.4). На данный момент содержит 23 записи.

Таблица 4.4 Структура таблицы TMC

Имя поля	Тип и размер	Назначение
NOMER	INTEGER	Код группы ТМЦ. Первичный ключ.
NAIM	VARCHAR(30)	Наименование группы.

SKLAD - справочник мест размещения (см. табл. 4.5). На данный момент содержит 21 запись.

Таблица 4.5 Структура таблицы SKLAD

Имя поля	Тип и размер	Назначение
NOMER	INTEGER	Код места размещения. Первичный ключ
NAIM	VARCHAR(30)	Наименование места размещения товара.

PROVIDERS - справочник поставщиков (см. табл. 4.6). На данный момент содержит 2 записи.

Таблица 4.6 Структура таблицы PROVIDERS

Имя поля	Тип и размер	Назначение
pID	INTEGER	Код поставщика. Первичный ключ.
pName	VARCHAR(30)	Наименование поставщика товара.

BRAK - Информация о забракованных препаратах (см. табл. 4.7). Количество записей постоянно меняется.

DEFECTUR - Информация о стойкой дефектуре - перечень товаров, отсутствующих на складе и у поставщиков (см. табл. 4.8). Количество записей постоянно меняется.

Таблица 4.7 Структура таблицы BRAK

Имя поля	Тип и размер	Назначение
NOMER	INTEGER	Код строки. Первичный ключ.
NAIM	VARCHAR(36)	Наименование забракованного товара.
DTBRAK	DATE	Дата забраковки.
N_ISG	SMALLINT	Код изготовителя. Внешний ключ.
SERIA	VARCHAR(15)	Серия
PISMO	VARCHAR(25)	Наименование и дата офиц. докмента.
REZULT	VARCHAR(15)	Решение компании о реализации.
COMMENT	VARCHAR(25)	Комментарий.

Таблица 4.8 Структура таблицы DEFECTUR

Имя поля	Тип и размер	Назначение
NOMER	INTEGER	Код позиции.
NAIM	VARCHAR(36)	Наименование товара.
N_ISG	SMALLINT	Код изготовителя. Внешний ключ.
DTDEF	DATE	Дата опубликования информации.
COMMENT	VARCHAR(80)	Комментарий

NEED - Прайс-лист товаров для хозяйственных нужд (табл. 4.9).

Таблица 4.9 Структура таблицы NEED

Имя поля	Тип и размер	Назначение
ID	INTEGER	Код позиции.
NAIM	VARCHAR(45)	Наименование товара.
COL	INTEGER	Количество на остатке.
KOLVO	INTEGER	Заказанное количество.
CENA	CURRENCY	Цена.

ORDERS - Таблица заказов (табл. 4.10).

Таблица 4.10 Структура таблицы ORDERS

Имя поля	Тип и размер	Назначение
NOMER_I	INTEGER	Код позиции в прайсе.
NAIM	VARCHAR(40)	Наименование товара.
KOLVO	INTEGER	Заказанное количество.
CLIENT	VARCHAR(15)	Пользователь, заказавший товар.

Схема взаимосвязи таблиц представлена на рис. 4.2.

Рисунок 4.2 Схема локальной базы данных

4.4 Организация многопользовательского режима

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

5. Реализация

Выбирая инструменты для разработки программного обеспечения необходимо учитывать условия, в которых ведется реализация данного проекта, и накопленный опыт сотрудников, участвующих в проекте. Временные и кадровые ограничения требуют того, чтобы выбираемая среда разработки предоставляла широкий перечень программных компонентов и других инструментов, тем самым максимально автоматизируя сам процесс создания программного продукта. Наиболее всего для этого подходит интегрированная среда разработки Borland Delphi 7.0 от компании Borland Software Corporation.

Интегрированная среда разработки (IDE - Integrated Development Environment) Delphi 7 представляет собой многооконную систему. Вид интегрированной среды разработки (пользовательский интерфейс) может различаться в зависимости от настроек. Пользовательский интерфейс среды служит для организации взаимодействия с программистом и включает в себя рад окон, содержащих различные элементы управления. С помощью средств интегрированной среды разработчику удобно проектировать интерфейсную часть приложения, а также писать программный код и связывать его с элементами управления. В интегрированной среде разработки проходят все этапы создания приложения, включая отладку.

Delphi относится к системам визуального программирования, называемым также системами RAD (Rapid Application Development - быстрая разработка приложений). Разработка приложения в Delphi включает два взаимосвязанных этапа:

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

- определение функциональности приложения.

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

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

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

Пользовательский интерфейс приложения составляют компоненты, которые разработчик выбирает в палитре компонентов и размещает в форме, т. е. компоненты являются своего рода строительными блоками. При конструировании интерфейса приложения действует принцип WYSIWYG (What You See Is What You Get - «что видите, то и получаете»), и разработчик при создании приложения видит форму почти такой же, как и при его выполнении.

Компоненты являются структурными единицами и делятся на визуальные (видимые) и невизуальные (системные). При этом понятия «видимый» и «невидимый» относятся только к этапу выполнения, на этапе проектирования видны все компоненты приложения.

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

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

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

- Выполнение до указанной инструкции;

- Пошаговое выполнение приложения;

- Выполнение до точки останова (Break point);

- Включение и выключение точек останова;

- Просмотр значений объектов, например, переменных в окне просмотра;

- Установка значений объектов во время выполнения приложения;

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

Интегрированная среда Delphi 7.0 для работы с сокетами предоставляет удобные инструменты - компоненты Indy (Internet Direct 9.0).

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

Например, для установления соединения производится вызов метода Connect(). После некоторого ожидания, если вызов был успешный, управление будет возвращено из метода, а при ошибке будет возбуждено исключение.

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

Разработчикам Indy удалось найти решение, устраняющее данную неприятность. В Indy имеется специальный компонент, который решает проблему замораживания пользовательского интерфейса. Название этого компонента говорит само за себя - TIdAntiFreeze, расположен он на вкладке Indy Misc. Этот компонент добавляется в проект в любом месте. TIdAntiFreeze работает по внутреннему таймеру вне стека вызовов и вызывает процедуру Application.ProcessMessages() по окончании таймаута, которая позволяет обработать системные сообщения. Внешние вызовы к Indy продолжают оставаться блокирующими и поэтому работают точно также как и без использования компонента TIdAntiFreeze. Использование TIdAntiFreeze позволяет получить все преимущества блокирующих сокетов без видимых недостатков.

Достоинства блокирующего режима:

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

Типичная сессия в Indy выглядит следующим образом:

with IndyClient do begin

Connect();

try

// Data Transfer

finally

Disconnect();

end;

end;

В то время, как с другими компонентами сессия будет выглядеть примерно так:

procedure TForm1.TestOnClick(Sender: TComponent);

begin

with SocketComponent do begin

Connect();

try

while Connected do begin

if IsError then Abort;

Application.ProcessMessages();

OutData:= 'Data To send';

while length(OutData) > 0 do begin

Application.ProcessMessages();

end;

end;

finally Disconnect();

end;

end;

end;

procedure TForm1.OnConnectError(...);

begin

IsError:= True;

end;

procedure TForm1.OnRead(...);

var

i: Integer;

begin

i:= SocketComponent.Receive(OutData);

OutData:= Copy(OutData, i + 1, MaxInt);

end;

2. Удобство и простота работы с потоками. С блокирующими сокетами почти всегда используются кодовые потоки.

Достоинства потоков:

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

- Инкапсуляция. Каждое соединение может содержать некоторое подобие интерфейса с другим соединением.

- Безопасность. Каждый поток может иметь различные атрибуты безопасности.

- Несколько процессоров. Дает преимущество на системах с несколькими процессорами.

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

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

Стоит упомянуть еще одно достоинство Indy:

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

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

Пул потоков в Indy доступен через компонент TIdThreadMgrPool.

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

5.1 Реализация протокола взаимодействия сервера и клиента

Первый шаг в построении сервера и клиента - это разработка протокола прикладного уровня. Протокол - это набор соглашений, который определяет обмен данных между различными программами. Для стандартных протоколов это определяется соответствующим RFC. В данном проекте требуется разработать протокол, который должен основываться на сервисах протоколов более низкого уровня в модели OSI, а именно протокола TCP стека TCP/IP.

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

После соединения, сервер посылает приветственное сообщение, затем принимает команду. Эта команда может быть любой текстовой строкой, например, “Quit”, которая заставляет сервер разорвать соединение. Сервер может принять несколько команд, прежде чем будет послана команда “Quit”.

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

Таблица 5.1 Протокол взаимодействия клиентского и серверного приложения

№	Функции	Формат команды
1	Закрытие соединения.	QUIT
2	Запрос прайса. Login #27 Password - Имя пользователя и пароль, разделенные непечатаемым символом ESC.	Zakaz.EXE_IDenTif_ + `LOGIN'#27`PASSWORD'
3	Отправка заказа.	Zakaz.EXE_IDentiFSendOrdX_ + `LOGIN'#27`PASSWORD'
4	Запрос накладных.	Zakaz.EXE_IDenTiFNeedBills_ + `LOGIN'#27`PASSWORD'
5	Отправка заявки на накладные.	Zakaz.EXE_IDenTiFOrderBills_ + `LOGIN'#27`PASSWORD'

Выполнение вышеперечисленных функций, кроме закрытия соединения, организовано в форме диалога между клиентом и сервером. Таким образом, четыре из перечисленных операций можно представить в виде коротких схем, изображенных на рисунках 5.1, 5.2, 5.3, 5.4.



Рисунок 5.1 - Запрос прайса

Рисунок 5.2 - Отправка заказа

Рисунок 5.3 - Запрос накладных



Рисунок 5.4 - Отправка заявки на накладные

5.2 Сервер заказов

Особенность работы серверных компонентов Indy.

Indy серверные компоненты создают слушающий поток, который изолирован от главного кодового потока программы. Слушающий поток прослушивает входящие запросы от клиентов. Для каждого клиента, которому отвечает, создается новый поток для обслуживания клиента. Соответствующие события затем обслуживаются в контексте данного потока. (Схема представлена на рис. 5.5)

Рисунок 5.5 - Использование потоков в сокетах Indy

Основная задача при программировании сервера заказов сводится к тщательной реализации метода Execute().

5.3 Клиентское приложение (Клиент)

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

Для этого можно воспользоваться Win32 API для создания Мьютекса - именованного объекта ядра Windows.

В самом начале программы происходит создание Мьютекса с определенным именем. Если во второй аргумент функции CreateMutex передать логическое значение True, то функция GetLastError() вернет код ошибки, равный ERROR_ALREADY_EXISTS, если мьютекс с таким именем уже создан кем-то другим (в данном случае другой копией приложения). В этом случае другими функциями Win32 API отыскивается уже существующее окно программы и производится попытка вывести его на передний план на рабочем столе, и после этого выполняется выход из программы.

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

В листинге 5.1 приведен отрывок кода, реализующий запуск одной копии приложения.

Листинг 5.1

var

hMutex: Cardinal;

hApp: HWND;

MutexName: String;

begin

SetLength(MutexName, 256);

GetShortPathName(PAnsiChar(ExtractFilePath(Application.ExeName)), PAnsiChar(MutexName), 256);

SetLength(MutexName, Pos(#0, MutexName) - 1);

MutexName:= StringReplace(MutexName, '\', '_', [rfReplaceAll]) + 'EZakaz_One_Copy';

hMutex:= CreateMutex(nil, True, PAnsiChar(MutexName));

if (GetLastError=ERROR_ALREADY_EXISTS) then begin

ReleaseMutex(hMutex);

CloseHandle(hMutex);

hApp:= FindWindow('TApplication', 'Шексна-Фарма (электронный заказ)');

ShowWindow(hApp, SW_RESTORE);

SetForegroundWindow(hApp);

halt;

end;

...

Application.Run;

end.

6. Тестирование

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

Цели тестирования:

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

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

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

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

6.1 Методика тестирования

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Но в данном проекте были использованы следующие виды:

Модульное тестирование (unit-testing) (По степени изолированности компонентов). Цель модульного тестирования -- изолировать отдельные части программы и показать, что по отдельности эти части работоспособны.

Тестирование белого ящика (white box) (По знанию системы). При тестировании белого ящика (англ. white-box testing, также говорят -- прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции -- работоспособны и устойчивы, до определённой степени.

Тестирование совместимости (compatibility testing) (По объекту тестирования)

Функциональное тестирование (functional testing) (По объекту тестирования). Проводится в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.

На этапе проектирования было проведено модульное тестирование, а на этапе реализации - функциональное тестирование. Модульное тестирование не выявило ошибок, поэтому подробнее остановимся на функциональном тестировании.

Использование средств тестирования:

– встроенный отладчик интегрированной среды разработки Delphi7:

– метод ручного тестирования - пошаговая отладка при обнаружении ошибки;

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

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

– Тщательная проверка руководства.

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

- Процессор Intel Pentium III 600 MHz;

- ОЗУ 256 Mb;

- НЖМД 40 Gb;

- Видеокарта 16Mb.

На рабочих станциях установлена ОС MS Windows XP.

Также было проведено тестирование на совместимость с более ранними и с современными версиями ОС Windows, а именно Windows 98SE и Windows Vista. По результатам тестирования было выявлено, что данный программный продукт совместим и с новой операционной системой, что позволит в дальнейшем перейти на новую платформу без внесения изменений в программный код.

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

Самая простая операция - скачивание прайса. Но для успешного скачивания необходимо, чтобы были выполнены настройки связи, т.е. выбран пользователь, задан IP-адрес сервера и порт в окне настроек (рис. 6.1).

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

После «отлавливания» и обработки этих ошибок, пользователь будет получать уже следующие сообщения (рис. 6.2, 6.3, 6.4):



Рисунок 6.1 - Окно настроек клиентской программы

Рисунок 6.2 - Сообщение об отсутствии выбранного клиента

Рисунок 6.3 - Подсказка о необходимости указания IP-адреса

Рисунок 6.4 - Подсказка о необходимости указания порта

6.2 Оценка показателей качества по результатам тестирования

Программное обеспечение может быть оценено следующими характеристиками:

1. Надежность системы оценивается с помощью следующих критериев:

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

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

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

2. Практичность программы оценивается с помощью следующих критериев:

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

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

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

3. Эффективность программы оценивается с помощью следующих критериев:

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

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

4. Сопровождаемость программы оценивается с помощью следующих критериев:

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

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

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

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

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

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

- Простота внедрения - атрибут программного обеспечения, относящийся к усилиям, необходимым для внедрения программного обеспечения в конкретное окружение. Для компьютера необходима операционная система: MS Windows XP/7. Для установки клиентской программы создан инсталляционный пакет. Оценка простоты внедрения - 10 баллов.

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

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

7. Внедрение

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

7.1 Установка программного обеспечения на рабочие места

Разработанная программа изначально была предназначена для установки в аптеки и аптечные пункты торговой сети. Так как не все ошибки могут быть выявлены в процессе тестирования на этапе реализации, целесообразно внедрение начинать постепенно. Поэтому было принято решение вначале испытать программу на одной из аптек - Аптека «Шексна-Фарма», ул. Ильюшина. Эта аптека была выбрана ввиду того, что она располагается ближе всего к офису, что позволяет максимально оперативно решать проблемы, возникающие на этапе внедрения.

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

Текст скрипта приводится в приложении А

При запуске данный скрипт создает файл Setup.exe, который при установке дает возможность пользователю выбрать язык установки (русский или английский), показывает приветственную страницу, требует ознакомиться с лицензией на установку и использование, предлагает выбрать директорию для установки, отображает процесс установки, после установки открывает скопированный файл ReadMe.txt, содержащий инструкции по настройке.

Собственно инсталлятор Setup.exe выполняет следующие действия:

1. Записывает в реестр Windows информацию о директории предыдущей установки (строковый параметр ZakazPath, ключ HKLM\Software\Zakaz)

2. Удаляет в данной директории файл Zakaz.exe и шаблон отчета Order.rav старой версии (если такие есть).

3. Из собственных ресурсов копирует файлы: Zakaz.exe, Unrar.dll, Order.rav, ReaMe,txt. Если инсталлятор не находит файл настроек Sttngs.ini, то он устанавливает также и его с начальными стандартными настройками.

4. Последний этап - создание ярлычка на рабочем столе с именем «Заказ Шексна-Фарма».

7.2 Обучение персонала

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

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

Пользователи были также снабжены краткой памяткой-инструкцией.

7.3 Внесение изменений и дополнений

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

После этого, программа с учетом доработок и пожеланий персонала аптеки «Шексна-Фарма» на ул. Ильюшина была установлена в остальных аптеках и аптечных пунктах торговой сети.

В целом программа выполняет работу в соответствии с требуемыми условиями. С учетом внесенных исправлений по заключению специалистов ООО «Шексна-Фарма» программное обеспечение готово к эксплуатации в производственных условиях и в настоящее время используется в работе аптек и аптечных пунктов.

Основные характеристики клиентской программы приведены в таб. 7.1.

Таблица 7.1 Основные характеристика клиентской программы

Характеристика	Ед. изм.	Значение
Размер исполняемого файла программы	Мб	2,62
Количество места, занимаемого локальной БД на НЖМД на момент внедрения	Мб	6,17
Объем оперативной памяти, занимаемый программой	Мб	48,8

8. Технико-экономическое обоснование проекта

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

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

Для расчета показателя экономической эффективности воспользуемся формулой 8.1:

(8.1)

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

8.1 Расчет выгоды в результате внедрения проекта

Заказы, присылаемые от удаленных компьютеров, состоят из разного количества выбранных позиций. Заказ, содержащий большее количество заказанных позиций, будет оформляться дольше, поэтому нельзя ориентироваться исключительно на количество заказов. Соответственно необходимо вычислить среднее время, затрачиваемое на нахождение и выбор одной позиции из прайса оператором, т.е. «вручную» (t_ср.). Далее необходимо вычислить среднее количество позиций, содержащихся в заказах, поступающих в рабочий день (N). Перемножая эти показатели, можно вычислить количество человеко-часов в рабочий день. Если это количество разделить на 8 - продолжительность нормального рабочего дня в часах при сорокачасовой рабочей неделе, можно получить количество человек (P), необходимых для поддержания бизнес-процессов при отказе от использования предлагаемого программного продукта.

Таким образом, количество человек, которые выполнят работу, эквивалентную работе данного программного продукта, будет рассчитываться по формуле 8.2:

,(8.2)

где N - среднее количество позиций в день;

t_ср. - время в секундах выборки одной позиции;

28800 - количество секунд в 8 часах.

Для вычисления t_ср. были собраны следующие статистические данные:

При выборе позиций вручную в существующей системе фиксировалась дата и время, в результате чего накопилась таблица с данными TIMSET.DBF, которая состоит из 66053 записей. Эта таблица с данными содержит поля с номером накладной (NNAKL), кодом покупателя (NP), кодом пользователя (USERID), датой выбора позиции (DTOTGR), временем выбора позиции (CTIM). С каждой накладной всегда работает только один пользователь, таким образом можно сформировать SQL запрос, который сгруппирует записи и с помощью агрегирующих функций выдаст время занесения первой позиции (MIN(CTIM)), время занесения последней позиции (MAX (CTIM)) и количество позиций (COUNT(*)) для каждой накладной. С помощью вычисляемого поля можно представить продолжительность ручного оформления накладной, которая равняется разнице между временем занесения первой и последней позиции. В связи с этим накладные, состоящие только из одной позиции необходимо отбросить, так как в этом случае разница будет равна 0. Если этого не сделать, то результат подсчета не будет объективным.

Так как Local SQL BDE не поддерживает выполнение запросов вида SELECT … FROM SELECT…, необходимо выполнить 2 запроса с формированием промежуточной таблицы данных.

Первая SQL-инструкция будет выглядеть следующим образом:

SELECT NNAKL, NP, USERID, DTOTGR, MAX(CTIM) AS MAXCTIM, MIN(CTIM) AS MINCTIM, CAST((CAST(MAX(CTIM) AS TIME) - CAST(MIN(CTIM) AS TIME)) / (CAST('00:00:01' AS TIME) - CAST('00:00:00' AS TIME)) AS INTEGER) AS LGTH, COUNT(*) AS CNT FROM TIMSET GROUP BY NNAKL, DTOTGR, USERID, NP HAVING COUNT(*) > 1

Результатом этого запроса будет промежуточная таблица (TIMDATA1), содержащая сгруппированные данные по каждой накладной. Поля таблицы содержат следующую информацию: номер накладной (NNAKL), Код покупателя (NP), код пользователя (USERID), дата выписки накладной (DTOTGR), время занесения последней позиции (MAXCTIM), время занесения первой позиции (MINCTIM), продолжительность ручного оформления накладной в секундах (LGTH), количество позиций в накладной (CNT).

Для проведения такого исследования в среде Delphi 7 было создано приложение, в котором были использованы компоненты для работы с таблицами DBase посредством BDE (Borland Database Engine).

Вид единственного окна приложения представлен на рисунке 8.1.

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

Вторая SQL-инструкция будет выглядеть следующим образом:

SELECT CAST(SUM(LGTH) AS INTEGER) AS TOTAL_LGTH, CAST(SUM(CNT - 1) AS INTEGER) AS TOTAL_POS, SUM(LGTH) / SUM(CNT - 1) AS AVG_TIME FROM TIMDATA1

Рисунок 8.1 - Формирование промежуточной таблицы данных

Результатом второго запроса будет конечная таблица (TIMDATA2), содержащая единственную запись. (Рис. 8.2). Таблица включает в себя три поля: TOTAL_LGTH - показывает общее количество времени в секундах, затраченное на ручную выборку всех анализируемых позиций; TOTAL_POS - количество всех анализируемых позиций; AVG_TIME - среднее время в секундах, которое затрачивается на поиск одной позиции в прайсе (t_ср). Оно получается в результате деления TOTAL_LGTH / TOTAL_POS и составляет 23,836 с.

Для подсчета среднего количества позиций, содержащихся в заказах, поступающих в рабочий день (N), лучше всего брать календарный период, кратный месяцу. В данном проекте представлен отчет за май 2014г. (Этого должно быть достаточно). Заказы представляют собой файлы с расширением DBF, содержащие записи - собственно, выбранные позиции. Если посчитать общее количество всех заказанных позиций (K) и поделить его на количество рабочих дней D (согласно производственному календарю на 2014 в мае 19 рабочих дней, т.е. D = 19), то в результате будет получена требуемая характеристика N.

Рисунок 8.2 - Конечный результат анализа статистических данных

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

По окончании выполнения программы (Рис 8.3), были получены следующие результаты: общее количество анализируемых файлов - 5741; общее количество выбранных позиций (K) - 278528.

- заказанных позиций в рабочий день в среднем.

Таким образом,

человек.

Это означает, что производительность разрабатываемого программного продукта компенсирует труд 12-ти человек с оплатой полной ставки (при сорокачасовой рабочей неделе) вместе с одним человеком, работающим на ј ставки - минимальная возможная нагрузка, предусмотренная на предприятии.

Рисунок 8.3 - Подсчет количества заказанных позиций за один месяц

При минимальном размере ставки, который составляет 16000 рублей в месяц для должности с данной квалификацией, общая экономия средств составит: 16000 · 12,25 = 196000 рублей в месяц.

Соответственно годовая экономия составит 2352000 рублей.

8.2 Расчет затрат на выполнение проекта

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

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

8.2.1 Расчет стоимости материалов и комплектующих

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

Таблица 8.1 Расчет стоимости материалов и комплектующих

Наименование	Марка, тип	Ед. изм.	Потреб. кол-во	Цена за ед., руб	Ст-ть, руб
Материалы
Интернет	ADSL	Mb	100	1,70	170
Учебник Delphi 7	Учебник	шт.	1	395	395
Комплектующие
Бумага	Xerox A4	пач.	1	139	139
Картридж для принтера Canon LBP-2900	CP-703	шт.	1	1590	1590
CD-RW диски	TDK	шт.	5	25	125
Итого Зм					2419

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

8.2.2 Определение трудозатрат

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

Таблица 8.2 Перечень этапов и работ по проектированию программного продукта

Этапы работ	Содержание этапа
1. Техническое задание	1.1. Анализ имеющихся решений в данной области. 1.2. Согласование и утверждение ТЗ
2. Эскизный проект	Разработка общей архитектура системы
3. Технический проект	3.1. Проектирование алгоритмов для модулей ПО 3.2. Проектирование базы данных 3.3. Проектирование пользовательского интерфейса
4. Рабочий проект	4.1. Разработка модулей ПО
5. Тестирование и отладка	5.1. Тестирование разработчиком; 5.2. Тестирование руководителем; 5.3. Обработка результатов, выявление недочётов разработчиком и руководителем; 5.4. Контрольное тестирование;
6. Заключительный этап	6.1. Составление технической документации 6.2. Составление пользовательской документации 6.3. Оформление и утверждение результатов работ 6.4. Внедрение в эксплуатацию

8.2.3 Организационный план работ

Организация работ по проведению разработки в данном дипломном проекте основывается на последовательно-параллельном выполнении этапов и работ. В этом случае цикл исследования или разработки будет определяться по формуле 8.3:

^,(8.3)

где n - число этапов;

К_пар - средний коэффициент параллельности выполнения стадии;

t_i - трудоемкость стадии, чел-дн;

ч_i - численность людей, одновременно выполняющих данную стадию (ч_i=2 чел).

Рассчитаем Т_{посл-пар} для каждого этапа отдельно, а затем просуммируем результаты и получим время цикла разработки Т_цик.

Расчет цикла разработки приведен в таблице 8.3.

Таблица 8.3 Расчет цикла разработки

Этапы работ	Тпосл-пар
1. Техническое задание	11
2. Эскизный проект	28
3. Технический проект	35
4. Рабочий проект	42
5. Тестирование и отладка	15
6. Заключительный этап	16
Тцик,дн	147

Время цикла разработки Т_цик = 147 дней.

8.2.4 Оценка трудоемкости работ

Для определения трудоемкости разработки используются типовые нормы времени по программированию задач для ЭВМ. Нормы времени рассчитаны на комплексы задач и указаны в человеко-днях, человеко-часах или нормо-часах при пятидневной рабочей неделе с продолжительностью рабочего дня 8 час.

Расчет трудоемкости исследования или разработки производится по формуле 8.4:

,(8.4)

где t_i - трудоемкость работ по стадиям (этапам) разработки, чел-дн.;

n - количество работ (стадий, этапов) проектирования.

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

Определим максимальное и минимальное время, которое необходимо для разработки каждого пункта. Исходя из этих значений, определим ожидаемое время. Ожидаемое время определяется по формуле 8.5:

, (8.5)

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

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

Оценка трудоемкости работ и этапов представлена в таблице 8.4.

Таблица 8.4 Состав и трудоемкость работ

Этапы работ	Tmin чел -дн	tmax, чел-дн	Тож, чел-дн
1. Техническое задание	8	14	11
2. Эскизный проект	23	35	28
3. Технический проект	32	39	35
4. Рабочий проект	36	51	42
5. Тестирование и отладка	13	17	15
6. Заключительный этап	15	17	16
Итого	127	173	147

Фонд времени работы каждого участника определяется путем распределения работ между исполнителями на каждом этапе (см. таблицу 8.5).

Таблица 8.5 Списочный состав и фонды времени исполнителей

Этапы работ	Трудоемкость, чел-дн	Исполнители	Доля участия, %	Фонд времени, дн.
1. Техническое задание	11	Руководитель	36	4
		Инженер	64	7
2. Эскизный проект	28	Руководитель	18	5
		Инженер	82	23
3. Технический проект	35	Руководитель	26	9
		Инженер	74	26
4. Рабочий проект	42	Руководитель	12	5
		Инженер	88	37
5. Тестирование и отладка	15	Руководитель	27	4
		Инженер	73	11
6. Заключительный этап	16	Руководитель	25	4
		Инженер	75	12
Итого	147

Ленточный график работ представлен в приложении Б.

8.2.5 Расчет численности исполнителей работ

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

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

Состав и фонды времени исполнителей указаны в таблице 8.5.

Примерные обязанности и функции исполнителей в проектировании:

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

2. Дипломник: Проектирует, программирует, тестирует все модули. Описывает в документации информацию по ним.

8.2.6 Расчет оплаты труда персонала

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

Среднедневная оплата труда каждого участника рассчитывается по формуле:

,(8.6)

где З_мес - среднемесячная оплата труда, руб;

Ф - среднемесячный плановый фонд времени одного работника, дни.

Расчет оплаты труда приведен в таблице 8.6.

Таблица 8.6 Расчёт оплаты труда

Этапы работ	Трудоемкость, чел-дн	Исполнители	Доля участия, %	Фонд времени, дн.	Среднедневная оплата труда, руб.	Фонд платы труда, руб.
1. Техническое задание	11	Руководитель	36	4	1500	6000
		Инженер	64	7	900	6300
2. Эскизный проект	28	Руководитель	18	5	1500	7500
		Инженер	82	23	900	20700
3. Технический проект	35	Руководитель	26	9	1500	13500
		Инженер	74	26	900	23400
		Инженер	88	37	900	33300
4. Рабочий проект	42	Руководитель	12	5	1500	7500
		Инженер	88	37	900	33300
5. Тестирование и отладка	15	Руководитель	27	4	1500	6000
		Инженер	73	11	900	9900
6. Заключительный этап	16	Руководитель	25	4	1500	6000
		Инженер	75	12	900	10800
Итого З						150900

8.2.7 Расчет отчислений на социальные нужды