metoda_2013

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

7.Повторное тестирование: после того, как ошибки были исправлены, команда тестеров прогоняет свои тесты еще раз.

8.Регрессионное тестирование: при тестировании нового функционала тестеры сначала прогоняют все старые тесты, чтобы убедиться, что система работает правильно.

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

Виды работ при тестировании

Планирование и управление

Спецификация/проектирование

Подготовка среды и инструментов тестирования

Выполнение тестов

Анализ и отчетность

Рецензирование

Распределение ролей при тестировании

Руководитель тестирования

-выбор стратегии тестирования

-планирование и управление процессом

Тест-аналитик

-проектирование тестовых сценариев

-подготовка среды тестирования

Тестер

-выполение тестов

-написание отчетов

170

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

36. Метрики проекта.

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

Метрики программного продукта включают:

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

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

Внешние метрики продукта - это метрики:

надежности продукта, которые служат для определения числа дефектов;

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

сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);применимости продукта, которые способствуют определению степени доступности для изучения и использования;

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

Внутренние метрики продукта включают:

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

метрики сложности, необходимые для определения сложности продукта;

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

Количественные метрики

Количество строк кода, количество пустых строк, количество комментариев, процент комментариев (отношение числа строк, содержащих комментарии к общему количеству строк, выраженное в процентах), среднее число строк для функций (классов, файлов), среднее число строк, содержащих

171

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

исходный код для функций (классов, файлов), среднее число строк для модулей.

Объектно-ориентированные метрики

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

Ксамым распространенными ОО метриками относятся:

количество вызываемых удаленных методов (Number Of

Remote Methods, NORM). При его вычислении просматриваются все конструкторы и методы класса и подсчитывается число вызываемых удаленных методов (не определенных в классе и его родителях);

отклик на класс (Response For Class, RFC) – количество методов, которые могут вызываться экземплярами класса, вычисляется как сумма локальных и удаленных методов;

взвешенная насыщенность класса 1 (Weighted Methods Per

Class 1, WMPC1) – отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим их количеством считается более сложным (при вычислении метрики родительские классы не учитываются);

взвешенная насыщенность класса 2 (WMPC2) – мера сложности класса, основанная на том, что класс с боóльшим количеством методов и метод с боóльшим количеством параметров являются более сложными (при вычислении метрики родительские классы не учитываются);

недостаток связности методов 1 (Lack Of Cohesion Of

Methods 1, LOCOM1) – отражает меру взаимозависимости методов (связность характеризует степень взаимодействия

172

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

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

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

Метрики Надежности

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

Метрики менеджмента

1)цена – расходы на приобретение/разработку

2)время разработки – мера времени формирования заказа на программу до поставки

3)среда разработки – процент целевых компьютерных ресурсов используемых системой

173

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Метрики требований

1)соответствие требованиям – дает возможность контролировать спецификации, изменение требований, а также степень их удовлетворения

2)стабильность требований

Метрики качества

1)адаптируемость - мера гибкости системы

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

3)тестовое покрытие - степень полноты различных типов тестирования

4)надежность - вероятность работы системы без отказов

5)профили ошибок - кумулятивное число обнаруженных ошибок

степень удовлетворения заказчика - степень соответствия программного обеспечения ожиданиям и требованиям заказчика

37. Отладка. Основные методы отладки.

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

узнавать текущие значения переменных;

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

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

174

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Вывод текущего состояния программы с помощью расположенных в критических точках программы операторов вывода — на экран, принтер,

громкоговоритель или в файл. Вывод отладочных сведений в файл называется журналированием.

Процесс отладки начинается при обнаружении ошибки и проводится в два этапа: 1) определяется природа и местонахождение ошибки в программе, 2) фиксируется и исправляется ошибка.

Методы "грубой силы"

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

Методы грубой силы можно разделить по крайней мере на три категории: 1) отладка с использованием дампа памяти; 2) отладка в соответствии с общим предложением «расставить операторы печати по всей программе»; 3) отладка с использованием автоматических средств.

Метод индукции

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

Процесс индукции разбивается на следующие шаги:

1. Определение данных, имеющих отношение к ошибке.

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

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

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

4.Доказательство гипотезы. Пропуск этого шага и переход непосредственно к заключениям и попыткам решить проблему

175

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Метод дедукции

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

1.Перечисление возможных причин или гипотез.

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

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

4.Доказательство выбранной гипотезы. Этот шаг совпадает с шагом 4 в методе индукции.

Прослеживание логики в обратном порядке

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

Метод тестирования

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

176

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Принципы отладки Принципы локализации ошибок.

-Думайте.

-Если вы зашли в тупик, отложите рассмотрение программы.

-Если вы зашли в тупик, изложите задачу кому-нибудь еще.

-Используйте средства отладки только как вспомогательные.

-Избегайте экспериментирования. Пользуйтесь им, как последним средством.

Принципы исправления ошибок.

-Там, где есть одна ошибка, вероятно, есть и другие.

-Находите ошибку, а не ее симптом

-Вероятность правильного нахождения ошибки не равна 100%.

-Вероятность правильного нахождения ошибки уменьшается с увеличением объема программы.

38. Архитектура программы. Цели выбора архитектуры. Декомпозиция.

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

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

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

Классификация программных систем по их архитектуре:

Централизованная архитектура;

Архитектура "файл-сервер";

Двухзвенная архитектура "клиент-сервер";

Многозвенная архитектура "клиент-сервер";

Архитектура распределенных систем;

Архитектура Веб-приложений;

Сервис-ориентированная архитектура.

177

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Централизованная архитектура

Реализовывалась на базе мейнфреймов; особенность такой архитектуры– полная "неинтеллектуальность" терминалов, их работой управляет хост-ЭВМ, пользователь не может настроить рабочую среду под свои потребности – все используемое программное обеспечение является коллективным

Архитектура "файл-сервер"

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

Функции сервера: хранения данных и кода программы. Функции клиента: обработка данных происходит

исключительно на стороне клиента.

Многозвенная архитектура "клиент-сервер"

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

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

Архитектура распределенных систем

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

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

Архитектура Веб-приложений

Особенности:

отсутствие необходимости использовать дополнительное ПО на стороне клиента – это позволяет

178

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

автоматически реализовать клиентскую часть на всех платформах;

возможность подключения практически неограниченного количества клиентов;

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

доступность при работоспособности сервера и каналов связи и недоступность при ее отсутствии

достаточно низкая скорость Веб сервера и каналов передачи данных;

Сервис-ориентированная архитектура

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

Основными целями применения SOA являются:

сокращение издержек при разработке приложений, за счет упорядочивания процесса разработки;

независимость от используемых платформ, инструментов, языков разработки;

повышение масштабируемости создаваемых систем;

улучшение управляемости создаваемых систем.

Цели выбора архитектуры:

Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущим потребностям пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java – JCP (Java Community Process), IEEE (Institute of Electrical and Electronics

Engineers) и другие.

179