Среднее Заочное отделение / 8 семестр / Эксплуатация программного обеспечения сетей телекоммуникаций / 5. Качество ПО
.docКачество ПО
Наибольшую популярность приобрели некоторое время назад численные оценки качества программ, предложенные Холстедом. Согласно предложенной им метрике, длина программы N=η1log2η1+η2log2η2, где η1 – число простых операторов, а η2 – число простых операндов в программе.
В практической же области в настоящее время используются иные модели оценки качества ПО, из которых мы упомянем две – одну, предложенную Институтом разработки программного обеспечения (SEI) университета Карнеги Меллона и называемую моделью мандатной зрелости (CMM), и другую, разработанную ISO (TCC176). Обе модели поддерживают процесс сертификации организаций-разработчиков программного обеспечения.
Модель мандатной зрелости CMM оперирует пятью уровнями зрелости процесса разработки ПО.
Первый уровень называют начальным (initial level). Он соответствует ситуации, когда процесс разработки ПО не организован, и разработка основана только на индивидуальных качествах, грамотности и опыте программистов.
Второй уровень называется уровнем повторяемости (repeatable level). На этом уровне зрелости существуют правила и процедуры разработки ПО, обеспечивается дисциплинированный подход к разработке, предусматривающий планирование и отслеживание проектов и позволяющий, когда это возможно, успешно повторять решения и подходы одного проекта в других проектах.
Третий уровень называется уровнем определенности (defined level). Это означает, что процесс проектирования ПО хорошо определен и документируется. Он включает в себя стандарты и процедуры выполнения работы, устойчивые и повторяемые элементы, общее понимание целевой функции ПО, сквозной контроль и критерии завершения.
Четвертый уровень называется уровнем управляемости (managed level) и предполагает, что качество процесса проектирования ПО, как и качество продукта, в определенной степени предсказуемо. Процесс этого уровня является устойчивым, измеряемым и корректируемым, что дает возможность влиять на качество продукта.
Последний, пятый уровень называется уровнем оптимизации (optimizing level). На этом уровне реализуется программа непрерывной модернизации, используются профилактические методики, которые сокращают время разработки и повышают качество ПО, применяются новые приемы и методики, направленные на постоянное улучшение процесса разработки и, следовательно, качества продукта.
Характеристика организации-разработчика ПО может уточняться в зависимости от достигнутого ею уровня проектирования, и командой сертифицированных специалистов ее программному продукту может быть присвоен соответствующий мандатный уровень зрелости.
Аналогична задача международного стандарта управления качеством ISO 9000-3, обеспечивающего гарантии качества разработки, поставки и сопровождения ПО. Он определяет систему оценки качества, включая его управляемость, а также функции жизненного цикла (разработку, тестирование и установку) и функции сопровождения (управление конфигурацией, документация, измерение и обучение). Соответствие организации-разработчика ПО этим требованиям проверяется организацией, которая имеет подтвержденные ISO право и полномочия выдавать сертификат согласия ISO, причем организация-разработчик должна сертифицироваться регулярно с определенной периодичностью. На рис. 9.8 показана технология проектирования телекоммуникационного ПО, соответствующая приведенным принципам обеспечения качества ПО.
Сопровождение программного обеспечения
На программное обеспечение приходится почти 80% стоимости разработки станции, но достаточно глубокие исследования методов его технического обслуживания не проводились. А ведь нужно, кроме прочего, иметь в виду, что сопровождение ПО цифровой АТС выполняет как ее производитель (действия, связанные с коррекцией или модернизацией текущей версии ПО, включая «заплаты» и корректировки для исправления ошибок в текущей версии), так и оператор станции (регламентное обслуживание, диагностика, корректировка таблиц станционных файлов, добавление линий и трактов в базу данных АТС).
Нормальная работа системы программного управления АТС может нарушаться по следующим причинам:
• ошибки программного обеспечения, включая «жучки» (bugs), вызывающие ошибки доступа к оперативной памяти, или программные сбои, которые могут быть исправлены только с помощью перезагрузки системы;
• аппаратные сбои, связанные с неисправностями аппаратных средств управляющих компьютеров;
• некорректное восстановление, когда из-за ошибки в программном обеспечении и/или в документации невозможно правильно детектировать неисправность и изолировать неисправный блок;
• процедурные ошибки, связанные, например, с вводом неправильных данных оператором или с неправильным действием во время процедур восстановления, расширения и корректировки.
Смена версий ПО большой цифровой АТС обычно происходит один-два раза в год; между этими сменами корректировки ПО производятся с помощью «заплат» (patches), которые представляют собой модификации программы без перекомпиляции всей версии.
Сложность любой версии станционного ПО настолько высока, что избежать ошибок при ее проектировании и реализации практически невозможно. Опыт прошедших десятилетий показал, что не существует универсальной методики производства абсолютно безошибочного ПО АТС при допустимых ценах и при разумных затратах времени на разработку. Вероятно, такой методики не появится и в ближайшее десятилетие, тем более, что сложность станционного ПО обусловлена, прежде всего, его объемом, который может выражаться более чем миллионом строк исходного текста программы. 25–30% этого объема занимают программы обработки телефонного трафика, порядка 20% – операционная система, а ПО эксплуатационного управления – порядка 50%.
В отличие от разработки аппаратных средств, где те или иные решения часто бывают обусловлены технологическими ограничениями, программное обеспечение проектируют специалисты, чей подход к работе в большей степени обусловлен доброй волей и свободой выбора, нежели необходимостью, которую диктуют возможности технологии. В то же время, затраты на программирование превышают затраты на аппаратные средства. И то, и другое вместе часто побуждает руководителей проектов сокращать объем проектирования ПО, откладывая на завтра реализацию в нем тех или иных функций, в частности, функций его обслуживания. Следствием такой ориентации руководства иногда оказывается значительное ухудшение качества ПО. А куда разумнее было бы не экономить хотя бы на разработке простых и ясных программных средств сопровождения ПО в течение всего жизненного цикла АТС.