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

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

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

Объектно-ориентированный анализ и проектирование

Основная идея объектно-ориентированного анализа и проектирования состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий и сущностей). В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов в терминах предметной области. В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы. В процессе конструирования или объектно-ориентированного программирования обеспечивается реализация разработанных компонентов и классов.

Наиболее важным моментом объектно-ориентированного анализа и проектирования является квалифицированное распределение обязанностей между компонентами программной системы [2]. Обязанности объектов и их взаимодействия изображаются с использованием диаграмм классов и диаграмм взаимодействий. Диаграмма классов и их взаимодействия в составе ПС показана на рисунке 3.1.



Рисунок 3.1 - Диаграмма классов и их взаимодействия в составе ПС

Принципы модульного программирования

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

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

- хороший модуль снаружи проще, чем внутри;

- хороший модуль проще использовать, чем построить.

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

- размер модуля;

- прочность модуля;

- сцепление с другими модулями;

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

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

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

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

- выбор алгоритма и структуры данных;

- программирование (кодирование) модуля;

- шлифовка текста модуля;

- проверка модуля;

- компиляция модуля.

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

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

По определению Г. Майерса, модульность - свойство ПО, обеспечивающее интеллектуальную возможность создания сколь угодно сложной программы. Соотношение - это обоснование модульности. Оно приводит к заключению «разделяй и властвуй» - сложную проблему легче решить, разделив ее на управляемые части. Результат, выраженный неравенством, имеет важное значение для модульности и ПО. Фактически, это аргумент в пользу модульности.

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

Инструментальная среда

При разработке программных средств используется в той или иной мере компьютерная поддержка процессов разработки и сопровождения ПС [7]. Это достигается путем представления программных документов ПС на компьютерных носителях данных и предоставления в распоряжение разработчика ПС специальных ПС или включенных в состав компьютера специальных устройств, созданных для обработки таких документов. Компьютерная поддержка процессов разработки и сопровождения ПС производится не только за счет использования отдельных инструментов, но и за счет использования логически связанной совокупности программных и аппаратных инструментов. Такую совокупность называют инструментальной средой разработки и сопровождения ПС.

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

Исходя из технического задания, в качестве инструментальной среды программирования в дипломном проекте выбраны инструменты, предоставляемые фирмой Borland для создания Win32 приложений под ОС Windows, позволяющие компилировать, транслировать, тестировать и отлаживать программы на языке программирования Delphi [2, 15]. Данная среда является языково-ориентированной. Вследствие этого используются мощные возможности, учитывающие специфику данного языка. Ещё одной особенностью инструментальной среды является синтаксическая управляемость, при этом она базируется на знании синтаксиса языка программирования. В такой среде вместо текстового используется синтаксически-управляемый редактор, позволяющий пользователю использовать различные шаблоны синтаксических конструкций (в результате этого разрабатываемая программа всегда будет синтаксически правильной). Одновременно с программой такой редактор формирует (в памяти компьютера) ее синтаксическое дерево, которое может использоваться другими инструментами.

Жизненный цикл программного средства

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

В настоящее время можно выделить 5 основных подходов к организации процесса создания и использования ПС: [2]

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

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

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

4. Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их в программы путем корректных преобразований. На этом подходе базируется компьютерная технология (CASE-технология) разработки ПС.

5. Сборочное программирование. Этот подход предполагает, что ПС конструируется, главным образом, из компонент, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может многократно использоваться в разных ПС. Такие компоненты называются повторно используемыми (reusable). Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования.

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

Жизненный цикл ПС изображён на рисунке 3.2 и содержит в себе: разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС.

Рисунок 3.2 - Стадии и фазы жизненного цикла ПС

Стадия разработки ПС состоит из этапа его внешнего описания, этапа конструирования ПС, этапа кодирования (программирование в узком смысле) ПС и этапа аттестации ПС. Всем этим этапам сопутствуют процессы документирования и управления ПС.

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

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

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

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

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

3.1.5 Обеспечение надежности программного средства

Известны четыре подхода к обеспечению надежности [8]:

1. предупреждение ошибок;

2. самообнаружение ошибок;

3. самоисправление ошибок;

4. обеспечение устойчивости к ошибкам.

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

1. борьба со сложностью;

