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

Отладка и тестирование программ: основные подходы и ограничения

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Объект исследования – отладка и тестирование программ.

Предмет исследования – виды тестирования, тестирование надежности, организация процесса тестирования. Финишные этапы разработки программных систем.

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

В соответствии с целью была определена необходимость постановки и решения следующих задач:

– изучить виды тестирования;

– изучить тестирование надежности;

– изучить организацию процесса тестирования;

– изучить финишные этапы разработки программных систем;

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

1. Тестирование и отладка программ

1.1. Виды тестирования

Функциональное тестирование.

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

Тестирование «белого ящика» (white box) представляет собой использование операций тестирования на соответствие программной системы некоторым требованиям с учетом знаний внутренней структуры реализации программной системы (при наличии исходного кода и технической спецификации).

Тестирование «черного ящика» (black box) представляет собой тестирование на соответствие программной системы заявленным требованиям без знания внутренней структуры реализации программной системы [4].

Системное тестирование.

Системное тестирование представляет собой высокоуровневую проверку функционала всей программно системы или некоторой системы в целом.

Тестирование производительности.

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

Нагрузочное тестирование.

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

Стресс тестирование.

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

Регрессионное тестирование.

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

Модульное тестирование.

Каждая достаточно сложная программная система состоит из отдельных программных частей, отдельных модулей, которые выполняют определенные функции в составе программной системы. Для того, чтобы определить правильность и корректность работы всей программной системы, необходимо сперва выполнить тестирование каждого отдельного модуля программной системы по отдельности. Если возникнуть какие-либо проблемы в процессе тестирования программной системы в целом это поможет намного проще выявить программные модули, которые вызвали проблемы, и устранить проблемы обработки информации. Такого рода тестирование программных модулей по отдельности называется модульным тестированием [3].

Тестирование безопасности.

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

Тестирование локализации.

Тестирование локализации - это процесс тестирования локализованной версии программного продукта. Проверка правильности перевода элементов интерфейса пользователя, проверка правильности перевода системных сообщений и ошибок, проверка перевода раздела "Помощь"/"Справка" и сопроводительной документации [9].

Юзабилити тестирование.

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

1.2. Тестирование надежности

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

На интуитивном уровне понятие надежности программной системы может отражать тот факт, что программная система не всегда может выдавать правильные результаты. Это означает, что надежность программной системы является некоторой характеристикой ее исполняемых инструкций и содержащегося в ней кода. Исполняемый код программной системы можно соотнести с исходным текстом программы так же, как, например, электродвигатель можно соотнести с его чертежами: можно говорить о некоторой надежности конечного изделия, но бессмысленно говорить о надежности его описания, некоторого чертежа, определенного текста 2]. Даже взяв две идентичные программы с одинаковыми функциональными особенностями, но написанные при помощи разных языков программирования, или запасные части, которые разработанные для различных типов машин, или для одинаковой машины, но с использованием различных компиляторов, с точки зрения надежности необходимо считать разными.

Надежность и правильность программной системы.

Программная система может быть правильной, если она не будет содержать ошибок выполнения. Такая программная система не будет давать ложных результатов, т.е. она будет абсолютно надежной и в полной мере выполнять свои функции. Данный факт порождает ложные представления о том, что число ошибок в программной системе может быть наиболее естественной мерой ее конечной надежности. Сегодня встречается множество работ, в которых предлагаются различные методы для оценки количества оставшихся в программном коде ошибок в результате операций ее тестирования, в том числе метод «засорения» наиболее известными ошибками [6]. Однако, как будет видно из приведенных ниже соображений, количество возможных ошибок в ее программном коде не имеет никакого отношения к конечной надежности программной системы стабильной, безотказной работы:

1. Число ошибок в программной системе представляет собой определенную величину «ненаблюдаемую», наблюдаются не сами возникающие ошибки, а результат их проявления в конечной программной системе.

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

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

4. Надежность характеризуется частотой проявления возможных ошибок, но не их количества; в то же время хорошо является известным, что ошибки могут проявляться с разной частотой: множество ошибок будут неопределенными после нескольких месяцев и даже лет конечной эксплуатации программной системы, но, с другой стороны, нетрудно найти примеры, когда одна ошибка может привести к неверному выполнению программной системы при любых исходных данных, т.е. к некоторой нулевой надежности [15].

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

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

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

В качестве примера рассмотрим метод восходящего тестирования.

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

Разработка драйверов и заглушек при восходящем интеграционном тестировании представлена в Приложении.

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

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

1.3. Организация процесса тестирования

