Модернизация информационной системы предприятия

метки: Информационный, Модернизация, Система, Рисунок, Подсистема, Delphi, Модель, Обследование

информационный windows экономический

Актуальность темы дипломного проекта обусловлена тем, что учет клиентов, заявок клиентов, количества совершенных ими сделок и суммы сделок в отделе продаж ЗАО «СтавГазСервис» до сих пор не автоматизирован и реализован в виде БД на бумажных носителях. Бланк документа «Счет — фактура» оформляется начальником отдела продаж в виде незаполненного документа Microsoft Word, который потом распечатывается на принтере и заполняется от руки

Ежемесячно, при составлении и анализе отчетов о результатах работы отдела продаж, начальник отдела продаж вынужден затрачивать порядка 50% своего рабочего времени, т. е. около 80 часов в месяц на ручную выборку данных из БД, реализованной на бумажных носителях.

Объектом исследования является ЗАО «СтавГазСервис», основным видом деятельности которого является производство и реализация АГРС и газораспределительных станций.

Предметом исследования является информационная система отдела продаж предприятия.

Целью данной работы является модернизация информационной системы предприятия.

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

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

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

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

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

Во втором разделе пояснительной записки рассмотрены вопросы реализации информационной подсистемы «Client», автоматизирующей решение задач, связанных с ведением БД клиентов и выписки счетов — фактур в отделе продаж ЗАО «СтавГазСервис», г. Ставрополь. При разработке БД этой информационной подсистемы использовалось CASE — средство ERwin 4.0, а само Windows — приложение было реализовано в среде Borland Delphi 7. Рассматриваются вопросы информационного и программного обеспечения разработки, а также обоснованы требования к техническому обеспечению, гарантирующие нормальную работу разработанной информационной подсистемы «Client». Приводятся результаты тестирования программного продукта.

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

... работы. Полную версию Вы можете получить в офисах Всероссийского Учебного Центра Elite Education или по электронной почте. 1.2. Информационные технологии в медицине ... 1. Автоматизация административной работы, заключающаяся чаще всего в автоматизации бухгалтерии, отдела статистики, отдела кадров, хозяйственного блока ... только при определенном и немало объеме продаж. И этот объем проще всего реализовать ...

В третьем разделе проведено технико — экономическое обоснование проекта. Рассчитаны показатели экономической эффективности его использования в условиях ЗАО «СтавГазСервис»

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

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

В заключении подведены основные итоги дипломного проектирования и намечены перспективные направления дальнейшего развития его темы.

В приложениях к пояснительной записке представлены: SQL — скрипт создания БД информационной подсистемы «Client» и листинги основных модулей проекта Delphi.

1. ДИАГНОСТИЧЕСКИЙ АНАЛИЗ ЗАО «СТАВГАЗСЕРВИС»

Результаты предпроектного обследования ЗАО «СтавГазСервис»

В рамках темы дипломного проекта объектами обследования являются:

• ЗАО «СтавГазСервис»;
• цели функционирования ЗАО «СтавГазСервис»;
• организационно—функциональная структура ЗАО «СтавГазСервис»;
• документооборот ЗАО «СтавГазСервис»;
• совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для работы с клиентами в ЗАО «СтавГазСервис»

Основными целями выполнения предпроектного обследования ЗАО «СтавГазСервис» являются:

• выявление основных параметров предметной области связанных с функционированием отдела продаж ЗАО «СтавГазСервис»;
• установление условий, в которых будет функционировать проект информационной подсистемы;
• обнаружение временных и стоимостных ограничений на процесс проектирования информационной подсистемы.

Характеристики всех методов при проведении обследования ЗАО

«СтавГазСервис» представлены в таблице 1.1. Характеристика этих методов сбора нужного материала для обследования, используемых в ходе преддипломной практики, представлена в таблице 1.2.

Таблица 1.1—Методы организации проведения обследования ЗАО «СтавГазСервис»

Классификации методов организации проведения обследования	Выбранный метод
По цели проектирования	Локальное обследование
По числу исполнителей	Индивидуальное обследование
По степени охвата объекта	Сплошное обследование
По отношению к этапам	Последовательное обследование

Таблица 1.2—Характеристика методов сбора материалов обследования ЗАО «СтавГазСервис»

Название методов сбора материалов обследования	Характеристика методов
Силами исполнителей	Метод анализа операций
По числу исполнителей	Личное наблюдение
По степени охвата объекта	Беседы и консультации с генеральным директором, заместителем генерального директора и начальником отдела продаж
По отношению к этапам	Опрос должностных лиц и персонала на рабочих местах

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

• степеньличного участия проектировщика информационной подсистемы в процессе сборе материала;
• трудовые, временные и стоимостные затраты на получение нужных сведений в ЗАО «СтавГазСервис»».

Программа обследования ЗАО «СтавГазСервис» представлена в таблице 1.3.

Таблица 1.3—Программа обследования ЗАО «СтавГазСервис»

Наименование вопроса		Получатель информации
Общие сведения о фирме	Генеральный директор	Проектировщик
Цели функционирования фирмы	Аналогично	Аналогично
Организационная структура фирмы	Аналогично	Аналогично
Особенности работы начальника отдела продаж	Аналогично	Аналогично
Наличие средств вычислительной техники и программного обеспечения	Аналогично	Аналогично
Порядок создания и хранения документов фирмы, используемых в документообороте при работе с клиентами в отделе продаж	Начальник отдела продаж	Аналогично
Характеристики существующей информационной системы, используемой в отделе продаж при работе с клиентами	Аналогично	Аналогично
Технологии, методы и технические средства преобразования информации при работе с клиентами в отделе продаж	Аналогично	Аналогично
Проблемные ситуации в работе информационной подсистемы отдела продаж фирмы	Аналогично	Аналогично

