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

Введение

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

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

Основные функции систем АСУ ТП: контроль и управление, обмен данными, обработка, накопление и хранение информации, формирование сигналов тревоги, построение графиков и отчетов.

Внедрение АСУ ТП получает широкое распространение в различных секторах отечественной экономики, таких как нефтяная и газовая промышленность, химия и нефтехимия, металлургия, энергетика. В последнее время АСУ ТП начинают проникать в такие сферы, как управление дорожным движением, медицина, машиностроение, жилищно-коммунальное хозяйство. Отдельное направление их применения составляет военная и космическая техника, где системы автоматизации используются в качестве встроенных средств контроля и управления. [1]

На западном рынке системы промышленной автоматизации получили широкое распространение в середине 70-х годов, когда компьютерные технологии вышли на уровень, сделавший оправданным их массовое использование в производстве. В нашей стране формирование сектора АСУ ТП началось в конце 80-х — начале 90-х годов.

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

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

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

1. Системное проектирование

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

1.1 Анализ технического задания

1.1.1 Назначение программного обеспечения

Система диспетчерского контроля состояния технологического процесса «NordVision» предназначена для автоматизации контроля за параметрами технологического процесса и обеспечения оперативного персонала всей необходимой информацией для принятия решений по управлению технологическим процессом.

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

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

2. отображение значений технологических параметров на мнемосхеме и на графиках в режиме реального времени;

3. генерация сообщений о возникновении аварийных ситуаций и неполадок в работе оборудования;

4. сохранение истории значений технологических параметров и истории аварийных сообщений в базе данных;

5. генерация отчетов и отображение истории изменения значений технологических параметров в виде графиков.

1.1.2 Спецификация программного обеспечения

АРМ «NordVision» предназначен для диспетчера котельной. Программа будет поддерживать выполнение следующих функций:

· Сбор информации с исполнительных механизмов;

· Архивирование собранной информации;

· Формирование графиков;

· Вывод состояния котлоагрегата на экран;

1.1.3 Цель проекта

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

1.1.4 Анализ требований

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

1. социальные требования;

2. экономические требования.

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

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

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

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

Технические требования, предъявляемые к программному продукту, следующие:

· программный продукт должен функционировать под управлением операционных систем Microsoft Windows XP/Vista/7 на компьютерах с процессором Intel i3;

· объем оперативной памяти 4 Gb;

· жёсткий диск 300 Gb;

· монитор iiYama 24'';

· программный продукт должен использовать в качестве СУБД PostgreSQL.

Требование к пользовательскому интерфейсу

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

1.2 Выбор и расчет характеристик качества программного продукта

1.2.1 Выбор показателей эффективности

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

· функциональная емкость;

· удобство;

· надежность;

· техническая эффективность;

· адаптивность;

· сопровождаемость;

· универсальность;

· стоимость;

· переносимость.

Теперь остановимся на каждом из этих показателей подробнее.

· Функциональная емкость:

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

— Детализируется на следующие характеристики:

— пригодность для применения (соответствие назначению);

— точность;

— способность взаимодействовать со средой;

— соответствие нормам;

— безопасность (резервное копирование данных, защита от взлома данных и др.)

· Удобство:

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

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

— простота освоения (трудовые и временные затраты на освоение средств);

— адаптируемость к конкретным требованиям пользователя;

— количество информации, предъявляемой системой, которое необходимо переработать пользователю;

— количество действий, предпринимаемых пользователем при работе с системой;

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

— простота использования.

· Надежность:

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

— отсутствие в готовой программе ошибок проектирования и программирования;

— защищенность программы от непредусмотренных условий эксплуатации.

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

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

— непредусмотренных действий пользователя;

— недопустимых сочетаний исходных данных;

— влияние операционного окружения.

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

Сюда же следует отнести устойчивость программы при попытках несанкционированного доступа, а также вирусоустойчивость.

· Техническая эффективность:

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

— объем оперативной памяти;

— объем внешней памяти;

— время работы процессора;

— привлекаемые компоненты операционной системы.

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

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

Таким образом, эффективность ПО следует рассматривать по следующим двум характеристикам:

— быстродействие и время отклика;

— потребление ресурсов.

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

· Адаптивность:

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

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

· Сопровождаемость:

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

Характеризуется следующими показателями:

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

— пригодность к изменениям;

— совместимость обновлений (совместимость новых версий с существующими, включая, например, совместимость по входным или выходным данным);

— стабильность;

— тестируемость.

