Программное обеспечение системы управления и планирования работы сети таксофонов
Дипломный проект
на тему:
"Программное
обеспечение системы управления и планирования работы сети таксофонов"
Москва 2010
Введение
Сегодня мы являемся свидетелями того, как ворвалась в нашу
жизнь и становится всепроникающей телекоммуникационная телефония. Ее область
применения постоянно расширяется, однако одним из основных и самых
перспективных приложений по-прежнему остается предоставление услуг связи.
По оценкам [3] в число 200 крупнейших по капитализации
компаний России вошло 50 телекоммуникационных компаний, 29 из которых вошли в
число 30 наиболее привлекательных для инвестиций. В сочетании с большой
емкостью телекоммуникационного рынка, в частности рынка таксофонных услуг, а
также с его высокой доходностью (предоставление услуг таксофонной связи входит
в число 10 наиболее прибыльных видов бизнеса) это свидетельствует о
значительном потенциале развития в данной области.
По данным рейтинга «Эксперт 200» «наиболее высоко среди
российских компаний инвесторы сейчас оценивают предприятия связи. Причины
такого предпочтения довольно очевидны. Во-первых, предприятия связи в меньшей
степени страдают от неплатежей (тому, кто не платит, тут же отключают связь - и
нет проблем), поэтому их финансовое состояние более благополучно. Во-вторых, Россия
испытывает жесточайший дефицит услуг связи, и в ближайшие годы они просто
обречены развиваться. В-третьих, во всем мире сейчас наблюдается рост спроса на
телекоммуникационные услуги, обусловленный внедрением новых информационных
технологий (в частности развитием компьютерных сетей).»
На Всемирной конференции по развитию электросвязи,
организованной Международным союзом электросвязи в Буэнос-Айресе в марте 1994
года, была выставлена концепция Глобальной инфраструктуры связи (ГИИ), которая
заключается в объединении ресурсов информационных технологий и развитой
инфраструктуры электросвязи в целях обеспечения взаимодействия всех
пользователей для получения любого вида информации в реальном масштабе времени
вне зависимости от расстояния и используемых технических средств.
Интеграция российской сети электросвязи в ГИИ и построение
Взаимоувязанной Сети Связи (ВСС) России является национальной стратегической
задачей, получившей отражение в ряде законодательных и нормативно-правовых
актов, принятых в 2005-2007 годах. В частности, одним из стратегических
направлений, определяемых документом [12] является построение единой
таксофонной сети России и интеграция ее в ВСС.
Министерством связи России разрабатывается концепция
построения единой таксофонной сети России [13]. Концепция подразумевает
выработку единых требований, которым должны удовлетворять системы таксофонной
связи и используемое в них оборудование, для интеграции их между собой с целью
осуществления кроссбиллинга операторов (организация взаимозачетов за предоставляемые
услуги таксофонной связи) и оказания пользователям услуг по роумингу
(обслуживание в карточных таксофонах по картам других таксофонных систем,
входящих в единую таксофонную сеть).
1.
Исследовательская часть
1.1 Анализ проблем управления сетью таксофонов и синтез
решения по его оптимизации
По оценкам экспертов [3] уровень телефонизации России (число
работающих телефонных аппаратов на 100 человек населения) составляет менее 20.
По этому показателю Российская Федерация значительно отстает от развитых стран
и, в первую очередь, от стран Европейского сообщества.
По количеству таксофонных аппаратов потенциал России также
достаточно высок и сравним с потенциалами таких стран, как Франция и Германия:
Германия - 1 таксофон на 400 человек населения
Франция - 1 таксофон на 300 человек населения
Россия (в среднем) - 1 таксофон на 700 человек населения
Россия (крупные города) - 1 таксофон на 300-250 чел.
населения
Москва (32000 таксофонов) - 1 таксофон на 300 человек
населения
Исследования Ленинградского отраслевого НИИ связи (ЛОНИИС)
показали, что оптимальной плотностью размещения таксофонов на территории России
является 2-3 таксофона на 1000 человек, или 1 таксофон на 500-300 человек.
Таким образом, плотность таксофонов, особенно в крупных городах, уже приблизилась
к намеченной цифре, но подавляющее большинство установленных таксофонов не
соответствуют современным стандартам. В связи с этим увеличиваются требования,
предъявляемые к охвату населения услугами таксофонной связи с качеству
обслуживания.
В настоящее время (состояние на июль 2009 года) в России
насчитывается:
·
около
190000 таксофонов местной телефонной связи,
·
около
25000 таксофонов, предоставляющих междугороднюю связь и
·
около
2500 таксофонов общего назначения.
К 2001 году планируется замена более 170000 установленных на
сегодня таксофонов (80%) и увеличение парка таксофонов на 40-110%. В этой связи
возникают следующие проблемы:
1.
настройка
функционирования аппаратов
В настоящее время настройку и тестирование таксофонов
осуществляет обслуживающий персонал для каждого аппарата отдельно. При каждом
изменении управляющей информации (коды доступа, тарифы и т.д.) необходим выезд
техника для ввода данных.
2.
диагностика
неисправностей
Для своевременного обнаружения и устранения неисправностей требуется
проводить регулярный осмотр таксофонов, что также ведет к дополнительным
затратам.
3.
сбор
статистики
4.
фискальный
контроль
Сбор статистических и фискальных данных осуществляется путем
ручной выемки блока флэш-памяти и сброса информации в накопитель, что вызывает,
кроме прочего, вынужденный простой таксофона.
5.
топология
сети таксофонов
Оптимальное размещение таксофонов на территории района
невозможно без тщательного анализа статистической информации.
Таким образом, увеличение количества таксофонов ведет к росту
численности технического персонала (либо к увеличению интервалов регулярного
технического обслуживания) и, как следствие, повышению себестоимости
эксплуатации таксофонной сети.
Рассмотрим возможные пути решения возникающих проблем:
Для сокращения количества выездов к таксофонам при изменении
управляющей информации можно рекомендовать предварительное формирование пакетов
данных объемом не менее установленного. Установленный лимит рассчитывается,
исходя из экономической эффективности. Однако, этот способ не выдерживает
критики с точки зрения безопасности (изменение «черного» и «белого» списков), а
также из-за большого разброса значимости разнородной управляющей информации.
Наиболее приемлемым решением данной проблемы является организация внутрирайонных
(городских) сетей таксофонов с дистанционным вводом служебных данных из единого
управляющего центра.
Недостатки (трудности) данного решения:
·
Создание
сети влечет затраты на организацию модемной связи и дополнительное аппаратное
обеспечение, а также их обслуживание.
·
Необходимость
разработки соответствующего программного обеспечения.
Преимущества:
·
Своевременное
внесение изменений.
·
Сокращение
времени на осуществление ввода данных.
·
Уменьшение
численности обслуживающего персонала.
Своевременное обнаружение и устранение неисправностей может
быть достигнуто путем регулярного обхода таксофонов с проведением визуального
осмотра на предмет внешних повреждений, тестирования и контрольных звонков. Так
как современные таксофоны оснащены системой самодиагностики, которая постоянно
следит за работой узлов таксофона, то использование центра управления
представляется наиболее оптимальным решением: в случае возникновения каких-либо
проблем система самодиагностики блокирует таксофон и сообщает в центр свой
идентификационный номер и характер возникшей неисправности, аналогичным образом
аппарат ведет себя при попытке несанкционированного доступа.
Недостатки:
·
Не
все сбои в работе таксофона система самодиагностики может идентифицировать
(например, обрыв линии).
Преимущества:
·
Регулярное
тестирование и своевременное обнаружение неисправностей уменьшает расходы на их
устранение, повышает срок службы таксофонов.
·
Защита
от несанкционированного доступа - важный элемент надежности системы и качества
обслуживания.
Для сокращения времени вынужденных простоев таксофонов можно
рекомендовать проведение сбора статистики в ночное время. Но это не сокращает
численность обслуживающего персонала, а использование централизованной системы
управления позволяет автоматизировать процесс сбора служебной информации. Во
время ежедневных сеансов связи между аппаратами и центром, проводимых в
определенное персоналом время, таксофоны передают все накопленные данные для
дальнейшей обработки.
Преимущества:
·
Регулярный
и частый сбор накопленных данных позволяет снизить требования к емкости
запоминающих устройств таксофонов, а следовательно, уменьшить стоимость самих
аппаратов.
·
Исключение
повторного ввода собранной информации в базу данных (имеет место при ручном сборе)
также ведет к снижению расходов.
·
Сбор
статистики проводится без «изъятия» таксофона из рабочего процесса, что
обеспечивает исключение вынужденных простоев.
·
Совмещение
функций сбора и обработки поступающих от таксофонов данных позволяет проводить
более быстрый и тщательный анализ фискальной, диагностической и статистической
информации, что повышает степень обоснованности принятия решений о рациональном
размещении таксофонных аппаратов и оптимизирует использование оборудования.
Таким образом, проанализировав проблемы, непременно
возникающие при увеличении количества таксофонов, и исследовав возможные пути
их решения, приходим к выводу: управление сетью публичных таксофонов (в рамках
района / города) из одного центра при помощи системы удаленного управления и
контроля (ЦСК) - наиболее эффективное средство для эксплуатации и обслуживания
парка таксофонов.
1.2 Состав выполняемых централизованной системой контроля
функций
1.
Хранение
и обработка информации о состоянии таксофонов.
Сохраняется вся информация о текущем состоянии таксофонов и
обо всех изменениях за определенный период (сутки, месяц, год). Кроме того,
хранятся данные о расположении таксофонов и их распределении по модемам, а
также информация об обслуживающем персонале.
2.
Обеспечение
дистанционного управления таксофонами со вводом управляющей информации и
контролем правильности действий оператора.
Управляющая информация подготавливается на рабочем месте
оператора ЦСК и помечается как готовая к отправке по окончании процесса
подготовки. При очередном сеансе связи таксофона с ЦСК управляющая информация
таксофона заменяется на подготовленную оператором.
3.
Предоставление
оператору информации о состоянии таксофонов.
При обнаружении неисправностей в таксофоне системой
самодиагностики либо при пропуске очередного и резервного сеансов связи
оператор ЦСК получает список неисправных таксофонов, возможно, со списком
неисправностей.
4.
Формирование
отчетной документации с различной периодичностью.
·
Статистический
отчет.
Отчет содержит данные о количестве считанных с таксофонных
карт бит и количестве разговоров по каждому таксофону и по группам таксофонов
для следующих видов разговоров:
·
городской
звонок,
·
междугородний
звонок,
·
международный
звонок.
Также подсчитывается общая сумма считанных бит и общее
количество разговоров за отчетный период.
·
Диагностический
отчет.
В отчет включается информация по отказам (неисправностям) и
ремонтам:
·
количество
отказов,
·
код
ремонта,
·
количество
ремонтов.
Данные формируются по каждому таксофону отдельно, а также по
группам таксофонов.
·
Фискальный
отчет.
Кроме статистической информации (см. статистический отчет)
финансовый отчет содержит данные о стоимости городских, междугородних и
международных разговоров по каждому таксофону и по группам таксофонов для
каждого звонка, а также итоговые суммы по видам разговоров.
Отчетная документация формируется за период:
·
задаваемый
пользователем (включая периоды по времени суток для диагностических отчетов).
5.
Защита
информации от несанкционированного доступа средствами операционной системы и
сервера базы данных (БД).
1.3 Аппаратные средства, операционные системы и
инструментальные средства
Разработанное в данном дипломном проекте программное
обеспечение должно работать на ЭВМ типа IBM PC с установленной
операционной системой Windows.
Минимальные требования к серверу базы данных:
·
IBM PC-совместимый компьютер с процессором 389/33МГц с
установленной операционной системой Windows 3.11;
·
количество дисковой памяти, достаточное для установки сервера базы
данных и самой БД (приблизительно 4МБ).
Рекомендуемая конфигурация сервера базы данных:
·
IBM PC-совместимый компьютер с установленной операционной системой
Windows NT 4.х;
·
32МБ оперативной памяти;
·
3МБ свободного дискового пространства для установки серверного
программного обеспечения на системном диске и не менее 5МБ для файлов базы
данных.
ЦСК может быть установлена на любом компьютере с
установленной ОС Windows 3.11 или выше и имеющем соединение с сервером БД.
Исходные тексты программы написаны на языке SAL (Scaleable
Application Language - расширяемый язык приложений) в интегрированной среде
командной разработки Centura Team Developer.
Первая версия Centura (компания Gupta,
позже переименованная в Centura Software Corporation) появилась в 80-х годах.
Развиваясь одновременно с ОС Windows, в настоящее время Centura является мощным
инструментом разработки крупных информационных систем с высокой скоростью
обработки данных. Можно выделить следующие основные достоинства языка SAL:
·
Centura предоставляет прикладной интерфейс ко всем базовым
функциям многозадачных операционных систем, что обеспечивает переносимость
программ в другие ОС без переписывания кода.
·
Centura предоставляет средства доступа к различным серверам баз
данных, при этом использует все возможности самых продвинутых серверов
(например, ORACLE, SYBASE) и исправляет недостатки слабых БД (например, FoxPro).
·
При необходимости имеющийся функционал легко расширяется
средствами Centura.
·
Средства разработки созданы специально для быстрой разработки
корпоративных информационных систем, применяются специальные методы ускорения
разработки.
·
Наличие поставляемой вместе со средствами разработки встроенной
СУБД масштаба предприятия.
·
Все это позволяет сделать выбор в пользу языка SAL
интегрированной среды командной разработки Centura (SQL Windows 32).
2. Разработка алгоритмов и программ. Аппаратно-программная
структура системы
таксофон оптимизация программа управление
Таксофонная сеть накладывается на телефонную сеть
общего пользования, имеющую шлюзы для предоставления услуг междугородней и
международной связи, а также местной связи с абонентами других сетей.
В соответствии с концепциями построения
Взаимоувязанной Сети Связи и единой таксофонной сети России в системе,
разрабатываемой НИИ «Научный Центр», реализована двухуровневая структура (см.
рис. 2.1):
1.
оконечные
терминальные устройства связи (терминалы) - таксофоны с расширенными функциями,
2.
центр
управления системой (один или несколько, объединенных в сеть) - централизованная
система контроля (ЦСК).
При большой разветвленности сети центров управления либо при
объединении нескольких таксофонных сетей в единую систему возможна надстройка
третьего уровня (верхнего уровня управления) для координации работы всей сети
(на рисунке блоки этого уровня показаны пунктиром). Связь между ЦСК второго и
третьего уровня осуществляется посредством высокоскоростных модемов.
ЦСК является самостоятельным модулем (узлом), который:
·
входит
в состав цифровой АТС в качестве расширения ЭВМ технической эксплуатации
(служба ремонта) или
·
подключается
к существующим АТС городского типа по выделенным линиям при помощи модемной
связи через концентратор «НЦ-1».
Терминалы подключаются к ЦСК опосредованно - по телефонным
линиям (ТЛ) через коммутатор АТС. Связь ЦСК с АТС и другими участниками системы
осуществляется по проводному каналу RS-232.
Структура программного комплекса
Программный комплекс состоит из следующих частей
(см. рис. 2.1):
·
модуля поддержки канала,
·
серверного программного обеспечения,
·
ПО централизованной системы контроля и управления (ЦСК).
Рис. 2.1. Аппаратно-программная структура системы
Модуль поддержки канала предназначен для предварительной
обработки поступающих от таксофонов данных, для поддержки работы оборудования,
обеспечивающего связь с таксофонами, а также для пересылки управляющей
информации из ЦСК в таксофоны, подготовленной оператором ЦСК. Взаимодействие с
ЦСК осуществляется посредством специальной библиотеки, поставляемой вместе с
ЦСК и являющейся функциональной частью модуля поддержки канала.
Получение информации из ЦСК и сохранение данных в ЦСК
производится путем вызова соответствующих функций библиотеки. Серверное
программное обеспечение предназначено для поддержки структуры хранения,
управления файлами данных, обеспечения аутентификации пользователя и для
исключения неавторизованного доступа к данным ЦСК. Серверное программное
обеспечение контролирует целостность данных в соответствии с биснес-правилами,
установленными разработчиком структуры данных. Кроме того, серверное ПО
обеспечивает одновременную работу нескольких пользователей с ЦСК и исключает
вмешательство одного пользователя в результаты работы другого.
Централизованная система контроля предназначена для
дистанционного управления таксофонной сетью в составе до трех тысяч таксофонов.
ЦСК обеспечивает централизованное хранение и обработку информации о состоянии
таксофонов, хранение данных о расположении таксофоных аппаратов и их
распределении по модемам, а также информации об обслуживающем персонале. ЦСК
предоставляет оператору служебную информацию, осуществляет формирование
статистической, диагностической и финансовой отчетной документации за различные
периоды: стандартный и задаваемый пользователем. На основе анализа статистических
данных, предоставляемых системой, руководство компании получает возможность
принимать обоснованные и оперативные решения о развитии сети таксофонов,
грамотно распределять нагрузку по имеющемуся в наличии оборудованию,
контролировать эффективность средств, вложенных в обслуживание сети таксофонов.
В данном дипломном проекте реализовано программное обеспечение централизованной
системы контроля таксофонов и серверное ПО (на рисунке эти блоки выделены серым
цветом).
Общая структура алгоритма
В общей структуре разработанного ПО централизованной системы
контроля можно выделить следующие укрупненные блоки (см. рис. 2.2):
1. Определение прав доступа пользователя и соединение с
базой данных - описывается группой блоков 2,3,4:
·
соединение
с базой данных (блок 2);
·
определение
прав доступа (блок 3);
·
формирование
доступного меню (блок 4).
2. Выбор режима работы - эта группа состоит из:
·
блока
собственно выбора режима (блок 5) и
·
блоков
перехода к выбранному режиму работы: просмотр данных (блок 6), пересылка данных
(блок 7), изменение данных (блок 8), выход из системы (блок 9).
3. Просмотр данных - включает в себя следующие операции
(блоки 11-16):
·
выбор
режима просмотра (блок 11);
·
просмотр
данных на экране, состоящий из:
·
подготовки
формы (блок 12),
·
вывода
данных на экран (блок 13);
·
вывод
данных на печать, состоящий из:
·
выбор
режима печати (блок 14),
·
подготовка
данных (блок 15),
·
печать
данных (блок 16).
4. Пересылка данных - осуществляется в следующей
последовательности:
·
вначале
происходит проверка правильности данных (блок 17),
·
если
ошибок не обнаружено (блок 18), то устанавливается связь с модулем поддержки
канала (блок 19), в противном случае происходит автоматический переход в режим
изменения (см. п. 5) для корректировки передаваемой информации;
·
вызывается
соответствующая команда модуля поддержки канала.
Рис. 2.2. Укрупненная структура алгоритма
5. Изменение данных - происходит следующим образом
(блоки 21 - 25):
·
Сначала
подготавливается форма ввода (блок 21),
·
после
этого форма выводится на экран (блок 22);
·
затем
пользователь изменяет данные (блок 23),
·
после
чего проводится проверка данных на целостность (блок 24).
·
Если
информация верна, то изменения записываются в базу данных (блок 25), а в случае
обнаружения ошибки происходит возврат на предыдущий шаг (блок 23) для
редактирования введенных данных.
6. Выход из программы и окончание работы (блок 10).
Структура данных
Для увеличения скорости обработки данных и экономии
оперативной памяти информация, хранимая в базе данных, организована в виде
системы справочников.
Структура входных и выходных данных представлена на рисунке
2.3.
Входной информацией для разработанной в данном дипломном
проекте программе являются следующие данные:
·
Таблицы
(справочники), показанные на схеме прямоугольниками с тенью, являются «первичными»,
содержащиеся в них данные не изменяются в процессе работы. В поставляемой
конечному пользователю системе эти справочники:
·
список
ответственных,
·
список
номеров телефонов,
·
список
номеров таксофонных карт,
·
список
серий таксофонных карт,
·
список
модемов для таксофонов,
·
список
типов таксофонов,
·
виды
соединения таксофонов,
·
виды
разговоров,
·
типы
неисправностей,
·
коды
стран,
·
коды
городов.
Рис. 2.3. Структура входных и выходных данных
·
Таблицы,
показанные на схеме параллелепипедами, являются журналами регистраций. В них
фиксируются все изменения в управляемой системе таксофонов, заносятся учетные
данные. На основе информации журналов система строит статистические, финансовые
и другие отчеты. Структура журналов подробно показана в приложении ХХ.
Выходной информацией в данной системе являются:
·
Отчетная
документация за различные периоды: стандартные (сутки, месяц, год) и задаваемые
пользователем, а именно
·
статистические
отчеты,
·
диагностические
отчеты и
·
финансовые
отчеты
·
Экранные
формы.
·
Печатные
формы.
Для просмотра данных на экране дисплея или на бумаге
предусмотрен вывод списков (первичных справочников), журналов и промежуточных
таблиц в виде экранных и печатных форм.
Алгоритм определения прав доступа
Определение прав пользователя и соединение его с системой
осуществляется в следующей последовательности (см. рис. 2.4):
1.
Вывод
окна диалога с пользователем.
Оператору предлагается либо ввести свое имя, пароль и
название базы данных (блок 3) для получения доступа к системе и продолжения
работы, либо выйти из системы (блоки 4, 19).
2.
Ввод
пользователем идентифицирующих его данных.
Для получения доступа к ЦСК и базе данных пользователю
необходимо ввести следующую информацию:
·
имя
базы данных (А),
·
имя
пользователя (В),
·
пароль
(С).
Проверка введенной информации и включение возможности
соединения с базой данных (блоки 5-13).
Вначале проверяется полнота ввода (все ли данные введены: А,
В и С) (блок 5). Если и А, и В, и С введены, то включается возможность
соединения с БД (блок 6) и происходит переход к следующему этапу (п. 4). Затем
определяется, какая информация была введена пользователем (блоки 7, 9, 11) и,
если введена не вся необходимая информация, то введенные значения присваиваются
соответствующим переменным (блоки 8, 10, 12) и происходит переход к п. 3, то
есть к вводу недостающих данных.
Рис. 2.4. Алгоритм определения прав доступа
1.
Подтверждение
соединения с базой данных.
После того, как все данные пользователя, необходимые для его
идентификации, введены (проверка включения возможности соединения с БД - блок
13), переменные с введенными значениями имени БД, имени и пароля пользователя
сравниваются с имеющимися на сервере БД оригиналами. В случае совпадения
соответствующих значений подтверждается правомочность доступа пользователя к
работе с базой данных (блок 14), иначе - переход к п. 3.
2.
Соединение
с базой данных (блок 15) и проверка на ошибку (блок 16).
В случае, если по какой-либо причине соединение не произошло,
выводится сообщение об ошибке (блок 17) и предлагается повторить процедуру
ввода данных заново. В случае успешного соединения с БД происходит переход к п.
6.
3.
Вывод
главного окна ЦСК (блок 18).
Алгоритм изменения данных
Изменение данных (см. рис. 2.5) включает в себя следующие
функции:
·
Изменение
существующей строки (группа блоков 2-6).
Режим внесения изменений включается при выборе непустой
строки (блок 2), она редактируется (блок 3), затем введенная информация
проверяется (блок 4) и, в случае ее успешного завершения (блок 5),
·
Отмена.
Для окончания редактирования (блок 12) в появившемся окне
выбора режима (блок 7) выбирается строка «отмена» (блок 8).
·
Добавление
новой записи (строки) - описывается блоками 9-12, 17-19.
Первоначально при выборе режима добавления (блок 9)
проверяется, существует ли разбиение экрана (блок 10). Если нет, то экран
делится на два окна (две части) (блок 11). Верхнее окно - уже существующие
записи, а в нижнем окне создаются новые. Затем создается пустая строка (блок
12), в которую осуществляется ввод данных (блок 17).
Рис. 2.5. Алгоритм изменения данных
·
Удаление
строки - блоки 13-16.
Выбор режима удаления (блок 13) для строки означает ее стирание с
экрана, если она новая (блок 15), и маркировку строки как удаляемой (
) в противном случае (блок 16).
·
Обновление
данных (без сохранения внесенных изменений) - группа блоков 21, 40-42.
После проверки наличия разбиения экрана на два окна (блок 40)
это разбиение удаляется (блок 41), если оно существует, и происходит вывод
данных на экран из БД (блок 42).
·
Сохранение
внесенных изменений.
При выборе этого режима (блок 20) производятся следующие
действия:
1.
После
проверки на существование (блоки 22, 34) удаляются строки, маркированные как
удаляемые, с экрана (блок 35) и соответствующие им записи из базы данных (блок
23); происходит проверка на ошибку (блок 24).
2.
Сохраняются
новые строки в базе данных и происходит проверка на ошибку (блоки 25-27).
3.
Сохраняются
в базе данных изменения записей, маркированных как изменяемые: проводится
проверка на ошибку, затем - подтверждение записи в базу данных, а после этого -
снятие флага с записей, маркированных как изменяемые. В заключение удаляется
разбиения на два окна, если оно существует.
Алгоритм просмотра данных на экране
Вывод данных для просмотра на экране дисплея осуществляется в
следующей последовательности:
Сначала проводится инициализация полей фильтров (блок 2) -
это процесс восстановления введенных пользователем в последний сеанс работы с
формой данных в поля, ограничивающие вывод информации в экранные формы.
(Например, список сбоев таксофонов, произошедших за первый квартал 2010 года.)
В разделе \CURRENT_USER\SOFTWARE\ЦСК\<имя экранной
формы> в строковых параметрах, имена которых совпадают с именами полей
фильтров, значения которых устанавливаются, хранятся исходные данные. Доступ к
ним осуществляется посредством функций API WINDOWS для работы с системным
реестром. Значения параметров считываются непосредственно в заполняемые поля.
Потом происходит соединение курсора с базой
данных (организация канала связи с базой данных) (блок 3). Курсор - это
указатель на результирующий набор данных в БД. Все данные получаются из БД
через курсоры, открываемые явно или неявно. Для начала работы с курсором
необходимо сопоставить его с открытым сетевым соединением с базой данных. При
этом на сервере выделяются ресурсы для работы с будущим результирующим набором
данных, на клиенте создается указатель, ссылающийся на эти ресурсы через сетевое
соединение.
Затем проводится проверка на ошибку (блок 4) -
произошло ли соединение, если ошибка не обнаружена, то подготавливается текст
запроса к базе данных (блок 6), в противном случае - выход из режима просмотра
после вывода соответствующего сообщения об ошибке (блок 5). После успешного
завершения проверки запроса (иначе - сообщение об ошибке (блок 9) и выход из
режима) и подготовки курсора к исполнению запроса (блоки 7,8) на экран
выводится пустая форма (блок 10) и заполняется данными (блок 11).
Алгоритм вывода данных на печать
Алгоритм вывода данных на печать приведен на рис. 2.7.
Последовательность выполнения действий по организации канала связи с базой
данных, подготовке текста запроса к БД, проведению соответствующих проверок с
выводом сообщений об ошибках (блоки 1-9) аналогична алгоритму просмотра
информации на экране дисплея (см. п. 2.6). После успешного завершения проверки
запроса на экран выводится форма отчета (блок 10) для предварительного
просмотра, затем - видимая часть отчета, заполненного данными, (блок 11). После
ввода подтверждения о печати (блок 12) на принтер передается видимая на экране
часть отчета (блок 13), затем - оставшиеся данные (блок 14), после этого
происходит печать (блок 15).
Рис. 2.6. Алгоритм просмотра данных на экране
Структура меню
Многоуровневое меню централизованной системы контроля имеет
следующую структуру:
1. Централизованная система контроля
1.1. Конфигурация. Распределение модемов и таксофонов
1.2. Список пользователей
.3. Справочники
1.3.1. Список таксофонов
1.3.2. Коды стран
.3.3. Коды городов
.3.4. Типы неисправностей
.3.5. Виды разговоров
.3.6. Типы таксофонов
.3.7. Модемы для таксофонов
.3.8. Список серий таксофонных карт
.3.9. Список номеров таксофонных карт
1.4. Справка
1.5. Параметры
2. Таксофон
2.1. Список таксофонов
2.2. Характеристика
2.2.1. Код города, страны
.2.2. Тариф
2.2.2.1. Городской звонок
2.2.2.2. МГ звонок по рабочим дням
.2.2.3. МГ звонок по праздничным дням
.2.2.4. МН звонок по рабочим дням
.2.2.5. МН звонок по праздничным дням
2.3. Параметры
2.3.1. Виды соединения
2.3.2. Виды разговоров
.3.3. Максимальное количество цифр в номере
.3.4. Максимальное время ответа
.3.5. Бесплатные телефонные номера
.3.6. Запрещенные номера таксофонных карт
.3.7. Запрещенные серии таксофонных карт
.3.8. Разрешенные серии таксофонных карт
3. Управление
3.1. Дата, время перехода на время
3.1.1. Зимнее
3.1.2. Летнее
Рис. 2.7. Алгоритм вывода данных на печать
3.2. Дата праздничного дня
3.3. Дата, время ввода тарифов
3.3.1. Городского
3.3.2. Междугороднего
.3.3. Международного
3.4. Основное время связи с ЦСК
3.5. Резервное время связи с ЦСК
4. Финансы
4.1. Ежедневный отчет
4.2. Отчетность
4.2.1. Ежемесячный отчет
4.2.2. Годовой отчет
5. Статистика
5.1. Ежедневный отчет
5.2. Отчетность
5.2.1. Ежемесячный отчет
5.2.2. Годовой отчет
6. Диагностика
6.1. Ежедневный отчет
6.2. Отчетность
6.2.1. Ежемесячный отчет
6.2.2. Годовой отчет
6.3. Список таксофонов
6.4. Состояние таксофонов
.5. Истории событий
6.5.1. Отказы
6.5.2. Ремонты
.5.3. Изменение характеристик
.5.4. Изменение кодов городов
.5.5. Изменение тарифов
.5.6. Изменение параметров
.5.7. Изменение бесплатных номеров
.5.8. Изменение «белого списка» (разрешенные серии
таксофонных карт)
.5.9. Изменение «черного списка» (запрещенные серии
таксофонных карт)
.5.10. Прием счетчиков
6.6. Количество опознанных ДТК
6.6.1. Городские
6.6.2. Междугородние
.6.3. Международные
.6.4. Проверочные
.6.5. Неиспользуемого типа
.6.6. С нулевым содержанием
.6.7. Из «черного списка»
6.7. Количество срабатываний защиты
6.7.1. От имитаторов
6.7.2. От параллельных подключений
7. Выход
3.
Методика испытаний и результаты экспериментальной проверки
Методика испытаний программного обеспечения
Как показано в [5], процесс тестирования программ обычно
включает:
·
создание
совокупности тестовых эталонных значений и правил, которым должна
соответствовать программа по выполняемым функциям, структуре, правилам
описания, значениям исходных и соответствующих им результирующих данных;
·
статическое
тестирование текстов разработанных программ и данных на выполнение всех
заданных правил построения и описания без исполнения объектного кода;
·
тестирование
программы с её исполнением в объектном коде и с разными уровнями детализации:
детерминированное, стохастическое, и тестирование в реальном масштабе времени;
·
диагностику
и локализацию причин отклонения результатов тестирования от заданных эталонных
значений и правил;
·
разработку
изменения программы с целью исключения причин отклонения результатов от
эталонных;
·
реализацию
корректировки программы, обеспечивающую соответствие программы заданному
эталону.
Статическое тестирование является наиболее формализованным и
автоматизируемым методом проверки корректности программ. В качестве эталонов
применяются правила структурного построения программных модулей и обработки
данных, конкретизированные для проекта КП в целом. Кроме того, могут
использоваться некоторые частные правила обработки данных, зафиксированные в
спецификациях на отдельные компоненты программ. Проверка степени выполнения
этих правил проводится без исполнения объектного кода программы путём
формального анализа текста программы на языке программирования. Операторы и
операнды текста программ при этом анализируются в символьном виде, поэтому
такой метод называют также символическим тестированием. Развитие и углубление
символического тестирования может доводиться до уровня формальной верификации
программы на соответствие её текста детальной спецификации совокупности
утверждений, полностью определяющей связи между входными и выходными данными
этой программы.
Наиболее трудоёмкими и детализирующими являются методы
детерминированного тестирования. При детерминированном тестировании
контролируется каждая комбинация исходных эталонных данных и соответствующая ей
комбинация результатов функционирования программы. Это позволяет выявлять
отклонение результатов от эталона с конкретным фиксированием всех значений
исходных и результирующих данных, при которых это отклонение обнаружено.
В сложных программах невозможно перебрать все комбинации
исходных данных и проконтролировать результаты функционирования программы на
каждой из них. В таких случаях применяется стохастическое тестирование, при
котором исходные тестовые данные задаются множествами случайных величин с
соответствующими распределениями и для сравнения полученных результатов
используются также распределения случайных величин. В результате при
стохастическом тестировании возможно более широкое варьирование исходных
данных, хотя отдельные ошибки могут быть не обнаружены, если они мало искажают
средние статистические значения или распределения. Стохастическое тестирование
применяется в основном для обнаружения ошибок, а для диагностики и локализации
ошибок приходится переходить к детерминированному тестированию с использованием
конкретных значений параметров из области изменения ранее использовавшихся
случайных величин.
Последующее расширение области изменения исходных данных
возможно при применении тестирования в реальном масштабе времени. В процессе
такого тестирования проверяется исполнение программ и обработка исходных данных
с учётом времени их поступления, длительности и приоритетности обработки,
динамики использования памяти и взаимодействия с другими программами и т.д. При
обнаружении отклонений результатов исполнения программ от предполагавшихся
эталонных для локализации ошибки приходится фиксировать время и переходить к
детерминированному тестированию.
Особенности задачи в приложении к тестированию программ.
Среда программирования Centura и язык
программирования в ней SAL имеют ряд особенностей, влияющих на тестирование
программ:
·
SAL является языком программирования высокого уровня, что
увеличивает значимость статического (символьного) тестирования;
·
среда программирования разработана для поддержки высокой степени
использования стандартных поставляемых в модулях процедур. Эти модули являются
уже оттестированными и испытанными. Считается, что вызываемые процедуры
обладают высокой надёжностью и свободны от ошибок.
·
среда программирования имеет развитую систему автоматической
символьной проверки. Она на этапе написания программы следит за корректностью
вводимого текста и обнаруживает все синтаксические ошибки.
·
большую часть структуры программы в Centura занимают
стандартные, автоматически создаваемые объекты, управляющие работой программы в
ответ на действия пользователя. Поэтому ошибки в основном содержатся в
алгоритмах процедур, написанных программистом;
Особенности поставленной задачи.
Надежность представленной системы зависит от
следующих компонент:
·
надежность сервера базы данных и библиотек связи клиента -
сервера;
·
надежность сетевого соединения;
·
надежность клиентской части.
Первые две компоненты являются стандартными,
поэтому имеет смысл лишь проверка надежности третьей компоненты.
Тестирование надежности программного обеспечения.
Ввиду особенностей поставленной задачи полные
испытания программы одновременно с доработкой должны производиться после
вхождения разработок аппаратной части в окончательную фазу. На текущем этапе
всеобъемлющее тестирование не имеет смысла.
При тестировании надежности клиентской части
необходимо решить следующие проблемы:
·
высвобождение ненужных системных ресурсов, затребованных ранее;
·
своевременная фиксация изменений в базе данных (отсутствие
неподтвержденных оконченных транзакций);
·
устойчивость к ошибочному вводу пользователя.
В рамках проверки надежности клиентской части
было проведено тестирование:
1.
Используя
механизм сообщений Windows, с каждой формой приложения были выполнены следующие действия:
a)
вызов
формы,
b)
обновление
данных,
c)
добавление
новой строки,
d)
удаление
строки,
e)
изменение
данных.
Контроль правильности вводимых данных.
В разработанной программе контроль правильности вводимых
данных осуществляется механизмом ограничений целостности, поддерживаемым
сервером базы данных.
Ограничения целостности делятся на следующие типы:
1.
Ограничения
пустого значения.
Разработчиком задаются поля, которые не могут быть пустыми.
Например, порядковый (он же идентификационный) номер таксофона не может быть
пустым, то есть оператор всегда должен вводить порядковый номер таксофона.
2.
Ограничения
ссылочного ключа.
В указанное разработчиком поле или группу полей не может быть
введено значение, которое не существует в справочнике, указанном разработчиком.
Например, таксофон не может быть закреплен за ответственным лицом,
несуществующим в справочнике ответственных лиц.
3.
Ограничения
уникальности.
В указанное разработчиком поле не может быть введено двух
одинаковых значений. Например, среди поддерживаемых системой таксофонов не
может быть двух с одинаковыми порядковыми номерами.
4.
Ссылочные
ограничения
·
Если
на строку данной таблицы ссылаются другие строки, то запрещены операции
удаления и изменения этой строки до тех пор, пока ссылающиеся строки не будут
удалены либо изменены.
·
При
попытке изменения строки данной таблицы во всех ссылающихся на нее строках
происходят соответствующие изменения (удаление). Данное ограничение гарантирует
правильные данные в базе данных и исключает ссылки каких-либо полей на
несуществующие строки. Например, таксофон не может быть закреплен за
сотрудником, которого нет в системе. При попытке удаления ответственного лица,
за которым закреплен таксофон, оператор получит соответствующее предупреждение,
вынужден будет закрепить таксофон за другим сотрудником и только затем получит
возможность удалить данного служащего.
Таким образом, использование механизма ограничения
целостности исключает появление в системе неверных данных.
Функциональное тестирование.
После ввода централизованной системы управления в
эксплуатацию все таблицы фиксируют свой размер, так как нет интенсивного ввода
(изменения, удаления), кроме таблиц «Параметры таксофонов» и «Счетчики
таксофонов».
Зависимость размера файлов БД от срока эксплуатации системы
(обслуживание 3000 таксофонов).
Для выявления скорости роста файлов базы данных и мер по
предотвращению поддержки чрезмерного объема данных достаточно рассмотреть
изменения, вызываемые указанными таблицами («Параметры таксофонов» и «Счетчики
таксофонов»).
Таблица «Параметры таксофонов» ежедневно вырастает на 3000
строк. В зависимости от данных в строке последняя занимает вместе со связанными
структурами (индексы) от ХХ до ХХХ байт дискового пространства. Средний размер
строки предположительно ХХХХ байт.
4.
Технологическая часть
4.1 Технология создания программного обеспечения
с учетом контроля качества (надежности)
Проблема качества программного обеспечения становится сегодня
все более острой, особенно по мере расширения использования информационных
технологий и роста сложности ПО. Высокое качество продуктов дает разработчикам
не только конкурентные преимущества и кредит доверия клиентов, но и облегчает
сопровождение и развитие программного обеспечения.
Согласно формулировке стандарта ISO 8402, под качеством
понимается совокупность характеристик программного продукта, относящихся к его
способности удовлетворять установленные и предполагаемые потребности клиентов.
Основными параметрами качества считаются: функциональная полнота, соответствие
требованиям законодательства стран СНГ, безопасность информации, простота эксплуатации,
не требующая специальных знаний в области информационных технологий,
эргономичность пользовательского интерфейса, минимизация затрат на
эксплуатацию, развитие и модернизацию.
Под надежностью обычно понимается способность
системы выполнять заданные функции, сохраняя основные характеристики при
определенных условиях эксплуатации. Применительно к программному обеспечению
это прежде всего безотказная работа, отсутствие ошибок, препятствующих
нормальному функционированию предприятия.
Качество и надежность в комплексе обеспечивают
высокие потребительские свойства ПО. В процессе создания программного продукта
они одновременно и непрерывно контролируются и совершенствуются.
Создание качественного ПО невозможно без
обеспечения надежности и качества на всех стадиях разработки, начиная от
проектирования. В связи с этим в настоящее время значительно возрос интерес к
методике разработки и контроля качества программного обеспечения.
Этапы создания программного продукта.
Жизненный цикл программного обеспечения включает в себя
следующие фазы:
1.
Анализ
осуществимости системы.
На данной стадии проводится исследования о возможности и
необходимости реализации системы программным путем, тщательно изучаются и
анализируются существующие аналоги (если они есть), в самых общих чертах
определяются основные функциональные требования к будущему программному
продукту.
2.
Планирование
и анализ требований к ПО.
На этой стадии проводится тщательное определение и
подтверждение требований к ПО до начала основной работы над проектом всей
системы, их анализ, а кроме того, планирование разработки изделия. План
разработки также должен быть проанализирован и утвержден. Степень формальности
и строгости процессов анализа соответствует сложности разрабатываемой системы и
степени риска, связанного с ее использованием.
3.
Проектирование
изделия.
Анализ проектирования, выполняемый до начала основных работ,
затрагивает такие аспекты, как выполнимость проекта, удовлетворение требованиям
защиты и безопасности системы, выполнение правил программирования и возможность
тестирования. При проектировании ПО должны учитываться:
·
используемый
метод проектирования и его соответствие конкретной задаче,
·
опыт
предыдущих проектов,
·
требования
последующих процессов (тестирования, установки, сопровождения и использования)
·
соображения
защиты и безопасности.
1.
Кодирование.
Для обеспечения высокого качества создаваемого продукта
процесс кодирования (программирования) должен проводиться строго в соответствии
с заданными правилами использования языков программирования, принципами
кодирования и правилами составления адекватных комментариев.
2.
Тестирование.
Тестирование программного продукта требуется на нескольких
уровнях, от отдельных элементов ПО до законченной системы. Объем тестирования,
степень контроля за средой испытаний, входные и выходные данные тестов могут
варьироваться в зависимости от выбранного подхода тестирования, сложности
системы и связанных с ней рисков.
3.
Опытная
эксплуатация (внедрение).
Прежде чем система будет передана заказчику, согласно
стандарту ISO 9000-3 поставщик (разработчик) должен утвердить систему на
соответствие заданному назначению. Заказчику может быть передан только
утвержденный продукт. Однако до окончательного утверждения необходимо проверить
ПО в реальных условиях, для чего после завершения тестирования изделие
поступает в опытную эксплуатацию на предприятие (к заказчику).
4.
Коммерческая
реализация и функционирование (эксплуатация).
Разработчиком продукта на данной стадии проводится его
обслуживание. Для программного обеспечения под обслуживанием понимается
сопровождение системы (maintanance) и поддержка заказчиков (customer support).
Сопровождение системы, как правило, включает в
себя:
·
обнаружение и анализ несоответствий в системе, вызывающих сбои в
ее работе;
·
коррекцию программных ошибок;
·
модификацию интерфейсов, что необходимо в случае внесения
добавлений или изменений в аппаратуру:
·
функциональное расширение или улучшение производительности.
Согласно стандарту ISO 9000-3 все действия
по сопровождению должны проводиться и контролироваться в соответствии с планом
сопровождения, который заранее определяется и согласовывается поставщиком
(разработчиком) и заказчиком.
Разработка системы - это процесс преобразования
исходных требований в конечный программный продукт. Этот процесс должен
проводиться в строго определенном порядке, что позволит предотвратить появление
ошибок и снизит зависимость от процессов проверки.
Период разработки программного продукта
начинается фазой проектирования изделия после успешного анализа требований к ПО
и оканчивается фазой испытаний (после успешного завершения анализа результатов
приемки ПО).
Проектирование программного продукта.
На сегодня соотношение времени, затраченного на
проектирование, кодирование и тестирование составляет 40%, 20% и 40%
соответственно.
Проектирование разбивается на несколько этапов:
1.
Разработка
технического задания (постановка задачи) и его анализ.
2.
Составление
проекта (создание макета) системы.
3.
Алгоритмизация.
Результаты каждого этапа подвергаются экспертизе,
перекрестной проверке и взаимосогласованию. Наличие детально проработанной
проектной документации существенно снижает вероятность возникновения ошибок и
служит дополнительной гарантией надежности ПО.
Итак, рассмотрим более подробно этапы создания программного
продукта.
Постановка задачи.
На этапе формирования технического задания (ТЗ) определяются
основные технические требования к программному продукту:
·
функциональные
требования,
·
требования к информационной и программной совместимости,
·
требования к надежности ПО,
·
требования к условиям эксплуатации.
Техническое задание регламентирует всю работу по
созданию программного изделия и содержит формулировку задачи, необходимые
характеристики разрабатываемой системы, требования к взаимодействию различных
модулей и блоков.
Разработке такого задания для крупных программных
систем предшествует большая работа научно-исследовательского характера (фазы
1,2 жизненного цикла ПО).
Задание на разработку программы по форме и
характеру должно быть аналогично техническому заданию (ТЗ) на разработку
какого-либо технического продукта (см., например, ГОСТ 19.201-78 Единой системы
программной документации).
Техническое задание полезно и в том случае, когда
заказчик и исполнитель работают в одной и той же комнате или даже являются
одним и тем же лицом. Наличие четкой письменной формулировки будет
препятствовать подмене или отходу в процессе разработки программы от
сформулированных в ТЗ требований в угоду каким-то другим побочным целям. Кроме
того, письменно сформулированное задание делает возможным обсуждение, оценку и
согласованную с заказчиками (пользователями) корректировку отдельных требований
ТЗ в ходе разработки изделия, ТЗ препятствует проникновению в программу таких
ошибок и противоречий, которые могут быть обнаружены только после разработки
большей части программы или уже на стадии анализа полученных результатов. Чем
более формализованным по характеру будет техническое задание, тем больше
шансов, что разрабатываемая программа будет решать именно ту задачу, которую
имел в виду заказчик.
Техническое задание должно содержать также
требования или указания, касающиеся принципов проверки и испытаний готового
программного продукта.
Составление проекта.
На основании анализа технического задания
выбирается основной метод решения задачи и составляется общий проект программы.
Выбранный подход к решению задачи должен обеспечивать правильные результаты для
тех условий функционирования программы, которые определены ТЗ, гарантировать
требуемую скорость работы, предусматривать удобство использования программы и
т.п.
В проекте, помимо формулировки выбранного общего
метода решения задачи, характеризуются основные части проектируемой программы,
их функции, взаимосвязь и последовательность выполнения, а также точно определяются
входные данные и выдаваемые результаты, как всей программы, так и основных ее
частей. Поскольку каждая разрабатываемая программа, как правило, используется в
дальнейшем широким кругом пользователей, как программистов, так и
неспециалистов в области информатики, то составляется и проект инструкции для
пользователей, в которой фиксируется (и, таким образом, может быть заранее
оценен и исправлен) предполагаемый режим общения пользователя (и оператора) с
программой.
Для очень простых задач проектирование может
проводиться программистом мысленно, без фиксации на бумаге. Наоборот, крупные и
сложные задачи требуют нескольких этапов проектирования:
·
предэскизное,
·
эскизное,
·
техническое
- по аналогии с инженерным проектированием.
Алгоритмизация.
На этот этап иногда смотрят как на
вспомогательный, подготовительный к выполнению следующего этапа разработки ПО -
программированию, или кодированию (см. п. 4.4.), на котором производится
написание программы на выбранном языке программирования. Введение такого
«промежуточного» этапа преследует цель облегчить выполнение этапа 4.4. и тем
самым предотвратить возникновение многих ошибок при его осуществлении для
сложных задач, а следовательно, повысить качество и надежность создаваемого ПО.
Формулировка алгоритма закрепляет последовательность основных шагов выполнения
программы, четко фиксирует функциональное содержание ее частей, позволяет
уделить необходимое внимание простоте логической структуры разрабатываемой
программы. Этап алгоритмизации является совершенно необходимым также в случае,
когда язык, на котором предстоит программировать, не вполне освоен
программистом-разработчиком и предвидятся трудности при его использовании на
этапе кодирования.
При разработке алгоритма необходимо учитывать
ресурсы используемой ЭВМ (ее скорость, память) и возможности применяемой для
решения задачи операционной системы. Алгоритмы для несложных задач, требования
которых к ресурсам невелики, являются обычно машинно-независимыми.
В ходе разработки общего алгоритма обычно используют
языки специфицирования (формализованные разговорные) либо блок-схемы, которые
позволяют наиболее наглядно представить логическую структуру разрабатываемой
программы, взаимосвязь ее отдельных частей и модулей, условия или кратность
выполнения таких частей. Для отображения вычислительной (арифметической)
стороны программы используются обычные математические средства или элементы
алгоритмических языков, а в самых общих блок-схемах - просто словесная
формулировка; иногда используются и все эти способы вместе.
Для достаточно сложных программ алгоритмизация
проводится в несколько шагов с целью постепенной детализации алгоритма.
Критерием окончания детализации при этом является то, что для каждого (псевдо)
оператора в полученном на очередном шаге алгоритме программист уже имеет четкое
и конкретное мысленное представление о том, как этот оператор алгоритма может
быть выражен средствами выбранного языка программирования на этапе 4.4. Для
простых задач обычно разрабатывают блок-схемы на двух уровнях:
·
общая блок-схема программы и
·
блок-схемы отдельных частей (блоков) программы.
После последнего шага детализации алгоритма (а
иногда и после отдельных крупных шагов) проводится проверка полученного
алгоритма для выявления допущенных ошибок. Методы контроля алгоритма аналогичны
некоторым методам контроля программы.
В ходе разработки алгоритма, возможно, придется
уточнять или изменять решения, принятые на этапе 4.3.2., и в этом случае такие
изменения обязательно вносятся в проект, который всегда должен соответствовать
разрабатываемому алгоритму.
Кодирование.
В случае, когда на этапе проектирования была четко
проработана структура программы и получен детальный алгоритм, составление
программы в выбранной среде разработки сводится к переводу этого алгоритма на
язык программирования. Основные трудности и, следовательно, причины ошибок на
этом этапе заключаются в:
·
необходимости
знания всех требований и ограничений выбранного языка (среды) программирования
и
·
необходимости
постоянного внимания ко многим деталям языка, которые приходится учитывать в
ходе написания программы.
Этап программирования, т.е. собственно процесс написания
программы, в последнее время получил название кодирования, подчеркивая тем
самым его механический, нетворческий характер. Чем более процесс кодирования
будет походить на перевод, чем более механическим будет такой перевод, тем
более легким будет составление программы и тем меньше возникнет ошибок на этом
этапе, самом щедром на ошибки.
Тестирование программного обеспечения.
Тестирование - один из ключевых элементов обеспечения
качества. Многие известные разработчики ПО проводят тестирование своих
продуктов в несколько этапов, которые отличаются видами выполняемых работ и
привлекаемыми ресурсами.
Фактически, тестирование начинается еще в процессе
кодирования очередной версии [9]: оперативно тестируются и отлаживаются вновь
разрабатываемые или изменяемые функции системы. Подобная организация работ
позволяет сэкономить время и силы, поскольку значительная часть ошибок
выявляется и устраняется практически в момент возникновения. Работа
тестировщика (отладчика) на этом этапе как бы локализована в рамках одного
модуля или части системы, разрабатываемой данной группой (для крупных систем),
поэтому такое тестирование называется локальным.
При определенной степени готовности системы проводится
перекрестное тестирование: разработчики различных частей «свежим взглядом»
проверяют работу друг друга, одновременно обмениваясь опытом. При создании
небольших программных продуктов, когда программист-разработчик одновременно
является тестировщиком, этот этап обычно пропускается, часто незаслуженно.
И локальное, и перекрестное тестирование сопровождается
проверкой исходного кода. Если работа тестировщика с системой - это поиск
ошибок по их проявлениям в процессе выполнения программы, то работа с исходным
кодом позволяет «отловить» ошибки, которые при обычном тестировании проявятся
не сразу.
Во время кодирования проверяются отдельно взятые функции или
их блоки в пределах одного модуля системы. Затем начинается тестирование
системы как единого целого (интегральное тестирование). На корпоративном уровне
эта стадия цикла разработки программного продукта включает несколько этапов.
Сначала в работу включаются только подразделения Департамента
разработки ПО (отдел интегрального тестирования) - этот этап цикла разработки
называется внутренним тестированием. Проверяется функциональная полнота
системы, соответствие проектной документации, корректность проектных решений;
контролируется соответствие законодательствам стран СНГ.
На следующем этапе в работу вовлекаются ресурсы, внешние по
отношению к Департаменту разработки ПО:
·
подразделения
корпорации, занимающиеся сбытом и технической поддержкой;
·
клиенты
- заказчики новой системы (новых функций модифицируемой системы);
·
другие
заинтересованные организации.
На стадии внешнего тестирования происходит концентрация
усилий сотен опытных экспертов, использующих различную методологию и
разнообразные подходы к работе с системой. Практически все подразделения
корпорации участвуют во внешнем тестировании, а объединение с другими
корпорациями создает возможность обмена программными продуктами для
перекрестного интегрального тестирования.
И на внутреннем, и на внешнем тестировании постоянно
проводится статистический анализ количества обнаруженных и исправленных ошибок,
на основе результатов которого принимается решение о переходе к следующему
этапу (см. рис. 4.1).
Заключительное тестирование проводит отдел интегрального
тестирования Департамента разработки ПО. Его задача - еще раз проверить
реализацию максимального количества бизнес-процессов и убедиться, что
исправление ошибок на предшествующих этапах не вызвало новых ошибок. Фактически
это «прогон» системы, на который отводится до 10 рабочих дней.
Далее версия системы передается в опытную эксплуатацию на
предприятия. Это тоже ответственная стадия, ибо даже самое полное тестирование
не всегда позволяет выявить все нюансы, которые обнаруживаются при реальной
эксплуатации. (Обычно заинтересованный заказчик выступает в роли придирчивого и
дотошного тестировщика.) Если в течение месяца серьезных замечаний не
поступает, версия передается остальным клиентам и на коммерческую реализацию.
В итоге версия на пути от разработчика до клиента проходит
шесть уровней тестирования, на каждом из которых обеспечивается минимизация
ошибок и достижение установленных в начале разработки значений показателей
качества и надежности [10].
Сам фактор надёжности включает в себя два критерия:
·
устойчивость
функционирования -
способность обеспечивать продолжение работы программы после
возникновения отклонений, вызванных сбоями технических средств, ошибками во
входных данных и ошибками обслуживания;
·
работоспособность
-
способность программы функционировать в заданных режимах и
объёмах обрабатываемой информации в соответствии с программными документами при
отсутствии сбоев технических средств.
Оценка каждого из критериев включает в себя оценки так
называемых метрик:
|
Средства
восстановления при ошибках при входе Средства восстановления при сбоях
оборудования Реализация управления средствами восстановления
|
|
для критерия
устойчивости функционирования
|
|
Функционирование
в заданных режимах Обеспечение обработки заданного объёма информации
|
|
для критерия
работоспособности.
|
В своей оценке каждая из метрик содержит оценки так
называемых оценочных элементов. Каждый оценочный элемент обозначается кодом,
составленным из 5 символов.
В таблице 4.1 описаны используемые оценочные элементы, их
значение и методы оценки.
Таблица 4.1. Оценочные элементы
|
Код элемента
|
Наименование
|
Метод оценки
|
Оценка
|
|
H0101
|
Наличие
требований к программе по устойчивости функционирования при наличии ошибок во
входных данных
|
Экспертный
|
0 - 1
|
|
H0102
|
Возможность
обработки ошибочных ситуаций
|
««
|
0 - 1
|
|
H0103
|
Полнота
обработки ошибочных ситуаций
|
««
|
0 - 1
|
|
H0104
|
Наличие тестов
для проверки допустимых значений входных данных
|
««
|
0 - 1
|
|
H0105
|
Наличие системы
контроля полноты входных данных
|
««
|
0 - 1
|
|
H0106
|
Наличие средств
контроля корректности входных данных
|
««
|
0 - 1
|
|
H0107
|
Наличие средств
контроля непротиворечивости входных данных
|
Экспертный
|
0 - 1
|
|
H0108
|
Наличие
проверки параметров и адресов по диапазону их значений
|
««
|
0 - 1
|
|
H0109
|
Наличие
обработки граничных результатов
|
««
|
0 - 1
|
|
H0110
|
Наличие
обработки неопределённостей (деление на 0, квадратный корень из
отрицательного числа)
|
««
|
0 - 1
|
|
H0201
|
Наличие
требований к программе по восстановлению процесса выполнения в случае сбоя
операционной системы, процессора, внешних устройств
|
««
|
0 - 1
|
|
H0202
|
Наличие
требований к программе по восстановлению результатов при отказах процессора,
операционной системы
|
««
|
0 - 1
|
|
H0203
|
Наличие средств
восстановления процесса в случае сбоев оборудования
|
««
|
0 - 1
|
|
H0204
|
Наличие
возможности разделения по времени выполнения отдельных функций программ
|
««
|
0 - 1
|
|
H0205
|
Наличие
возможности повторного старта с точки останова
|
««
|
0 - 1
|
|
H0301
|
Наличие
централизованного управления процессами, конкурирующими из-за ресурсов
|
««
|
0 - 1
|
|
H0302
|
Наличие
возможности автоматически обходить ошибочные ситуации в процессе вычисления
|
««
|
0 - 1
|
|
H0303
|
Наличие
средств, обеспечивающих завершение процесса решения в случае помех
|
««
|
0 - 1
|
|
H0304
|
Наличие
средств, обеспечивающих выполнение программы в сокращённом объёме в случае
ошибок или помех
|
Экспертный
|
0 - 1
|
|
H0305
|
Показатель устойчивости
к искажающим воздействиям
|
Расчётный
|
|
|
где
|
D -
|
число
экспериментов, в которых искажающие воздействия приводили к отказу
|
|
|
К -
|
число
экспериментов, в которых имитировались искажающие воздействия
|
|
H0401
|
Вероятность
безотказной работы
|
Расчётный
|
|
|
где
|
Q -
|
число
зарегистрированных отказов,
|
|
|
N -
|
число
экспериментов
|
|
H0501
|
Оценка по
среднему времени восстановления
|
Расчёт ный
|
|
|
|
|
|
|
где
|
 допустимое среднее время восстановления;