2. обеспечение точности перевода;

3. преодоление барьера между пользователем и разработчиком;

4. обеспечение контроля принимаемых решений.

В процессе разработки применяются два общих метода борьбы со сложностью систем:

1. обеспечения независимости компонент системы;

2. использование в системах иерархических структур.

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

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

Контроль принимаемых решений

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

С учетом специфики ПС применены:

1. смежный контроль;

2. сочетание как статических, так и динамических методов контроля.

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

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

3.2 Технология разработки интерфейса пользователя

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

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

В данном дипломном проекте пользовательский интерфейс разработан с учётом основных требований к интерфейсу:

- прстота пользования интерфейсом;

- кнтроль пользователем;

- бстрое взаимодействие пользователя с интерфейсом;

- пследовательность в работе интерфейса;

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

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

- оознанное использование функций интерфейса;

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

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

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

а) сбор и анализ информации от пользователей. Первый этап может быть разбит на пять шагов:

1) определение профиля пользователя;

2) анализ стоящих перед ними задач;

3) сбор требований, предъявляемых клиентами;

4) анализ рабочей среды пользователей;

5) соответствие требований пользователей стоящим перед ними задачами;

б) разработка пользовательского интерфейса. Разработка включает в себя следующие шаги:

1) определение цели с точки зрения удобства применения продукта;

2) разработка задач и сценария действий пользователей;

3) определение целей и операций интерфейса;

4) определение иконок объектов и визуального представления;

5) разработка меню объектов и окон;

6) оптимизация визуальной разработки;

в) построение пользовательского интерфейса;

г) подтверждение качества пользовательского интерфейса.

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

4. Экономический раздел

4.1 Планирование разработки программы с построением сетевого графика выполнения работ

Основные этапы разработки программного средства

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

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

Все работы по созданию и внедрению программного средства (ПС) разделены на 5 стадий: техническое задание (ТЗ), эскизный проект (ЭП), технический проект (ТП), рабочий проект (РП), внедрение (ВН) [11].

Трудоемкость каждого вида работ Т_раб от общей трудоемкости стадии (Т_i) определяется по формуле (4.1):

Т_раб = К_в ? Т_i, (4.1)

где - весовой коэффициент (0 < К_в < 1, ).

Расчет продолжительности работ в днях по всем работам определяется по формуле (4.2):

_, (4.2)

где - трудоемкость работы, человеко-дней;

- количество работников, одновременно занятых в работе;

- коэффициент выполнения нормы, .

Количество рабочих дней в году Т_раб.дн.=251, общее число дней Т_год =365.

Коэффициент календарных дней вычисляется по формуле (4.3):

. (4.3)

К_д = 251/365 = 0,69.

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

Т_к = Т_ц / К_д. (4.4)

Построение сетевого графика выполнения работ

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

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

Напряженным участком работ является путь, проходящий через работы 1-2, 2-3. Работа 1-3 имеет свободный резерв времени, следовательно, с этой работы можно перевести часть исполнителей на однородную работу (1-2).

На участке 1-3 занято 2 человека, на участке 1-2 - 2 человека. В этом случае трудоемкость работ определяется по формуле (4.5) [22]:

Т_цij=W_pij?T_ij, (4.5)

где W_pij - количество исполнителей;

Т_ij - продолжительность работы в днях.

Т_ц(1-3)=W_p(1-3)?T_(1-3)=2?4=8 человеко-дней;

Т_ц(1-2)=W_p(1-2)?T_(1-2)=2?3=6 человеко-дней.

Количество исполнителей (х), которых можно перевести с работы 1-3 на работу 1-2, увеличив продолжительность работы 1-3 на 1 день:

Тогда новая продолжительность работы 1-2: , а новая продолжительность работы 1-3:

Напряженным участком работ является путь, проходящий через работы 6-7, 7-8. Работа 6-8 имеет свободный резерв времени, следовательно, с этой работы можно перевести часть исполнителей на однородную работу (6-7).

На участке 6-8 занято 2 человека, на участке 6-7 - 1 человек.

Т_ц(6-8)=W_p(6-8)?T_(6-8)=2?3=6 человеко-дней;

Т_ц(6-7)=W_p(6-7)?T_(6-7)=1?6=6 человеко-дней.

