Система управления автоматизированным тепличным хозяйством

65 часов *10  руб/час = 650 руб.

3. Накладные расходы. Инструкция по эксплуатации и пояснительная записка

Печать листов 48*1,5 руб. = 72 руб.

Итого: полная себестоимость программы = 1554,5 руб.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Выводы

1. Для данного проекта были проанализированы и выбраны программные средства разработки и поддержки проекта: среда Microsoft Visual Studio 2012, C#, SQL Compact. Описаны возможности данных средств разработки, которые сыграли решающую роль в пользу их выбора.
2. Наглядно представлена реализация проекта. Представлены основные модули ПП.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Анализ качества разработанного программного продукта

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

4.1. Тестирование на  стадии анализа и исследования предметной области

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

4.2. Тестирование на  стадии проектирования

В ходе тестирования программного продукта качество продукта определялось по следующим показателям:

• Правильность и полнота проектирования структуры программного продукта;
• Соответствие проекта предъявленным требованиям;
• Полнота описания проекта: все ли взаимосвязи между модулями и данными описаны;
• Удовлетворение системных ресурсов требованиям проекта;
• Соответствие выбранных инструментальных средств разработки;

При анализе данных факторов было установлено, что они соответствуют  требованиям проекта. Выбранные  системные ресурсы полностью  соответствуют данным требованиям, так как их выбор основывался на выборе среды разработки.

Также выбранная среда разработки Microsoft Visual Studio 2012 обладает всеми необходимыми возможностями для создания данного проекта.

4.3. Тестирование разработанного программного продукта

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

1. Модульное тестирование;
2. Интеграционное тестирование;
3. Альфа – тестирование;

4.3.1 Модульное тестирование

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

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

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

4.3.2 Интеграционное тестирование

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

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

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

4.4. Тестирование на  стадии внедрения ПП 

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

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

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

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

В рамках тестирования проекта использовался  только этап альфа тестирования.

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

При тестировании программного продукта вместе с автоматизированной теплицей основанной на микроконтроллере Arduino Uno. Было произведено 50 пробных запусков в ходе которых были обнаружены следующие ошибки.

Ошибки	Комментарии	Кол-во
Медленное отображение графиков	Медленно отображались графики  данных с датчиков в особенности  совмещенный график	2
Зависание при подключении к  контроллеру	Каждый раз при подключении  к контроллеру система на некоторое  время переставала отвечать на запросы пользователя	1
Некорректное сохранение настроек программы	Сохранение неверной информации о  влажности воздуха в базу данных	1
Ошибка при сохранении данных с  датчиков  в базу данных	Программа начала вызывать исключение после перехода класса взаимодействия с базой данных на технологию Linq To SQL	1

 

Разберем конкретно каждую из возникших  проблем. Первая из перечисленных проблем  возникала по причине присутствия  множества включенных ненужных визуальных эффектов в компоненте, таких как точки на графике и сглаживание. Следующая проблема возникала по причине выполнения подключения в том же потоке что и обращение к контроллеру. Это вызывало кратковременное зависание системы. Проблема была исправлена путем обращения к контроллеру в отдельном потоке. Третья проблема возникала из-за неправильного парсинга данных, полученных от контроллера. Последняя проблема связана с особенностями технологии Linq To SQL, возникало данное исключение из-за неправильного использования дополнительного потока. Выявленные ошибки и недочеты были учтены и исправлены.

4.5 Предложения по сопровождению  и улучшению качества разработанного  ПП

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

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

1. В связи с изменением функций проекта возможны изменения интерфейса
2. Добавление наглядной схемы процесса выращивания
3. Добавление набора стандартных профилей для различных культур

 

 

 

 

 

 

 

 

 

 

 

Выводы

1. Для определения уровня производительности и надежности системы автоматизированного управления тепличным хозяйством «GreenHouse» была построена система показателей качества и выявлены основные направления их анализа. На основе эти показателей выбраны методы тестирования ИС.
2. Проанализированы методы тестирования программного обеспечения. Результаты тестирования говорят о том, что созданный программный продукт является надежным и эффективным продуктом в своем классе.
3. Сформулированы предложения по сопровождению и улучшению качества разработанного программного продукта. Эти предложения послужат отправной точкой в последующей доработке и модификации программного продукта.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Заключение

1. Были изучены и проанализированы материалы по данному направлению деятельности, описана работа тепличного хозяйства.
2. На основании исследования предметной области для разработки программного продукта выбраны методологии проектирования RAD и спиральная модель жизненного цикла продукта. Была описана архитектура программного продукта и построена логическая модель.
3. С помощью данного программного продукта информационная система тепличного хозяйства переходит на уровень практически полной автоматизации.
4. Был проведен анализ возможностей программных средств разработки и поддержки проекта и на основе этого, выбраны наиболее подходящие, такие как среда разработки Microsoft Visual Studio, СУБД SQL Compact, система контроля версий Team Foundation Server. Благодаря этому выбору программный продукт обладает умеренными потребностями в аппаратных ресурсах и основан на мульти-платформенной технологии. Описана структура проекта. Представлены основные модули программного продукта, такие как модуль управления БД, модуль взаимодействия с контроллером и модуль интерфейса.
5. После выбора средств разработки проект был реализован
6. Для определения уровня производительности и надежности программного продукта была построена система показателей качества и выявлены направления проведения их анализа. На основе этих показателей выбраны и проанализированы методы тестирования. В результате тестирования, созданный программный продукт был признан довольно надежным и эффективным. Также были сформулированы предложения по сопровождению и улучшению качества ПО, что послужит толчком для последующей доработки и модификации ПО. Программный продукт соответствует требованиям заказчика и обладает функциональностью, надежностью, мобильностью и удобством использования.