Я, Долгов Артем Юрьевич проходил преддипломную практику в БК «ФОН». Целью дипломной работы является разработка программы для обеспечения быстрого и многофункционального доступа к базам данных предприятия и поэтому решил выбрать тему создание базы данных строительной компании «Красногорскстрой» для информации, где построены новые дома ,детские сады ,школы.
Однако создание базы данных осуществлялся в Microsoft Access не в полном объеме и отнимал много времени, поэтому мною было решено автоматизировать данный процесс, путем разработки специализированного программного обеспечения для баз данных предприятия БК ”ФОН”.
Таким образом, выбранная тема дипломного проекта «Создание базы данных строительной компании «Красногорскстрой» является актуальной.
Разрабатываемое ПО позволяет осуществлять загрузку и просмотр информации базы данных. Удобный и интуитивно понятный интерфейс, который позволит с легкостью найти, удалить, редактировать, добавить, построить график.
Для разработки ПО необходимо было решить ряд задач, а именно:
- Разработать укрупненную структурную схему.
- Выбрать язык и среду программирования.
- Реализовать удобный пользовательский интерфейс.
4. Провести отладку и тестирование разработанного ПО.
5. Составить пояснительную записку согласно правилам оформления текстовой документации.
1Техническое задание на разработку программного продукта
1.1 Основание для разработки
Основанием для данной работы является задание, выданное на дипломный проект для разработки базы банных строительной компании «Красногорскстрой ». Задание для дипломного проектирования выдано в соответствии с работами на предприятии «ИП Абасова» и утверждено зам. директора.
1.1.2 Назначение разработки
База данных для просмотра новых жилых домах ,служебных помещений, добавления, удаления и редактирования данных.
2 Требования к программе
2.1 Требования к функциональным характеристикам
Программа должна:
- отображать таблицы;
- добавлять записи;
- удалять старые;
- редактировать записи;
- система поиска.
2.2 Требования к надежности
Программа должна работать с базой данных в соответствии с алгоритмом функционирования, поддерживать диалоговый режим в рамках предоставляемых пользователю возможностей.
1.2.3 Условия эксплуатации
Скопировать программу в любое место на компьютере. Запустить программу с помощью файла с расширением ЕХЕ. Для удобства можно отправить файл с расширением ЕХЕ на рабочий стол.
Создание технического задания на разработку информационной системы
... разработки технического задания является задание к курсовой работе по курсу "Проектирование информационных систем". Наименование темы разработки - "Разработка информационной системы агентства по продаже и бронированию авиабилетов" Условное обозначение темы разработки (шифр темы) - "ИС ... доступа пользователя на уровне функций и массивов данных при работе с системой. Требования по сохранности ...
2.4 Требования к составу и параметрам технических средств
Программа должна быть рассчитана на пользователя имеющего навыки работы с БД.
Для работы программы должен быть выделен ответственный оператор.
Минимальные технические требования к ЭВМ, необходимой для нормального функционирования программного обеспечения:
1) Процессор Pentium III
2) Частота 600 Mhz
Оперативная память 128Mb
4) Видеокарта 64Мb
Клавиатура и мышь
Рекомендуемые технические требования:
Процессор Pentium IV
2) Частота 1000 Mhz
Оперативная память 256Mb
4) Видеокарта 128Мb
Клавиатура и мышь
2.5 Требования к информационной и программной совместимости
Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3.
2.6 Технико-экономические показатели
Эффективность программного обеспечения определяется удобством его использования для учета, редактирования, добавления и изменения данных а также экономической выгодой, полученной от внедрения данной программы.
2.7 Стадии и этапы разработки
Стадии этапы разработки велись в соответствии с установленными сроки выполнения работы (таблица 1).
Таблица 1. Стадии и этапы разработки
|
Этап |
Наименование работ |
Чем заканчивается работа |
Срок исполнения, начало окончание |
|
1 |
Анализ задания на технологической практике и подготовка раздела «Введение» |
Написание раздела «Введение» |
14.04.12 15.04.12 |
|
2 |
Подготовка раздела «Техническое задание» |
Написание раздела «Техническое задание» |
15.04.12 18.04.12 |
|
3 |
Подготовка раздела «Постановка задачи» |
Написание раздела «Постановка задачи» |
21.04.12 22.04.09 |
|
4 |
Разработка функциональной схемы модуля |
Наличие функциональной схемы модуля |
22.04.12 24.04.12 |
|
5 |
Разработка программы |
Разработка программы |
24.04.12 26.05.12 |
|
6 |
Тестирование программы |
Готовая рабочая программа |
26.05.12 28.05.12 |
|
7 |
Подготовка разделов «Заключение» и «Список литературы» |
Наличие готовых разделов |
02.06.12 06.06.12 |
|
8 |
Разработка презентационного материала |
Презентационный материал, выполненный в виде слайдов |
08.06.12 09.06.12 |
Руководитель преддипломной практики: Студенова О. В.
2.8 Выбор языка программирования
Для разработки программного продукта на тему дипломного проект мною была выбрана такая среда программирования, как Borland Delphi 7, которая является универсальным средством для создания Windows приложений. Delphi 7 обладает большим набором достоинств по сравнению с остальными средами программирования.
Он представляет собой быстрый компилятор, является объектно-ориентированным языком программирования, обладающий интуитивной и понятной средой визуального программирования, так же обладает большим наборов компонентов для создания приложений, представляет возможность создания приложений, предоставляет возможность создания приятного и, в то же время, многофункционального интерфейса, дает большие возможности для разработки API-приложений, Web-сервисов и работы с базами данных различных платформ, в частности с Microsoft Access, а так же с SQL-запросами. Это лишь некоторые основные возможности Delphi 7, которые повлияли на мой выбор.
Глава 2. Основная часть
1 Описание программы
1.1 Общие сведения
Наименование: Разработка базы банных строительной компании «Красногорскстрой».
Данная программа предназначена для просмотра товаров на предприятии, позволяющие пользователю выполнять действия по добавлению, удалению, редактированию, поиску и сортировки записей.
Программное обеспечение: ОС MS Windows 95, 98, 2000, XP;Процессор: не ниже Pentium166.
Базовый язык программирования Delphi 7.
Начальная стадия разработки интерфейса происходила совместно с разработкой программы и написанием алгоритма, интерфейс показан на рисунке 1
Рисунок 1. Интерфейс программы(главная форма)
- Пункт меню с вкладками «Файл».
- Выводит форму на которой отображается таблица «Жилые дома».
- Выводит форму на которой отображается таблица «Муниципальная собственность».
- Выводит форму на которой отображается таблица «Соцзащита».
- Выводит форму на которой отображается таблица «служебные помещения».
- Календарь.
1.2 Функциональное назначение
Программа предназначена для просмотра новых жилых домов, служебных помещений, нежилых помещений.
Программа отображает четыре таблицы, в первой таблице отображаются новые жилые дома , во второй список служебных помещений , в третьей муниципальная собственность и в четвертой квитанции об оплате в соцзащите. Все записи могут редактироваться.
1.3 Описание логической структуры
В состав данной программы входят следующие модули:
- Главный модуль.
1) открытие других модулей (unit1, unit2, unit5, unit6, unit7, unit8, unit9, unit10, unit11, unit12);
2) Form1 открывается при нажатии на картинку на Form2;
3) Form2 открывается после нажатия на кнопку Добавить или Изменить на Form1;
4) Form5 открывается после нажатия кнопки Жилые дома на Form1;
5) Form6 открывается после нажатия кнопки Служебные помещения на Form1;
6) Form7 открывается при нажатии на кнопку муниципальная собственность на Form1;
7) Form8 открывается при нажатии на кнопку соцзащита на Form1;
8) Form9 открывается при нажатии на кнопку с Form5
2.1.4 Используемые технические средства
Минимальные технические требования к ЭВМ, необходимой для нормального функционирования программного обеспечения:
1) Процессор Pentium III
2) Частота 600 Mhz
3) Оперативная память 128Mb
4) Видеокарта 64Мb
Клавиатура и мышь
1.5 Входные данные
(в программировании)
1.6 Выходные данные
Выходные данные — это результат ввода входных данных. Это то, что выводиться на мониторе ЭВМ в результате работы и выполнения опредёлённых действий в ходе работы программы. Все данные отображается в двух DBGRID которые отображают разную информацию в зависимость от введенных данных во время работы программ.
1.7 Условия применения
Для работы в диалоговом режиме используется экран дисплея, клавиатура и манипулятор типа «мышь». Для поддержки графического режима необходим видеоадаптер VGA. Входные данные хранятся на жестком диске. Программа работает под управлением ОС Windows 98 (и выше).
2 Руководство системного программиста
2.1 Общие сведения о программе
Минимальные технические требования к ЭВМ, необходимой для нормального функционирования программного обеспечения:
1) Процессор Pentium III
Частота 600 Mhz
9) Оперативная память 128Mb
10) Видеокарта 64Мb
Клавиатура и мышь
2.2 Используемые программные средства.
Запуск программы осуществляется на ОС Windows XP и более поздних её версиях. Среда разработки — Borland Delphi 7.
2.2.3 Структура таблиц базы данных предприятия
Предоставлены диаграммы связей таблиц базы данных.
В базе данных четыре таблицы (рисунок 3 ,4 ,5 ,6).
Рисунок 2. Схема данных
Рисунок 3. Таблица 1 — Жилые дома
Рисунок 4. Таблица 2 — муниципальная собственность
Рисунок 5. Таблица 3 — служебные помещения
2.2.4 Этап разработки программы
Разработка программы «создание базы данных строительной компании «Красногорскстрой» » является актуальной, начинается с создания нового проекта. Создаём новый проект («File» -> «New Application») и сразу изменяем заголовок и иконку exe файла программы (рис. 6).
Иконка была выбрана в соответствии с целью разработки.
Рисунок 6. Создание нового проекта
Далее на форме Form1 добавляются компоненты:
Один TADOConnection, TADPQuery, TDataSourse которые взяты с закладки ADO.
На втором этапе добавляются четыре кнопки Tbutton взятый из закладки Standart.
На третьем этапе добавляется TMainMenu.
На четвертом этапе добавляются savedialog , opendialog, printdialog,
На пятом monthcalendar
Результатом выше перечисленных действий становится первоначальный интерфейс программы (рисунок 6).
Рисунок 6. Первоначальный интерфейс программы
На шестом этапе создается четыре таблицы с помощью Microsoft Office Access: Жилые дома , служебные помещения , муниципальная собственность и соцзащита.
На седьмом этапе в событиях выставляется последовательности для отображения таблиц из созданной таблицы Microsoft Office Access.
На Form1 создаем объект TImage с закладки Additional.
На этом этапе происходит оформление интерфейса на Form1.(рисунок 7)
Рисунок 7. Оформление интерфейса главной формы
Происходит создание Unit2. Для этого создаём новый проект («File» -> «Form»).
На Form2 объекты:
- TImage;
- Оформление интерфейса окна Form2. (рисунок 8)
Рисунок 8. Оформление окна формы
Происходит создание Unit5. Для этого создаём новый проект («File» -> «Form»).
На Form5 добавляются объекты:
Один TADOConnection, TADPQuery, TDataSourse которые взяты с закладки ADO.
На втором этапе добавляется компонент TDBGrid взятый из закладки Data Controls.
На Form5 создаем объект TImage с закладки Additional.
добавляем 2 label и 2 edit с закладки Standart
На этом этапе происходит оформление интерфейса на Form1.(рисунок 9)
Рисунок 9. Оформление интерфейса Form5.
Происходит создание Unit6. Для этого создаём новый проект («File» -> «Form»).
На Form6 добавляется объекты:
Один TADOConnection, TADPQuery, TDataSourse которые взяты с закладки ADO.
На втором этапе добавляется компонент TDBGrid взятый из закладки Data Controls.
На Form6 создаем объект TImage с закладки Additional.
Добавляем 2 label и 2 edit с закладки Standart
Оформление интерфейса окна Form6. (рисунок 10)
Рисунок 10. Оформление интерфейса Form6
Происходит создание Unit7. Для этого создаём новый проект («File» -> «Form»).
На Form7 добавляется объекты:
Один TADOConnection, TADPQuery, TDataSourse которые взяты с закладки ADO.
На втором этапе добавляется компонент TDBGrid взятый из закладки Data Controls.
На Form6 создаем объект TImage с закладки Additional.
добавляем 2 label и 2 edit с закладки Standart
Оформление интерфейса окна Form7. (рисунок 11)
Рисунок 11. Оформление интерфейса Form7
Происходит создание Unit8. Для этого создаём новый проект («File» -> «Form»).
На Form8 добавляются объекты:
Один TADOConnection, TADPQuery, TDataSourse которые взяты с закладки ADO.
На втором этапе добавляется компонент TDBGrid взятый из закладки Data Controls.
На Form8 создаем объект TImage с закладки Additional
добавляем 2 label и 2 edit с закладки Standart
Оформление интерфейса окна Form8. (рисунок 12)
Рисунок 12. Оформление интерфейса Form8
Происходит создание Unit9. Для этого создаём новый проект («File» -> «Form»).
На Form9 объекты:
- Button;
- Для печати записей.
Memo;
- Для отображения данных;
- PrinterSetupDialog;
- PrintDialog;
- Для печати;
- Оформление интерфейса окна Form9. (рисунок 13)
Рисунок 13. Оформление интерфейса Form9
Написание алгоритма для главной формы.
Написание алгоритма для второй формы.
Написание алгоритма для пятой формы.
Написание алгоритма для шестой формы.
Написание алгоритма для седьмой формы.
Написание алгоритма для восьмой формы.
Написание алгоритма для девятой формы.
2.2.5 Настройка программы
Для работы программы требуется скопировать программу с прилагаемого носителя на компьютер. Запустить EXE файл из папки и для удобства её можно поместить на рабочий стол для быстрого запуска.
2.2.6 Проверка программы
2.2.6.1 Общие сведения о тестировании
Тестирование программного обеспечения — процесс выявления ошибок в программном обеспечении (ПО).
Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью устранить все дефекты и ошибки и установить корректность функционирования анализируемой программы особенно в закрытых частных программах. Поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.
Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют, с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
Тестирование ПО — попытка определить, выполняет ли программа то, что от неё ожидают. Как правило, никакое тестирование не может дать абсолютной гарантии работоспособности программы в будущем. Для наглядности: почти все производители коммерческого ПО исправляют ошибки в своих продуктах. Например: Корпорация Microsoft выпускает пакеты обновлений («Service Pack»), для своих операционных систем. Разработчики игр регулярно выпускают «патчи» для своих продуктов. Большинство разработчиков ПО после устранения ошибок выпускают обновлённую (новую) версию своей программы.
Тестирование программного обеспечения.
Уровни тестирования.
Модульное тестирование (юнит-тестирование) тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.
Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
Системное тестирование — тестируется интегрированная система на её соответствие требованиям.
Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.
Бета-тестирование — в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей. Часто для свободного/открытого ПО стадия Альфа-тестирования характеризует функциональное наполнение кода, а Бета тестирования — стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.
Тестирование «белого ящика» и «чёрного ящика».
В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.
При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.
При тестировании чёрного ящика тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Как правило, в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).
Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели. Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию).
Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску, чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы/процесса).
Статическое и динамическое тестирование описанные выше техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.
При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях, анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).Также к статическому тестированию относят тестирование требований, спецификаций, документации.
Регрессионное тестирование.
После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования.
Тестовые скрипты.
Тестировщики пишут и используют тестовые скрипты в юнит-, системном и регрессионном тестировании. Тестовые скрипты нужно писать для модулей с наивысшим риском появления отказов и наибольшей вероятностью того что этот риск станет проблемой.
Покрытие кода.
Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и/или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.).
Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов. Тестировщики могут использовать результаты теста покрытия кода для разработки тестов или тестовых данных, которые расширят покрытие кода на важные функции.
Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях. Разработка через тестирование (test-driven development).
Разработка через тестирование (англ. test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования. Ни один программист не считает работу над некоторым фрагментом кода завершенной, не проверив перед этим его работоспособность. Однако, если вы тестируете свой код, это не означает, что у вас есть тесты. Тест — это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. Когда программист проверяет работоспособность разработанного им кода, он выполняет тестирование вручную. В данном контексте тест состоит из двух этапов: стимулирование кода и проверки результатов его работы.
Автоматический тест выполняется иначе: вместо программиста стимулированием кода и проверкой результатов занимается компьютер, который отображает на экране результат выполнения теста: код работоспособен или код неработоспособен. Методика разработки через тестирование(Test-Driven Development, TDD) позволяет получить ответы на вопросы об организации автоматических тестов и выработке определенных навыков тестирования.
«Чистый код, который работает» — в этой короткой, но содержательной фразе, кроется весь смысл методики разработки приложений через тестирование. Чистый код, который работает, — это цель, к которой стоит стремиться, и этому есть причины: Это предсказуемый способ разработки программ. Разработчик знает, когда работу следует считать законченной, и можете не беспокоиться о длинной череде ошибок. У разработчика появляется шанс усвоить уроки, которые преподносит ему код. Если он воспользуется первой же идеей, которая пришла ему в голову, у него не будет шанса реализовать вторую, лучшую идею. Коллеги по команде могут рассчитывать на разработчика, а он, в, свою очередь, на них. Разработчику приятнее писать такой код.
Однако как мы можем получить чистый код, который работает? Очень многие силы мешают нам добиться этого, а иногда нам не удается получить даже код, который работает. Чтобы избавиться от множества проблем, мы будем разрабатывать код, исходя из автоматических тестов.
Такой стиль программирования называется разработкой через тестирование.
В рамках этой методики мы:
Пишем новый код только тогда, когда автоматический код не сработал.
Удаляем дублирование.
Два столь простых правила на самом деле генерируют сложное индивидуальное и групповое поведение со множеством технических последствий.
Проектируя код, мы постоянно запускаем его и получаем представление о том, как он работает, это помогает нам принимать правильные решения. Мы самостоятельно пишем свои собственные тесты, так как мы не можем ждать, что кто-то другой напишет тесты для нас. Наша среда разработки должна быстро реагировать на небольшие модификации кода.
Архитектура программы должна базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование кода упрощается.
Два упомянутых правила TDD определяют порядок этапов программирования:
Красный — напишите небольшой тест, который не работает, а возможно, даже не компилируется.
Зеленый — заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
Рефакторинг — удалите из написанного вами кода любое дублирование. Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными. Заставив тест работать, мы знаем, что теперь тест работает , отныне и навеки. Мы стали на шаг ближе к завершению работы, чем мы были до того, как тест сработал. После этого мы заставляем второй тест работать, затем третий, четвертый и т.д. Чем сложнее проблема, стоящая перед программистом, тем меньшую область функциональности должен покрывать каждый тест.
Определенно существуют задачи, которые невозможно(по крайней мере, на текущий момент) решить только при помощи тестов. В частности, TDD не позволяет механически продемонстрировать адекватность разработанного кода в области безопасности данных и взаимодействия между процессами. Безусловно, безопасность основана на коде, в котором не должно быть дефектов, однако она основана также на участии человека в процедурах защиты данных. Тонкие проблемы, возникающие в области взаимодействия между процессами, невозможно с уверенностью воспроизвести, просто запустив некоторый код.
Терминология, связанная с модульными тестами
Разработка через тестирование — процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.
Модульные тесты — Unit Tests, Programming Tests, Developer Tests — тесты, проверяющие функциональность отдельных классов, компонентов, модулей приложения. Эти тесты не видны конечному заказчику или доменному эксперту. Обычно их начинают писать после оформления функциональных тестов.
Зеленая/Красная полоса — многие графические среды для выполнения модульных тестов отображают результат выполнения тестов в виде линии, которая окрашена в зеленый цвет, если все тесты выполнились удачно, и красной, если были ошибки.
Моки, Мок-объекты (MockObjects) — автоматически генерируемые заглушки, которые могу выступат в роли реальных объектов. Поведением моков можно управлять непосредственно в тесте. Моки могут выполнять дополнительные проверки, что тестируемый код их использовал, как ожидалось.
Модульный тест — тест, который проверяет поведение небольшой части приложения. Эта часть может быть одним классом, одним методом или набором классов, который реализуют какое-то архитектурное решение, и это решение необходимо проверить на работоспособность.
Тест — TestCase — набор тестовых методов, предназначенных для тестирования одного класса (в среде xUnit).
Обычно TestCase состоит из методов, чье имя начинается с приставки test. Каждый такой метод тестирует какой-либо один момент тестируемого класса. В приемочном тестировании TestCase — это набор команд, которые тестируют одну значимую для заказчика функциональность.
Фикстура — Fixture — состояние среды тестирования, которое требуется для успешного выполнения тестового метода. Это может быть набор каких-либо объектов, состояние базы данных, наличие определенных файлов и т.д. Фикстура создается в методе setUp() перед каждым вызовом метода вида testSomething теста (TestCase) и удаляется в tearDown() после окончания выполнения тестового метода.
Проверка — Assert — метод класса TestCase, который предназначен для сверки реального состояния тестируемого кода с ожидаемым.
Терминология, связанная с наборами тестов
Набор тестов — TestSuite — набор тестов, предназначенный для тестирования какой-либо укрупненной сущности программной системы. В SimpleTest есть понятие TestGroup, которые практически эквивалентно понятию TestSuite. Иногда TestSuite употребляют в значении «все тесты, которые есть для приложения».
Терминология, связанная с приемочными тестами.
Приемочные (функциональные) тесты — Customer tests, Acceptance tests — тесты, проверяющие функциональность приложения на соответствие требованиям заказчика. Приемочные тесты не должны ничего знать о деталях реализации приложения. Приемочные тесты заменяют ТЗ при использовании методики экстремального программирования (XP).
Регрессионный тесты — тесты, которые проверяют, что поведение системы не изменилось.
На самом деле, большинство регрессионных тестов являются или модульными или функциональными тестами, которые включаются в определенный набор тестов (RegressionTestSuite), который гарантирует, что функциональность системы не будет случайно изменена.
Каждому программисту известно, сколько времени и сил уходит на отладку и тестирование программ. На этот этап приходится около 50% общей стоимости разработки программного обеспечения.
Но не каждый из разработчиков программных средств может верно определить цель тестирования. Нередко можно услышать, что тестирование — это процесс выполнения программы с целью обнаружения в ней ошибок. Но эта цель недостижима: ни какое самое тщательное тестирование не дает гарантии, что программа не содержит ошибок.
Другое определение тестирования (у Г. Майерса): тестирование — это процесс выполнения программы с целью обнаружения в ней ошибок. Такое определение цели стимулирует поиск ошибок в программах. Отсюда также ясно, что “удачным” тестом является такой, на котором выполнение программы завершилось с ошибкой. Напротив, “неудачным можно назвать тест, не позволивший выявить ошибку в программе.
2.6.2 Виды тестирования
Тестирование модуля, или автономное тестирование (module testing, unit testing) — контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей).
Тестирование сопряжении (integration testing) — контроль сопряжении между частями системы (модулями, компонентами, подсистемами).
Тестирование внешних функций (external function testing) — контроль внешнего поведения системы, определенного внешними спецификациями.
Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.
Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.
Тестирование настройки (installation testing) — проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
По объекту тестирования:
- Функциональное тестирование (functional testing);
- Нагрузочное тестирование;
- Тестирование производительности (perfomance/stress testing);
- Тестирование стабильности (stability/load testing);
- Тестирование удобства использования (usability testing);
- Тестирование интерфейса пользователя (UI testing);
- Тестирование безопасности (security testing);
- Тестирование локализации (localization testing);
- Тестирование совместимости (compatibility testing).
По знанию системы:
Тестирование чёрного ящика (black box).
Тестирование белого ящика (white box).
Тестирование серого ящика (gray box).
По степени автоматизированности:
Автоматизированное тестирование (automated testing).
Полуавтоматизированное тестирование (semiautomated testing).
По степени изолированности компонентов:
- Компонентное (модульное) тестирование (component/unit testing);
2) Интеграционное тестирование (integration testing);
- Системное тестирование (system/end-to-end testing).
По времени проведения тестирования:
- Альфа тестирование (alpha testing);
- Тестирование при приёмке (smoke testing);
- Тестирование новых функциональностей (new feature testing);
- Регрессионное тестирование (regression testing);
- Тестирование при сдаче (acceptance testing);
- Бета тестирование (beta testing).
По признаку позитивности сценариев:
- Позитивное тестирование (positive testing);
- Негативное тестирование (negative testing).
2.2.6.3 Методы тестирования
1. Существует два основных вида тестирования: функциональное и структурное. При функциональном тестировании программа рассматривается как “черный ящик” (то есть ее текст не используется).
Происходит проверка соответствия поведения программы ее внешней спецификации.
Поскольку исчерпывающее функциональное тестирование невозможно, речь может идти о разработки методов, позволяющих подбирать тесты не “вслепую”, а с большой вероятностью обнаружения ошибок в программе.
2. При структурном тестировании программа рассматривается как “белый ящик” (т.е. ее текст открыт для пользования).
Происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей на графе передач управления программы (ее управляющем графе).
Даже для средних по сложности программ числом таких путей может достигать десятков тысяч. Если ограничиться перебором только линейных не зависимых путей, то и в этом случае исчерпывающее структурное тестирование практически невозможно, т. к. неясно, как подбирать тесты , чтобы обеспечить “покрытие” всех таких путей.
Поэтому при структурном тестировании необходимо использовать другие критерии его полноты, позволяющие достаточно просто контролировать их выполнение, но не дающие гарантии полной проверки логики программы.
3. Метод большого скачка
Вероятно, самый распространенный подход к интеграции модулей — метод “большого скачка”. В соответствии с этим методом каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу.
Метод большого скачка по сравнению с другими подходами имеет много недостатков и мало достоинств. Заглушки и драйверы необходимы для каждого модуля. Модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут остаться необнаруженными. Метод большого скачка значительно усложняет отладку.
И все же большой скачок не всегда нежелателен. Если программа мала и хорошо спроектирована, он может оказаться приемлемым. Однако для крупных программ метод большого скачка обычно губителен.
- Восходящее тестирование
При восходящем подходе программа собирается и тестируется снизу вверх. Только модули самого нижнего уровня (“терминальные” модули; модули, не вызывающие других модулей) тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопряжении программы.
При восходящем тестировании для каждого модуля необходим драйвер: нужно подавать тесты в соответствии с сопряжением тестируемого модуля. Одно из возможных решений — написать для каждого модуля небольшую ведущую программу. Тестовые данные представляются как “встроенные” непосредственно в эту программу переменные и структуры данных, и она многократно вызывает тестируемый модуль, с каждым вызовом передавая ему новые тестовые данные.
Имеется и лучшее решение: воспользоваться программой тестирования модулей — это инструмент тестирования, позволяющий описывать тесты на специальном языке и избавляющий от необходимости писать драйверы.
2.2.6.4 Принципы тестирования
Майерсом сформулированы также основные принципы организации тестирования:
1. Необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы, чтобы можно было быстро выяснить наличие или отсутствие ошибки в ней.
2. Следует по возможности избегать тестирования программы ее автором, т.к. кроме уже указанной объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречит человеческой психологии ( однако отладка программы эффективнее всего выполняется именно автором программы ).
- По тем же соображениям организация — разработчик программного обеспечения не должна “единолично ” его тестировать (должны существовать организации, специализирующиеся на тестировании программных средств ).
4. Должны являться правилом доскональное изучение результатов каждого теста, чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе.
- Необходимо тщательно подбирать тест не только для правильных ( предусмотренных ) входных данных, но и для неправильных (непредусмотренных).
6. При анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать.
7. Следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика).
2.3 Руководство оператора
интерфейс программный тестирование оператор
2.3.1 Назначение программы
Программа предназначена для просмотра новых жилых домов, служебных помещений, муниципальной собственности.
Программа отображает четыре таблицы, в первой таблице отображаются новые жилые дома , во второй список служебных помещений , в третьей муниципальная собственность и в четвертой квитанции об оплате в соцзащите. Все записи могут редактироваться.
2.3.2 Условия выполнения программы
Условия необходимые для выполнения программы.
Минимальные:
1) Процессор Pentium III
2) Частота 600 Mhz
3) Оперативная память 128Mb
4) Видеокарта 64Мb
Клавиатура и мышь
3.3 Выполнение программы
Запуск «Project1.exe»( Рисунок 14)
Рисунок 14. Запуск проекта
Форма, открывающаяся при запуске проекта .(Рисунок 15)
Рисунок 15. Форма, открывающаяся при запуске проекта
На главной форме изображена картинка при нажатии которой открывается основная форма программы.
При нажатии картинки открывается главная форма.(Рисунок 16).
Рисунок 16. Главная форма
На главной форме четыре кнопке при нажатии на них открываются дополнительные формы с таблицами базы данных.
На этом рисунке показано все 4 таблицы. (Рисунок 17).
Рисунок 17. Четыре таблицы базы данных
При выборе страницы распечатать и нажатии кнопки печать открывается форма 9. (Рисунок 18).
Рисунок 18. Форма для печати
При нажатии на кнопку график на главной форме открывается таблица Excel .(Рисунок 19).
Рисунок 19. Таблица Excel
2.3.4 Сообщения оператору
Системные сообщения выводится, если пользователь хочет удалить запись.( Рисунок 20)
Рисунок 20. Форма сообщения
Системное сообщение выдается при закрытии программы. ( Рисунок 21).
Рисунок 21. Форма сообщения
Глава 3. Экономическая часть
Рассчитайте экономическую эффективность от создания программного продукта
Раздел 1. Расчет времени на создание программного продукта.
Раздел 2. Расчет годового фонда заработной платы исполнителя по созданию программного продукта.
Раздел 3. Расчет начислений на заработную плату (социальное страхование).
Раздел 4. Расчет расходов на содержание и эксплуатацию ПЭВМ.
Раздел 5. Расчет себестоимости программного продукта.
Раздел 6. Расчет цены программного продукта.
Раздел 7. Расчет экономической эффективности.
Имеются следующие исходные данные:
1. Подготовка описания задачи (Тпо) — 7 человеко /часов
2. Коэффициент учета изменения задач (В) — 1,3
- Количество дней в месяце — 30 дней
- Тарифный коэффициент, соответствующий разряду тарифной сетки по которому работает исполнитель = 1,3
- Балансовая стоимость ЭВМ, определяется исходя из цены и количества комплектующих изделий ЭВМ по рыночной стоимости
- Фэф — эффективный годовой фонд работы ПЭВМ в часах — 2016 часов
7. tp.д. — продолжительность рабочего дня в часах — 8 часов
1 Расчет времени на создание программного продукта
Затраты времени на создание программного продукта дает трудоемкость .
Трудоемкость измеряет человека в часах, в днях и она является обратным показателем производительности труда т.е снижая трудоемкость по большому счету повышается производительность труда который является единственным источником роста благосостояния личности хозяйственного субъекта и в целом экономики.
Структура общего времени на создание программного продукта представлена в табл.1
Таблица 1
|
№ этапа |
Обозначение времени данного этапа |
Содержание этапа |
|
1 |
Тпо |
Подготовка описания задачи |
|
2 |
То |
Описание задачи |
|
3 |
Та |
Разработка алгоритма |
|
4 |
Тбс |
Разработка блок-схемы алгоритма |
|
5 |
Тн |
Написание программы на языке … |
|
6 |
Тп |
Набивка программы |
|
7 |
Тот |
Откладка и тестирование программы |
|
8 |
Тд |
Оформление документации, инструкции пользователю, пояснительной записки |
Время рассчитывается в человеко-часах, причем Тпо берется по фактически отработанному времени (исходные данные), а время остальных этапов определяется расчетно по условному числу команд Q.
Условное число команд определяется по формуле:
Q=q*c (1)
где q — коэффициент, учитывающий условное число команд.
Выбрать значение где c — коэффициент, учитывающий новизну и сложность программы коэффициента q можно из табл.2
Таблица 2
|
Тип задачи |
Пределы измерений коэффициента |
|
Задачи учета |
от 1400 до 1500 |
|
Задачи оперативного управления |
от 1500 до 1700 |
|
Задачи планирования |
от 3000 до 3500 |
|
Многовариантные задачи |
от 4500 до 5000 |
|
Комплексные задачи |
от 5000 до 5500 |
Моя программная разработка соответствует следующему типу задачи: задачи учета. Следовательно, предел изменений коэффициента равен 1400.
Программные продукты по степени новизны отнесены к одной из 4-х групп:
группа А — разработка принципиально новых задач.
группа Б — разработка оригинальных программ.
группа В — разработка программ с использованием типовых решений.
группа Г — разовая типовая задача.
Моя программная разработка относится к группе Г.
По степени сложности программные продукты могут быть отнесены к одной из 3-х групп:
1- алгоритм оптимизации и моделирования систем;
2- задачи учета, отчетности и статистики;
3-стандартные алгоритмы.
Моя программная разработка по степени сложности относится к группе стандартных алгоритмов.
Коэффициент С определяется из табл.3 на пересечении групп сложности новизны.
Таблица 3
|
Язык программирования |
Группа сложности |
Степень новизны |
|||
|
А |
Б |
В |
Г |
||
|
Высокого уровня |
1 |
1,38 |
1,26 |
1,15 |
0,69 |
|
2 |
1,30 |
1,19 |
1,08 |
0,65 |
|
|
3 |
1,20 |
1,10 |
1,00 |
0,60 |
|
|
Низкого уровня |
1 |
1,58 |
1,45 |
1,32 |
0,79 |
|
2 |
1,49 |
1,37 |
1,24 |
0,74 |
|
|
3 |
1,38 |
1,26 |
1,15 |
0,69 |
|
Следовательно, Q=1450*0,60=870 чел/час
Определяем время, затраченное на каждый этап создания программного продукта: чел/час
1) Тпо берется по факту 7 чел/час
2) То определяется по формуле:
То=Q*B/(50*K) (2)
где В — коэффициент учета изменений задачи
К — коэффициент, учитывающий квалификацию программиста. Выбрать значение коэффициента К можно из табл.4
Таблица 4
|
Стаж программиста |
Значение коэффициента К |
|
до 2-х лет |
0,8 |
|
от 2 до 3 лет |
1,0 |
|
от 3 до 5 лет |
1,1 — 1,2 |
|
от 5 до 10 лет |
1,2 — 1,3 |
|
свыше 10 лет |
1,3 — 1,5 |
Тпо= 870 *1,3/(50*0,8)=28,3 чел/час (3)
3) Та рассчитываем по формуле:
Та=Q/(50*K) (4)
Та=870/(50*0,8)=22чел/час
4) Тбс определяется аналогично Та
Тбс=870/(50*0,8)=22чел/час (5)
Тн определяется по формуле:
Тн=Q*1,5/(50*K) (6)
Тн=870*1,5/(50*0,8)=32,5чел/час
Тп определяется по формуле:
Тп=Q/50 (7)
Тп=870/50=17,4 чел/час
Тот определяется по формуле:
Тот=Q*4,2/50*K (8)
Тот=870*4,2/50*0,8=91,4чел/час
Тд определяется аналогично Тпо
Тд=7чел/час
Теперь зная время, затраченное на каждом этапе, можно подсчитать общее время на создание программного продукта:
Т=Тпо+То+Та+Тбс+Тн+Тп+Тот+Тд (9)
Т=7чел/час+28,3 чел/час+22 чел/час+22 чел/час+32,5 чел/час+17,4 чел/час+91,4 чел/час+7 чел/час=227,6 чел/час
3.2 Расчет годового фонда заработной платы исполнителя по созданию программного продукта
Фонд заработной платы состоит из основной и дополнительной зарплаты.
Основная заработная плата включает оплату по отдельным расценкам, тарифным ставкам, должностному окладу, премии (40%).
Дополнительна заработная плата — это оплата отпусков (11,4%) доплата по территориальному коэффициенту (15%).
Основная ЗП определяется по формуле:
ЗПосн=(Х*Кт*Т/Чр*tp.д)*(1+П/100) (10),
где Х- среднемесячная ЗП программиста (руб)- определяется самостоятельно по рыночной ситуации(18 000 руб.);
- Кт- тарифный коэффициент, соответствующий разряду тарифной сетки по которому работает исполнитель (исходные данные);
- Т-общее время на создание программного продукта (чел/час);
- Чр- число рабочих дней в месяц (исходные данные);
- tp.д — продолжительность рабочего дня в часах;
- П — процент премии(40%).
ЗПосн=(18000*1,3*220,6чел/час)/30дн/мес.*8час/раб. дн.*(1+40/100)=
=31067,4руб
Дополнительная ЗП берется в размере 11,3% от основной.
ЗПдоп=ЗПосн*11,3% (11)
ЗПдоп=31067,4*11,3%=3510,6 руб.
Общая ЗП будет равна сумме основной и дополнительной:
ЗПобщая=ЗПосн+ЗПдоп (12)
ЗПобщая=31067,4+3510,6 =34578руб.
3 Расчет начислений на заработную плату (социальное страхование)
Социальное страхование в РФ является обязательным каждый хозяйствующий субъект, любой организационно правовой формы собственности отчисляет денежные средства в фонд ЗП во вне бюджетные фонды отчисляют на:
- Фонд социального страхования — 2,9 %
ФСС= ЗП общ*2,9%/100% (13)
ФСС=34578*2,9%/100%=1002,7 руб.
- Пенсионный фонд России — 22 %
ПФР= ЗП общ*22%/100% (14)
ПФР= 34578*22%/100%=7607,16 руб.
- Федеральный фонд обеспечения медицинского страхования — 5,1 %
ФФОМС= ЗП общ*5,1%/100% (15)
ФФОМС=34578*5,1%/100%=1763,5 руб.
ФСС+ПФР+ФФОМС=10373,36руб.
3.4 Расчет расходов на содержание и эксплуатацию ПЭВМ
Расходы на содержание и эксплуатацию ПЭВМ рассчитываются по следующим статьям:
Основная ЗП работников, обеспечивающих функционирование ПВЭМ.
Для системных программистов: Нобсл=25, Кт=2,02 , Х=31067,4руб
ЗПосн.год.=((Х*Кт/Нобсл.)*(1+П/100))*12 (16)
ЗПосн.год=(31067,4руб *2,02/25)*(1+40%/100%)*12мес=42172руб
Дополнительная ЗП обслуживающего персонала — 11,3% от основной заработной платы
ЗПдоп=42172*11,3%/100%=4765,4 руб.(за год)
Общая ЗП будет равна сумме основной и дополнительной:
ЗПобщая=ЗПосн+ЗПдоп (17)
ЗПобщ.год=42172+4765,4 =46937,4 руб.
3)Начисления на ЗП обслуживающего персонала (30%):
Нзп=ЗПгод.о.п*30% (18)
Нзп. год.= 46937,4 *0,3=14081,22руб.
Социальные отчисление с заработной платы вспомогательного персонала (30% от общей заработной платы)
Совп. год=(ЗПобщая год + Нзп год)*30%= 46937,4 *0,3=14081,22 руб.(19)
5) Амортизационные отчисления определяются в размере 25% от балансовой стоимости ПВЭМ (Кб)(исходные данные).
А=Кб*25 (20)
Балансовая стоимость ЭВМ равна 30000 руб. (в том числе: системный блок-22000 руб.; монитор-6000 руб.; комплектующие изделия-2000 руб.)
А= 30000*25%/100%=7500 руб. (моральный износ ЭВМ)
6)Затраты на электроэнергию:
Зс.эн(осв)=Фэф * Цэ * P (21)
Фэф — эффективный годовой фонд работы ПЭВМ в часах (исходные данные 2016 час)
Цэ — стоимость 1кВт/ч. (определяется самостоятельно исходя из рыночной стоимости)
P — мощность ПЭВМ с периферией в кВт/ч.
P= 0,7-1,2- в зависимости от периферии (определяется самостоятельно)
Зс.эн(осн)=2016час*3,65*1,0*0,8=5886,72 руб.
Расходы на профилактику составляют 2% от балансовой стоимости ПВЭМ с периферией.
Зпроф.=Кб*2% (22)
Зпроф=30000*0,02=600 руб.
Прочие производственные расходы берутся в размере 30% от основной ЗП работников, обеспечивающих функционирование ПВЭМ.
Ппр=42172*0,3=12651,6руб.
Зобщ.год=46937,4+12651,6+10373,3+5886,72+600+14081,22=90530,24 руб.
Сложив все компоненты, определяем годовые расходы на содержание и эксплуатацию 1-ой ПЭВМ.
Далее определяем себестоимость 1-го машино-часа работы ПВЭМ, которая определяется по формуле:
Смч .= (Зобщ/12мес*30дн*8час)*Т (23)
Смч=(90530,24 /12*30*8) 227,6 =7154,4руб.
5 Расчет себестоимости программного продукта
Себестоимость продукции представляет собой стоимостную оценку используемых в процессе производства продукции природных ресурсов, сырья, материалов, топлива, энергии, основных фондов, трудовых ресурсов, а также затрат связанных с реализацией.
В себестоимость программного продукта входят следующие элементы:
- Основная ЗП исполнителя работ по созданию программного продукта;
- Дополнительная ЗП исполнителя работ по созданию программного продукта;
Начисления на ЗП:
- Расходы на содержание и эксплуатацию ПВЭМ, относящихся к данному программному продукту;
- Прочие расходы.
Первые 4 элемента уже известны, а прочие расходы составляют 10% от суммы первых 4-х элементов.
Структуру себестоимости программного продукта опишите в таблице № 5
Таблица 5
|
№ |
Элементы себестоимости |
Сумма (руб.) |
% в общей сумме себестоимости |
|
1 |
Основная ЗП исполнителя |
31067,4 |
52% |
|
2 |
Доп. ЗП исполнителя |
3510,6 |
6% |
|
3 |
Начисления на ЗП |
10373,36 |
17% |
|
4 |
РС и ПЭВМ |
600 |
2% |
|
5 |
Прочие расходы (1+2+3+4)*10% |
4555,1 |
23% |
|
Итого: |
54661,56 |
100% |
3.6 Расчет цены программного продукта
Цена — это денежное выражение стоимости продукции.
Цена складывается из нескольких компонентов:
Ц=С+П+НДС (24)
где
С — себестоимость программного продукта
П — прибыль, которую берем в размере 40% от себестоимости
НДС- налог на добавленную стоимость, который берется в размере 18% от суммы себестоимости и прибыли.
П=54661,56*40%/100%=21864,6 руб.
НДС=(54661,56+21864,6)*0,18=13774,7 руб.
Ц=54661,56+21864,6 +13774,7 =90300,86 руб.
Эффективность это результативность т.е. получение результата с учетом затрат — более того с минимальными затратами трудовых, материальных, финансовых средств труда.
(более 15 %) (25)
∆ ПР = приблизительный рост прибыли за два года
∆ ПР= Пр отч.год — Пр прош.год
КВ — капитальные вложения = себестоимость программного продукта
Во втором году планируется увеличение прибыли с 40% до 65%, следовательно, планируемая прибыль за второй год составляет Ппр=54661,56*0,65=35530руб.
∆ П=35530-21864,6 =13665,4 руб.
Эа=13665,4 /54661,56=0,25=25%
Вывод: В экономической части ДП произведен расчет себестоимости и цены программного продукта «разработка базы банных строительной компании «Красногорскстрой» ».
Расчеты отвечают современным требованиям ведения бухгалтерского учета и плановой политики предприятия.
Создание программного продукта считается эффективным.
Тема дипломного проекта была выбрана в соответствии с заданием, выданном руководителем преддипломной практики.
В первой главе выполнены следующие задачи, а именно: конкретизирована постановка задачи, проведён обзор существующих решений и обоснован выбор языка программирования.
Во второй главе выполнены следующие задачи, а именно: разработана структурная схема, разработан интерфейс программного продукта, определены технические требования к оборудованию, на котором будет выполняться разработанная программа, проведён тест программного продукта, разработано оператора и руководство системного программиста.
В третьей главе выполнены следующие задачи, а именно:
Составленная смета затрат на программный продукт.
Подводя итоги выполненного задания, следует отметить, что в нём были достигнуты поставленная цель и задачи.
Список используемой литературы
[Электронный ресурс]//URL: https://inzhpro.ru/diplomnaya/baza-dannyih-stroitelnoy-firmyi/
1. ГОСТ 19.402 — 78. Описание программы.
2. ГОСТ 19.503 — 79. Руководство системного программиста. Требования к содержанию и оформлению.
3. ГОСТ 19.505 — 79. Руководство оператора. Требования к содержанию и оформлению.
4. ГОСТ 24.207 — 80. Требования к содержанию документов по программному обеспечению
5. Род Стивенс. Delphi. Готвые алгоритмы г. Санткт Петербург: издательство «Питер», 2004г. — 384с.
— Галисеев Г. В. Программирование в среде Delphi . Самоучитель;
-Жуков А. В. Изучаем Delphi. г. Санкт-Петербург: издательство «Питер», 2001 г. — 352 с.;
— Фаронов В. В. Delphi. Программирование на языке высокого уровня г. Санкт-Перетбург: издательство «Питер», 2007 г. — 640 с.;
— Бобровский С.И. Delphi — Учебный курс. г. Санкт-Петербург: издательство «Питер», 2004 г. — 736 с.;
10. www.edelphi.ru/ (интернет -источник)
— www.delphi.int.ru/ (интернет -источник)
— www.delphiexpert.ru/ (интернет -источник)
Приложение. Код программы
unit Unit1;
— interface, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, Menus, DB, StdCtrls, Grids, ComObj, DBGrids, ADODB, ExtCtrls, DBCtrls,, jpeg;= class(TForm): TADOConnection;: TADOQuery;: TMainMenu;: TButton;: TButton;: TButton;: TButton;: TDataSource;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TOpenDialog;: TSaveDialog;: TMenuItem;: TPrintDialog;: TButton;: TMonthCalendar;: TTimer;: TImage;: TLabel;btn1Click(Sender: TObject);btn2Click(Sender: TObject);btn3Click(Sender: TObject);btn4Click(Sender: TObject);Exit1Click(Sender: TObject);N3Click(Sender: TObject);FormClose(Sender: TObject; var Action: TCloseAction);Button1Click(Sender: TObject);Timer1Timer(Sender: TObject);Save1Click(Sender: TObject);N4Click(Sender: TObject);Print1Click(Sender: TObject);
{ Private declarations }
{ Public declarations };
— var: TForm1;Unit3, Unit2, Unit5, Unit6, Unit7, Unit8, Unit9;
— {$R *.dfm}TForm1.btn1Click(Sender: TObject);.show;.Active:=false;.SQL.clear;.sql.Add(‘select * from jilie’);.ExecSQL;.Active:=true;;
— TForm1.btn2Click(Sender: TObject);.show;.Active:=false;.SQL.clear;.sql.Add(‘select * from mun’);.ExecSQL;.Active:=true;;
— TForm1.btn3Click(Sender: TObject);.show;.Active:=false;.SQL.clear;.sql.Add(‘select * from sluj’);.ExecSQL;.Active:=true;;
— TForm1.btn4Click(Sender: TObject);.show;.Active:=false;.SQL.clear;.sql.Add(‘select * from soc’);.ExecSQL;.Active:=true;;
— TForm1.Button1Click(Sender: TObject);: Variant;:string;XL := CreateOLEObject(‘Excel.Application’); // Создание OLE объекта(‘Cannot start MS Excel.’);
— end;(0,AppLocation); // Возвращает текущий каталог диска
XL.WorkBooks.Open(AppLocation +’\Test.xls’);.visible := true;;
— TForm1.Exit1Click(Sender: TObject);
beginMessageBox(0,’Выйти из программы?’,’Выход из программы’, MB_YESNO) of
IDYES:.Close;;:;.Close;;
— TForm1.FormClose(Sender: TObject; var Action: TCloseAction);.close;;
— TForm1.N3Click(Sender: TObject);:string;.Connected:=false;
— dlgOpen1.Execute then:=dlgOpen1.FileNameShowMessage(‘Ошибка’);.ConnectionString:=’Provider=Microsoft.Jet.OLEDB.4.0;Data Source=’ +PathToDb+’;Persist Security Info=False’;.LoginPrompt := False;.Connected:=true;;;
— TForm1.N4Click(Sender: TObject);fn: string;
— if dlgsave1.Execute then
:= dlgsave1.FileName;Form1.dlgsave1.FilterIndex of
: fn:=ChangeFileExt(fn,’.txt’);;;;TForm1.Print1Click(Sender: TObject);.execute;;
— TForm1.Save1Click(Sender: TObject);not dlgsave1.Execute then exit;CopyFile(Pchar(dlgopen1.FileName),Pchar(dlgsave1.FileName+’.mdb’),true)ShowMessage(‘Фаил сохранен’)ShowMessage(‘Ошибка сохранения’);;
— TForm1.Timer1Timer(Sender: TObject);.Caption:=timetostr(time);
— end;
