Разработка ПО контроля метрологических характеристик плотномера

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

2.2 Проектирование модели жизненного цикла системы

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

- каскадная;

- инкрементная;

- спиральная.

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

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

Рис. 2.1 - Каскадная стратегия жизненного цикла

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

Достоинства модели:

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

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

Недостатки модели:

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

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

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

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

Рис. 2.2 - Инкрементная стратегия жизненного цикла

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

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

- отсутствия у заказчика возможности сразу финансировать весь дорогостоящий проект;

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

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

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

Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий (рис. 2.3).



Рис. 2.3 - Спиральная стратегия жизненного цикла

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

Достоинства модели:

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

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

- обеспечивает большую гибкость в управлении проектом;

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

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

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

Недостатки модели:

- увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;

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

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

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

2.3 Отладка системы

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

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

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

Программные ошибки, как правило, делятся на три вида:

1. Синтаксическая ошибка. Неправильное употребление синтаксических конструкций, например, употребление оператора цикла For без то или Next.

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

3. Логическая ошибка. Нарушение логики программы, приводящее к неверному результату. Это наиболее трудный для "отлова" тип ошибки, ибо подобного рода ошибки, как правило, кроются в алгоритмах и требуют тщательного анализа и всестороннего тестирования.

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

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

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

2.4 Тестирование системы

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

1. Сравнение программы со схемой алгоритма.

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

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

4. Редактирование внешних связей и компоновка программы. На этапе редактирования внешних связей программных модуле программа-редактор внешних связей, или компоновщик задач, обнаруживает такие синтаксические ошибки, как несоответствие числа параметров в описании подпрограммы и обращении к ней, вызов несуществующей стандартной программы. например, 51 H вместо 51 N, различные длины общего блока памяти в вызывающем и вызываемом модуле и ряд других ошибок.

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

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

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

Наиболее простые способы получения тестов:

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

- Использование результатов, полученных на других ЭВМ или по другим программам.

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

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

3.1 Алгоритм работы

При запуске программного обеспечения появляется окно (рис. 3.1).

Рис. 3.1 - Начало работы с программой

Для правильной работы программы необходимо ввести данные, поточному и лабораторному плотномеру (рис. 3.2).

Рис. 3.2 - Данные плотномеров

- тип, марка и заводской номер нам будут необходимы для формирования протокола КМХ;

- предел допускаемой абсолютной погрешности необходим для проверки условия годности для дальнейшей эксплуатации.

После ввода данных нажимаем кнопку «ПРИНЯТЬ».

Далее нам необходимо получить данные по БИК (Рис. 3.3), такие как:

- температура;

- давление;

- плотность.

Для этого необходимо нажать кнопку «ОБНОВИТЬ»

Рис. 3.3 - Данные по БИК до нажатия кнопки «ОБНОВИТЬ»

После нажатия на кнопку обновить появляются данные: расход, температура, давление, плотность (рис. 3.4).

Рис. 3.4 - Данные по БИК после нажатия на кнопку «ОБНОВИТЬ»

При внедрении модуля в систему «Cropos» данные по БИК будут получаться автоматически с датчиков измеряемых эти показатели.

После проведения всех процедур описанных выше, выбираем количество измерений необходимых для проведения КМХ и нажимаем кнопку «Начать новый КМХ» в нижней, левой части окна (рис. 3.5)

Рис. 3.5 - Выбор количества измерений и начало КМХ.

После нажатия на кнопку «Начать новый КМХ» появляются поля для заполнения в количестве соответствующим выбранному количеству измерений (рис. 3.6).



Рис. 3.6 - Начало нового КМХ

Затем нажимаем кнопку запуск необходимого нам измерения. При нажатии на кнопку запуск будет происходить заполнение столбцов 1-5, которые заполняются автоматически с данных по БИК. Одновременно с нажатием на кнопку запуск происходит отбор разовой пробы нефти через ручной пробоотборник и передача этой пробы в испытательную лабораторию. В испытательной лаборатории делают анализ отобранной пробы и передают данные по плотности приведенные к стандартным условиям (температура 20 °С, давление 0 Мпа).

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

Далее происходит приведение лабораторной плотности к условиям БИК, при помощи коэффициента сжимаемости нефти, г, 1/Мпа и коэффициента объемного расширения нефти, в, 1/°С. Вычисляемых по формулам (3.1; 3.2; 3.3):

, (3.1)

, (3.2)

, (3.3)

где₂₀ - значение плотности нефти при стандартных условиях (t = 20 °С и Р = 0 МПа), кг/м3;

t - значение температуры нефти, при которой определяется коэффициент сжимаемости нефти, °С;

Значение плотности нефти при температуре t и избыточном давлении равном Р рассчитывается по формуле (3.4) и записывается в 10 столбец:

, (3.4)

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

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

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

Рис. 3.7 - Заключении о пригодности плотномера к эксплуатации

Рис. 3.8 - Заключение о непригодности плотномера к эксплуатации

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

3.2 Тестирование модуля после внедрения в систему «Cropos»