Количество исполнителей (х), которых можно перевести с работы 6-8 на работу 6-7, увеличив продолжительность работы 6-8 на 3 дня:

Тогда новая продолжительность работы 6-7: , а новая продолжительность работы 6-8: .

Напряженным участком работ является путь, проходящий через работы 10-11, 11-12. Работа 10-12 имеет свободный резерв времени, но нет исполнителей, которых можно было бы перевести с других работ на этот путь.

Напряженным участком работ является путь, проходящий через работу 13-16. Работа 15-16 имеет свободный резерв времени, следовательно, с этой работы можно перевести часть исполнителей на однородную работу (13-16).

На участке 15-16 занято 2 человека, на участке 13-16 - 1 человек.

Т_ц(15-16)=W_p(15-16) ?T_(15-16)=2?7=14 человеко-дней.

Т_ц(13-16)=W_p(13-16) ?T_(13-16)=1?122=122 человеко-дней.

Количество исполнителей (х), которых можно перевести с работы 15-16 на работу 13-16, увеличив продолжительность работы 15-16 на 7 дней:



Тогда новая продолжительность работы 13-16: , а новая продолжительность работы 15-16: .

В результате оптимизации удалось сократить продолжительность работ на 36 дней, то есть на 12,5%, так как новая продолжительность критического пути составила 251 день.

4.2 Расчет затрат на разработку и экономической эффективности проекта

Расчет затрат на создание и внедрение программного обеспечения

Определение единовременных затрат на создание и внедрение ПО, проводится по формуле 4.6 [10]:

, (4.6)

где - предпроизводственные затраты на создание ПО;

- капитальные вложения на внедрение ПО;

- изменение величины оборотных средств предприятия.

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

, (4.7)

рассчитывается по формуле:

, (4.8)

где - стоимость одного машинного часа работы ЭВМ;

- затраты машинного времени на отладку и опытную эксплуатацию ПО.

Стоимость одного часа работы ЭВМ С_ЧАС рассчитывается по формуле:

, (4.9)

где - основная и дополнительная часовая заработная плата производственного персонала (с отчислениями на социальное страхование), обеспечивающего эксплуатацию комплекса технических средств (КТС).

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

- стоимость материалов и электроэнергии, необходимых для эксплуатации КТС в течение часа, руб.;

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

- накладные расходы на содержание вычислительного центра в час, руб.

Расчёт заработной платы персонала, обслуживающего ЭВМ, производится по формуле:

 (4.10)

где r_i - численность работников i-й категории (i=1-n), обеспечивающих эксплуатацию ЭВМ, чел.;

- среднемесячная заработная плата производственного персонала i-й категории, обеспечивающего эксплуатацию ПО, руб.;

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

- доля рабочего времени, приходящаяся на ЭВМ, на которой разрабатывается ПО;

- среднее количество рабочих часов в месяц ( = 172 часа).

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

, (4.11)

где - размер дополнительных выплат к основной заработной плате. Так как размер дополнительной заработной платы составляет 10%, то=0,1;

- начисления на заработную плату, 1,24.

Таким образом, по формуле (5.15) .

Доля рабочего времени , приходящаяся на ЭВМ, на которой разрабатывается ПО, рассчитывается по формуле:

, (4.12)

где N - количество машин (N=30).

Следовательно, по формуле (5.16) .

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

руб.

Расчёт амортизационных отчислений проводится по формуле:

(4.13)