· Универсальность:

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

· Стоимость:

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

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

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

· Переносимость:

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

Данный показатель качества ПО характеризуют следующие частные показатели:

— адаптируемость;

— совместимость с версиями операционных систем (возможность работы в среде различных версий одной и той же ОС);

— структурированность;

— заменяемость;

— легкость инсталляции;

— соответствие нормам по переносимости и инсталляции;

— внедряемость.

1.2.2 Выбор метода оценки эффективности программного продукта

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

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

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

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

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

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

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

Метод аналогий позволит использовать лучшие характеристики прототипа.

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

1.2.3 Реализуемые требования

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

· удобство;

· надежность.

1.2.4 Предварительное ранжирование

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

Среднее значение ранга по данным всех экспертов рассчитаем по формуле:

(2.1)

где c_ij — ранг i-го показателя, назначенный j-м экспертом,

m — количество экспертов.

Средне квадратичное отклонение i-го показателя места от его среднего значения z_i рассчитаем по формуле:

(2.2)

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

1. если некоторое значение z_i является наименьшим из всех остальных:

2. z₁, …, z_i-1, z_i+1, …, z_n

3. то ему назначается предварительный ранг r_i = 1 и заносят в графу _x таблиц 2.1 и 2.2

4. выбирается следующий наименьший по величине ранг z_k (k?i), ему назначается предварительный ранг 2 и заносят в ту же графу той же таблицы;

5. если некоторые подмножества средних рангов z_u, z_v и т. д. u? v отличаются друг от друга не более чем на ?_z:

,(2.3)

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

· ?_z = 0,2 — для удобства программного обеспечения;

· ?_z = 0,16 — для надежности программного обеспечения.

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

(2.4)

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

(2.5)

Результаты опроса экспертов и расчетов приведены в таблицах 2.1 и 2.2.

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

Список содержит следующие требования:

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

2) время, необходимое для обучения и освоения программного средства должно стремиться быть минимальным;

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

4) количество действий, предпринимаемых пользователем при работе с программой должно стремиться быть минимальным;

5) наличие контекстно-зависимой помощи;

6) наличие полной, понятной и удобочитаемой пользовательской документации;

7) требования к уровню знаний, необходимых для работы с системой, ограничиваются ознакомлением работы с клавиатурой ПК;

8) предоставление пользователю на экране монитора только необходимых для его работы сведений и данных.

Таблица 2.1 Результат опроса экспертов

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

36=36

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

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

Список требований к надежности ПО:

1) Защищенность программного комплекса от непредусмотренных действий пользователя, т. е.:

— от нажатия непредусмотренных ПК комбинаций клавиш;

— от ввода недопустимых сочетаний данных (аналогично при корректировке);

— от удаления данных без подтверждения;

— от удаления данных, отсутствие которых может привести к некорректности информации.

2) Отсутствие в готовом программном комплексе ошибок проектирования и программирования;

3) Защита от несанкционированного доступа;

4) Защищенность программного комплекса от влияния операционного окружения;

5) Защищенность программного комплекса от непредусмотренных условий эксплуатации.

Таблица 2.2. Результат опроса экспертов.

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

15 = 15

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

1.2.5 Определение компетентности экспертов

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

Определение компетентности экспертов выполнятся по коэффициентам ранговой корреляции.

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

(2.6)

где и

Коэффициент компетентности рассчитывается по формуле:

(2.7)

Результаты вычислений значения величины d_i², коэффициента ранговой корреляции и коэффициента компетентности сведены в таблицы 2.3 и 2.4.

Таблица 2.3 Удобство программного обеспечения

Таблица 2.4 Надежность программного обеспечения

1.2.6 Повторное ранжирование показателей с учетом компетентности экспертов

Повторное ранжирование показателей с учетом компетентности экспертов осуществляется на основе таблиц 2.3 и 2.4, приведенной в пункте 2.2.5, а соответствующие оценки определяются по формулам:

· среднее значение ранга:

(2.8)

§ средне квадратичное отклонение i-го показателя места от его среднего значения z_i^* рассчитаем по формуле

(2.9)

Далее аналогично формированию графы _i — предварительных рангов таблиц 2.1 и 2.2, сформируем графу *_I — окончательных рангов с учетом и если она равна 0,5n (n+1), то значит, что окончательные ранги определены правильно и можно переходить к определению показателя согласия экспертов, что позволит заключить, состоялась или нет экспертиза. При этом используются доверительные интервалы, которые дают представление о степени точности и надежности оценки установленных рангов рассматриваемых величин.