План—график выполнения работ на стадии сбора материалов обследования представлен в таблице 1.4.

Таблица 1.4—План — график выполнения работ на стадии сбора материалов обследования ЗАО «СтавГазСервис»

Наименование вопроса	Код работы	Исполнитель	Кол-во дней
Общие сведения о фирме	001	Проектировщик	4
Цели функционирования фирмы	002	Аналогично	4
Организационная структура фирмы	003	Аналогично	5
Функциональные области деятельности фирмы	004	Аналогично	10
Документооборот фирмы	005	Аналогично	11
Формы документов, используемых в документообороте фирмы при работе с клиентами в отделе продаж	006	Аналогично	15
Порядок создания и хранения документов фирмы, используемых в документообороте при работе с клиентами в отделе продаж	007	Аналогично	5
Штатный состав фирмы	008	Аналогично	10

Полное название фирмы на русском языке: Закрытое акционерное общество «СтавГазСервис». Сокращенное наименование ЗАО «СтавГазСервис» [1].

Реквизиты фирмы ЗАО «СтавГазСервис»:

• ИИН юридического 2635054274;
• расчетный счет: 40702810160270100968 в Северо — Кавказском банке Сбербанка РФ, г. Ставрополь;
• корреспондентский счет: 30101810100000000644;
• БИК 040707644;
• юридический адрес: 355000 г.

Ставрополь, пр. Кулакова, 26 Б; телефон/факс: (8652) 38 — 71 — 46, 38 — 71 — 18;

• адрес электронной почты: gazserv@statel.stavropol.ru.

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

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

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

Организационная структура Общества. Управление Обществом осуществляется в соответствии с его Уставом [1].

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

Общество имеет свою структуру управления и организационную структуру (рисунок 1.1).

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

Рисунок 1.1—Организационная структура Общества

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

Таблица 1.5—Области деятельности Общества и процессы, в них протекающие

Номер и название функциональной задачи	Номер и содержание функциональной подзадачи
1. Производство	1.1 Закупка материалов
	1.2 Доставка и отгрузка продукции
	1.3 Контроль производства
	1.4 Реализация готовой продукции
2. Обеспечение	2.1 Материально-техническое
	2.2 Кадровое
	2.3 Информационное
	2.4 Документационное
3. Управление	3.1 Управление кадрами
	3.2 Управление политикой цен
	3.3 Планирование деятельности Общества

Организационно—управленческая структура Общества. Организационно— управленческая структура Общества представляется в виде трех уровней управления: верхнего, среднего и низшего (рисунок 1.2).

Как видно из рисунка 1.2, верхнему уровню управления соответствует управленческая подсистема.

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

Рисунок 1.2—Структура системы управления Генеральный директор действует на принципе единоначалия и несет ответственность за последствия своих действий в соответствии с федеральными законами, иными нормативными правовыми актами Российской Федерации.

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

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

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

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

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

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

Развернутое представление целей деятельности Общества, средства и критериев их достижения представлены в таблице 1.6.

Схема дерева целей деятельности Общества представлена ниже на рисунке 1.3.

Таблица 1.6—Цели деятельности Общества, средства и критерии их достижения

Цель	Средства достижения	Критерий эффективности
Ц1—заполнение регионального рынка продукцией Общества	Ц11—реклама деятельности Общества на территории Ставропольского края и за его пределами Ц12—повышение качества обслуживания клиентов Ц13—гибкое ценообразование на продукцию Общества с учетом объема заказов (скидки, бонусы, призы)	Повышение уровня конкурентоспособности и существенное увеличение коммерческой прибыли
Ц2 ? создание новых производственн ых мощностей на территории Ставропольског о края	Ц21— аренда дополнительных помещений Ц22—приобретение технологического оборудования Ц23—проведение рекламных акций на местах предполагаемого открытия пунктов продаж продукции Общества	Существенное увеличение коммерческой прибыли
Ц3— расширение международных связей	Ц31—наработка устойчивых деловых связей с наиболее крупными компаниями в России, выпускающими аналогичную продукцию и имеющими	Существенное увеличение денежных оборотов и
	выход на мировой рынок; Ц32—создание с этими организациями холдингов на основе взаимовыгодного сотрудничества для работы с иностранными партнерами; Ц33— наращивание собственного капитала Общества в виде основных фондов и ценных бумаг; Ц34—мобильность в принятии решений и претворение их в жизнь.	коммерческой прибыли

Таблица 1.7— Организационно — управленческая модель фирмы

1. 1 Закупка материалов

1.2 Доставка и отгрузка продукции

1.3 Контроль производства

1.4 Реализация готовой продукции

2.1 Материально — техническое

2.2 Кадровое о

2.3 Информационное

2.4 Документационное

3.1 Управление кадрами

3.2 Политика цен

3.3 Планирование

Генеральный директор

Ў

Ў

Ў

Ў

Главный бухгалтер

?

¦ ¦

?

Технический директор

Ў

Ў

¦¦

Ў

Директор по производству

Ў

Ў

¦¦

Ў

Директор по реализации СУГ

Ў

Ў

Ў

Зам. директора по производству

Ў

¦¦

Бухгалтерия

?

Проектная группа

?

?

¦¦

Участок по обеспечению производства

¦¦

?

¦¦

?

?

Автотранспортный участок

¦¦

?

?

?

?

Отдел продаж

?

Ў ¦¦

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

В таблице 1.7 на пересечении столбцов и строк стоят символы, означающее следующее: ¦¦—основной участник процесса; ?—частичное участие в процессе; Ў —основная ответственность за выполнение процесса; пустая ячейка—безучастие в процессе или очень слабое, косвенное участие в процессе.