где - норма амортизационных отчислений технических средств (= 0,33, (амортизация ЭВМ рассчитана на 3 года);

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

n - количество типов оборудования;

m_i - количество единиц оборудования i-ого типа;

- коэффициент, учитывающий стоимость приобретения вспомогательного оборудования и инвентаря ( 0,1);

Ф_Д - действительный годовой фонд времени работы ЭВМ;

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

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

Рассчитаем действительный годовой фонд времени работы ЭВМ.

, (4.14)

где - среднесуточная загрузка ЭВМ (Ф_СУТ = 8 ч).

час.

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

руб.

Затраты на потребляемые материалы включают затраты на гибкие магнитные носители, накопители на внешних носителях, элементы питания и другие вспомогательные материалы, принимаются равными 1% стоимости комплекса технических средств и рассчитываются по формуле:

(4.15)

Подставим данные в формулу (5.19):

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

, (4.16)

где М - суммарная мощность установленных технических средств, применяемых для обеспечения эксплуатации ПО (М 0,4 кВт/ч);

К_М - коэффициент интенсивности использования КТС по мощности (К_М 0,9);

Затраты на текущий и профилактический ремонт технических средств могут быть приняты в размере 3% от стоимости, используемой для эксплуатации ПО ЭВМ (Ц_ЭВМ):

(4.17)

Накладные расходы на содержание ВЦ, принимаются равными 10% от заработной платы производственного персонала:

, (4.18)

руб.

Определим себестоимость одного машинного часа, подставив значения в формулу (5.13)

руб.

Затраты машинного времени на отладку и опытную эксплуатацию ПО Т_МАШ составляют 500 часов (20 недель по 5 дней 5 часов в день). Таким образом, по формуле (5.12) величина равна:

руб.

Предпроизводственные расходы на заработную плату, связанную с работами по разработке и отладке ПО К_П2 вычисляют по формуле:

, (4.19)

где n_i - количество месяцев, затраченное на создание ПО работниками i-ой категории (n_i =6);

r_i - численность программистов i-ой категории, работающих над созданием ПО;

С_ЗП - среднемесячная заработная плата программистов i-ой категории, работающих над созданием ПО, руб.;

- доля рабочего времени, затрачиваемого программистами i-й категории на создание ПО;

Таким образом, по формуле (5.23):

руб.

Предпроизводственные затраты К_П по формуле (5.11) составляют:

= 6900 + 75389 = 82289 руб.

Определим величину капитальных вложений К_К. Так как ПО не требует дополнительных капитальных вложений и внедряется на существующем комплексе технических средств, К_К = 0.

Определим изменение величины оборотных средств предприятия ?О. ПО не изменяет величину оборотных средств предприятия, следовательно, ?О = 0. Таким образом, по формуле (5.10) единовременные затраты на создание и внедрение ПО равны:

руб.

Расчёт затрат на эксплуатацию программного обеспечения

Расчёт затрат на эксплуатацию ПО в год осуществляется по формуле:

, (4.20)

где - основная и дополнительная заработная плата производственного персонала в год с отчислениями на социальное страхование с учётом затрат времени работниками на обеспечение эксплуатации спроектированного ПО;

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

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

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

- накладные расходы на содержание ВЦ, отнесённые на решение рассматриваемой задачи.

Расчёт заработной платы персонала, участвующего в обеспечении эксплуатации ПО, приводится по формуле:

(4.21)

где r_i - численность работников i-й категории, обеспечивающих эксплуатацию ПО, чел.;

- среднемесячная заработная плата производственного персонала i-й категории, обеспечивающего эксплуатацию ПО, руб.;

- доля рабочего времени, затрачиваемого работниками i-й категории на обеспечение эксплуатации проектируемого ПО.

Т. к. данное ПО эксплуатируется 300 часов в год, то доля рабочего времени равна:

.

Подставим данные в формулу (5.25), учитывая, что ПО эксплуатирует системный аналитик, среднемесячная заработная плата которого 10089 руб., а = 1,364:

руб.

Расчёт амортизационных отчислений проводится по формуле:

, (4.22)

где - требуемое годовое количество часов работы ЭВМ для эксплуатации проектируемого ПО.

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

Учитывая, что = 300 ч., получаем

Затраты на потребляемые материалы включают затраты на гибкие магнитные носители и другие вспомогательные материалы и принимаются в пределах 1% стоимости КТС, отнесённой к решению данной задачи, и рассчитывается по формуле:

(4.23)

 руб.

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

, (4.24)

руб.

Затраты на текущий и профилактический ремонт технических средств принимаются в размере 3% от стоимости, используемой для эксплуатации ПО ЭВМ (Ц_ЭВМ).

(4.25)

руб.

Накладные расходы на содержание ОИТ, отнесённые к данной задаче, принимаются равными 50% от заработной платы производственного персонала:

(4.26)

руб.

Подставим полученные значения в формулу (5.24) и получим затраты на эксплуатацию ПО:

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

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

1) годовой экономический эффект,

2) годовой прирост прибыли,

