- •Е.А. Калиберда е.П. Яхина анализ эффективности информационных систем
- •Предисловие
- •Введение
- •Экономические методы оценки эффективности ис
- •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.2. Смежные вопросы тестирования
Экономическая сторона тестирования. Тестирование само по себе является затратной деятельностью, отнимающей у нас время и деньги. Поэтому в большинстве случаев разработчики программного обеспечения (ПО) заранее формулируют какой-либо критерий качества создаваемых программ (определяют так называемую планку качества), добиваются выполнения этого критерия и после этого прекращают тестирование и выпускают продукт на рынок. Такая концепция получила название Good Enough Quality (достаточно хорошое ПО), в противовес более очевидной концепции Best Possible Quality (максимально качественное ПО).
К сожалению, принцип Good Enough Quality зачастую понимают неправильно, ближе к формулировке Quality - If Time Permits (качество - если будет время). Конечно, выпуск плохо протестированного продукта из-за недостатка времени - это плохая практика. Практика показывает, что пользователи склонны со временем забывать даже значительные задержки с выпуском продукта, но плохое качество выпущенного продукта запоминается на всю жизнь.
На самом деле, Good Enough Quality - это просто поиск разумного компромисса между затратами на тестирование, длительностью разработки продукта и его качеством.
Психологические аспекты тестирования. Тестирование принципиально отличается от программирования по своим психологическим характеристикам [26]. Дело в том, что программирование носит конструктивистский характер, а тестирование ПО - деструктивно по своей природе. Можно сказать, что программист строит что-то, создает из ничего нечто, а тестировщик отыскивает недостатки этих построений. Поэтому программисты так часто не замечают очевидных ошибок в своих программах: к своему творчеству трудно относиться критично - как к своим детям.
Все это не значит, что тестирование "хуже", чем программирование, или что в процессе тестирования нет места творчеству - просто эти виды деятельности отличаются коренным образом, и для тестирования требуется иной склад характера, чем для программирования. Следовательно, программист не должен тестировать свои собственные программы; для этого необходим другой человек. Более того, программист не должен тестировать даже чужие программы! Дело в том, что программист потратит какое-то время просто на "раскачку", перенастраиваясь на новую задачу. Даже переключение с одной программистской задачи на другую требует обычно от 10 минут до получаса. Понятно, что переключение с одного образа мышления на другой отнимет существенно больше времени - возможно даже день или два.
Именно поэтому с точки зрения разработчика e-mail значительно выгоднее телефона (есть возможность ответить на вопросы после достижения некоторой логической точки в работе). Более того, программистам рекомендуют проверять почту не постоянно, а два-три раза в день - чтобы увеличить среднее время работы без отвлечений.
Из всего вышесказанного следует очевидный вывод о том , что команда разработчиков не должна совпадать с командой инженеров тестирования, но при этом разработчики и тестировщики должны постоянно взаимодействовать друг с другом для достижения приемлемого качества окончательного продукта.