Полученные характеристики занесены в таблицы 2.5. и 2.6.

Таблица 2.5. Удобство программного обеспечения

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

36=36

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

Таблица 2.6. Надежность программного обеспечения

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

15 = 15

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

1.2.7 Оценка значимости показателей

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

(2.10)

где r^*_i — окончательный ранг i-го показателя.

Данные для расчетов сведены в таблицы 2.7 и 2.8.

Таблица 2.7. Удобство программного обеспечения

Таблица 2.8. Надежность программного обеспечения

1.2.8 Степень согласия экспертов

Степень согласованности экспертов определим с помощью коэффициента конкордации Кендалла [3].

(2.11)

Где

Удобство программного обеспечения Определим согласованность экспертов для m=5, n=8

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

Согласно экспертной оценке выберем три самых важных с точки зрения экспертов критерия:

· удобство и интуитивность пользовательского интерфейса;

· время, необходимое для обучения и освоения программного средства должно стремиться быть минимальным;

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

Надежность программного обеспечения Определим согласованность экспертов для m=5, n=5

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

Согласно экспертной оценке выберем три самых важных с точки зрения экспертов критерия:

· Защищенность программного комплекса от непредусмотренных действий пользователя;

· Отсутствие в готовом программном комплексе ошибок проектирования и программирования;

· Защита от несанкционированного доступа;

1.2.9 Формирование обобщенного показателя эффективности системы

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

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

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

(2.12)

где — весовые коэффициенты, учитывающие важность частного критерия, они также определяют степень влияния i частного критерия на эффективность системы в целом;

— частный критерий.

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

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

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

Показатели оцениваются при помощи балльной шкалы. Для них установлены пределы 1−2 баллов. Данный список был предложен пяти экспертам с предложением ранжировать их по принципу «чем больше, тем лучше». Результаты сведены в таблицу 2.9.

Таблица 2.9

Произведем повторное вычисление с учетом компетентности экспертов. Полученные результаты занесены в таблицу 2.10.

Таблица 2.10

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

(2.13)

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

Таблица 2.11.

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

(2.14)

и имеет значение: = 0,67 * 0,83 + 0,33 * 1= 0,88

1.3 Оценка системных показателей

1.3.1 Выбор и расчет характеристик качества программного обеспечения

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

Минимально возможное количество операторов и операндов

n₁* - минимальное число операторов, которое может иметь работоспособная программа

n₁* = 2 ед.

n₂* - минимальное количество операторов, которое может быть в программе в идеале

n₂* = 150 ед.

Число простых или отдельных операторов и операндов

n₁ — число различных операторов, которое предположительно по спецификации может иметь место в программе

n₁ = 200 ед.

n₂ — фактически предполагаемое число простых или отдельных операндов в системе, вычисляется по формуле:

(2.15)

Подставляя числовые значения, получим: n₂ = 1367 ед.

Определение словаря ПО

— словарь

n = 1567 ед.

Длина реализации программы Длина реализации программы N рассчитывается по формуле:

(2.16)

N = 1529+ 14 241 = 15 769 бит.

Оценка длины программы

n? N? n₁ⁿ¹ x n₂ⁿ², (2.17)

1567? 15 769? 200²⁰⁰ x 1367¹³⁶⁷

Объем программы Максимально возможный объем программы V_max вычисляется по следующей формуле:

(2.18)

V_max = 167 375 бит Минимально возможный объем программы V_min вычисляется по формуле:

(2.19)

V_min = 1102 бит Средняя характеристика объема программы рассчитывается следующим образом:

(2.20)

причем действует соотношение

= 7861 бит

167 375? 7861? 1102

Уровень программы Уровень программы определяет отношение числа строк (или символов) в машинных кодах к той записи, которая получена на языке высокого уровня:

= 0.0066

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

где отношения для операторов:

= 0,01

· отношения операндов:

= 0,096 (N₂ = n₂ log₂ n₂), следовательно,

= 0,96

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

I = 161 ед.

Квантификация процесса программирования Реализация описанного алгоритма заключается в том, что N-раз выбирается из словаря n элементы;

· Каждый выбор эквивалентен двоичному поиску;

· Программа порождается выполнением N log n мысленных сравнений;

· Число мысленных сравнений равно объему программы;

· Каждое мысленное сравнение содержит в свою очередь ряд мысленных операций Соп, которые определяются сложность программы: = 152 ед.