Рисунок 1.3—Дерево целей деятельности Общества

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

К указанному документообороту относятся документы, представленные в таблице 1.8.

Таблица 1.8—Перечень документов

Код документа	Название документа	Кто составляет документ	Кто использует документ	Периодичност ь составления документа
01	Бухгалтерский баланс	Главный бухгалтер	Руководство	Постоянно
02	Отчет о прибылях и убытках	Аналогично	Руководство	с 1 января по 31 декабря включительно
03	Налоговая декларация по налогу на прибыль	Аналогично	Налоговый орган	Ежемесячно
04	Расчет по налогу на имущество Общества	Аналогично	Налоговый орган	Аналогично
05	Налоговая декларация по страховым взносам на обязательное пенсионное страхование	Аналогично	Налоговый орган	Аналогично
06	Налоговая декларация по ЕСН	Аналогично	Налоговый орган	Аналогично
07	Счет — фактура	Начальник отдела продаж Главный бухгалтер	Бухгалтер, клиент, налоговая инспекция	Аналогично
08	Сводная ведомость реализации и приёма сырья	Главный бухгалтер	Руководство	Аналогично
09	Расчетный лист	Бухгалтер	Кассир	Ежемесячно
10	Табель рабочего времени	Бухгалтер	Главный бухгалтер	Аналогично
11	Ведомость перечислений в СБ РФ	Главный бухгалтер	Руководство	Аналогично
14	Приказ о предоставлении отпуска работнику	Руководство	Аналогично	Аналогично
15	Приказ о поощрении работника	Руководство	Аналогично	Аналогично

Схема документооборота Общества представлена на рисунке 1.4.

Рисунок 1.4—Схема документооборота Общества

Из средств вычислительной техники, которые можно использовать для автоматизации документооборота Общества, связанного с деятельностью отдела продаж, имеется: три персональных компьютера одинаковой комплектации класса; лазерный принтер. На всех компьютерах установлена операционная система Windows 7, офисное приложение Microsoft Office 2007 стандартной комплектации (Word, Excel, Access и др.) и другое специализированное программное обеспечение (файловые менеджеры, антивирусные программы и пр.).

Персональные компьютеры подключены через концентратор к локальной вычислительной сети Общества на основе сетевой технологии Ethernet (рисунок 1.4).

Рисунок 1.4—Структура локальной вычислительной сети отдела продаж

Анализ проблемных ситуаций и обоснование путей их решения

В работе информационной подсистемы, существующей в настоящее время в отделе продаж Общества, выявлены следующие проблемные ситуации:

• учет клиентов, количества совершенных ими сделок и суммы сделок до сих пор не автоматизирован и реализован в виде базы данных на бумажных носителях;
• бланк документа «Счет — фактура» оформляется начальником отдела продаж в виде незаполненного документа Microsoft Word, который потом распечатывается на принтере и заполняется от руки;
• ежемесячно, при составлении и анализе отчетов о результатах работы отдела продаж, начальник отдела продаж вынужден затрачивать порядка 50 % своего рабочего времени, т.

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

• отчет о результатах работы отдела продаж оформляется начальником отдела продаж в виде документа Microsoft Word.

— Анализ перечисленных проблемных ситуаций показывает, что для их разрешения необходимо разработать информационную подсистему, позволяющее автоматизировать ведения базы данных клиентов и выписки счетов — фактур. По требованию заказчика (генерального директора ЗАО «СтавГазСервис», г. Ставрополь) такую информационную подсистему необходимо реализовать в виде приложения Microsoft Windows.

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

Проведенное выше рассмотрение позволяет перейти к формулировке задач проектирования.

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

Полное наименование подсистемы—информационная подсистема «Client» для отдела продаж ЗАО «СтавГазСервис», г. Ставрополь.

Код системы—«Client».

Наименование Общества заказчика—ЗАО«СтавГазСервис»,г. Ставрополь.

Перечень документов, на основе которых создается система:

• отчет о преддипломной практике студента;
• форма счета — фактуры.

Порядок оформления и предъявления заказчику результатов работ по созданию системы—информационная подсистема «Client», реализованная в виде приложения Microsoft Windows в электронном формате на CD — ROM.

Назначение системы—автоматизация ведения БД клиентов и выписки счетов — фактур.

Цели создание системы:

• сокращение временных затрат начальник отдела продаж на ведения БД клиентов и выписки счетов — фактур;
• переход от БД учет клиентов, количества совершенных ими сделок и суммы сделок, реализованной в виде БД на бумажных носителях, к приложению Microsoft Windows.

Краткие сведения об объекте автоматизации—рабочее место начальника отдела продаж ЗАО «СтавГазСервис»

Условия эксплуатации—стандартные.

Характеристика окружающей среды—кабинет начальника отдела продаж ЗАО «СтавГазСервис»

Формулировка задач проектирования

Требования к системе в целом——-информационная подсистема «Client» должна автоматизировать решение задач, связанных с ведения БД клиентов и выписки счетов—фактур в отделе продаж ЗАО «СтавГазСервис».

Требования к функциям (задачам), выполняемым подсистемой:

1. Информационная подсистема «Client» должна обеспечить:

2. ведение базы данных клиентов;

3. ведение базы данных заказов клиентов;

4. ведение базы данных товаров;

5. автоматизированное формирование прайс — листа;

6. автоматизированное формирование счета—фактуры с представлением суммы к оплате прописью.

7. Информационная подсистема«Client» должна поддерживать формирование, просмотр и печать следующих четырех отчетов:

• список клиентов;
• сведенья о сумме счетов клиентов ЗАО «СтавГазСервис» за период времени;
• прайс — лист на товар;
• счет — фактура.

8. Информационная подсистема «Client» должна содержать справочники: товары, единицы измерения, данные о фирме, постоянный клиент и дисконт.

9. Информационная подсистема «Client» должна поддерживать специальные функции администрирования:

• ведение списка пользователей с указанием их прав доступа к ресурсам информационной подсистемы;
• смену пароля администратора и пользователя информационной подсистемы.

10.Информационная подсистема «Client» должна быть реализована в виде приложения Microsoft Windows.

Перечисленные выше требования, предъявляемые к информационной подсистеме «Client» со стороны заказчика, можно представить в виде следующей диаграммы вариантов использования [3, 4] (рисунок 1.5).

Рисунок 1.5—Диаграмма вариантов использования информационной подсистемы «Client»

Выводы

• В настоящее время приоритетными направлениями деятельности ЗАО «СтавГазСервис» являются производство, продажа и монтаж автоматизированных газораспределительных станций (АГРС) «Кавказ».
• В работе информационной подсистемы, существующей в настоящее время в отделе продаж Общества, выявлены следующие проблемные ситуации:
• учет клиентов, количества совершенных ими сделок и суммы сделок до сих пор не автоматизирован и реализован в виде базы данных на бумажных носителях;
• бланк документа «Счет — фактура» оформляется начальником отдела продаж в виде незаполненного документа Microsoft Word, который потом распечатывается на принтере и заполняется от руки;
• ежемесячно, при составлении и анализе отчетов о результатах работы отдела продаж, начальник отдела продаж вынужден затрачивать порядка 50 % своего рабочего времени, т.

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

• отчет о результатах работы отдела продаж оформляется начальником отдела продаж в виде документа Microsoft Word.

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

2. РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ «CLIENT» В ВИДЕ WINDOWS—ПРИЛОЖЕНИЯ

Методология разработки информационных систем, основанная на использовании средств быстрой разработки Windows — приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений—RAD (Rapid Application Development).

Эта методология охватывает все этапы жизненного цикла современных информационных систем и подсистем [3 ? 5].

Для разработки Windows — приложения «Client» была выбран инструмент Borland Delphi 7. Достоинствами этого инструменты RAD являются:

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

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

Создание логической модели БД информационной подсистемы «Client»

При создании логической модели БД информационной подсистемы «Client» будем использовать CASE — средство ERwin.

Шаг 1. Откроем CASE — средство ERwin. На экране увидим диалоговое окно (рисунок 2.1.).

ОК.

Рисунок 2.1 —начальное окно программы ERwin

Выберем «Create a new model» (см. рисунок 2.1) и надавим на кнопку

Шаг2.Запуститсядиалоговоеокнопрограммы(рисунок2.2).

Выберем тип модели Logical/Physical и сервер базы данных (БД) Paradox, выберем версию Paradox 7.x и нажмем кнопку ОК (см. рисунок 2.2).

Рисунок 2.2—Второе диалоговое окно программы ERwin

Шаг 3. Запустится окно программы ERwin (рисунок 2.3).

Сохраним данный проект с именем «Client».

Рисунок 2.3—Основное окно программы ERwin

Для построения логической модели данных найдем набор сущностей.

Выделим все восемь сущностей представленные на таблице 2.1.

Таблица 2.1—Перечень сущностей предметной области

Идентификатор сущности	Назначение сущности
CLIENT	Хранение информации о клиентах
CLIENTPATRONDISC OUNT	Хранение информации о критериях предоставления клиенту статуса «постоянного» и дисконта
DETAILORDER	Хранение информации о параметрах заказа клиента
FIRMA	Хранение информации о реквизитах учреждения
ORDERCLIENT	Хранение информации о заказах клиента
GOODS	Хранение информации о товарах
UNITMEASUREMENT	Хранение информации о единицах измерения товаров
USER	Хранение информации о пользователях

Для внесения указанных сущностей в логическую модель БД информационной подсистемы «Client» в ERwin выполним следующие шаги:

Шаг 1. Откроем проект, созданный до этого.

Шаг 2. Кликнем на инструмент «Entity», который находится на панели инструментов ERwin (рисунок 2.4), перенесем в область модели 7 сущностей, названных выше.

Рисунок 2.4—Инструмент «Entity» («Сущность»)

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

Рисунок 2.5—В область модели внесены восемь сущностей

После того как определены сущности, следующим шагом в разработке логической модели базы данных «Client» в ERwin, является определение атрибутов этих сущностей. Перечень указанных выше восьми сущностей, их атрибутов с характеристиками приведен в таблице 2.2

• символом обозначается первичный ключ сущности.
• символом FK обозначается внешний ключ сущности.

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

Более подробные сведенья о взаимосвязи зависимых (дочерних) и независимых (родительских) сущностях приведены в таблице 2.3.

Таблица 2.3—Данные о взаимосвязи сущностей базы данных

Зависимая сущность	Наследуемый (внешний)	Независи мая	Первичный ключ	Тип связи	Кра тно
	ключ	сущность	независимой сущности		сть свя зи
DETAILO RDER	ОrderID	ORDERC LIENT	ОrderID	неидентифи цирующая	1:N
	GoodsID	GOODS	GoodsID	неидентифи цирующая	1:N
ORDERC LIENT	ClientID	CLIENT	ClientID	неидентифи цирующая	1:N
SERVICE	UnitID	UNITME ASUREM ENT	UnitID	неидентифи цирующая	1:N

Из анализа таблицы 2.3 можно сделать следующие выводы:

1. Количество зависимых сущностей — три(DETAILORDER, ORDERCLIENT и GOODS).

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

