- •Е.А. Калиберда е.П. Яхина анализ эффективности информационных систем
- •Предисловие
- •Введение
- •Экономические методы оценки эффективности ис
- •1.1. Финансовые методы оценки эффективности
- •Статические методы оценки Метод окупаемости
- •Метод «затраты - прибыль»
- •Динамические методы оценки Метод чистой текущей стоимости (npv)
- •Метод индекса рентабельности (pi)
- •Метод внутренней нормы доходности (irr)
- •1.2. Затратные методы оценки эффективности ис
- •Совокупная стоимость владения
- •Невидимые затраты
- •Неконтролируемые затраты
- •Первоначальные затраты
- •1.3. Комплексные методы оценки эффективности ис Система сбалансированных показателей (Balanced Scorecard)
- •1.4. Пример расчета затрат на информационную систему
- •2. Элементы теории вероятности
- •2.1. Формулы комбинаторики
- •2.2. Случайная величина
- •Свойства математического ожидания
- •Математическое ожидание числа появления события в независимых испытаниях
- •2.3. Биноминальное распределение
- •2.4. Распределение Пуассона
- •2.5. Экспоненциальное распределение
- •2.6. Простейший поток событий
- •3. Качество и эффективность информационных систем Методы оценки качества
- •3.1. Показатели качества программного изделия
- •Количественные показатели функциональных возможностей программного изделия
- •Количественные показатели эффективности программного изделия
- •Количественная оценка безопасности информационной системы
- •3. 2. Основные понятия теории надёжности
- •Определение надёжности программного изделия
- •Основные количественные показатели надёжности
- •3.3. Примеры оценки основных показателей качества
- •4. Тестировапние программных проодуктов Понятие тестирования
- •Роль тестирования в процессе разработки программ
- •4.1. Различные подходы к тестированию (черный ящик, белый ящик)
- •4.2. Смежные вопросы тестирования
- •Заключение
- •Библиографический список
- •ПриложенИя
- •Работы, выполняемые разработчиками постановки задачи
- •Работы, выполняемые разработчиками постановки задачи
- •Работы, выполняемые разработчиками постановки задачи
4. Тестировапние программных проодуктов Понятие тестирования
Тестирование является одним из этапов жизненного цикла ПИ, направленным на повышение качественных характеристик. При создании типичного ПИ около 40% общего времени и более 40% общей стоимости расходуется на проверку (тестирование) разрабатываемой программы.
Программы как объекты тестирования имеют ряд особенностей, которые отличают процесс их тестирования от общепринятого, применяемого при разработке аппаратуры и других технических изделий. Особенностями тестирования ПИ являются:
Отсутствие эталона (программы), которому должна соответствовать тестируемая программа;
Высокая сложность программ и принципиальная невозможность исчерпывающего тестирования
Практическая невозможность создания единой методики тестирования (формализация процесса тестирования) в силу большого разнообразия ПИ по их сложности, функциональному назначению, области использования и т.д.
Применительно к ПИ тестирование – это процесс многократного выполнения программы с целью обнаружения ошибок [17].
Роль тестирования в процессе разработки программ
До начала 80-х годов процесс тестирования ПО был разделен с процессом разработки: вначале программисты реализовывали заданную функциональность, а затем тестировщики приступали к проверке качества созданных программ. Однако такой подход создает множество проблем. Например, разработка программ может оказаться достаточно длительной (скажем, несколько месяцев) - чем в это время должны заниматься тестировщики?
Другая, более серьезная проблема заключается в плохой предсказуемости результатов такого процесса разработки. Ключевой вопрос таков: сколько времени потребуется на завершение продукта, в котором существует 500 известных ошибок? На самом деле, предугадать это совершенно невозможно, так как разные ошибки будут требовать разного времени на исправление, а исправление известных ошибок будет неизбежно связано с внесением новых. Steve McConnell приводит в своей книге [29] следующую мрачную статистику: даже однострочное изменение в программе с вероятностью 55% либо не исправляет старую ошибку, либо вносит новую. Если же учитывать изменения любого объема, то в среднем менее 20% изменений корректны с первого раза!
В связи с этим в 90-х годах появилась другая методика разработки, которую мы вслед за Microsoft'ом будем называть zero-defect mindset. Основная идея этой методики заключается в том, что качество программ проверяется не post factum, а постоянно в процессе разработки [27, 28]. Например, программист не может перейти к разработке новой функциональности, если существуют известные ошибки высокого приоритета в частях, разработанных им ранее.
При такой постановке вопроса тестирование становится центральной частью любого процесса разработки программ. С другой стороны, zero-defect mindset предъявляет существенно более высокие требования к квалификации инженера тестирования: теперь в сферу его ответственности попадает не только функциональное тестирование, но и организация процесса разработки (процесс ежедневной сборки, участие в инспекциях, сквозных просмотрах и обычное чтение исходных текстов тестируемых программ). Поэтому идеальной кандидатурой на позицию тестировщика становится наиболее опытный программист.