Информационный объект
|
Обозначение
|
Семантика ИО
|
Реквизиты
|
Примеч
|
Приход
|
PRHD
|
Сведения о приходе
|
Код прихода
|
*
|
|
|
|
Дата
|
|
Код прихода
|
KODPRHD
|
Приход товара
|
Код
|
*
|
|
|
|
Код прихода
|
|
|
|
|
Код товара
|
|
|
|
|
Количество
|
|
|
|
|
Цена
|
|
Тип товара
|
TTOV
|
Название типа товара
|
Код типа товара
|
*
|
|
|
|
Название
|
|
Товар
|
TOV
|
Данные о товаре
|
Код типа
|
*
|
|
|
|
Код товара
|
*
|
|
|
|
Марка
|
|
|
|
|
Модель
|
|
|
|
|
Цена заказа
|
|
Розница
|
ROZ
|
Название розницы
|
Код розницы
|
|
|
|
|
Дата
|
*
|
|
|
|
Продавец
|
*
|
Розница товара
|
ROZTOV
|
Название итоговой розницы
|
Код итога
|
*
|
|
|
|
Код розницы
|
|
|
|
|
Код товара
|
|
Инфологическое проектирование
На этапе инфологического
(информационно-логического) проектирования построена семантическая
модель, описывающая необходимые сведения из предметной области, которые следуют
из анализа потребностей пользователей системы.
Сначала из объективной реальности
выделена предметная область, т.е. очерчены ее границы. Логический анализ
выделенной предметной области и потенциальных запросов пользователей завершен
построением инфологической модели - перечня сведений об объектах предметной
области, которые, необходимо хранить в БД, и связях между ними.
Анализ информационных потребностей
потенциальных пользователей имеет два аспекта:
определение собственно сведений об
объектах предметной области;
анализ возможных запросов к БД и
требований по оперативности их выполнения.
Анализ возможных запросов к БД
позволил уточнить связи между сведениями, которые необходимо хранить. Хранение
большого числа связей усложняет БД и приводит к увеличению памяти ЭВМ, но часто
существенно ускоряет поиск требуемой информации. Поэтому разработчику БД
(администратору БД) приходится принимать компромиссное решение, причем процесс
определения перечня хранимых связей, как правило, имеет итерационный характер.
Инфологическая модель «сущность -
связь» (eпtity - relationshiр model; ER-model) П. Чена представляет собой описательную (неформальную) модель
предметной области, семантически определяющую в ней сущности и связи[23]
2.3 Разработка структуры
программы
Создаваемая в дипломном проекте
программа не может быть отнесена к простейшим, для реализации которой
достаточно одного главного модуля, в котором можно решить все проблемы путем
простого перетаскивания объектов.
Вместе с тем, не целесообразно
создавать программу, состоящую только из одного рабочего модуля. т.к. программа
должна обеспечивать расчет стоимости услуг по техническому обслуживанию, по
ремонту, по закупке бытовой и вычислительной техники и т.д. и для реализации
отдельных расчетов пришлось бы повторять ее отдельные фрагменты.
Следовательно, в данном случае
необходимо иметь несколько блоков и модулей, каждый из которых может неоднократно
использоваться в разных режимах исследований. Для этого разработана структура
программы, т.е. сформирован ее состав (отдельные блоки, модули и процедуры), а
также организованы связи между ними при проведении расчетов.
Существует несколько способов выделения
составных частей разрабатываемой программы. В данном дипломном проекте
использован способ выделения составных частей программы по решаемым задачам с
учетом возможностей выбранной системы программирования.
Важнейшей особенностью
разрабатываемой программы является то, что она использует в качестве исходных
данных персонифицированные данные и следовательно, должна быть решена задача
разграничений доступа к базе данных. С учетом этого в состав программного
средства включен блок авторизации, реализованный по стандартной для ОС Windows процедуре (имя
пользователя и пароль).
Непосредственно согласует работу
всех модулей главный модуль программы, доступ к которому осуществляется только
после выполнения процесса авторизации. Этим модулем является модуль «Ввод пароля».
В соответствии с другими
выполняемыми функциями программа включает еще 2 модуля: «Продажа товара» и
«Добавление закупок».
Работа с клиентом на данном АРМ
начинается с авторизации. После ее успешного похождения главный модуль передает
управление модулю «Продажа товара», где создается новый или редактируется
существующий заказ.
При составлении заказа используется
информация, хранящаяся в справочниках базы данных.
После завершения составления
основных граф заказа главный модуль передает управление модулю «Добавление
закупок», в котором производится предварительный расчет стоимости всех услуг.
При этом также используется справочная информация из базы данных.
Информация о наличии и стоимости тех
или иных видов бытовой техники поступает в базу данных с АРМ бухгалтерии и
склада.
В базе данных хранится также массив
информации о сотрудниках предприятия. По одному (или нескольким) из этих
адресов и отправляется процент стоимости оплаты за выполненные работы для
начисления ему в бухгалтерии заработной платы.
Хранение информации в базе данных о
товаре, услугах и сотрудниках позволяет быстро и без ошибок использовать их при
проведении расчетов.
Для вывода и отображения результатов
в программе предусмотрен блок вывода выходной информации.
Учитывая возможности системы
программирования, в дипломном проекте приято решение об отображении входной и
выходной информации на едином окне интерфейса пользователя с выделением
различных панелей.
Вся справочная и промежуточная
информация хранится в базе данных, взаимодействие программы с которой
осуществляется через СУБД.
.4 Разработка алгоритмов
модулей
В данном пункте представлены схемы
алгоритмов основных модулей программного средства разработанной в дипломном
проекте автоматизированной системы.
При помощи основного модуля программы
«Авторизация» осуществляется вывод формы для ввода данных оператором
программного средства, после чего он вводит пароль, так производится
авторизация пользователя.
В модуле «Продажа товара»
производятся операции по выбору товара, ввода цены товара и занесению данных в
базы данных, связанные с программой, осуществляется вывод на экран данных и
отчётов.
Посредством модуля «Добавление
закупок» выполняются основные операции по поиску необходимого товара или услуги
по закупочной цене, продажной цене, количеству и наименованию товаров и услуг,
занесению этих данных в связанные с программным средство базы данных. Так же с
помощью данного модуля выполняется выведение отчётов на печать.
.5 Разработка интерфейса
пользователя
Описание интерфейса программы
При открытии программы «Бытовая
техника» необходимо запустить Access, открыть программу с таким названием.
Можно также запустить из любого окна, например, «Мой компьютер» или
«Проводник».
Главное окно разработанной АСУ
Главное меню программы предназначено
для управления последовательностью действий. Оно представляет собой несложную
древовидную структуру. Наиболее просто элемент меню выбирается с помощью мыши.
Сначала выбирается элемент главного меню, в результате чего раскроется
соответствующее подменю. Главное меню программы состоит из следующих подменю:
- товары (ввод справочной
информации);
- документы (ввод,
просмотр и печать документов);
- проверка качества
(просмотр, добавление, редактирование и печать документов);
- управленческие
факторы (просмотр управленческих факторов);
- справка (сведения о
программе);
- выход (выход из
ИС).
Рассмотрим более подробно каждый из
элементов меню.
При выборе меню «Вывод» раскрывается
подменю с выбором следующих пунктов:
- прибыль (содержит
информацию о прибыли предприятия за определенный период);
- приход (содержит
информацию о поступлении товара в количественном и в денежном выражении);
- продажа (содержит
информацию о продажах товара в количественном и в денежном выражении за
указанный период).
При выборе меню «менеджер»
раскрываются пункты:
- продаж (содержит
информацию о товаре, который готовится к оплате покупателем, т.е. он уже
выбран, показывается его стоимость);
- закупок (содержит
информацию о товаре, который готовится к закупке предприятием торговли, т.е. он
уже выбран, показывается его стоимость).
При нажатии этих кнопок появляется
форма для ввода пароля, показанная на рисунке.
Форма ввода пароля
При выборе меню «Документы»
раскрывается подменю с выбором документов.
При выборе меню «Справка»
открывается подменю «О программе». В этом подменю указаны сведения о программе
кем и когда была сделана программа.
Меню «Выход». При нажатии на этот
пункт меню система закрывается, и выходит из неё.
При запуске программы
БЫТОВАЯ_ТЕХНИКА появляется окно «Бытовая техника LG», в котором появляется меню
с кнопками. В появившемся окне видны кнопки, назначение которых интуитивно
понятно из их названия.
Нажать кнопку «Товар». Исходными
данными для программы являются данные о товаре, которые содержатся в таблице
или представленные в виде формы. Здесь можно вносить данные о поступивших новых
товарах, изменять сведения у имеющихся (например, цену). Для этого нужно
использовать окно «Запись» в левом нижнем углу и кнопки или для
изменения, для добавления кнопку . Изменять и вносить данные можно непосредственно в таблицу.
Окно типа товара
Для добавления нового типа товара,
которого ранее не было (например, DVD), необходимо нажать кнопку «Тип»,
появится окно «Ввод типа товара», показанное на рисунке 2.8, в которое
необходимо внести требуемые данные.
В окне «Приход», заносятся данные о
количестве полученного товара, от кого поступил, затраты на его покупку. Для
правильной работы необходимо обязательно указать дату в соответствующем окне.
При необходимости можно сформировать и отпечатать накладную. Для этого
достаточно щелкнуть по кнопке «Накладная» . Для анализа продаж за период достаточно щелкнуть по кнопке , появится окно, показанное на рисунке.
Окно данных о товаре в табличной
форме
Окно прихода товара
Кнопка «Цены» позволяет получить и
при необходимости отпечатать форму для внесения изменений цены товара.
Для анализа остатка товара
необходимо щелкнуть по кнопке «ОСТАТОК», высветится форма в виде страниц текста
(рисунок).
Окно отчета об остатках товара
Группа кнопок «Вывод» служит для
анализа прибыли, и продаж.
Окно «Приход» имеет вид, показанный
на рисунке.
Окно данных о приходе
После нажатия на кнопку высвечиваются данные по форме.
Тестирование и отладка программы
На этап отладки и тестирования
программ приходится около 50% всей работы над разработкой программного
обеспечения.
Тестирование - это процесс
выполнения программы с целью обнаружения в ней ошибок. Такое определение цели
стимулирует поиск ошибок в программах. Отсюда также ясно, что «удачным» тестом
является такой, на котором выполнение программы завершилось с ошибкой.
Напротив, «неудачным» можно назвать тест, не позволивший выявить ошибку в
программе.
Существует два основных вида
тестирования: функциональное и структурное. При функциональном тестировании
текст программы не используется. Происходит проверка соответствия поведения
программы ее внешней спецификации. Очевидно, что критерием полноты тестирования
в этом случае являлся бы перебор всех возможных значений входных данных, что
невыполнимо.
Поскольку исчерпывающее
функциональное тестирование невозможно, речь может идти о разработки методов,
позволяющих подбирать тесты не «вслепую», а с большой вероятностью обнаружения
ошибок в программе.
При структурном тестировании текст
программы открыт для пользования. Происходит проверка логики программы. Полным
тестированием в этом случае будет такое, которое приведет к перебору всех
возможных путей на графе передач управления программы (ее управляющем графе).
Даже для средних по сложности программ число таких путей может достигать
десятков тысяч. Если ограничиться перебором только линейных не зависимых путей,
то и в этом случае исчерпывающее структурное тестирование практически
невозможно, так как неясно, как подбирать тесты, чтобы обеспечить «покрытие»
всех таких путей. Поэтому при структурном тестировании необходимо использовать
другие критерии его полноты, позволяющие достаточно просто контролировать их
выполнение, но не дающие гарантии полной проверки логики программы.
Но даже если предположить, что
удалось достичь полного структурного тестирования некоторой программы, в ней,
тем не менее, могут содержаться ошибки, так как:
- программа
может не соответствовать своей внешней спецификации, что в частности, может
привести к тому, что в ее управляющем графе окажутся пропущенными некоторые
необходимые пути;
- не
будут обнаружены ошибки, появление которых зависит от обрабатываемых данных (то
есть на одних исходных данных программа работает правильно, а на других - с
ошибкой).
Таким образом, ни структурное, ни
функциональное тестирование не может быть исчерпывающим.
Рассмотрим подробнее основные этапы
тестирования программных комплексов. В тестирование многомодульных программных
комплексов можно выделить четыре этапа:
1) тестирование отдельных модулей;
2) совместное тестирование
модулей;
) тестирование функций
программного комплекса (то есть поиск различий между разработанной программой и
ее внешней спецификацией);
) тестирование всего
комплекса в целом (то есть поиск несоответствия созданного программного
продукта сформулированным ранее целям проектирования, отраженным обычно в
техническом задании).
На первых двух этапах используются,
прежде всего, методы структурного тестирования, так как:
- на последующих этапах
тестирования эти методы использовать сложнее из-за больших размеров
проверяемого программного обеспечения;
- последующие этапы
тестирования ориентированы на обнаружение ошибок различного типа, которые не
обязательно связаны с логикой программы.
При тестировании, как отдельных
модулей, так и их комплексов должны быть решены две задачи:
- построение эффективного
множества тестов;
- выбор способа
комбинирования (сборки) модулей при создании трестируемого варианта программы.
Отладка выполнялась с помощью точек
останова и наблюдения за значениями некоторых переменных. При обнаружении
ошибок устанавливалась точку останова, и выполнялись несколько операторов в
пошаговом режиме. Над выявленным ошибочным оператором производились действия по
отладке.
Также был использован метод отладки
приложения на тестовых данных. Использование данного метода дает возможность
проверки правильности работы алгоритмов расчета. Метод базируется на
составлении тестовых данных и ручном вычислении по используемым в программе
алгоритмам. Далее полученные значения сравниваются с результатами вычисления
программы.
Отладка программы выполнялась как в
процессе разработки, так и в процессе тестирования приложения. Были выявлены
ошибки, связанные с несовпадением типов файлов в таблицах базы, с
незначительными отклонениями от требуемой функциональности программы, а также
ошибки, возникающие в процессе работы программы, связанные с неверной
организацией работы пользователя. Выявленные ошибки были исправлены, после чего
программное средство повторно тестировалось. Результаты повторных тестов
показали соответствие разработанной программы требуемому программному средству.
3. Технологический
раздел
.1 Технология разработки
программы
Под технологией программирования
понимается совокупность производственных процессов, приводящая к созданию
требуемого ПС, а также описание этой совокупности процессов [2]. Каждый процесс
этой совокупности базируется на использовании методов и средств разработки ПС.
В данном разделе рассматриваются как сам процесс разработки программного
комплекса для имитации передачи данных в беспроводной локальной вычислительной
сети, так и средства и методы его разработки.
Целью программирования является
описание процессов обработки данных. Программа должна быть понятной и человеку,
т.к. и при разработке программ, и при их использовании часто приходится
выяснять, какой именно процесс она порождает. Поэтому программа составляется на
удобном для человека формализованном языке программирования, с которого она с
помощью транслятора автоматически переводится на язык, понятный компьютеру.
Программисту прежде, чем составлять
программу на удобном для него языке программирования, приходится преодолевать
большую подготовительную работу по уточнению постановки задачи, выбору метода
её решения, выяснению специфики применения требуемой программы и др. Использование
этой информации может существенно упростить задачу понимания программы
человеком. Поэтому её весьма полезно фиксировать в виде отдельных документов.
Обычно программы разрабатываются в расчете на обычного пользователя, поэтому
для освоения программы пользователем помимо ее текста требуется определенная
дополнительная документация.
Программа или логически связанная
совокупность программ на носителе данных, снабженная программной документацией,
называется программным средством (ПС). ПС позволяют осуществлять автоматическую
обработку данных, а программная документация позволяет понять, какие функции
выполняет та или иная программа программного средства, как подготовить исходные
данные и запустить процесс их обработки, а также что означают полученные результаты.
Резкое удешевление стоимости
компьютеров и в особенности стоимости хранения информации на компьютерных
носителях привело к широкому внедрению ПК во все сферы человеческой
деятельности, что существенно изменило направленность технологии программирования,
и человеческий фактор сыграл в ней решающую роль. Сформировалось глубокое
понятие качества ПС, в котором акценты стали ставиться не столько на его
эффективность, сколько на удобство работы с ним пользователей и надежность.
Объектно-ориентированный анализ и
проектирование
Основная идея
объектно-ориентированного анализа и проектирования состоит в рассмотрении
предметной области и логического решения задачи с точки зрения объектов
(понятий и сущностей). В процессе объектно-ориентированного анализа основное
внимание уделяется определению и описанию объектов в терминах предметной
области. В процессе объектно-ориентированного проектирования определяются
логические программные объекты, которые будут реализованы средствами
объектно-ориентированного языка программирования. Эти программные объекты
включают в себя атрибуты и методы. В процессе конструирования или
объектно-ориентированного программирования обеспечивается реализация
разработанных компонентов и классов.
Наиболее важным моментом
объектно-ориентированного анализа и проектирования является квалифицированное
распределение обязанностей между компонентами программной системы [2].
Обязанности объектов и их взаимодействия изображаются с использованием диаграмм
классов и диаграмм взаимодействий. Диаграмма классов и их взаимодействия в
составе ПС показана на рисунке 3.1.
Рисунок 3.1 - Диаграмма классов и их
взаимодействия в составе ПС
Принципы модульного программирования
Модульное программирование является
воплощением общих методов борьбы со сложностью и обеспечение независимости
компонент системы, и использование иерархических структур. Для воплощения
первого метода формулируются определенные требования, которым должен
удовлетворять программный модуль, т.е. выявляются основные характеристики
«хорошего» программного модуля. Для воплощения второго метода используют
древовидные модульные структуры программ (включая деревья со сросшимися
ветвями).
Не всякий программный модуль
способствует упрощению программы. Выделить хороший с этой точки зрения модуль
является серьезной творческой задачей. Для оценки приемлемости выделенного
модуля используются некоторые критерии. Так, Хольт предложил следующие два
общих таких критерия:
- хороший модуль снаружи
проще, чем внутри;
Майерс предлагает для оценки
приемлемости программного модуля использовать более конструктивные его
характеристики:
- размер модуля;
- прочность модуля;
- сцепление с другими
модулями;
- рутинность модуля
(независимость от предыстории обращений к нему).
В качестве модульной структуры
программы принято использовать древовидную структуру, включая деревья со
сросшимися ветвями. В узлах такого дерева размещаются программные модули, а
направленные дуги (стрелки) показывают статическую подчиненность модулей, т.е.
каждая дуга показывает, что в тексте модуля, из которого она исходит, имеется
ссылка на модуль, в который она входит. Другими словами, каждый модуль может
обращаться к подчиненным ему модулям, т.е. выражается через эти модули. При
этом модульная структура программы, в конечном счете, должна включать и
совокупность спецификаций модулей, образующих эту программу.
При разработке программного модуля
обычно придерживаются следующего порядка действий:
- изучение и проверка спецификации
модуля, выбор языка программирования;
- выбор алгоритма и
структуры данных;
- программирование
(кодирование) модуля;
- шлифовка текста
модуля;
- проверка модуля;
- компиляция модуля.
Модуль - фрагмент
программного текста, являющийся строительным блоком для физической структуры
системы. Как правило, модуль состоит из интерфейсной части и части-реализации.
Модульность -
свойство системы, которая может подвергаться декомпозиции на ряд внутренне
связанных и слабо зависящих друг от друга модулей.
По определению Г.
Майерса, модульность - свойство ПО, обеспечивающее интеллектуальную возможность
создания сколь угодно сложной программы. Соотношение - это обоснование
модульности. Оно приводит к заключению «разделяй и властвуй» - сложную проблему
легче решить, разделив ее на управляемые части. Результат, выраженный
неравенством, имеет важное значение для модульности и ПО. Фактически, это
аргумент в пользу модульности.
Однако здесь
отражена лишь часть реальности, ведь здесь не учитываются затраты на
межмодульный интерфейс. Как показано на рис. 3.7, с увеличением количества
модулей (и уменьшением их размера) эти затраты также растут.
Инструментальная среда
При разработке программных средств
используется в той или иной мере компьютерная поддержка процессов разработки и
сопровождения ПС [7]. Это достигается путем представления программных
документов ПС на компьютерных носителях данных и предоставления в распоряжение
разработчика ПС специальных ПС или включенных в состав компьютера специальных
устройств, созданных для обработки таких документов. Компьютерная поддержка
процессов разработки и сопровождения ПС производится не только за счет
использования отдельных инструментов, но и за счет использования логически
связанной совокупности программных и аппаратных инструментов. Такую
совокупность называют инструментальной средой разработки и сопровождения ПС.
Инструментальная среда
программирования включает, прежде всего, текстовый редактор, позволяющий
конструировать программы на заданном языке программирования, а также инструменты,
позволяющие компилировать или интерпретировать программы на этом языке,
тестировать и отлаживать полученные программы. Кроме того, могут быть и другие
инструменты, например, для статического или динамического анализа программ.
Взаимодействуют эти инструменты между собой через обычные файлы с помощью
стандартных возможностей файловой системы.
Исходя из технического задания, в
качестве инструментальной среды программирования в дипломном проекте выбраны
инструменты, предоставляемые фирмой Borland для создания Win32 приложений под ОС Windows, позволяющие компилировать, транслировать, тестировать и
отлаживать программы на языке программирования Delphi [2, 15]. Данная среда
является языково-ориентированной. Вследствие этого используются мощные
возможности, учитывающие специфику данного языка. Ещё одной особенностью
инструментальной среды является синтаксическая управляемость, при этом она
базируется на знании синтаксиса языка программирования. В такой среде вместо
текстового используется синтаксически-управляемый редактор, позволяющий
пользователю использовать различные шаблоны синтаксических конструкций (в
результате этого разрабатываемая программа всегда будет синтаксически
правильной). Одновременно с программой такой редактор формирует (в памяти
компьютера) ее синтаксическое дерево, которое может использоваться другими
инструментами.
Жизненный цикл программного средства
Широкое внедрение компьютерных сетей
привело к естественному развитию распределённых вычислений, дистанционного
доступа к информации и электронного способа обмена сообщения между людьми.
В настоящее время можно выделить 5
основных подходов к организации процесса создания и использования ПС: [2]
1. Водопадный подход. При таком
подходе разработка ПС состоит из цепочки этапов. На каждом этапе создаются
документы, используемые на последующем этапе. В исходном документе фиксируются
требования к ПС. В конце этой цепочки создаются программы, включаемые в ПС.
2. Исследовательское
программирование. Этот подход предполагает быструю (насколько это возможно)
реализацию рабочих версий программ ПС, выполняющих лишь в первом приближении
требуемые функции. После экспериментального применения реализованных программ
производится их модификация с целью сделать их более полезными для
пользователей. Этот процесс повторяется до тех пор, пока ПС не будет достаточно
приемлемо для пользователей. Такой подход применялся на ранних этапах развития
программирования, когда технологии программирования не придавали большого
значения (использовалась интуитивная технология). В настоящее время этот подход
применяется для разработки таких ПС, для которых пользователи не могут точно
сформулировать требования (например, для разработки систем искусственного
интеллекта).
. Прототипирование. Этот
подход моделирует начальную фазу исследовательского программирования вплоть до
создания рабочих версий программ, предназначенных для проведения экспериментов
с целью установить требования к ПС. В дальнейшем должна последовать разработка
ПС по установленным требованиям в рамках какого-либо другого подхода (например,
водопадного).
. Формальные преобразования.
Этот подход включает разработку формальных спецификаций ПС и превращение их в
программы путем корректных преобразований. На этом подходе базируется
компьютерная технология (CASE-технология) разработки ПС.
. Сборочное программирование.
Этот подход предполагает, что ПС конструируется, главным образом, из компонент,
которые уже существуют. Должно быть некоторое хранилище (библиотека) таких
компонент, каждая из которых может многократно использоваться в разных ПС.
Такие компоненты называются повторно используемыми (reusable). Процесс разработки ПС
при данном подходе состоит скорее из сборки программ из компонент, чем из их
программирования.
Для разработки системы учета
учебно-воспитательной работы общеобразовательного учреждения будем использовать
сборочное программирование, поскольку существуют общепринятые стандартные
процедуры обработки баз данных, стандартные скрипты форумов и т.п. Однако,
некоторые компоненты системы учета учебно-воспитательной работы
общеобразовательного учреждения будут разрабатываться «с нуля». Для их
разработки будем использовать водопадный подход, после чего они будут включены
в систему методом сборочного программирования.
Жизненный цикл ПС изображён на
рисунке 3.2 и содержит в себе: разработку ПС, производство программных изделий
(ПИ) и эксплуатацию ПС.
Рисунок 3.2 - Стадии и фазы
жизненного цикла ПС
Стадия разработки ПС состоит из
этапа его внешнего описания, этапа конструирования ПС, этапа кодирования
(программирование в узком смысле) ПС и этапа аттестации ПС. Всем этим этапам
сопутствуют процессы документирования и управления ПС.
Этап внешнего описания ПС
включает процессы, приводящие к созданию внешнему описанию ПС. Этот документ является
описанием поведения ПС с точки зрения внешнего по отношению к нему наблюдателя
с фиксацией требований относительно его качества. Кодирование ПС включает
процессы создания текстов программ на языках программирование, их отладку с
тестированием ПС. На этапе аттестации ПС производится оценка качества ПС и
принятие решения о практическом применении ПС.
Программное изделие (ПИ) - экземпляр
или копия разработанного ПС. Изготовление ПИ - это процесс генерации или
воспроизведения (снятия копии) программ и программных документов ПС с целью их
поставки пользователю для применения по назначению. Производство ПИ - это
совокупность работ по обеспечению изготовления требуемого количества ПИ в
установленные сроки. Стадия производства ПИ в жизненном цикле ПС является, по
существу, вырожденной (не существенной), так как представляет рутинную работу,
которая может быть выполнена автоматически и без ошибок. Этим она принципиально
отличается от стадии производства различной техники.
Стадия эксплуатации ПС охватывает
процессы хранения, внедрения и сопровождения ПС, а также транспортировки и
применения ПИ по своему назначению. Она состоит из двух параллельно проходящих
фаз: фазы применения ПС и фазы сопровождения ПС.
Применение ПС состоит в его
использование для решения практических задач на компьютере путем создания
динамически подключаемых модулей для эмулирования ИНС.
Сопровождение ПС - это процесс сбора
информации о качестве ПС в эксплуатации, устранения обнаруженных в нем ошибок,
его доработки и модификации, а также извещения пользователей о внесенных в него
изменениях.
.1.5 Обеспечение надежности
программного средства
Известны четыре подхода к
обеспечению надежности [8]:
1. предупреждение ошибок;
2. самообнаружение ошибок;
. самоисправление ошибок;
. обеспечение устойчивости к
ошибкам.
При разработке ПС применён подход
предупреждения ошибок. Цель его применения - не допустить ошибок в готовых
продуктах, в данном случае - в ПС. Природа ошибок при разработке ПС позволяет
для достижения этой цели сконцентрировать внимание на следующих вопросах:
1. борьба со сложностью;
2. обеспечение точности
перевода;
. преодоление барьера между
пользователем и разработчиком;
. обеспечение контроля
принимаемых решений.
В процессе разработки применяются
два общих метода борьбы со сложностью систем:
1. обеспечения независимости
компонент системы;
2. использование в системах
иерархических структур.
Обеспечение независимости компонент
означает разбиение системы на такие части, между которыми должны остаться по
возможности меньше связей. В ПС используются иерархические структуры,
позволяющие локализовать связи между компонентами, допуская их лишь между
компонентами, принадлежащими смежным уровням иерархии.
Обеспечение точности перевода
направляется на достижение однозначности интерпретации документов различными
разработчиками, а также пользователями ПС.
Контроль принимаемых решений
Обязательным шагом в каждом процессе
(этапе) разработки ПС является проверка правильности принятых решений. Это
позволяет обнаруживать и исправлять ошибки на самой ранней стадии после её
возникновения, что, во-первых, существенно снижает стоимость её исправления и,
во-вторых, повышает вероятность правильного её устранения.
С учетом специфики ПС применены:
1. смежный контроль;
2. сочетание как статических,
так и динамических методов контроля.
Смежный контроль означает, проверку
полученного документа лицами, не участвующими в его разработке, с двух сторон:
во-первых, со стороны автора исходного для контролируемого процесса документа,
и, во-вторых, лицами, которые будут использовать полученный документ в качестве
исходного в последующих технологических процессах. Такой контроль позволяет
обеспечивать однозначность интерпретации полученного документа.
Сочетание статических и динамических
методов контроля означает, что проверяется как содержание документа, так и
процесс обработки данных, который он описывает. Это отражает одну из
специфических особенностей ПС (статическая форма, динамическое содержание).
.2 Технология разработки
интерфейса пользователя
Эргономичный и понятный интерфейс
пользователя это очень важная составляющая при создании программного
обеспечения. Во многом от характеристик и функциональных возможностей
интерфейса зависит быстродействие и чёткость в работе оператора программного
средства. Графический интерфейс связывает такие компоненты как устройства
ввода, вывода, взаимодействие с базами данных, программное обеспечение которое
обслуживает их.
Интерфейс пользователя содержит в
себе всё необходимое для корректного взаимодействия пользователя с программной
средой.
В данном дипломном проекте
пользовательский интерфейс разработан с учётом основных требований к
интерфейсу:
прстота пользования интерфейсом;
кнтроль пользователем;
бстрое взаимодействие пользователя с
интерфейсом;
пследовательность в работе
интерфейса;
крректное графическое отображение
необходимых пользователю функция программного средства;
Существует ряд обоснованных
принципов, которые позволяют соблюдать при разработке графического интерфейса
простоту его использования и контроль пользователя над системой:
оознанное использование функций
интерфейса;
взможность использования интерфейса
посредством мыши, клавиатуры или комбинированно;
итерфейс программного средства
необходимо проектировать так, чтобы при любых обстоятельствах пользователь мог
сохранить результаты работы;
Процесс проектирования и разработки
пользовательского интерфейса состоит из четырёх основных этапов:
а) сбор и анализ информации от
пользователей. Первый этап может быть разбит на пять шагов:
) определение профиля пользователя;
) анализ стоящих перед ними задач;
) сбор требований, предъявляемых
клиентами;
) анализ рабочей среды
пользователей;
) соответствие требований
пользователей стоящим перед ними задачами;
б) разработка пользовательского
интерфейса. Разработка включает в себя следующие шаги:
) определение цели с точки зрения
удобства применения продукта;
) разработка задач и сценария
действий пользователей;
) определение целей и операций
интерфейса;
) определение иконок объектов и
визуального представления;
) разработка меню объектов и окон;
) оптимизация визуальной разработки;
в) построение пользовательского
интерфейса;
г) подтверждение качества
пользовательского интерфейса.
Таким образом целесообразно сделать
вывод, что результаты разработки программной среды в данном дипломном проекте позволяют
убедиться в адекватности и актуальности создания подобной системы, и её
удобства и эргономичности по все параметрам, включая гибкий и простой в
использовании интерфейс пользователя, который даёт возможность эффективной и
грамотной работы рабочего персонала рассматриваемой организации. Графический
интерфейс полностью удовлетворяет поставленным в дипломном проекте задачам.
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=Wpij×Tij,
(4.5)
где Wpij - количество
исполнителей;
Тij - продолжительность
работы в днях.
Тц(1-3)=Wp(1-3)×T(1-3)=2×4=8 человеко-дней;
Тц(1-2)=Wp(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)=Wp(6-8)×T(6-8)=2×3=6 человеко-дней;
Тц(6-7)=Wp(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)=Wp(15-16) ×T(15-16)=2×7=14 человеко-дней.
Тц(13-16)=Wp(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)
где ri - численность
работников 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 - количество типов оборудования;
mi - количество единиц оборудования 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)
где ni - количество
месяцев, затраченное на создание ПО работниками i-ой категории (ni
=6);
ri - численность программистов i-ой категории,
работающих над созданием ПО;
СЗП - среднемесячная заработная плата программистов i-ой категории,
работающих над созданием ПО, руб.;
- доля
рабочего времени, затрачиваемого программистами i-й категории на создание
ПО;
Таким образом, по формуле (5.23):
руб.
Предпроизводственные затраты КП
по формуле (5.11) составляют:
= 6900 + 75389 = 82289 руб.
Определим величину капитальных
вложений КК. Так как ПО не требует дополнительных капитальных
вложений и внедряется на существующем комплексе технических средств, КК
= 0.
Определим изменение величины
оборотных средств предприятия ∆О. ПО не изменяет величину оборотных
средств предприятия, следовательно, ∆О = 0. Таким образом, по формуле
(5.10) единовременные затраты на создание и внедрение ПО равны:
руб.
Расчёт затрат на эксплуатацию
программного обеспечения
Расчёт затрат на эксплуатацию ПО в
год осуществляется по формуле:
,
(4.20)
где - основная и дополнительная заработная плата производственного
персонала в год с отчислениями на социальное страхование с учётом затрат
времени работниками на обеспечение эксплуатации спроектированного ПО;
-
затраты на амортизацию технических средств, необходимых для эксплуатации
проектируемого ПО, с учётом их фактической загрузки решением рассматриваемого
комплекса задач, т.е. удельного веса этой загрузки в общем годовом фонде времени;
-
стоимость материалов и электроэнергии, необходимых для эксплуатации ПО в
течение года;
-
затраты на текущий и профилактический ремонт технических средств, используемых
для эксплуатации ПО;
-
накладные расходы на содержание ВЦ, отнесённые на решение рассматриваемой
задачи.
Расчёт заработной платы персонала,
участвующего в обеспечении эксплуатации ПО, приводится по формуле:
(4.21)
где ri - численность
работников 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) и получим затраты на эксплуатацию ПО:
Определение основных показателей
экономической эффективности введения в эксплуатацию программы
К основным показателям экономической
эффективности введения в эксплуатацию любого программного обеспечения
относятся:
) годовой экономический эффект,
) годовой прирост прибыли,
) срок окупаемости единовременных
затрат на создание и внедрение в эксплуатацию результатов проектирования.
Экономический эффект представляет
собой экономию труда, материалов и производственных фондов предприятия и
рассчитывается по формуле:
,
(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.
Архангельский А.Я.
Программирование в 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.
Градов А.П. Экономическая стратегия фирмы // Специальная
литература. М.:Современник, - 2001. - С. 177-277.
10 Дипломное и
курсовое проектирование по машинной обработке экономической информации: Учебное
пособие / Абанина А.В., Бурляк Г.Н и др. - М.: «Финансы и статистика», 2005 -
239 с., илл.
Инновационный менеджмент:
/ Учебник для ВУЗов. Под
редакцией С.Д. Ильенковой. - М.:ЮНИТИ, 2004 - 327 с.
Иллюстрированный
самоучитель по Microsoft Access. - http://www.taurion.ru/access.
Липаев В.В.
Технико-экономическое обоснование проектов сложных программных средств. - М.:
Синтез, 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. - С. 138-146.
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.
Тонноли. Базы данных:
проектирование, реализация и сопровождение. Теория и практика. 3-е издание.:
Пер. с англ. / Тонноли Т., Бегг. К. - М.: Вильямс, 2005 - 586с
Фаронов В.В., Шумаков
П.В. Delphi 5. Руководство разработчика баз данных. - М.: Интеллект-Центр,
2000. - 640 с.
Фигурнов В.Э. IBM PC для
пользователя // Учебное пособие. М.:
Инфра-М, - 2006. - С. 112 -159.
Приложение
, Messages, SysUtils,
Variants, Classes, Graphics, Controls, Forms,, Menus;= class(TForm): TMainMenu;:
TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;:
TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;:
TMenuItem;: TMenuItem;: TMenuItem;N4Click (Sender: TObject);N6Click (Sender:
TObject);N7Click (Sender: TObject);N15Click (Sender: TObject);N8Click (Sender:
TObject);N10Click (Sender: TObject);N1Click (Sender: TObject);N2Click (Sender:
TObject);N3Click (Sender: TObject);FormClose (Sender: TObject; var Action:
TCloseAction);N12Click (Sender: TObject);
{Private declarations}
{Public declarations};:
TForm3;Unit2, Unit1, Unit4, Unit5, Unit6, Unit10, Unit8, Unit9, Unit11,;
{$R *.dfm}TForm3.N4Click
(Sender: TObject);. Close;;TForm3.N6Click (Sender:
TObject);.showmodal;;TForm3.N7Click (Sender: TObject);. Showmodal;;TForm3.N15Click
(Sender: TObject);. Showmodal;;TForm3.N8Click (Sender: TObject);.
Showmodal;;TForm3.N10Click (Sender: TObject);.showmodal;;TForm3.N1Click
(Sender: TObject);.showmodal;;TForm3.N2Click (Sender:
TObject);.showmodal;;TForm3.N3Click (Sender: TObject);.showmodal;;TForm3.N12Click
(Sender: TObject);.showmodal;;TForm3. FormClose (Sender: TObject; var Action:
TCloseAction);. Close;;.
, Messages, SysUtils,
Variants, Classes, Graphics, Controls, Forms,, ADODB, DB, ExtCtrls, DBCtrls,
Grids, DBGrids, StdCtrls;= class(TForm): TDataSource;: TDBGrid;: TDBNavigator;:
TADOTable;: TPanel;: TEdit;: TEdit;: TEdit;: TButton;: TButton;: TLabel;:
TLabel;: TLabel;: TButton;: TButton;: TButton;: TLabel;: TLabel;:
TButton;Button1Click (Sender: TObject);Button3Click (Sender:
TObject);Button4Click (Sender: TObject);Button5Click (Sender:
TObject);Button2Click (Sender: TObject);ADOTable1BeforeDelete (DataSet:
TDataSet);Button6Click (Sender: TObject);
{Private declarations}
{Public declarations};:
TForm5;: boolean;Unit3, Unit4, Unit1, Unit2, Unit9, Unit10;
{$R *.dfm}TForm5.
Button1Click (Sender: TObject);(Edit1. Text<>'') and
(Edit2. Text<>'')
and
(Edit3.
Text<>'')flag=true then ADOTable1. InsertADOTable1. Edit;. FieldValues ['Наименование услуги']:=Edit1. Text;.
FieldValues['Стоимость']:=Edit2. Text;. FieldValues ['Ед Измерения']:=Edit3. Text;. Post();ShowMessage ('Необходимо заполнить поля ввода');;TForm5.
Button3Click (Sender: TObject);. Text:='';. Text:='';. Text:='';:=true;.
Visible:=true;. Visible:=true;. Visible:=false;;TForm5. Button4Click (Sender:
TObject);:=false;. Visible:=true;. Visible:=true;. Visible:=false;.
Text:=ADOTable1. FieldValues ['Наименование услуги'];. Text:=ADOTable1. FieldValues['Стоимость'];. Text:=ADOTable1. FieldValues ['Ед Измерения'];;TForm5. Button5Click (Sender: TObject);. Delete;;TForm5.
Button2Click (Sender: TObject);. Text:='';. Text:='';.
Text:='';;TForm5.ADOTable1BeforeDelete (DataSet: TDataSet);:real;:=MessageDlg
('Хотите удалить текущую запись в базе данных?', mtConfirmation, [mbYes, mbNo], 0);Del<>mrYesbegin.
Cancel();();;;TForm5. Button6Click (Sender: TObject);. Close;;.
Unit8;
, Messages, SysUtils,
Variants, Classes, Graphics, Controls, Forms,, ADODB, DB, ExtCtrls, DBCtrls,
Grids, DBGrids, StdCtrls;= class(TForm): TDataSource;: TDBGrid;: TDBNavigator;:
TADOTable;: TPanel;: TLabel;: TLabel;: TLabel;: TLabel;: TEdit;: TEdit;:
TEdit;: TEdit;: TButton;: TButton;: TButton;: TButton;: TButton;: TLabel;:
TLabel;: TButton;Button3Click (Sender: TObject);Button1Click (Sender: TObject);Button4Click
(Sender: TObject);Button5Click (Sender: TObject);Button2Click (Sender:
TObject);ADOTable1BeforeDelete (DataSet: TDataSet);Button6Click (Sender:
TObject);
{Private declarations}
{Public declarations};:
TForm8;: boolean;
Unit6;
{$R *.dfm}TForm8.
Button3Click (Sender: TObject);. Text:='';. Text:='';. Text:='';.
Text:='';:=true;. Visible:=true;. Visible:=true;. Visible:=false;;TForm8.
Button1Click (Sender: TObject);(Edit1. Text<>'') and
(Edit2. Text<>'')
and
(Edit3. Text<>'')
and
(Edit4. Text<>'')flag=true
then ADOTable1. InsertADOTable1. Edit;. FieldValues['Должность']:=Edit1.
Text;. FieldValues ['Фиксир з/п в час']:=Edit2. Text;. FieldValues ['Раб часы
в день']:=Edit3. Text;. FieldValues ['Раб дни
в неделе']:=Edit4. Text;StrToInt (Edit3. Text)>24 then('Неверно введено значение в поле Раб часы в день');
DataSource1. DataSet.
Cancel();();;StrToInt (Edit4. Text)>7 then
ShowMessage ('Неверно введено
значение в поле Раб дни в неделе');
DataSource1. DataSet.
Cancel();();;. Post();ShowMessage ('Необходимо заполнить поля
ввода');;TForm8.
Button4Click (Sender: TObject);:=false;. Visible:=true;. Visible:=true;.
Visible:=false;. Text:=ADOTable1. FieldValues['Должность'];. Text:=ADOTable1. FieldValues ['Фиксир з/п в час'];. Text:=ADOTable1. FieldValues ['Раб часы
в день'];. Text:=ADOTable1. FieldValues ['Раб дни
в неделе'];;TForm8. Button5Click (Sender: TObject);.
Delete;;TForm8.ADOTable1BeforeDelete (DataSet: TDataSet);:real;:=MessageDlg ('Хотите удалить текущую запись в базе данных?', mtConfirmation, [mbYes, mbNo], 0);Del<>mrYesbegin.
Cancel();();;;TForm8. Button2Click (Sender: TObject);. Text:='';. Text:='';.
Text:='';. Text:='';;TForm8. Button6Click (Sender: TObject);. Close;;.
unit Unit10;, Messages,
SysUtils, Variants, Classes, Graphics, Controls, Forms,, DB, ADODB, ExtCtrls,
DBCtrls, Grids, DBGrids, StdCtrls;= class(TForm): TDataSource;: TDBGrid;:
TDBNavigator;: TADOTable;: TPanel;: TLabel;: TLabel;: TLabel;: TLabel;: TEdit;:
TButton;: TButton;: TButton;: TButton;: TButton;: TLabel;: TLabel;: TButton;: TComboBox;:
TComboBox;: TComboBox;: TEdit;: TLabel;: TEdit;: TButton;Button6Click (Sender:
TObject);Button3Click (Sender: TObject);Button4Click (Sender:
TObject);Button1Click (Sender: TObject);Button5Click (Sender:
TObject);ADOTable1BeforeDelete (DataSet: TDataSet);Button2Click (Sender:
TObject);Button7Click (Sender: TObject);
{Private declarations}
{Public declarations};:
TForm10;: boolean;Unit4, Unit5, Unit6;
{$R *.dfm}TForm10.
Button6Click (Sender: TObject);. Close;;TForm10. Button3Click (Sender:
TObject);. Text:='';. Text:='';. Text:='';. Items. Clear;. Text:='';. Items.
Clear;. Text:='';. Items. Clear;.ADOTable1. Open;.ADOTable1. First;.ADOTable1.
Open;.ADOTable1. First;.ADOTable1. Open;.ADOTable1. First;not Form4.ADOTable1.
Eof do. Items. Add (Form4.ADOTable1. FieldValues['Фирма']);.ADOTable1.
Next;;not Form5.ADOTable1. Eof do. Items. Add (Form5.ADOTable1. FieldValues ['Наименование услуги']);.ADOTable1.
Next;;not Form6.ADOTable1. Eof do. Items. Add (Form6.ADOTable1. FieldValues ['ФИО сотрудника']);.ADOTable1.
Next;;:=true;. Visible:=true;. Visible:=true;. Visible:=false;;TForm10.
Button4Click (Sender: TObject);:=false;. Visible:=true;. Visible:=true;.
Visible:=false;. Text:=ADOTable1. FieldValues['Количество'];. Text:=ADOTable1. FieldValues ['Дата заказа'];. Text:=ADOTable1. FieldValues['Клиент'];. Items. Clear;. Text:=ADOTable1. FieldValues ['Наименование услуги'];. Items. Clear;.
Text:=ADOTable1. FieldValues ['ФИО сотрудника'];. Items. Clear;.ADOTable1. Open;.ADOTable1. First;.ADOTable1.
Open;.ADOTable1. First;.ADOTable1. Open;.ADOTable1. First;not Form4.ADOTable1.
Eof do. Items. Add (Form4.ADOTable1. FieldValues['Фирма']);.ADOTable1.
Next;;not Form5.ADOTable1. Eof do. Items. Add (Form5.ADOTable1. FieldValues ['Наименование услуги']);.ADOTable1.
Next;;not Form6.ADOTable1. Eof do. Items. Add (Form6.ADOTable1. FieldValues ['ФИО сотрудника']);.ADOTable1.
Next;;;TForm10. Button1Click (Sender: TObject);(Edit1. Text<>'') and
(Edit2. Text<>'')
and
(Combobox1.
Text<>'') and
(Combobox2.
Text<>'') and
(Combobox3.
Text<>'')flag=true then ADOTable1. InsertADOTable1. Edit;. FieldValues['Количество']:=Edit1.
Text;. FieldValues ['Дата заказа']:=Edit2. Text;. FieldValues['Клиент']:=Combobox1. Text;. FieldValues ['Наименование услуги']:=Combobox2. Text;. FieldValues ['ФИО сотрудника']:=Combobox3. Text;. Post();ShowMessage ('Необходимо заполнить поля ввода');;TForm10.
Button5Click (Sender: TObject);. Delete;;TForm10.ADOTable1BeforeDelete
(DataSet: TDataSet);:real;:=MessageDlg ('Хотите удалить текущую запись
в базе данных?', mtConfirmation, [mbYes, mbNo], 0);Del<>mrYesbegin.
Cancel();();;;TForm10. Button2Click (Sender: TObject);. Text:='';. Text:='';.
Text:='';. Text:='';. Text:='';;TForm10. Button7Click (Sender: TObject);
{Form5.ADOTable1.
Open;.ADOTable1. First;not Form5.ADOTable1. Eof doForm5.ADOTable1. FieldValues
['Наименование услуги']=ADOTable1.
FieldValues ['Наименование услуги'] then. Text:=IntToStr (StrToInt(ADOTable1. FieldValues['Количество'])+StrToInt
(Form5.ADOTable1. FieldValues['Стоимость']));.ADOTable1. Next;;};.
Unit11;, Messages,
SysUtils, Variants, Classes, Graphics, Controls, Forms,, DB, ADODB, StdCtrls,
Grids, DBGrids, ExtCtrls, DBCtrls;= class(TForm): TComboBox;: TComboBox;:
TEdit;: TDataSource;: TDBGrid;: TButton;: TADOTable;: TDBNavigator;: TLabel;:
TButton;ComboBox1Change (Sender: TObject);ComboBox2Change (Sender:
TObject);Button1Click (Sender: TObject);Button2Click (Sender: TObject);
{Private declarations}
{Public declarations};:
TForm11;, strIndex1, strText1: string;
{$R *.dfm}TForm11.
ComboBox1Change (Sender: TObject);. Enabled:=false;. Enabled:=false;.
Enabled:=false;. Text:='';. Items. Clear;. Text:='Выберите поле';ComboBox1.
ItemIndex of
:. Items. Add ('Код клиента');. Items. Add('Фирма');. Items. Add ('Контактное лицо');. Items. Add('Телефон');. Items. Add('Адрес');. Items. Add
('e-mail');:='client';;
:. Items. Add ('Код услуги');. Items. Add ('Наименование услуги');. Items. Add('Стоимость');. Items. Add ('Ед измерения');:='uslugi';;
:. Items. Add ('Код заказа');. Items. Add('Клиент');. Items. Add ('Наименование услуги');
ComboBox2. Items. Add('Количество');.
Items. Add ('ФИО
сотрудника');.
Items. Add ('Дата
заказа');:='zakaz';;
:. Items. Add ('Код сотрудника');.
Items. Add ('ФИО
сотрудника');.
Items. Add('Должность');. Items. Add('Телефон');. Items. Add('Адрес');. Items. Add ('e-mail');:='sotrud';;
:. Items. Add('Должность');.
Items. Add ('Фиксир з/п в час');
ComboBox2. Items. Add ('Раб часы в день');. Items. Add ('Раб дни
в неделе');:='dolzhn';;
:. Items. Add ('ФИО сотрудника');.
Items. Add ('Причина вычета');. Items. Add('Вычет');:='vichet';;;. Enabled:=true;;TForm11. ComboBox2Change (Sender:
TObject);. Enabled:=true;. Enabled:=true;. Caption:='Введите значение';;TForm11.
Button1Click (Sender: TObject);:= ComboBox2. Text;:= Edit1. Text;.
Active:=false;. TableName:=vibor;. DataSet:=ADOTable1;. Active:=true;not
AdoTable1. Locate (strIndex1, strText1, [loCaseInsensitive, loPartialKey])
then. Active:=false;(strText1 + ' не найдено в ' + strIndex1);;;TForm11. Button2Click (Sender: TObject);.
Close;;.