Тестирование программной системы одновременно проводится по нескольким направлениям:

1. Проверка кода (review): в процессе которой тестер просматривает визуально исходный код программной системы и ищет в нём имеющиеся ошибки, а так же выполняет поиск различных несоответствий программного кода и требований, предъявляемых к нему. Под требованиями к программному коду понимается определенный стандарт, которого должны придерживаться разработчики программной системы, реакция на те или иные действия со стороны среды воздействия на программную систему, поведение программной системы в различных ситуациях [16].

2. Тестирование высокого уровня: в процессе которого главной целью тестирования является определение удовлетворяет ли программная системы всем заявленным требованиям определенного заказчика. Для программной системы разрабатываются специальные эмуляторы, при помощи которых тестер наблюдает за работой программной системы в роли определенного оператора. Он может увидеть, как программная система выполняет свой диалог с пользователями, какие сообщения программная система выдаёт, как она реагирует на различные события, каким образом сохраняет полученную информацию и т.д. Большинство найденных ошибок на данном этапе связанно с ошибками по взаимодействию программной системы с пользователями - вывод ошибочных сообщений, не правильная реакция на запрос от оператора и т.п. [20].

3. Тестирование низкого уровня: тестировщик выполняет проверку, на сколько логически полным является исходный код, и насколько он покрывает всё возможные варианты непосредственной работы программной системы, для которой он был разработан.

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

Стандарт ISO 9001.

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

Стандарт ISO/IEC 12207 и IEEE/EIA 12207.

ISO/IEC 12207 - это международный стандарт, описывающий структуру процессов жизненного цикла ПО от концепции до изъятия из обращения. Стандарт IEEE/EIA 12207 - адаптация ISO/IEC 12207 для США.

В соответствии с этими стандартами в той или иной отрасли производства выдвигаются требования к тестированию ПО. Например в авиации США на основе ISO/IEC 12207 был выработан стандарт RTCA( Requirements and Technical Concepts for Aviation). В нём перечислены следующие требования к тестированию верхнего и нижнего уровня. Тестирование верхнего уровня:

– предъявляемые требования высокого уровня должны содержать системные требования к определенной программной системе;

– предъявляемые требования высокого уровня должны формулироваться с учётом архитектуры определенной программной системы;

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

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

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

Тестирование нижнего уровня предполагает:

– выполнение проверки (Verification) требований нижнего уровня к программной системе;

– выполнение полной проверки архитектуры некоторой программной системы;

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

– выполнение контроля исполняемых процедур тестирования программной системы;

– проверка независимости программной системы от тестирования. Т.е. программная система не должно перестраиваться особым образом под выполняемые тесты;

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

– тестирование на предмет косвенного обнаружения ошибок [14]. Например: соответствие стандартам разработки определенной программной системы.

2. Финишные этапы разработки программных систем

Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» можно выделить такие стадии создания и этапы непосредственной разработки программной системы:

– формирование комплекса требований к программной системе;

– разработка концепции программной системы;

– техническое задание;

– эскизный проект программной системы;

– технический проект программной системы;

– рабочая документация программной системы;

– ввод в действие программной системы;

– сопровождение программной системы [5].

Рассмотрим более подробно финишные этапы разработки программных систем.

2.1. Рабочая документация

Разработка рабочей документации на программную систему и на её программные части регламентируется следующими документами:

– ведомость эксплуатационных документов программной системы;

– ведомость машинных носителей оперативной информации;

– паспорт программной системы;

– общее описание программной системы;

– технологическая инструкция на программную систему;

– руководство пользователя программной системы;

– описание технологического процесса обработки оперативных данных;

– инструкция по непосредственному формированию и ведению базы данных программной системы (набора данных программной системы);

– состав выходных данных (выдаваемых программной системой сообщений);

– каталог базы данных программной системы;

– программа и методика практических испытаний;

– спецификация на программную систему;

– описание программной системы;

– текст программной системы.

Разработка или адаптация программной системы:

– развернуты экземпляры программной системы. Созданы необходимые объекты базы данных;

– разработаны процессы ETL и процессы обеспечения качества данных. Выставлено расписание запуска процессов;

– реализованы дополнительные приложения;

– реализованы витрины данных и отчетность;

– настроены профили пользователей и прав доступа.

Согласованная и утвержденная рабочая документация.

2.2. Ввод в действие

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

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

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

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

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

Рисунок 1 – Схема используемого оборудования

В этом случае предлагается стандартная схема резервирования каналов связи:

– резервирование через терминалы различных операторов мобильной связи;