3. Кратность связей в рассмотренных случаях составляет 1:N (один — ко — многим).

4. Количество неидентифицирующих связей между сущностями—три.

Использую данные таблицы 2.3, установим связи между сущностями логической модели БД информационной подсистемы «Client» в ERwin. Для установления связей будем использовать палитру инструментов ERwin, представленную на рисунке 2.6.

Рисунок 2.6—Палитра инструментов ERwin, используемая для установления связей между сущностями

В результате логическая модель БД информационной подсистемы

«Client» в ERwin примет вид, представленный на рисунке 2.7.

Рисунок 2.7—Логическая модель базы данных информационной подсистемы

«Client» после внесения связей между сущностями

При помощи редактора связей зададим параметры связей между перечисленными в таблице 2.2 сущностями (рисунок 2.8).

Рисунок 2.8 —Панель диалога редактора связей

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

Работая аналогичным образом, произведем ввод атрибутов и заданим первичные ключи для всех оставшихся сущностей модели БД «Client» в ERwin.

Рисунок 2.9—Выбор опции «Attributes…» контекстного меню сущности CLIENT

Рисунок 2.10—Диалоговое окно «Attributes»

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

Рисунок 2.11—Логическая модель БД информационной подсистемы «Client»

Вызов редактором колонок осуществим при помощи всплывающего меню, представленного на рисунке 2.12.

Рисунок 2.12—Меню вызова редакторов, которые относятся к таблицам После выполнения всех вышеперечисленных действия, физическая модель приобретет вид, представленный на рисунке 2.13.

Рисунок 2.13—Физическая модель БД информационной подсистемы «Client»

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

Физическая схема БД создается на основе логической схемы и набора установок, определяющих, какие элементы должны войти в схему базы данных. Эти установки зададим в диалоговом окне генератора схем (рисунок 2.14).

Рисунок 2.14—Диалог генератора физической схемы базы данных Откроем редактор фильтра таблиц и кликнем таблицы (сущности), которые должны войти в схему (рисунок 2.15).

Рисунок 2.15 —Диалоговое окно фильтра таблиц Выполним просмотр созданного SQL — сценария создания БД.

Диалог содержит типовое текстовое окно и типовой набор кнопок для просмотра, редактирования и печати текста или сценария (рисунок 2.16).

Рисунок 2.16—Окно предварительного просмотра сценария Полученный сценарий сохраним в файле. Для сохранение SQL —сценария в текстовом файле нажмем кнопку с пиктограммой (рисунок 2.16).

Текст файла сгенерированного SQL — сценария создания базы данных в ERwin приведен в приложении А.

Нажмем кнопку «Generate» (Генерировать) и вызовем в диалог генерации системного каталога базы данных.

Кнопка «Generate» запускает процесс генерации «физической» схемы базы данных. В диалоге связи с БД (рисунок 2.17) введем имя пользователя (login) и пароль (password).

В выпадающем списке «Database» выберем имя базы данных.

Рисунок 2.17—Диалог связи с базы данных

После окончания процесса генерации БД раскроем содержимое папки C:\CLIENT_Database (рисунок 2.18).

Как видно из рисунка 2.18, ERwin сгенерировал набор файлов БД информационной подсистемы «Client» характерный для типа таблиц Paradox.

Рисунок 2.18—Содержимое папки C:\CLIENT_Database с файлами базыданных информационной подсистемы «Client»

Запустим утилиту Database Desktop, изучим и, при необходимости, откорректируем структуру таблиц базы данных, сгенерированных ERwin (рисунки 2.18—2.25).

Рисунок 2.19—Схема таблицы CLIENT.DB

Рисунок 2.20—Схема таблицы CLIENTPATRONDISCOUNT.DB

Рисунок 2.21—Схема таблицы DETAILORDER.DB

Рисунок 2.22—Схема таблицы FIRMA.DB

Рисунок 2.23—Схема таблицы ORDERCLIENT.DB

Рисунок 2.24—Схема таблицы GOODS.DB

Рисунок 2.25—Схема таблицы UNITMEASUREMENT.DB

Рисунок 2.26—Схема таблицы USER.DB

После генерации базы данных наша работа в среде ERwin может считаться завершенной. Теперь появляется возможность перейти к реализации клиентской части информационной подсистемы «Client» в средстве RAD Borland Delphi 7.

Создание проекта и модулей Borland Delphi 7 для реализации информационной подсистемы «Client»

Как видно на рисунке 2.18, ERwin создал рабочий каталог проекта в директории C:\CLIENT_Database.

Откроем Delphi 7 стандартным способом [7].

После запуска Delphi 7 откроется диалоговое окно, которое на этапе разработки программы называется формой (рисунок 2.26).

Прежде чем создавать остальные модули проекта, определимся с их назначением и количеством. Для этого воспользуемся диаграммой вариантов использования информационной подсистемы «Client» (рисунок 1.6).

Рисунок 2.26—Конфигурация среды Delphi 7 после создания нового проекта

Проведенный анализ диаграммы вариантов использования информационной подсистемы «Client» позволяет сделать вывод о том, что проектируемое Windows — приложение должно содержать следующие 21 экранную форму (таблица 2.4).