Чтобы вызвать окно проведения КМХ плотномера по лабораторному плотномеру необходимо нажать на кнопку «МЕТРОЛОГИЯ» в появившемся окне выбрать «КМХ плотномера по лаборатории» откроется окно проведения КМХ плотномера (рис. 3.9).

Рис. 3.9 - Окно проведение КМХ плотномера.

Для начала проведения КМХ плотномера по ареометру, необходимо выбрать количество измерений и нажать на кнопку «НАЧАТЬ НОВЫЙ КМХ», далее нажатием на кнопки «Запуск», произвести автоматические замеры данных в БИК. Лабораторные данные вводятся через окно «Ввод лабораторных данных» (рис. 3.10). Данное окно открывается через кнопки «Руч. ввод».

Рис. 3.10 - Ввод лабораторных данных

Также существует возможность исключения одного замера из КМХ. Для этого необходимо нажать на кнопки «Исключить». Данные кнопки активны только в следующих случаях:

- количество измерений больше трех;

- ни одно измерение еще не исключалось из текущего КМХ.

Протокол КМХ рабочего плотномера формируется нажатием на кнопку «Сформировать протокол» (рис. 3.11).

Рис. 3.11 - Кнопка «Сформировать протокол»

В дальнейшем протокол можно просмотреть через архив документов, для этого необходимо на главной экранной форме нажать кнопку «АРХИВ» в появившемся окне нажать кнопку «Архив документов» (рис. 3.12).

Рис. 3.12 - Вход в архив документов

При нажатии на кнопку «Архив документов» появляется новое окно (рис. 3.13), где мы можем просмотреть все сохраненные нами протоколы. Также в архиве документов имеется функция распечатки выбранного документа в двух ориентациях (книжной или альбомной).



Рис. 3.13 - Архив документов

Заключение

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

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

- освоен язык программирования С#;

- изучено формирование данных необходимых для приведения плотности к условиям измерения объёма.

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

В первой главе представлен анализ предметной области, описание системы «Cropos» и требования к предъявляемому модулю. Во второй главе описан выбор средств реализации, описание языков программирования, способы разработки программного обеспечения, выбор среды разработки. В третьей главе описана разработка программного обеспечения, алгоритм работы разработанного модуля, тестирование модуля после внедрения в систему «Cropos». Данное ПО написано на языке программирования С#, о достоинствах и недостатках которого так же было изложено в ходе работы.

Разработанный модуль успешно внедрён в систему «Cropos» на предприятии АО «Транснефть-Приволга» Самарское РНУ, что свидетельствует о практической значимости данной бакалаврской работы.

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

Анхимюк, В.Л. Теория автоматического управления [Текст] / В.Л. Анхимюк, О.Ф. Олейко, Н.Н. Михеев. - М.: Дизайн ПРО, 2002. - 352 с.

Бесекерский, В.А. Теория систем управления программным обеспечением [Текст] / В.А. Бесекерский, Е.П. Попов. - 4-е изд., перераб. и доп. - СПб.: Профессия, 2003. - 747 с.

Гудвин, Г.К. Проектирование программного обеспечения [Текст] / Г.К. Гудвин, С.Ф. Гребе, М.Э. Сальдаго. - пер. с англ. - М.: БИНОМ, Лаборатория знаний, 2004. - 911 с.

Брюханов, В.Н. Теория управления программным обеспечнием [Текст] : Учеб. для машиностроит. спец. вузов / В.Н. Брюханов, М.Г. Косов, С.П. Протопопов и др.; под ред. Ю.М. Соломенцева. - 3-е изд., стер. - М.: Высш. шк.; 2000. - 268 с.

Троелсен Э., Язык программирования C# 5.0 и платформа .NET 4.5, 6-е изд.: Пер. с англ. - М. : ООО «И.Д. Вильямс», 2013. - 1312

Техносфера [Электронный ресурс] / 2017. - Режим доступа: http://tekhnosfera.com, свободный. - Загл. с экрана.

ВЕДА программное обеспечение широкого профиля [Электронный ресурс] / 2017. - Режим доступа: http://www.medical.ua-ru.net, свободный. - Загл. с экрана.

Lib.ru: Журнал «Самиздат» [Электронный ресурс] / 2017. - Режим доступа: http://samlib.ru, свободный. - Загл. с экрана.

CIT FORUM [Электронный ресурс] / 2017. - Режим доступа: http://citforum.ru, свободный. - Загл. с экрана.

ОЛЛИ Информационные технологии [Электронный ресурс] / 2015. - Режим доступа: http://www.olly.ru, свободный. - Загл. с экрана.

TADVISER [Электронный ресурс] / 2017. - Режим доступа: http://www.tadviser.ru, свободный. - Загл. с экрана.

shportal [Электронный ресурс] / 2017. - Режим доступа: http://shportal.ru, свободный. - Загл. с экрана.

ГОСТ Р 8.595-2004 Масса нефти и нефтепродуктов. Общие требования к методикам выполнения измерений.

Р 50.2.076-2010 Плотность нефти и нефтепродуктов. Метододы расчета.

МИ 3240-2009 Преобразователи плотности жидкости поточные. Методика поверки.

Размещено на Allbest.ru

...