– резервирование основного GPRS-соединения резервным - через GSM;

– резервирование по коммутируемой телефонной линии (для неподвижных объектов).

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

Рисунок 2 – Технология выполнения пусконаладочных работ

Рисунок 3 – Технология выполнения пусконаладочных работ

На стадии проведения предварительных испытаний будет выполнен тест системы на ее полное соответствие заданию и работоспособность в соответствии с техническим заданием. Будут выполнены мероприятия по устранению неисправностей и внесению необходимых изменений в документацию с учетом проведенных испытаний. Результатом данной стадии будет заполнен акт приемки системы в опытную эксплуатацию. Например, настройка системы документооборота 1С: Предприятие может быть настроено при помощи специальной панели, рис. 4.

Рисунок 4 – Настройка системы

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

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

Рисунок 5 – Интерфейс конфигуратора системы

В процессе завершения работ будет подписан акт завершения работ на ввод в действие программной системы.

2.3. Сопровождение

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

Рисунок 6 – Схема взаимодействия с клиентом

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

Для обеспечения данной стадии может быть использован программный продукт «AS Система Опроса Абонентов v4» представляющая собой программную систему, предназначенную для выполнения опросов абонентов (клиентов) / наличие системы обратной связи и предназначена в основном для:

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

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

– формирования необходимых статистических отчётов о деятельности компании,

– выполнение контроля проведенных опросов и оперативного сравнительного анализа полученных отзывов [19].

Программная система «AS Система Опроса Абонентов v4»:

– включает полностью автоматизированные процедуры опросов клиентов посредством технологий SMS/IVR/WEB-опросов (с возможностью выбора на основе предпочтений клиента) и возможности формирования различных отчётов о пользовательских оценках работы операторов компании;

– система «AS Система Опроса Абонентов v4» является дальнейшим развитием программной системы «Система опроса абонентов» которая активно используется с начала 2003 года, данная система построена на новейших технологиях, включает в себе все самые актуальные алгоритмы, которые были разработаны на практике по запросам и в тесном сотрудничестве с специалистами в различных областях деятельности и непосредственно с пользователями системы;

– система «AS Система Опроса Абонентов v4» имеет модульную архитектуру, которая состоит из: ядра опросов, специальных интерфейсов, представляющих собой источники данных и специальных интерфейсов, предназначенных для взаимодействия с клиентами компании, - такая архитектура предоставляет возможности быстро добавлять необходимые интерфейсы и различные источники данных, интерфейсы для взаимодействия с клиентами компании, быстро наращивать свой функционал, добавляя новые модули и ничего не меняя в самой системе, а также существует множество возможности по оптимизации трафика данных по сети, размещая различные модули наиболее оптимальным образом для компании и пользователя;

– система «AS Система Опроса Абонентов v4» поддерживает кластеризацию/масштабирование, GEO-резервирование.

3. Оценка качества программных средств

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

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

3.1. Вычисление метрики SLOC

Программная система Locmetrics является достаточно простым бесплатным продуктом с минималистским пользовательским интерфейсом. К числу поддерживаемых языков программирования относятся – C/C++, C#, Java, php, python, SQL. При помощи данной программной системы становится возможным вычисление не только метрик SLOC и ее возможных разновидностей, но и цикломатической сложности исследуемой прикладной программной системы [7].

Пользовательский интерфейс программной системы Locmetrics представлен на рис. 7.

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

Рисунок 7 – Пользовательский интерфейс программной системы Locmetrics

Следующая система USC Codecount является бесплатным программным продуктом с открытым исходным кодом на языке ANSI C, который был разработан Университетом Южной Калифорнии. Программная система USC Codecount является официальным инструментом для выполнения операций подсчета метрик SLOC при использовании различных моделей. В число поддерживаемых программной системой USC Codecount языков программирования входят C/C++, C#, Java, JavaScript, SQL, Perl, XML, в документации указывается, что методика, на которой выполняются расчеты соответствует принятой SEI для специализированных моделей CMM/CMMI. Интерфейс системы USC Codecount представлен на рис. 8.

Рисунок 8 – Пользовательский интерфейс системы USC Codecount

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

Рисунок 9 – Работа с программной системой USC Codecount

Программная система USC Codecount предоставляет возможности по вычислению количества логических и физических SLOC, наличия пустых строк, наличия комментариев, используемых директив компилятора, наличие описаний используемых данных, наличие исполняемых инструкций по файлам реализуемого проекта по отдельности и в целом. Также, программная система USC Codecount предоставляет возможности по анализу статистики по числу вхождений ключевых слов категорий и соотношений между используемыми значениями внутри программы.

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