· Общее число элементарных мыслительных операций можно вычислить по формуле:

= 25 428 646 ед.

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

где k = 5.25 — количество различений в секунду, которое может реализовать человек k = 15.

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

= 613 868,2 с = 471 ч.

Уровень языка Уровень языка определим как .

= 7,3 ед.

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

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

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

= 19 модулей.

1.4 Концепция проекта

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

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

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

надежность программного обеспечения.

Конкретные требования для этих показателей изложены в п. 2.2.3.

Программное обеспечение должно разрабатываться в среде программирования Visual studio 2010. Язык программирования WPF.

В качестве сервера БД должно использоваться СУБД PostgreSQL под управлением операционной системы Windows;

Показатель эффективности, рассчитанный для частных показателей качества согласно методике и коэффициентам, определенным в п. 2.2.11, для разрабатываемого программного обеспечения должен составить не ниже Е = 0,92

2. Структурное проектирование

2.1 Анализ предметной области

АРМ оператора котельной включает в себя:

· Сбор, обработку и хранение информации о работе оборудования котельной;

· Вывод информации о текущем состоянии котельной;

· Построение архивных графиков;

· Вывод информации об аварийных ситуациях;

2.2 Структура системы АРМ «Nordvision»

Рассмотрев предметную область разрабатываемого ПО «Nordvision», составим структуру системы, которая будет представлена на рисунке 3.1.

Рис. 3.1. Структура движения информации АРМ «NordVision».

2.3 Инфологическая модель ПО «NordVision»

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

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

Выделим следующие объектные группы:

Act_values — содержит текущие значения параметров котлоагрегата.

Arc_values — содержит архивные значения параметров котлоагрегата.

Arc_alarms — содержит архив аварийных ситуаций.

Mb_desc — описание переменных типа boolean;

Mi_desc — описание переменных типа integer;

Alarms_desc — описание аварий;

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

Рис. 3.2. Инфологическая модель ПО «Статист».

2.4 Разработка структуры информационного обеспечения

Для выполнения требований предъявленных в п. 2.2.3, разработаем структуру программного обеспечения.

Разработка структуры информационного обеспечения (ИО) является одним из наиболее ответственных этапов разработки программного обеспечения, состоящая в разработке такой структуры ИО, которая была бы наиболее адекватна поставленным задачам. Удачный выбор такой структуры является залогом быстрого и успешного программирования и включает в себя разработку эффективной структуры хранения данных и программы.

Под эффективной структурой подразумевается уменьшение времени доступа к данным и объемных характеристик базы данных.

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

Логическая модель строится на основании инфологической модели и выполняется на языке описания данных конкретной СУБД. Описывается структура каждой таблицы. Каждому полю таблицы назначается имя, тип и размер. Ниже приведено описание структуры таблиц: act_values (таблица 2.1), arc_values (таблица 2.2), arc_alarms (таблица 2.3), mb_desc (таблица 2.4), mi_desc (таблица 2.5), alarms_desc (таблица 2.6).

Таблица 2.1 Act_values

Таблица 2.2 Arc_values

Таблица 2.3 Arc_alarms

Таблица 2.4 Mb_desc

Таблица 2.5 Otch_p

Таблица 2.6 Alarms_desc

2.5 Выбор средств разработки приложений

Согласно техническому заданию, программное обеспечение «Статист» должно разрабатываться в интегрированной среде разработки Visual studio 2010, написана на языке c# и использовать СУБД postgree.

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

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

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

Но, несмотря на это, можно выделить три основных этапа собственно разработки программного обеспечения:

· разработка структуры программы;

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

· разработка собственных или выбор известных алгоритмов.

2.6.1 Структура программного обеспечения

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

метод «сверху вниз»;

объектно-ориентированный метод.

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

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

Язык программирования C# поддерживает объектно-ориентированный подход, поэтому воспользуемся одноименным методом.

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

2.6.2 Разработка пользовательского интерфейса

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

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

§ цветовая гамма должна быть;

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

§ для заполнения общего экранного фона избегать цветов GREEN (зеленый) и MAGENTA (розовый);

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

Разработка экранных форм Для удобства работы пользователя разработаем экранные формы.

Данные были разбиты на следующие группа (экранные формы):

§ Главный экран;

§ Журнал событий;

§ Архивный график;

§ Управление Экранные формы приведены в приложении № 1.

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

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

Исходя из рассмотрения структуры ПО «Nordvision», разработаем основные алгоритмы работы программы (некоторые их них представлены ниже). Главный цикл программы представлен на рисунке 3.6