Название формы	Назначение модуля
fmMain	Главная экранная форма программы, обеспечивающая доступ к основным функциям информационной подсистемы
fmCalculation	Счет, выставляемый клиенту клиента
fmClientArray	Список клиентов
fmClientInputEditU	Ввод и корректировка данных о клиенте
fmClientPatronDiscoun tU	Ввод и корректировка данных о критериях предоставления клиенту статуса «постоянного» и дисконта
fmClient	Картотека клиентов
fmFirma	Данные об учреждении
fmGoodsMainU	Справочник товаров
mGoodsMainU	Форма для ввода данных в справочник товаров
fmOrder	Заказ клиента
fmPasswordConfirmati onDlg	Смена пароля
fmPasswordDlg	Регистрация пользователя
fmPeriodOfTime	Период отчета
fmPriceList	Прайс-лист
fmReportU	Отчет о выполненных заказах клиентов за период времени
fmServiceMain	Услуги, предоставляемые клиентам
fmService	Ввод и корректировка данных об услугах
fmUnitMeasurementEd it	Ввод и корректировка данных о единицах измерения услуги
fmUnitMeasurement	Справочник единица измерения услуг
fmUserList	Список пользователей
fmUserListChange	Редактирование списка пользователей

Кроме всех форм, указанных в таблице 2.4 создадим:

• меню MainMenu1 для управления нашим приложением, когда пользователь обладает правами администратора;
• дополнительное меню MainMenu2 для управления приложением, когда пользователь не обладает правами администратора (имеет доступ только к выводу на печать и просмотру основных отчетов);
• форму fmAboutBox, которая будет отображать справку о приложении;
• модуль данных DM для инкапсуляции наборов данных приложения.

Реализация приложения

Перенесём на форму компонент TMainMenu и сохраним его с именем MainMenu1. С помощью Menu Designer образуем пункты и подпункты (подменю) главного меню, так как показано на рисунках 2.27—2.30.

Рисунок 2.27—Конфигурация меню «Клиенты»

Рисунок 2.28—Конфигурация меню «Справочники»

Рисунок 2.29—Конфигурация меню «Отчеты»

Рисунок 2.30—Конфигурация меню «Администрирование»

В инспекторе объектов укажем свойства пунктов главного меню

MainMenu1, так как это показано на рисунке 2.31.

Рисунок 2.31—Свойства пунктов в меню MainMenu1открытых в инспекторе объектов Delphi

Средствами MenuDesigner изменим содержание меню, как изображено на рисунках 2.32 и 2.33.

Рисунок 2.32—Конфигурация меню «Клиенты»

Рисунок 2.33—Конфигурация меню «Отчеты»

Как видно из рисунков 2.30—2.31, вспомогательное меню MainMenu2 не содержит пунктов, поддерживающих администрирования и ввода информации. Таким образом, цель создания вспомогательного меню достигнута.

В инспекторе объектов изменим заголовок главной формы fmMain: Caption:=Информационной подсистемы отдела продаж ЗАО» СтавГазСервис», г. Ставрополь.

Поместим на форму fmMain компонент TStatusBar и сохраним его под именем StatusBar1. В инспекторе объектов поместим в свойство Align этого объекта значение alBottom. При помощи редактора панелей компонента StatusBar1 создадим две панели.

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

В результате форма fmMain принимает вид, представленный на рисунке 2.36.

Рисунок 2.36—Конфигурация формы fmMain в дизайнере Delphi

В окне кода модуля fmMainU напишем следующий программный код обработчиков FormCreate, FormActivate и FormClose связанных с событиями OnCreate, OnActivate и OnClose главной формы fmMain (рисунки 2.37— 2.39).

Рисунок 2.37—Обработчик FormCreate события OnCreate формы

fmMain

Рисунок 2.38—Обработчик FormActivate события OnActivate формы

fmMain

Рисунок 2.39—Обработчик FormClose события OnClose формы fmMain

Обработчик FormActivate события OnActivate формы fmMain предназначен для отображения формы fmPasswordDlg предназначенной для регистрации пользователя и определения прав его доступа к ресурсам информационной подсистемы (рисунок 2.40).

Для дальнейшей реализации приложения необходимо создать псевдоним базы данных.

Рисунок 2.40—Форма fmPasswordDlg

С помощью команды Database >Explorer из среды Delphi запустим утилиту SQL Explorer, на вкладке Database открывшегося окна сделаем правый клик на узле Database и выберем команду New в контекстном меню. Утилита предложит выбрать тип вновь создаваемого псевдонима Standard, предполагаемым по умолчанию. Согласимся с этим предложением. Изменим имя STANDARD1 на CorporateDatabase. Теперь перейдем на вкладку Definition и в пустом поле справа от свойства PATH введем путь доступа к файлам базы данных, сгенерированных ERwin: C:\ CorporateDatabase (рисунок 2.41).

Рисунок 2.41—Окно утилиты SQL Explorer

Как видно на рисунке 2.41, понадобятся семь компонентов TTable и 7 компонентов TDataSource. Поместим их в отдельном модуле данных, для того чтобы эти компоненты не заграждали основное окно.

Для связи таблиц и базы данных используем компонент TDatabase на вкладке BDE палитры компонентов Delphi. Сохраним его с именем DB и изменим свойства этого объекта в инспекторе объектов, согласно показанному на рисунке 2.42.

Рисунок 2.42—Свойства объекта DB в инспекторе объектов Теперь перенесем в модуль данных восемь компонентов TTable и такое же количество компонентов TDataSource (рисунок 2.43).

Рисунок 2.43—Конфигурация модуля данных DM

Зададим свойства компонентов TTable в инспекторе объектов, как показано на рисунке 2.44.

Рисунок 2.44—Свойства компонентов TTable в инспекторе объектов

Как следует из логической модели данных информационной подсистемы «Client» (рисунок 2.11), наборы данных client.DB, orderclient.DB и detailorder.DB связаны отношением один ко многим. Чтобы наборы данных «знали» об этом и согласовано отображали данные их нужно предварительно подготовить. С этой целью перейдем на вкладку Diagram в окне кода модуля данных и с помощью мыши «перетащим» классическим способом Drag&Drop наборы данных client.DB, orderclient.DB и detailorder.DB из окна дерева объектов на вкладку Diagram (рисунок 2.45).