3.2. Вычисление метрик сложности

Программная система Verisoft Complexity Measures Tool является коммерческим продуктом с достаточно большой ценой в 1250 евро. Программная система Verisoft Complexity Measures Tool поддерживает только языки C/C++ и Java.

При помощи Verisoft Complexity Measures Tool могут быть выполнены расчеты следующих метрик:

– SLOC (это метрика программного обеспечения, используемая для измерения его объёма с помощью подсчёта количества строк в тексте исходного кода. Как правило, этот показатель используется для прогноза трудозатрат на разработку конкретной программы на конкретном языке программирования, либо для оценки производительности труда уже после того, как программа написана);

– цикломатическую сложность программного проекта;

– метрики Холстеда;

– индекс оперативной сопровождаемости программной системы (вычисляется на базе предыдущих значений реализуемого проекта) [14].

Программная система Verisoft Complexity Measures Tool содержит удобный пользовательский графический интерфейс (с возможностями работы в режиме командной строки), позволяет сформировать необходимые отчеты в текстовой форме или в форматеHTML.

Программная система Borland Together является коммерческим инструментом, используемый для непосредственного UML-моделирования, который был дополнен специализированными возможностями вычисления метрик программного кода анализируемой программной системы, рис. 10.

Рисунок 10 – Пользовательский интерфейс системы Borland Together

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

Программная система Eclipse Metrics Plugin представляет собой специальный подключаемый модуль для IDE Eclipse, который был разработан в рамках открытого проекта, рис. 11.

Рисунок 11 – Пользовательский интерфейс системы Eclipse Metrics Plugin

Программная система Eclipse Metrics Plugin позволяет выполнить вычисления SLOC, выполнить количественные метрики реализуемых классов, выполнить анализ цикломатической сложности реализуемого проекта, выполнить анализ метрик сложности классов (анализ индекса специализации), выполнить анализ метрик связности, определить уровень абстракции и некоторые другие.

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

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

3.3. Оценка экономических параметров

В программной системе Duvessa Estimate Easy UC реализовано множество инструментов для выполнения оценки большого количества экономических параметров определенного проекта составляют основную часть класса Software Estimation, которые используются для выполнения оценки по трудоемкости выполняемых работ, сроков по реализации и стоимости будущей программной системы и часто являются максимально сложными, чем средства по расчету метрик проекта.

Программная система Duvessa Estimate Easy UC является довольно простым коммерческим продуктом с низкой ценой. Программная система Duvessa Estimate Easy UC предназначена для выполнения непосредственной оценки общей трудоемкости реализации определенного прикладного программного проекта на базе использования прецедентов.

Работа с системой Duvessa Estimate Easy UC заключается в регистрации составляющией UML-модели: возможных прецедентов и акторов (участников информационного процесса), для которых необходимо указать специальные параметры сложности и число необходимых форм и отчетов (для прецедентов) [17].

Программная система Duvessa Estimate Easy UC поддерживает возможности импорта необходимой информации из следующих форматов Rational Rose, Rational XDE, Visio и XML.

Rational Rose - популярное средство визуального моделирования объектно-ориентированных информационных систем. Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования.

Rational XDE позволяют создавать информационные системы на платформе .NET и Java-приложения (в том числе на базе различных технологий J2EE). XDE устанавливается либо в виде отдельного приложения (тогда дополнительно нужно установить Eclipse IDE), либо интегрируется в установленный заранее IBM WSAD или Microsoft Visual Studio .NET.

Помимо выполнения специальных вычислений объема определенного проекта в скорректированных точках прецедентов (согласно нотации UCP) и трудоемкости работ в человеко-часах, программная система Duvessa Estimate Easy UC выполняет автоматическое преобразование количества UCP в число объектных точек (OP) и затем выполняет еще дополнительную оценку трудоемкости работ, необходимых для конечной реализации определенного проекта в соответствии с методикой COCOMO II. Интерфейс системы представлен на рис. 12.

Рисунок 12 – Пользовательский интерфейс Duvessa Estimate Easy UC

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

ЗАКЛЮЧЕНИЕ

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

Были описаны следующие виды тестирования программных систем, к которым относятся:

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

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

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

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

Определены этапы разработки программных систем, согласно ГОСТ 34.601-90, к ним относятся: формирование требований к системе; разработка концепции системы; техническое задание; эскизный проект; технический проект; рабочая документация; ввод в действие; сопровождение системы.

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

