Читайте также:
|
|
В этом параграфе будет затронута важная тема сопровождения программного обеспечения АТС, по мнению автора, оставленная специалистами без должного внимания. В предыдущей главе отмечалось, что на программное обеспечение приходится почти 80% стоимости разработки станции, недостаточно глубокие исследования методов его технического обслуживания не проводились. А ведь нужно, кроме прочего, иметь в виду, что сопровождение ПО цифровой АТС выполняет как ее производитель (действия, связанные с коррекцией или модернизацией текущей версии ПО, включая «заплаты» и корректировки для исправления ошибок в текущей версии), так и оператор станции (регламентное обслуживание, диагностика, корректировка таблиц станционных файлов, добавление линий и трактов в базу данных АТС).
Нормальная работа системы программного управления АТС может нарушаться по следующим причинам:
• ошибки программного обеспечения, включая «жучки» (bugs), вызывающие ошибки доступа к оперативной памяти, или программные сбои, которые могут быть исправлены только с помощью перезагрузки системы;
• аппаратные сбои, связанные с неисправностями аппаратных средств управляющих компьютеров;
• некорректное восстановление, когда из-за ошибки в программном обеспечении и/или в документации невозможно правильно детектировать неисправность и изолировать неисправный блок;
• процедурные ошибки, связанные, например, с вводом неправильных данных оператором или с неправильным действием во время процедур восстановления, расширения и корректировки.
Смена версий ПО большой цифровой АТС обычно происходит один-два раза в год; между этими сменами корректировки ПО производятся с помощью «заплат» (patches), которые представляют собой модификации программы без перекомпиляции всей версии.
Сложность любой версии станционного ПО настолько высока, что избежать ошибок при ее проектировании и реализации практически невозможно. Опыт прошедших десятилетий показал, что не существует универсальной методики производства абсолютно безошибочного ПО АТС при допустимых ценах и при разумных затратах времени на разработку. Вероятно, такой методики не появится и в ближайшее десятилетие, тем более, что сложность станционного ПО обусловлена, прежде всего, его объемом, который может выражаться более чем миллионом строк исходного текста программы. 25- 30% этого объема занимают программы обработки телефонного трафика, порядка 20% - операционная система, а рассматриваемое в этой главе ПО эксплуатационного управления - порядка 50%.
В отличие от разработки аппаратных средств, где те или иные решения часто бывают обусловлены технологическими ограничениями, программное обеспечение проектируют специалисты, чей подход к работе в большей степени обусловлен доброй волей и свободой выбороа, нежели необходимостью, которую диктуют возможности технологии. В то же время, затраты на программирование превышают затраты на аппаратные средства. И то, и другое вместе часто побуждает руководителей проектов сокращать объем проектирования ПО, откладывая на завтра реализацию в нем тех или иных функций, в частности, функций его обслуживания. Следствием такой ориентации руководства иногда оказывается значительное ухудшение качества ПО. А куда разумнее было бы не экономить хотя бы на разработке простых и ясных программных средств сопровождения ПО в течение всего жизненного цикла АТС.
Ограниченный объем книги не позволяет рассмотреть эту проблематику более детально, но весьма полезно сопоставить кратко изложенные здесь соображения с материалом о качестве программного обеспечения, приведенном в предыдущей главе.
Дата добавления: 2015-12-07; просмотров: 51 | Нарушение авторских прав