Программное обеспечение системы управления и планирования работы сети таксофонов

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

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

общая блок-схема программы и

блок-схемы отдельных частей (блоков) программы.

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

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

Кодирование.

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

необходимости знания всех требований и ограничений выбранного языка (среды) программирования и

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

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

Тестирование программного обеспечения.

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

Фактически, тестирование начинается еще в процессе кодирования очередной версии [9]: оперативно тестируются и отлаживаются вновь разрабатываемые или изменяемые функции системы. Подобная организация работ позволяет сэкономить время и силы, поскольку значительная часть ошибок выявляется и устраняется практически в момент возникновения. Работа тестировщика (отладчика) на этом этапе как бы локализована в рамках одного модуля или части системы, разрабатываемой данной группой (для крупных систем), поэтому такое тестирование называется локальным.

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

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

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

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

На следующем этапе в работу вовлекаются ресурсы, внешние по отношению к Департаменту разработки ПО:

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

клиенты - заказчики новой системы (новых функций модифицируемой системы);

другие заинтересованные организации.

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

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

Заключительное тестирование проводит отдел интегрального тестирования Департамента разработки ПО. Его задача - еще раз проверить реализацию максимального количества бизнес-процессов и убедиться, что исправление ошибок на предшествующих этапах не вызвало новых ошибок. Фактически это «прогон» системы, на который отводится до 10 рабочих дней.

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

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

Сам фактор надёжности включает в себя два критерия:

устойчивость функционирования -

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

работоспособность -

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

Оценка каждого из критериев включает в себя оценки так называемых метрик:

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

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

Таблица 4.1. Оценочные элементы

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

В соответствие с приведённым в [14] порядком расчёта фактора надёжности можно составить схему технологии оценки надёжности программного средства (ПС).

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

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

Таблица 4.2. Определение оценочных элементов

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

Итоговая оценка k-й метрики j-го критерия ведется по формуле:

(4.1)

где Q - число оценочных элементов в метрике

- оценка q-го оценочного элемента

Таблица 4.3. Оценки метрик

Выбор весового коэффициента для каждой метрики (см. таб. 4.4).

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

Таблица 4.4. Весовые коэффициенты метрик

Нахождение абсолютных показателей критериев i-го фактора качества (надёжности) ведется по формуле:

(4.2)

где n - число метрик, относящихся к j-тому критерию

- весовые коэффициенты метрик

Таблица 4.5. Абсолютные показатели критериев надежности

Расчёт относительных показателей критериев i-го фактора качества ведется по формуле:

(4.3)

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

Выбор весового коэффициента для каждого критерия (см. таб. 4.6).

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

Таблица 4.6. Весовые коэффициенты критериев

Оценка фактора качества надёжность.

Фактор качества вычисляется по формуле:

(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 данной пояснительной записки, а также перспектив развития телекоммуникационного рынка, в частности рынка таксофонных услуг, и роста таксофонной сети России.

Литература