Рис. 3.6. Блок-схема программы.

Рис. 3.7. Блок-схема модуля «Журнал событий».

Рис. 3.8. Блок-схема модуля «графики».

Рис. 3.9. Блок-схема модуля «Сервер связи с исполнительными устройствами».

2.7 Вывод

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

проанализирована структура движения входной и выходной информации в ПО «NordVision» (п. 3.2.);

для выполнения требования функциональности проведен анализ предметной области (п. 3.1.) и построена инфологическая модель данных (п. 3.3.), разработана структура программного обеспечения (п. 3.4.1);

разработана структура информационного обеспечения (п. 3.4), в частности, разработана нормализованная структура базы данных, приведенная к 4НФ (п. 3.4.1), выбрана структура файлов для хранимых данных (п. 3.4.2);

для выполнения требования простоты освоения и использования ПО, был разработан пользовательский интерфейс (п. 3.6.2) и разработаны экранные формы (п. 3.6.2.3.);

разработаны основные алгоритмы ПО «NordVision» (п. 3.6.3.).

3. Логическое проектирование

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

3.1 Организация контекстно-зависимой помощи

Для выполнения требования простоты освоения и использования, предъявленного в пункте 2.1.4.2.1, в проектируемом ПО должна быть организована контекстно-зависимая помощь. Пример выполнения данного требования показан на рисунке 4.1.

Рис. 4.1. Пример контекстно-зависимой помощи.

3.2 Инструкции пользователя

3.2.1 Общие сведения

ПО «NordVision» предназначено для автоматизации работы диспетчера котельной.

ПО «NordVision» позволяет повысить эффективность работы диспетчеров за счет своевременной и полной выводимой информации о состоянии котлоагрегата.

3.2.2 Системные требования

Программное обеспечение «NordVision» разработано для персональных компьютеров типа IBM PC и совместимых с ними. Для работы программы необходимо:

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

· программный продукт должен функционировать под управлением операционных систем Microsoft Windows XP/Vista/7/8 с установленным Microsoft .Net Framework 4;

· Процессор не ниже Intel core2duo

· объем оперативной памяти 1024 Mb;

· жёсткий диск 320Gb;

· монитор iiyama e2407HDS или аналогичный.

3.2.3 Начало работы с программой «NordVision»

При запуске ПО «NordVision» на экран выводится актуальная информация о состоянии котельной в псевдотрехмерном режиме (основной экран) по нажатию кнопки «2D» информация выводится в двухмерном режиме.

3.2.4 Описание журнала событий

При нажатии кнопки «журнал событий» выводится экранная форма журнала событий:

Рис. 4.2

В данной форме присутствуют списки выбора диапазона дат за которые выводятся события, а также кнопка «Выгрузить в EXCEL» по нажатию которой создается файл формата xls.

3.2.5 Описания графиков

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

Рис. 4.3

Данное окно позволяет просматривать архивные значения в виде графиков.

3.2.6 Описание экранной формы «Управление»

При нажатии на кнопку «Управление» на экран выводится форма «управление»

Рис. 4.4

Здесь осуществляется удаленное управление котлоагрегатом (пуск, останов. Задание мощности котлоагрегата, задание температуры на выходе котельной) При выборе вкладки «Управление задвижками»

Осуществляется управление задвижками входной и выходной воды, а также газовой задвижкой Рис. 4.5

3.3 Тестирование

3.3.1 Оценка работоспособности и устойчивости программного обеспечения

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

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

При тестировании программного обеспечения «NordVision» в соответствии с предъявленными требованиями технического задания, а также для обеспечения выполнения поставленных требований к программному продукту, были проведены следующие мероприятия по оценки работоспособности и устойчивости системы:

· Проверка на формирование графиков за период указанный пользователем.

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

· Проверка правильности выводимых данных.

· Проверка правильности выполнения команд на управление котлоагрегатом

· Проверка выдачи на экран контекстно-зависимой помощи во всех режимах работы программы.

· Наличие полной, понятной и удобочитаемой пользовательской документации.

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

Тестирование программного продукта проводилось в отделе АСУиТП ООО «Норд Крафт» в течение трех недель, и все обнаруженные, в течение периода тестирования, недостатки и ошибки были устранены. Несмотря на возможное содержание в программе необнаруженных ошибок, программный продукт в целом соответствует предъявляемым требованиям, и может быть принят в эксплуатацию.