3) срок окупаемости единовременных затрат на создание и внедрение в эксплуатацию результатов проектирования.

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

, (4.27)

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

К - единовременные затраты на создание и внедрение ПО;

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

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

(4.28)

При расчетах затрат на ручную обработку информации используем формулу:

 (4.29)

где - численность работников i-й категории (i=1-n), обрабатывающих информацию (j-документ (j=1-m)) вручную до внедрения ПМО, чел.;

- среднемесячная заработная плата работника i-й категории, обрабатывающего документ j-го наименования до внедрения в эксплуатацию ПМО, руб.;

- доля рабочего времени, затрачиваемого работниками i-й категории на обработку j-го документа до использования ПМО;

До использования ПМО, подбор информации, необходимой ЛПР, осуществляли пять инженеров-аналитиков, среднемесячная заработная плата которых составляет 10089 руб. На выполнение этой работы каждый из них затрачивал 600 часов в год (0,3). Таким образом, по формуле (5.33):

руб.

Годовой прирост прибыли согласно (5.32):

.

Рассчитаем экономический эффект по формуле (5.31):

руб.

Эффективность затрат на создание и внедрение ПМО характеризуется:

а) коэффициентом экономической эффективности единовременных затрат на создание и внедрение дипломного проекта ():

, (4.30)

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

, (4.31)

Так как К_к =0, следовательно Е_к не учитывается.

Рассчитаем по формуле (5.34):

.

Срок окупаемости единовременных затрат на внедрение в эксплуатацию работу вычисляется:

. (4.32)

Следовательно, срок окупаемости составляет около восьми месяцев (7,8).

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

, (4.33)

где T_ср - средний срок окупаемости затрат для аналогичных продуктов (T_ср составляет 6 месяцев).

Подставляя значения в формулу (5.37), получаем:

Основными выводами из проведенных расчетов являются:

а) разработанное ПО соответствует современному научно-техническому уровню;

б) основные технические, натуральные и экономические показатели, приведённые в таблице 5.8;

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

Таким образом, проект признается годным к внедрению.

Заключение

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

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

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

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

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

Также в дипломном проекте были учтены вопросы безопасности при работе с ПК и непосредственно с программной средой фирмы ООО «Редтех»., описаны опасные и вредные факторы, составлена санитарно-гигиеническая характеристика помещения и организация рабочего места, а также организационно-технические мероприятия по обеспечению условий безопасности.

Таким образом, все задачи, поставленные в дипломном проекте, решены и все цели достигнуты.

Список использованных источников

1 Алексеев С.П., Казаков А.М., Колотиков Н.П., «Борьба с шумом и вибрацией в машиностроении. Машиностроение».-М. - 1970 - С. 207.

2 Архангельский А.Я. Программирование в Delphi 7. - М.: ООО «Бином-Пресс», 2003. - 1152 с.: ил.

3 «Безопасность жизнедеятельности: Под общей редакцией С.В. Белова. Изд. 2-е испр. и доп. М.: Высшая школа». - 2008 - 448 с.

4 Внедрение системы «Управление предприятием» на базе Microsoft

Dynamics AX 4.0. - http://www.icl.ru/ts.php.

5 ГОСТ 12.0.003. - 74. ССБТ. «Опасные и вредные производственные факторы. Классификация».

6 ГОСТ 24750-81. Средства технические вычислительной техники. Общие требования технической эстетики, 2006, - 360 с

7 ГОСТ 19.102-77 Единая система программной документации. Стадии разработки.

8 Голицына О.Л., Попов И.И., Партыка Т.Л., Максимов Н.В. Информационные технологии // Учебник. (Серия: «Профессиональное образование»). М.: Форум - Инфра-М, - 1998. - С. 53-59.

9 Градов А.П. Экономическая стратегия фирмы // Специальная литература. М.:Современник, - 2001. - С. 177-277.

10 Дипломное и курсовое проектирование по машинной обработке экономической информации: Учебное пособие / Абанина А.В., Бурляк Г.Н и др. - М.: «Финансы и статистика», 2005 - 239 с., илл.

11 Инновационный менеджмент: / Учебник для ВУЗов. Под
редакцией С.Д. Ильенковой. - М.:ЮНИТИ, 2004 - 327 с.