Рисунок 2.45— Вкладка Diagram в окне кода модуля данных

Как видно из рисунка 2.45 между наборами данных client.DB, orderclient.DB и detailorder.DB действительно существует связь один ко многим.

Создадим новую экранную форму и сохраним её под именем fmClient. Разместим на форме компонент TPanel и поместим в его свойство Name значение PanelControls, а в свойство Align значение alBottom. Эта панель для размещения на ней элементов управления: кнопок навигатора и командной кнопки «Закрыть».

Поместим на форму fmClientе четыре панели с именами PanelOrder, PanelShowAllClients, PanelClient и PanelClientControl.

В инспекторе объектов Delphi зададим их свойства компонентов TDBGrid как это показано на рисунке 2.46.

Рисунок 2.46—Свойства компонентов TDBGrid в инспекторе объектов Delphi

Поместим на форму fmClient элемент TMainMenu. Двойным левым кликом на компоненте MainMenu1 откроем Menu Designer. Средствами Menu Designer отредактируем содержание главного меню формы fmClient, как показано на рисунках 2.47—2.49.

Рисунок 2.47—Конфигурация меню «Сортировать» формы fmClient

Рисунок 2.48—Конфигурация меню «Заказы клиента» формы fmClient

Рисунок 2.49—Конфигурация меню «Товары» формы fmClient

После выполнения всех перечисленных действий Дерево Объектов формы fmClient принимает вид, представленный на рисунке 2.50.

Рисунок 2.50—Конфигурация Дерева Объектов формы fmClient

Конфигурация формы fmClient в окне формы Delphi показан на рисунке 2.519.

Рисунок 2.51—Конфигурация формы fmClient в окне формы Delphi

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

Кроме того, интерфейс формы fmClient при помощи набора вкладок с надписями А, Б, В и т. д., поддерживает прецедент ускоренного поиска клиента по первой букве в его фамилии.

Перед вызовом формы ввода данных о новом клиенте в таблицу CLIENT.DB добавляется новая запись, и в модальном режиме отображается fmClientInputEdit (рисунок 2.52).

Рисунок 2.52—Конфигурация формы fmClientInputEdit

Обработчики событий нажатия кнопок ChangeBitBtn (Изменить), DelBitBtn (Удалить) позволяют изменить и удалить записи о клиенте. Одновременно с удалением клиента из таблицы CLIENT.DB удаляются и связанные с ним записи в таблицах ORDERCLIENT.DB и DETAILORDER.DB.

Кнопка BitBtnCalculeteOrderAmount с надписью «Вычислить сумму к оплате» позволяет выполнить расчет значений полей OAmount (Сумма заказа) и OAmountInWords (Сумма заказа прописью) таблицы

ORDERCLIENT.DB.Фрагмент кода обработчика события нажатия на кнопку BitBtnCalculeteOrderAmount приведен на рисунке 2.53.

Рисунок 2.53—Фрагмент кода обработчика события нажатия на кнопку BitBtnCalculete Order Amount

Форма fmCalculation разрабатывалась в Delphi с использованием конструктора отчетов QuickReport. Конфигурация формы fmCalculation на этапе разработки в конструкторе QuickReport показан на рисунке 2.55.

Кроме отчета «СЧЕТ — ФАКТУРА», показанного на рисунке 2.54, информационная подсистема Client формирует еще три отчета:

• список клиентов;
• сведенья о сумме счетов клиентов ЗАО «СтавГазСервис» за период времени;
• прайс — лист на товар;
• Перечисленные отчеты разрабатывалась в Delphi с использованием конструктора отчетов QuickReport.

Конфигурация этих отчетов на этапе разработки в конструкторе QuickReport показан на рисунках 2.56—2.58.

Коды обработчиков событий выбора команд «Услуги за период времени», меню «Прайс — лист на услуги» и «Список клиентов» меню MainMenu1 формы fmMain приведен в листингах 2.3—2.5.

Рисунок 2.56—Конфигурация отчета «Сведенья о сумме счетов клиентов ЗАО «СтавГазСервис» за период времени» в конструкторе QuickReport

Рисунок 2.57—Конфигурация отчета «Прайс — лист на товары» в конструкторе QuickReport

Рисунок 2.58—Конфигурация отчета «Список клиентов» в конструктореQuickReport

Выбор команды «Сведенья о сумме счетов клиентов за период времени» меню MainMenu1 формы fmMain приводит к открытию в модальном режиме формы fmPeriodOfTime (рисунок 2.59).

Рисунок 2.59—Конфигурация формы fmPeriodOfTime

Форма fmPeriodOfTime позволяет пользователю задать начальную и конечную дату формирования отчета. Для этого на форме fmPeriodOfTime размещены два элемента типа TDateTimePicker (Календарь).

Код обработчика события нажатия на кнопку «OK» формы fmPeriodOfTime приведен в листинге 2.6.

Для формирования отчета «Услуги за период времени» используются два запроса DM.QueryPeriodOfTime и DM.QuerySumTotal. Тексты этих запросов на языке структурированных запросов SQL приведены на рисунках 2.60 и 2.61.

Рисунок 2.60—SQL — запрос DM.QueryPeriodOfTime

Рисунок 2.61—SQL — запрос DM.QuerySumTotal

Для формирования отчетов «Прайс — лист на товары» и «Список клиентов» использовались два SQL — запроса DM.QueryPriceList и DM.QueryClientArray. Тексты этих запросов на языке структурированных запросов SQL приведены на рисунках 2.62 и 2.63.

