Методы параметрических оценок

Методы параметрических оценок похожи на метод оценки «по аналогу» и также являются разновидностью метода «сверху вниз». Присущая им точность не лучше и не хуже точности метода оценок «по аналогу».

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

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

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

Тестирование

 

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

 

Восходящее тестирование. При восходящем подходе программа собирается и тестируется снизу вверх. Только модули самого нижнего уровня ("терминальные" модули; модули, не вызывающие других модулей) тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопряжений программы.

 

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

 

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

Практическая часть