12 Иллюстрированный самоучитель по Microsoft Access. - http://www.taurion.ru/access.

13 Липаев В.В. Технико-экономическое обоснование проектов сложных программных средств. - М.: Синтез, 2006 г.

14 Маклаков С.В. Моделирование бизнес-процессов с AIIFusion Process Modeler

15 Понаморев В. Самоучитель по Delphi 7 Studio // Учебник. - СПб.:БХВ-Петербург, -2003. - С. 5-504.

16 Разматов А.Н. Этапы разработки базы данных. - http://www.tads-ltd.com/C/2.4.5.1.1.htm.

17 Романов А.Н., Корлюгов Ю.Ю. Маркетинг // Учебник. - 1995. - С. 138146.

18 Фаронов В.В., Шумаков П.В. Delphi 5. Руководство разработчика баз данных. - М.: Интеллект-Центр, 2000. - 640 с.

19 Фигурнов В.Э. IBM PC для пользователя // Учебное пособие. М.: Инфра-М, - 2006. - С. 112 -159.

20 Соколов Э.М., Захаров Е.И., Панфёрова И.В., Макеев А.В. «Безопасность жизнедеятельности. Учебное пособие для студентов университетов». - Тула.: Гриф и К., - 2001.-С. 125-128.

21 СанПиН 2.2.2.542-96, «Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы».

22 Сетевые графики в планировании. Учебное пособие. М.:
Высшая школа, 2005.

23 Смольников И.А. Реинжиниринг бизнес-процессов. - http://www.reengine.ru/ts.html.

24 СНиП 23-05-95. «Естественное и искусственное освещение»

25 Соколов Э.М., Захаров Е.И., Панфёрова И.В., Макеев А.В. «Безопасность жизнедеятельности. Учебное пособие для студентов университетов». - Тула.: Гриф и К., - 2001.-С. 125-128.

26 Тонноли. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 3-е издание.: Пер. с англ. / Тонноли Т., Бегг. К. - М.: Вильямс, 2005 - 586с

27 Фаронов В.В., Шумаков П.В. Delphi 5. Руководство разработчика баз данных. - М.: Интеллект-Центр, 2000. - 640 с.

28 Фигурнов В.Э. IBM PC для пользователя // Учебное пособие. М.: Инфра-М, - 2006. - С. 112 -159.

Приложение

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Menus;

type

TForm3 = class(TForm)

MainMenu1: TMainMenu;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

N12: TMenuItem;

N13: TMenuItem;

N14: TMenuItem;

N15: TMenuItem;

N10: TMenuItem;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N16: TMenuItem;

procedure N4Click (Sender: TObject);

procedure N6Click (Sender: TObject);

procedure N7Click (Sender: TObject);

procedure N15Click (Sender: TObject);

procedure N8Click (Sender: TObject);

procedure N10Click (Sender: TObject);

procedure N1Click (Sender: TObject);

procedure N2Click (Sender: TObject);

procedure N3Click (Sender: TObject);

procedure FormClose (Sender: TObject; var Action: TCloseAction);

