Статья Get Software Quality Right от 25 июня 2010 в Dr.Dobb’s Journal. Сама по себе интересная и толковая. Но мне особенно понравились следующие нехитрые выкладки для оценок программного проекта:
Пусть есть проект, содержащий N функциональных точек. Тогда:
- если возвести N в степень 1.25, то получится приблизительное количество дефектов в проекте;
- если возвести N в степень 1.2, то получится приблизительное количество тестовых сценариев (test cases), необходимых для тестирования;
- если возвести N в степень 0.4, то получится приблизительное количество месяцев, необходимых на реализацию проекта;
- если разделить N на 150, то получится приблизительное количество программистов, необходимое для реализации проекта.
Т.е. для проекта в 1000 функциональных точек получится:
- порядка 5600 дефектов;
- около 4000 тестовых сценариев;
- более 15 месяцев на разработку;
- команда из 6-7 человек.
Занимательно. Особенно с учетом того, что я понятия не имею о том, что такое функциональная точка, с чем ее едят, как соотносятся функциональные точки и строки программы (например, на C++) и т.д. Но все равно занимательно.
А по поводу информации о функциональных точках переадресую читателей в Wikipedia ;)
Function Point
Software development effort estimation
Software Sizing
Эти функциональные точки по моему довольно мутная вещь. Насчет строк кода тут http://itc.ua/node/21814 есть табличка по ней на тысячу точек будет 53000 строк кода на C++ кажется и число дефектов и необходимое количество ресурсов для разработки прилично завышенными. Хотя практически все системы оценок (тот же COCOMO например) этим страдают, так как обычно они рассчитаны на большие проекты, на малых удельная скорость разработки на одного программиста обычно на порядок больше.
ОтветитьУдалитьСпасибо за ссылку.
ОтветитьУдалитьКоличество строк на функциональную единицу, однако, очень настораживают. Lisp проигрывает C++, а Delphi почти в три раза выигрывает у C++ -- очень странно.
Угу таблица корявая. Тот же пролог намного меньше должен быть. Ну и сама методология хоть и преподносится как нечто объективное, слишком субъективна.
ОтветитьУдалитьНам еще в начале 90-х в универе пытались читать какие-то предметы по организации разработки ПО и оценки трудозатрат. Там тоже что-то говорилось об оценках сложности и пр. Уже тогда у меня сложилось впечатление, что данные дисциплины сродни предсказанию погоды.
ОтветитьУдалитьПричем и тогда, и сейчас я думаю, что программист не в состоянии точно оценивать будущий объем работ. А тот, кто более-менее точно оценивает этот объем -- тот не программист :)