|
|
|
|
 среднее время восстановления, которое
определяется по формуле
|
|
|
|
|
где
|
N -
|
число
восстановлений
|
|
|
 время восстановления после i-го отказа
|
|
|
H0502
|
Оценка
по продолжительности преобразования входного набора данных в выходной
|
Расчётный
|
|
|
|
|
|
|
где
|
 -допустимое время преобразования i-го
набора данных;
|
|
|
|
 -фактическая продолжительность
преобразования i-го входного набора данных
|
|
|
|
|
|
|
|
|
|
|
В зависимости от фазы проектирования фактор надёжности
включает в себя различное количество показателей. На этапе анализа рассчитывается
только критерий устойчивости функционирования, включающий в себя только две
метрики: средства восстановления при ошибках при входе и средства
восстановления при сбоях оборудования. На этапе проектирования добавляется ещё
метрика реализации управления средствами восстановления. На фазах реализации,
тестирования, изготовления, обслуживания(сопровождения) начинает учитываться
критерий работоспособности и все его метрики.
В соответствие с приведённым в [14] порядком расчёта фактора
надёжности можно составить схему технологии оценки надёжности программного
средства (ПС).
Оценим надежность разработанного программного продукта,
выбрав в качестве фазы создания ПС, на которой производится расчёт, фазу
реализации и тестирования:
1.
Определяются
оценочные элементы используемых метрик (см. таб. 4.2).
Таблица 4.2. Определение оценочных элементов
|
Код оценочного
элемента
|
Выбранное
значение
|
Обоснование
|
|
H0101
|
0,1
|
Ввиду того, что
проект находится на ранней стадии развития, особых требований по устойчивости
функционирования не предъявлено. Учитываются лишь самые общие, отсюда и
низкий показатель.
|
|
H0102
|
0,8
|
Возможность
обработки ошибок в разработанной программе реализована.
|
|
H0103
|
0,8
|
Проверка на
ошибку происходит в каждой точке обращения к базе данных и другим компонентам
программы, что обеспечивают высокую полноту.
|
|
H0104
|
0,8
|
Проверку
допустимых значений входных данных осуществляет сервер базы данных.
|
|
H0105
|
0,8
|
Проверку
допустимых значений и контроль входных данных осуществляет сервер базы
данных.
|
|
H0106
|
0,9
|
Осуществляется
сервером базы данных.
|
|
H0107
|
0,9
|
Осуществляется
программой и сервером базы данных.
|
|
H0108
|
0,6
|
Частично
реализована в базе данных.
|
|
H0109
|
0,5
|
Не требуется в
силу специфики проекта.
|
|
H0110
|
1
|
Встроена в
стандартные компоненты, обеспечивается автоматически.
|
|
H0201
|
0,1
|
Оборудование
считается достаточно надёжным, чтоб не предъявлять такие требования. Частично
обеспечивается операционной системой.
|
|
H0202
|
0,9
|
Система
является самовосстанавливающейся, при сбоях оборудования все данные
сохраняются.
|
|
H0203
|
0,8
|
То же.
|
|
H0204
|
0,5
|
Частично
реализуется сервером базы данных, а также ОС в силу её многозадачности.
|
|
H0205
|
0
|
Отсутствует.
|
|
H0301
|
0,9
|
Таких процессов
практически нет, реализуется операционной системой и достаточностью ресурсов.
|
|
H0302
|
0,6
|
Частично реализовано
в рамках обработки ошибок.
|
|
H0303
|
0,9
|
Реализована на
уровне стандартных компонент и ОС при критических ошибках.
|
|
H0304
|
0
|
Отсутствует.
|
|
H0305
|
0,8
|
Нормальный.
|
|
H0401
|
0,8
|
Нормальная.
|
|
H0501
|
1
|
Достаточная.
|
|
H0502
|
1
|
Достаточная.
|
1.
По
полученным значениям оценочных элементов рассчитываются задействованные
согласно данной фазе проектирования метрики.
Итоговая оценка k-й метрики j-го критерия ведется по
формуле:
(4.1)
где Q - число оценочных элементов в метрике
- оценка q-го оценочного элемента
Таблица 4.3. Оценки метрик
|
Метрики
|
Оценки
|
|
1
|
Средства
восстановления при ошибках при входе
|
0,72
|
|
2
|
Средства
восстановления при сбоях оборудования
|
0,46
|
|
3
|
Реализация
управления средствами восстановления
|
0,64
|
|
4
|
Функционирование
в заданных режимах
|
0,8
|
|
5
|
Обеспечение
обработки заданного объёма информации
|
1
|
1.
Выбор
весового коэффициента для каждой метрики (см. таб. 4.4).
Он определяет значимость этой метрики для дальнейшего
расчёта. Для каждого критерия сумма весов входящих в него метрик должна
равняться единице.
Таблица 4.4. Весовые коэффициенты метрик
|
№ метрики
|
Весовой
коэффициент
|
Обоснование
|
|
1
|
0,5
|
Имеет
наибольшую важность
|
|
2
|
0,3
|
Требуется в
меньшей степени в силу самовосстанавливаемости системы и надёжности
оборудования
|
|
3
|
0,2
|
Имеет малую
важность в силу практического отсутствия необходимости в подобном управлении
|
|
4
|
0,6
|
Важности метрик
этого критерия практически равны в силу их стандартности
|
|
5
|
0,4
|
Имеет меньшую
важность, в силу работы программы не в режиме реального времени
|
Нахождение абсолютных показателей критериев i-го фактора качества
(надёжности) ведется по формуле:
(4.2)
где n - число метрик, относящихся к j-тому критерию
- весовые коэффициенты метрик
Таблица 4.5. Абсолютные показатели критериев надежности
|
Критерий
|
Оценка
|
|
1
|
0,31784
|
|
2
|
Работоспособность
|
0,88
|
1.
Расчёт
относительных показателей критериев i-го фактора качества ведется по формуле:
(4.3)
Относительные показатели критериев определяются отношением
абсолютных показателей критериев данного образца к абсолютным показателям
критериев базового образца. Показатели базового образца выбираются экспертами в
соответствии со значениями показателей, отражающих современный уровень и
прогнозируемый мировой. Поскольку техническая информация о характеристиках
подобных программ, которые имеются лишь за рубежом, отсутствует, базовые
показатели критериев возьмем равными единице, то есть идеалу.
1.
Выбор
весового коэффициента для каждого критерия (см. таб. 4.6).
Как и для метрик, весовой коэффициент определяет значимость
данного критерия для дальнейшего расчёта. Сумма весов должна равняться единице.
Таблица 4.6. Весовые коэффициенты критериев
|
№ критерия
|
Коэффициент
|
Обоснование
|
|
1
|
0,4
|
В силу
достаточной надёжности оборудования, критерий работоспособности имеет чуть
большее значение
|
|
2
|
0,6
|
|
1.
Оценка
фактора качества надёжность.
Фактор качества вычисляется по формуле:
(4.4)
где N - число критериев, относящихся к i-тому фактору
- весовые коэффициенты факторов
Получили 
. Как видно, надёжность данной программы
удовлетворяет требованиям. Однако следует учесть, что в значения относительных
критериев принимались равными абсолютным значениям (значения базовых критериев
приравнивались к единице, или идеалу, что на самом деле невозможно, а потому не
совсем корректно). Если значения базовых критериев отличной программы оценить
равными 0,9, то фактор надёжности нашей программы повысится до 
.
Технология разработки программного обеспечения - это целая наука.
В данном разделе дипломного проекта проблема создания качественного ПО
рассматривалась с позиции международной организации по стандартизации (ISO), идея которой состоит в
следующем: качество программного обеспечения напрямую зависит от качества
процесса его создания и разработки [11]. В качестве основы взяты требования к
обеспечению качества на разных этапах производственного процесса,
сформулированные в нескольких стандартах, одобренных в 80-х годах ISO: ISO
9001, 9002, 9003 [8]. Также рассмотрена технология оценки факторов качества
программных средств (на примере фактора надежность) и проведен расчет
надежности разработанного в данном дипломном проекте программного продукта в
соответствии с требования российского стандарта качества - ГОСТ 28195-89 [14].
Заключение
Программа централизованной системы контроля и
управления сетью таксофонов разработана на языке SAL и содержит ХХХ
операторов. Проведены оценка надежности (раздел 4 данной пояснительной записки)
и испытания созданного программного продукта (раздел 3 пояснительной записки),
что подтвердило его соответствие техническим требованиям. Проверка
осуществлялась в операционной среде Windows NT4.0 ххххх. Окончательное
тестирование предполагается после реализации аппаратной части.
Разработанное программное обеспечение в составе
всей системы имеет широкое практическое применение в силу высокой
конкурентоспособности, обоснованной в разделе 5 данной пояснительной записки, а
также перспектив развития телекоммуникационного рынка, в частности рынка
таксофонных услуг, и роста таксофонной сети России.
Литература
1.
Интегральная оценка работоспособности при умственном и физическом
труде. Методические рекомендации. М.: Экономика, 2009.
2.
Техническая документация «Разработка многоканальной ЦСК с
модифицированными кредитными картами». М.: НИИ «Научный Центр», 2010.
3.
Построение таксофонной сети «ТСНЦ»: обзор ситуации, концепция
построения. М.: НИИ «Научный Центр», 2009.
4.
Н.Н. Зубов, А.Я. Пьянзин. Методические указания по дипломному
проектированию по специальности «Программное обеспечение вычислительной техники
и автоматизированных систем». М.: МИЭТ, 1990.
5.
В.В. Липаев. Надежность программного обеспечения АСУ. М.:
Энергоиздат, 2009.
6.
Н.К. Моисеева, Т.Д. Костина. Маркетинговые исследования при
создании и использовании программных продуктов. Методические указания для
выполнения курсовых и дипломных работ по специальности «Менеджмент». М.: МГИЭТ
(ТУ), 2007.
7.
Общее руководство качеством и стандарты по обеспечению качества (ISO 9000-1).
Руководящие указания по применению стандарта ISO 9001 при разработке, поставке и
обслуживании программного обеспечения (ISO 9000-3).
8.
Международный стандарт ИСО 9001:9004. Системы качества. Модель
обеспечения качества при проектировании, разработке, производстве, монтаже и
обслуживании (второе издание). М., 2006.
9.
Д. Коул, Т. Горэм, М. МакДональд, Р. Спарджеон. Принципы
тестирования ПО. // Открытые системы №2, 2002.
10. Г. Гацко.
Тестирование ПО как один из элементов системы качества. // Открытые системы №6,
2008.
11. Н. Дубова.
Знак качества программному продукту. // Открытые системы №6, 2008.
12. Основные
положения развития взаимоувязанной сети связи России на перспективу до 2005
года. Утв. Решением ГКЭС России, М., 2007.
13. Концепция
применения таксофонного оборудования на телефонной сети общего пользования
России. С-П.: ЛОНИИС, 2007.
14. ГОСТ 28195-89.
Оценка качества программных средств. Общие положения.
15. А.В. Васильев.
Карточные таксофоны. // Вестник связи №9, 2006.
16. С.А. Козлов,
В.А. Козлов, В.В. Романов. Тарификационные системы для учрежденческих АТС. //
Сети и системы связи №12, 2007.
17. Д. Алешин, С.
Крестьянинов. Междугородний и международный разговор с помощью
дебетно-кредитной системы сервисных телефонных карт.