procedure N12Click (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

var

Form3: TForm3;

implementation

uses Unit2, Unit1, Unit4, Unit5, Unit6, Unit10, Unit8, Unit9, Unit11,

Unit12;

{$R *.dfm}

procedure TForm3.N4Click (Sender: TObject);

begin

Form1. Close;

end;

procedure TForm3.N6Click (Sender: TObject);

begin

Form4.showmodal;

end;

procedure TForm3.N7Click (Sender: TObject);

begin

Form5. Showmodal;

end;

procedure TForm3.N15Click (Sender: TObject);

begin

Form2. Showmodal;

end;

procedure TForm3.N8Click (Sender: TObject);

begin

Form6. Showmodal;

end;

procedure TForm3.N10Click (Sender: TObject);

begin

Form11.showmodal;

end;

procedure TForm3.N1Click (Sender: TObject);

begin

Form10.showmodal;

end;

procedure TForm3.N2Click (Sender: TObject);

begin

Form8.showmodal;

end;

procedure TForm3.N3Click (Sender: TObject);

begin

Form9.showmodal;

end;

procedure TForm3.N12Click (Sender: TObject);

begin

Form12.showmodal;

end;

procedure TForm3. FormClose (Sender: TObject; var Action: TCloseAction);

begin

Form1. Close;

end;

end.

unit Unit5;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ADODB, DB, ExtCtrls, DBCtrls, Grids, DBGrids, StdCtrls;

type

TForm5 = class(TForm)

DataSource1: TDataSource;

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

ADOTable1: TADOTable;

Panel1: TPanel;

Edit1: TEdit;

Edit2: TEdit;

Edit3: TEdit;

Button1: TButton;

Button2: TButton;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Button3: TButton;

Button4: TButton;

Button5: TButton;

Label4: TLabel;

Label5: TLabel;

Button6: TButton;

procedure Button1Click (Sender: TObject);

procedure Button3Click (Sender: TObject);

procedure Button4Click (Sender: TObject);

procedure Button5Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

procedure ADOTable1BeforeDelete (DataSet: TDataSet);

procedure Button6Click (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

var

Form5: TForm5;

flag: boolean;

implementation

uses Unit3, Unit4, Unit1, Unit2, Unit9, Unit10;

{$R *.dfm}

procedure TForm5. Button1Click (Sender: TObject);

begin

if (Edit1. Text<>'') and

(Edit2. Text<>'') and

(Edit3. Text<>'')

then

begin

if flag=true then ADOTable1. Insert

else ADOTable1. Edit;

ADOTable1. FieldValues ['Наименование услуги']:=Edit1. Text;

ADOTable1. FieldValues['Стоимость']:=Edit2. Text;

ADOTable1. FieldValues ['Ед Измерения']:=Edit3. Text;

ADOTable1. Post();

end

else ShowMessage ('Необходимо заполнить поля ввода');

end;

procedure TForm5. Button3Click (Sender: TObject);

begin

Edit1. Text:='';

Edit2. Text:='';

Edit3. Text:='';

flag:=true;

Panel1. Visible:=true;

Label4. Visible:=true;

Label5. Visible:=false;

end;

procedure TForm5. Button4Click (Sender: TObject);

begin

flag:=false;

Panel1. Visible:=true;

Label5. Visible:=true;

Label4. Visible:=false;

Edit1. Text:=ADOTable1. FieldValues ['Наименование услуги'];

Edit2. Text:=ADOTable1. FieldValues['Стоимость'];

Edit3. Text:=ADOTable1. FieldValues ['Ед Измерения'];

end;

procedure TForm5. Button5Click (Sender: TObject);

begin

ADOTable1. Delete;

end;

procedure TForm5. Button2Click (Sender: TObject);

begin

Edit1. Text:='';

Edit2. Text:='';

Edit3. Text:='';

end;

procedure TForm5.ADOTable1BeforeDelete (DataSet: TDataSet);

var

Del:real;

begin

Del:=MessageDlg ('Хотите удалить текущую запись в базе данных?', mtConfirmation, [mbYes, mbNo], 0);

If Del<>mrYes

then begin

DataSet. Cancel();

Abort();

end;

end;

procedure TForm5. Button6Click (Sender: TObject);

begin

Form5. Close;

end;

end.

unit Unit8;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ADODB, DB, ExtCtrls, DBCtrls, Grids, DBGrids, StdCtrls;

type

TForm8 = class(TForm)

DataSource1: TDataSource;

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

ADOTable1: TADOTable;

Panel1: TPanel;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Edit1: TEdit;

Edit2: TEdit;

Edit3: TEdit;

Edit4: TEdit;

Button1: TButton;

Button2: TButton;

Button3: TButton;

Button4: TButton;

Button5: TButton;

Label6: TLabel;

Label7: TLabel;

Button6: TButton;

procedure Button3Click (Sender: TObject);

procedure Button1Click (Sender: TObject);

procedure Button4Click (Sender: TObject);

procedure Button5Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

procedure ADOTable1BeforeDelete (DataSet: TDataSet);

procedure Button6Click (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

var

Form8: TForm8;

flag: boolean;

implementation

uses Unit6;

{$R *.dfm}

procedure TForm8. Button3Click (Sender: TObject);

begin

Edit1. Text:='';

Edit2. Text:='';

Edit3. Text:='';

Edit4. Text:='';

flag:=true;

Panel1. Visible:=true;

Label6. Visible:=true;

Label7. Visible:=false;

end;

procedure TForm8. Button1Click (Sender: TObject);

begin

if (Edit1. Text<>'') and

(Edit2. Text<>'') and

(Edit3. Text<>'') and

(Edit4. Text<>'')

then

begin

if flag=true then ADOTable1. Insert

else ADOTable1. Edit;

ADOTable1. FieldValues['Должность']:=Edit1. Text;

ADOTable1. FieldValues ['Фиксир з/п в час']:=Edit2. Text;

ADOTable1. FieldValues ['Раб часы в день']:=Edit3. Text;

ADOTable1. FieldValues ['Раб дни в неделе']:=Edit4. Text;

if StrToInt (Edit3. Text)>24 then

begin

ShowMessage ('Неверно введено значение в поле Раб часы в день');

DataSource1. DataSet. Cancel();

Abort();

end;

if StrToInt (Edit4. Text)>7 then

begin

ShowMessage ('Неверно введено значение в поле Раб дни в неделе');

DataSource1. DataSet. Cancel();

Abort();

end;

ADOTable1. Post();

end

else ShowMessage ('Необходимо заполнить поля ввода');

end;

procedure TForm8. Button4Click (Sender: TObject);

begin

flag:=false;

Panel1. Visible:=true;

Label7. Visible:=true;

Label6. Visible:=false;

Edit1. Text:=ADOTable1. FieldValues['Должность'];

Edit2. Text:=ADOTable1. FieldValues ['Фиксир з/п в час'];

Edit3. Text:=ADOTable1. FieldValues ['Раб часы в день'];

Edit4. Text:=ADOTable1. FieldValues ['Раб дни в неделе'];

end;

procedure TForm8. Button5Click (Sender: TObject);

begin

ADOTable1. Delete;

end;

procedure TForm8.ADOTable1BeforeDelete (DataSet: TDataSet);

var

Del:real;

begin

Del:=MessageDlg ('Хотите удалить текущую запись в базе данных?', mtConfirmation, [mbYes, mbNo], 0);

If Del<>mrYes

then begin

DataSet. Cancel();

Abort();

end;

end;

procedure TForm8. Button2Click (Sender: TObject);

begin

Edit1. Text:='';

Edit2. Text:='';

Edit3. Text:='';

Edit4. Text:='';

end;

procedure TForm8. Button6Click (Sender: TObject);

begin

Form8. Close;

end;

end.

unit Unit10;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, DB, ADODB, ExtCtrls, DBCtrls, Grids, DBGrids, StdCtrls;

type

TForm10 = class(TForm)

DataSource1: TDataSource;

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

ADOTable1: TADOTable;

Panel1: TPanel;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Edit1: TEdit;

Button1: TButton;

Button2: TButton;

Button3: TButton;

Button4: TButton;

Button5: TButton;

Label6: TLabel;

Label7: TLabel;

Button6: TButton;

ComboBox1: TComboBox;

ComboBox2: TComboBox;

ComboBox3: TComboBox;

Edit2: TEdit;

Label5: TLabel;

Edit3: TEdit;

Button7: TButton;

procedure Button6Click (Sender: TObject);

procedure Button3Click (Sender: TObject);

procedure Button4Click (Sender: TObject);

procedure Button1Click (Sender: TObject);

procedure Button5Click (Sender: TObject);

procedure ADOTable1BeforeDelete (DataSet: TDataSet);

procedure Button2Click (Sender: TObject);

procedure Button7Click (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

var

Form10: TForm10;

flag: boolean;

implementation

uses Unit4, Unit5, Unit6;

{$R *.dfm}

procedure TForm10. Button6Click (Sender: TObject);

begin

Form10. Close;

end;

procedure TForm10. Button3Click (Sender: TObject);

begin

Edit1. Text:='';

Edit2. Text:='';

Combobox1. Text:='';

Combobox1. Items. Clear;

Combobox2. Text:='';

Combobox2. Items. Clear;

Combobox3. Text:='';

Combobox3. Items. Clear;

Form4.ADOTable1. Open;

Form4.ADOTable1. First;

Form5.ADOTable1. Open;

Form5.ADOTable1. First;

Form6.ADOTable1. Open;

Form6.ADOTable1. First;