Программная система Locmetrics является очень простым бесплатным продуктом с минималистским пользовательским интерфейсом. К числу поддерживаемых языков программирования относятся – C/C++, C#, Java, php, python, SQL.

Программная система USC Codecount представляет собой бесплатный программный продукт с открытым исходным кодом на языке ANSI C, который был разработан Университетом Южной Калифорнии.

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

Программная система Eclipse Metrics Plugin представляет собой специальный подключаемый модуль для IDE Eclipse, который был разработан в рамках открытого проекта.

В программной системе Duvessa Estimate Easy UC реализовано множество инструментов для выполнения оценки экономических параметров определенного проекта составляют центральную часть класса Software Estimation, которые используются для выполнения оценки по трудоемкости выполняемых работ, сроков по реализации и стоимости будущей программной системы и часто являются максимально сложными, чем средства по расчету метрик проекта.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Архитектура и проектирование программных систем : монография / С.В. Назаров. – 2-е изд., перераб. и доп. – М. : ИНФРА-М, 2018. – 374 с.
Афонин В.В. Моделирование систем: учебно-практическое пособие / В.В. Афонин, С.А. Федосин. - М.: Интуит, 2016. – 231 c.
Бизнес-процессы: регламентация и управление : учебник / В.Г. Елиферов, В.В. Репин. – М. : ИНФРА-М, 2018. – 319 с.
Будылдина Н.В. Сетевые технологии высокоскоростной передачи данных: Учебное пособие для вузов / Н.В. Будылдина, В.П. Шувалов. - М.: РиС, 2016. – 342 c.
Валитов Ш.М. Современные системные технологии в отраслях экономики: Учебное пособие / Ш.М. Валитов, Ю.И. Азимов, В.А. Павлова. - М.: Проспект, 2016. – 504 c.
Венделева М.А. Информационные технологии в управлении.: Учебное пособие для бакалавров / М.А. Венделева, Ю.В. Вертакова. - Люберцы: Юрайт, 2016. – 462 c.
Гаврилов М.В. Информатика и информационные технологии: Учебник / М.В. Гаврилов, В.А. Климов. - Люберцы: Юрайт, 2016. – 383 c.
Гома Х. UML. Проектирование систем реального времени, распределенных и параллельных приложений / Х. Гома. - М.: ДМК, 2016. – 700 c.
Дарков А.В. Информационные технологии: теоретические основы: Учебное пособие / А.В. Дарков, Н.Н. Шапошников. - СПб.: Лань, 2016. – 448 c.
Довек Ж. Введение в теорию языков программирования / Ж. Довек, Ж.-Ж. Леви. - М.: ДМК, 2016. – 134 c.
Долганова О.И. Моделирование бизнес-процессов: Учебник и практикум для академического бакалавриата / О.И. Долганова, Е.В. Виноградова, А.М. Лобанова. - Люберцы: Юрайт, 2016. – 289 c.
Ерохин В.В. Безопасность информационных систем: учеб пособие / В.В. Ерохин, Д.А. Погонышева, И.Г. Степченко. - М.: Флинта, 2016. – 184 c.
Замятина О.М. Вычислительные системы, сети и телекоммуникации. моделирование сетей.: Учебное пособие для магистратуры / О.М. Замятина. - Люберцы: Юрайт, 2016. – 159 c.
Згадзай О.Э. Информационные технологии в юридической деятельности: Учебное пособие / О.Э. Згадзай и др. - М.: ЮНИТИ, 2016. – 335 c.
Информатика для экономистов: учебник для академического бакалавриата/Под ред. В.П. Полякова.- М.: Юрайт, 2015. – 524 с.
Информатика и информационно-коммуникационные технологии (ИКТ) : учеб. пособие / Н.Г. Плотникова. – М. : РИОР : ИНФРА-М, 2018. – 124 с.
Информационные технологии в профессиональной деятельности : учеб. пособие / Е.Л. Федотова. – М. : ИД «ФОРУМ» : ИНФРА-М, 2018. – 367 с.
Информационные технологии и управление предприятием: Пособие / Баронов В.В., Калянов Г.Н., Попов Ю.И., - 2-е изд., (эл.) – М.:ДМК Пресс, 2018. – 329 с.
Лукин В.Н. Введение в проектирование баз данных / В.Н. Лукин. - М.: Вузовская книга, 2015. – 144 c.
Моделирование экономических процессов: Учебник. / Под ред. М.В. Грачевой, Ю.Н. Черемных . - М.: ЮНИТИ, 2015. – 543 c.

ПРИЛОЖЕНИЕ

Разработка программных средств