Рисунок 2.62—SQL — запрос DM.QueryPriceLis

Рисунок 2.63—SQL — запрос DM.QueryClientArray

Тестирование программы в условиях ЗАО «СтавГазСервис» г. Ставрополь показало, что она в полном объеме удовлетворяет требованиям заказчика. В настоящее время информационная подсистема «Client», уже внедрена в практику работы ЗАО «СтавГазСервис» г. Ставрополь, и находится в стадии опытной эксплуатации.

Для реализации в среде Borland Delphi 7 Windows — приложения, обеспечивающего требования технического задания на разработку информационной подсистема «Client», потребовалось создать 20 программных модулей.

База данных информационной подсистема «Client» является реляционной и содержит семь таблиц. При разработке этой БД было использовано CASE — средство ERwin 4.0.

При помощи программы InstallShield Express создан файл setup.exe, позволяющий инсталлировать информационную подсистему «Client» на компьютер пользователя. Размер файла setup.exe составляет 220 кбайт.

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

«Client»составляет 18,5 Мбайт. Эта папка включает в себя восемь вложенных папок и 104 файла. Размер исполнимого файла разработанного Windows — приложения составляет 1,60 Мбайт.

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

3. ТЕХНИКО—ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА

Постановка задачи, В дипломном проекте разрабатывается информационная

Назначение программы—автоматизация ведения БД клиентов и выписки счетов — фактур в отделе продаж ЗАО «СтавГазСервис», г. Ставрополь.

Цель создания системы—сокращение временных начальника отдела продаж на ведение БД клиентов и выписки счетов — фактур.

Данная программа выполняет следующие функции:

• ведение БД клиентов;
• ведение БД заказов клиентов;
• ведение БД товаров;
• автоматизированное формирование прайс — листа;
• автоматизированное формирование счета—фактуры с представлением суммы к оплате прописью.

Информационная подсистема «Client» должна поддерживать формирование, просмотр и печать следующих четырех отчетов:

• список клиентов;
• сведенья о сумме счетов клиентов ЗАО «СтавГазСервис» за период времени;
• прайс — лист на товар;
• счет — фактура.

Информационная подсистема «Client» должна содержать справочники: товары, единицы измерения, данные о фирме, постоянный клиент и дисконт.

Информационная подсистема «Client» должна поддерживать специальные функции администрирования:

• ведение списка пользователей с указанием их прав доступа к ресурсам информационной подсистемы;
• смену пароля администратора и пользователя информационной подсистемы.

При всем многообразии программного обеспечения для решения коммерческих задач, на рынке программных продуктов имеются программы, которые можно было бы непосредственно применить для решения задач ведения БД клиентов и выписки счетов — фактур в отделе продаж ЗАО «СтавГазСервис» Однако они не устраивают руководство фирмы, как по цене, так и по функциональным возможностям. Поэтому, создание информационной подсистемы «Client» носило узкий прикладной характер и, в связи с этим, потребовало учета ряда особенностей, обеспечивающих нестандартные свойства этого информационной подсистемы.

Внедрение проекта позволит в значительной мере сократить временные затраты начальника отдела продаж ЗАО «СтавГазСервис» на ведения БД клиентов и выписки счетов — фактур и последующее формирование необходимых отчетов о результатах деятельности отдела продаж.

При создаии информационной подсистемы использовался язык программирования Delphi.

Ориентировочный срок работы программы до морального износа 4

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

Программу разрабатывает инженер — программист первой категории ЗАО «СтавГазСервис» Число операторов программы ??? = 820 ед.

В этом разделе рассмотрены вопросы расчета:

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

Трудоемкость выполняемых работ

Создание программного продукта подразумевает создание всей программной документации и программ, предусмотренной техническим заданием.

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

Трудоемкость для разработки программного обеспечения ТПО, чел. — ч., определяется по формуле

ТПО = ТО + ТИ + ТА + ТП + ТОТЛ + ТД,(3.1)

где ТО -трудовые затраты на описание задачи, чел.-ч.;

• ТИ — затраты на обследование предметной области, чел.-ч.;
• ТД — затраты на подготовку документации, чел.-ч.

ТОТЛ — затраты на отладку, чел.-ч.;

• ТА — затраты на проектирования блок-схем, чел.-ч.;
• ТП — затраты на программирование, чел.-ч.;

• Все составляющие в правой части формулы (4.1) определим через общее число операторов D, ед.:

ТПО = ТО + ТИ + ТА + ТП + ТОТЛ + ТД,(3.1)

где ТО -трудовые затраты на описание задачи, чел.-ч.;

• ТИ — затраты на обследование предметной области, чел.-ч.;
• ТД — затраты на подготовку документации, чел.-ч.

ТОТЛ — затраты на отладку, чел.-ч.;

• ТА — затраты на проектирования блок-схем, чел.-ч.;
• ТП — затраты на программирование, чел.-ч.;

• Все составляющие в правой части формулы (4.1) определим через общее число операторов D, ед.:
• где б — число операторов, ед.

(б = 820 ед.); с ? коэффициент сложности задачи;

• р — коэффициент коррекции программы, учитывающий новизну проекта.

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

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

Для текущего программного обеспечения, которое включает в себя алгоритмы учета, результаты отчетности—степень сложности задач, в равной 1,75 (с = 1,75).

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

D = 820Ч1,75Ч(1 + 0,1) = 1578,50 ед.

Затраты труда на описание задачи принимаем: ТО = 40 чел. — ч . Работу по описанию задачи выполняет инженер — программист первой категории с окладом 7000 руб. в месяц и коэффициентом квалификации kК = 1,35 (опыт работы по специальности 6 лет).