И. Соммервилл - Инженерия программного обеспечения (1133538), страница 123
Текст из файла (страница 123)
Например, при разработке больших сисгем производительность может быть очень низкой и доходить до 30 строк за человеко-месяц. На простых програминых системах производительность может подняться до 900 строк в месяц, В [44] высказано предположение, что производительность програм. миста может колебаться от 4 до 50 объектных точек в месяц, в эависилюсти от наличия средств поддержки и от способностей программиста. Недостатком оценок, которые основываются на подсчете объема выполненной работы илн определении количества затраченного времени, является то, что они не прннимают во внимание такие важные нефункциональные свойства разрабатываемой системы, как надежность, удобство эксплуатации и т.п.
Обычно здесь работает простое правило: больше — значит, лучше. Бек (Весх, [32]) приводит удачное замечание, что если вы работаете иад постоянным усовершенствованием и упрощением системы, то подсчет сгрок ничего не даст. 476 Часть УТ. Управление Таблица 23.3. Факторы, влияющие на производительность программиста Фактор Описание Опыт разработки ПО для данной предметной области Для эффективной разработки программного продукта нсобходи. мо знание той предметной области, где будет эксплуатироваться разрабатываемое ПО. Инженеры, имеющие понятие об этой предметной области, выявят наивысшую производительность Применяемый метод программированил может оказать сущсст.
венное влияние на производительность написания кода. Этот фактор рассматривается в главе 25 Чем больше проект, тем больше времени уходит на согласова- ние различных вопросов внутри группы разработчиков. Тем самым умсныпастся время, расходуемое непосредственно на разработку ПО, и снижается производительность Хорошая поддержка технологии разработки ПО, например САЗЕсредства или системы управления конфигурацией, может значительно повысить производительность труда программиста Как уже упоминалось в главе 22, спокойное рабочее окружение с индивидуальными рабочими местами способствует повыше- нию производительности Процесс управления ка- чеством Размер проекта Поддержка технологии разработки ПО Рабочая обстановка Описанные методы также не учитывают многократность использования программного продукта.
В действительности необходилю оценить стоимость повторного использования определенной системы с данным набором функциональных и качественных характеристик, имеющей собственныс показатели удобства сопровождения и т.д. Все зти параметры только косвенно соотносятся с такими количественными показателями, как, например, размер системы. Трулносгн также мо~ут возникнуп в случае, если менеджеры используют показатели производительности для оценивания способностей персонала.
В этои случае качество выполненной нрограчмисгом работы может отойти на второй ~иан по отношению к производительности. эгожст случиться, что "менее продуктивный" программист создаст код, который будет надежнее, понятнее и дешевле в использовании. Поэтому нельзя пользоваться по~яэателями произ. водителы юсги как единственным источником оцснивания труда про трам мистж 23.2. Методы оценивания Нс существует простого метода определения будущих затрат, необходимых для разработки программного продукта.
Начальное оценнвание можно провести, основываясь иа определенных пользовзтельсю1х требованиях высокого уровня. Но заранее нс известно, какие технологии будут применяться при разработке ПО и какие компьютеры будет использоваться. Также невозможно предугадать, какие люди будут работать пал проектом и какие у них бул>т навыки и опыт.
Это показывает, что чрезвгячайно трудно провести точную оценку стоимости проекта на самом раннем этапе. Более того, основнзя проблема в оценке себе. стоимости проектов азключается в низкой точности прииеняемых методов оценивания. Часто в расчет себестоимости проекта закладывается его окупаемость. Таким образом, первоначальная оценка себестоимости определлст бюджет проекта, за рамки которого нельзя выходить прн реализации проекта. Вместе с тем я нс знаю нн одного реализованного проекта, где Гня стоимость ие корректировалась по ходу его выполнения. Но всегда в ходе реализации проекта фактические расходы сравниваются с предварительной оценкой ъп рат.
23. Оценка стоимости программного продукта 477 Нсслютря ни на что, организации. разработчики обязательно должны оценивать затра. ты на разработку и себестоимость программного продукта. Для этого можно примснлть методы, описанные в табл. 2$.4 [4б). Таблица 2$.4. Методы оценки себестоимости Метод Описание Алгоритмическое модели- рование себестоимости Метод основан на анализе статистических данных о ранее выполненных проектах, при этом определяется зависимость себестоимости проекта от какого-нибудь количественного по- казателя программного продукта (обычно это размер про- граммного кода).
Проводится оценка этого показателя для дапнога проекта, после чего с помощью модели прогнозиру- ются будущис затраты Проводится опрос нескольких экспертов по технологии раз- работки ПО, знающих область применения создаваемого про- граммного продукта. Каждый из них дает свою оценку себе- стоимости проекта. Патон все оценки сравниваются и обсуж- даются. Этот процесс повторяется до тех пор, пока пс б>дст достигнуто согласие по окончательному варианту предвари- тельной сметгя проекта Этот метод используется в том случае, если в данной области применения создаваемого ПО уже реализованы аналогичные проекты.
В таком случае при оценке затрат для сравнения бе- рутся предыдущие проскгы. В кингс [251) дано достаточно ясное описание этого метода Оцснка эксперта Оценка по аналогии Согласно этому закону усилия, затраченные на работу, рас. прсдсляются равнолгсрно по выдслснному на проскг времени. Здесь критсрисм для оценки затрат по проекту лвляются чс- ловсчсскис ресурсы, а не целовал оценка самого программно- го продукта. Если проект, иад которым работает пять человек, должен быть закончен в тсчснис 12 месяцев, то затраты на его выполнение исчисляются в 60 человска.мстяцсв Закан Паркинсона Затраты на проект определяются наличием тех средств, ко- торые имсются у заказчика.
Поэтому ссбсстоилюсть проекта зависит от бюджета заказчика, а нс от функциональных ха- рактеристик создаваемого продукта Назначение цены с целью выиграть контракт В интересной статье [1б1) описан эксперимент, в котором менеджеров попросили провести прсдварителы ~ую оценку раз лгсра будущей программной системы и необходимых для сс раз. работки затрат. Мспслжсры при этом использовали мнения экспертов и оценку по аналоппь Результаты эксперимента показали, что менеджеры провели достаточно точную апси ау затрат, однако определение разл~сра будущси системы при этом было менее точным.
Это означает, что оценка затрат, основанная только па да ногах о размере програимы, будет неточной. Методы предварительной оценки себестоимости могут выполняться с примспспислг нисходящего нли восходлщсго подходов. При ппсходлщсм подходс оценка себестоимости начинается на >ровна системы: рассматриваются функциональные возможности праграл~мы в целом и то, как этн возможности реализуются посредством функций более низ. кого >ровня. Здесь учитывается ссбсстоимость таких этапов разработки, как сборка системы, управление конфигурацией и создание технической документации. 478 тХасть 71. управление В отличие от нисходящего подхода, восходящий начинается на уровне системных конно.
нентов. Система разбивается иа компоненты и опрсделяютгл затраты на разработку каждого из них. Затем зтн затраты суммируются для определения полной стоимости проекта. 11сдостатки восходящего полхода являются достоинствами нисходящего и наоборот. Восходящий подход может недооценить затраты, необходимые для решения сложных проблем, возникающих при разработке таких специфических компонентов системы, как интерфейсы для нестандартных аппаратных средств. Детального обоснования для востав.
> ленин сметы затрат в этом случае не существует. Нисходлнлий подход, напротив, дает такое обоснование, а также возможность рассмотреть каждый компонент в отлельпости. Вместе с тем данный подход больше акцентирует внимание на таких этапах реалиаацнн проекта, как, например, сборка системы. Кроме того, нисходящий подход является более дорогостоящим.
Для его применения нужно иметь хотя бы предварительный роз>льтат прослтирования системы с тем, чтобы оценить каждый ее компонент. Каждый метод оцениванил, безусловно, имеет слабые и гильпыс стороны. Для работы с болыпими проектами необходимо применить несколько методов оцспивання себестоимости для их последующего сравнения. Если при этом получаются совернилшо разные результаты, значит, ип4юрл>ации дня получения более точной оценки недостаточно. В этом случае необходимо воспользоваться дополнительной информацией, после чего повторить оцспиванпс, итак ло тех пор, пока результаты разных методов не стануг достаточно близкими. Описанные л>вгоды оцснивания применимы, если документированы требования длл булувгей системы. В таком случае существует возможность определить функциональные хэралтсристики разрабатываемой системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
