Трудоемкость обработки информации

ОЦЕНКА ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ПРОДУКТА

 

Методические указания

 

Красноярск

СФУ

УДК 65.011.46

Б35

 

Рецензент

А. В. Ивашина, канд. техн. наук, доц. кафедры «Прикладная информатика и экономика» ХТИ – филиала СФУ

 

 

Б35 Оценка экономической эффективности разработки программного продукта: метод. указания к выполнению экономического раздела дипломного проекта / сост. Т. Н. Бебрыш. – Абакан: Сиб. федер. ун-т; ХТИ – филиал СФУ, 2009. – 34 c.

 

 

Содержат теоретический и практический материал по работе над экономическим разделом дипломного проекта, а также примерную структуру данного раздела.

Предназначены для студентов направления и специальности «Прикладная информатика (в экономике)» очной и заочной форм обучения.

 

 

Рекомендовано к изданию

Редакционно-издательским советом ХТИ – филиала СФУ

 

 

УДК 65.011.46

 

Ó ХТИ – филиал СФУ, 2009

 

Печатается в авторской редакции

Корректор Н. А. Решетникова

 

Подп. в печать 29,09.09. Формат 60×84/16. Бумага тип. № 1.

Усл. печ. л. 2,0. Уч.-изд. л. 1,6. Тираж 100 экз. Заказ С 66

 

Сибирский федеральный университет; Хакасский технический институт –

филиал ФГОУ ВПО «Сибирский федеральный университет»

655017, Абакан, ул. Щетинкина, 27

 

Отпечатано в полиграфической лаборатории ХТИ – филиала СФУ

655017, Абакан, ул. Щетинкина, 27

 

ВВЕДЕНИЕ

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

При выполнении проекта по информатизации для любого предприятия принципиально важен вопрос об экономической эффективности выполняемых работ. Проще говоря, стоит ли вкладывать финансовые, материальные и прочие виды ресурсов в проект. Причем абсолютно не имеет значения, каким образом проект будут реализован: либо это информационная система собственной разработки (как вариант, информационная система, разработанная под данного заказчика сторонним производителем), либо это «стандартная» система, приведенная в качестве варианта решения проблем конкретного предприятия.

Проблема расчета экономической эффективности упирается в несколько ключевых точек:

· Заказчик, как правило, сам достаточно хорошо понимает, что существующая информационная система (или несуществующая) не устраивает его по некоторым параметрам, более того, эти параметры он достаточно четко готов сформулировать для себя, но как только дело доходит до разговора с подрядчиком, данная четкость пропадает.

· Заказчик стремится решить максимальное количество проблем в минимальное время, не придавая значения четкой постановке вопроса о том, что, сколько стоит и в какие сроки может быть выполнено, более того, в какие сроки произойдет возврат вложенных в данный проект средств.

· Разработчик «не видит» по своей вине или по вине заказчика те ключевые точки, которые принципиально важны для реализации проекта и которые оказывают ощутимое влияние на параметры экономических показателей системы.

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

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ

При работе над данным разделом дипломного проекта студентам рекомендуется придерживаться следующей структуры:

1. Провести анализ разработок, аналогичных выбранной теме дипломного проекта, выполненных на предприятии (если разработки осуществлялись).

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

3. Составить график по этапам работы, с указанием количества дней по каждому этапу и действующих лиц, участвующих в разработке (рекомендуется использовать Microsoft Project).

4. Рассчитать предварительную стоимость проекта.

5. После создания проекта составить отчетный график по этапам работы и сделать вывод о соотношении плановой и фактической трудоемкости.

6. Рассчитать эксплуатационные затраты и показатели экономической эффективности. Сделать вывод и внести предложения о применении разработанного проекта.

7. На плакате по экономическому разделу следует отразить показатели трудоемкости, сравнительный анализ расчетной трудоемкости и фактических затрат времени, показатели экономической эффективности.

ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ

РАЗРАБАТЫВАЕМОЙ СИСТЕМЫ

 

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

Абсолютные показатели:

- показатели величины трудоемкости обработки по базовому и предлагаемому варианту, оцениваемые по году эксплуатации информационной системы – и , причем предполагается, что при рассмотрении базового и предлагаемого вариантов будет предложено несколько версий новой системы;

- показатели эксплуатационных стоимостных затрат за год по базовому () и предлагаемому варианту (), показатель снижения стоимостных затрат за год:

 

 

- показатель снижения трудовых затрат за год ():

 

 

Относительные показатели:

- коэффициент снижения трудовых затрат показывает, на какую долю или на какой процент снижаются трудовые затраты предлагаемого варианта по сравнению с базовым:

 

 

- коэффициент снижения стоимостных затрат за год:

 

 

- индексы соответственно трудовых и стоимостных затрат рассматриваются в случае, если предложено несколько вариантов информационной системы к одному базовому:

 

 

ТРУДОЕМКОСТЬ ОБРАБОТКИ ИНФОРМАЦИИ

 

Рассмотрим первый из приведенных показателей – величину трудоемкости обработки информации. В реальной проектной ситуации достаточно трудно выделить и подсчитать величину трудоемкости как для реально действующей, так и для проектируемой системы.

Оценка трудоемкости является одним из наибо­лее важных видов деятельности в процессе создания программного проекта.

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

- разработка бюджета проекта (здесь, прежде всего, требуется точность общей оценки);

- анализ степени риска и выбор компромиссного решения (решение данной задачи позволяет уточнить такие характе­ристики проекта, как масштабы, возможность повторного использования, количество разработчиков, используемое оборудование и т. д.);

- планирование и управление проектом (полученные резуль­таты обеспечивают распределение и классификацию расхо­дов по компонентам, этапам и операциям);

- анализ затрат на улучшение качества программного проекта (это позволяет оценить затраты и прибыль от стратегии инвестирования в совершенствование аппаратных средств, технологий и воз­можности повторного использования).

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

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

Существуют различные методы оценки программных проектов.

1. Алгоритмическое моделирование. Метод основан на анализе статистических данных о ранее выполненных проектах, при этом определяется зависимость трудоемкости проекта от какого-ни­будь количественного показателя программного продукта (ПП) (обыч­но это размер программного кода). Проводится оценка этого по­казателя для данного проекта, после чего с помощью модели прогнозируются будущие затраты.

2. Экспертные оценки. Проводится опрос нескольких экспер­тов по технологии разработки ПП, знающих область его применения. Каждый из них дает свою оценку трудоемкости проекта, после чего все оценки сравниваются и обсуждаются. Этот процесс повторяется до тех пор, пока не будет достигнуто согласие по окончательному варианту предваритель­ной трудоемкости.

3. Оценка по аналогии. Этот метод используется в том случае, если в данной области применения создаваемого программного проекта уже реали­зованы аналогичные проекты. Метод основан на сравнении пла­нируемого проекта с предыдущими проектами, имеющими по­добные характеристики. Он использует экспертные данные или сохраненные данные о проекте. Эксперты вычисляют высокую, низкую и наиболее вероятную оценку трудоемкости, основыва­ясь на различиях между новым проектом и предыдущими проектами. Оценка может быть достаточно детальной в зависимости от глубины аналогий. Слабость модели заключается в том, что степень подобия нового проекта и предыдущих проектов, как правило, не слишком велика.

Самый лучший вариант - это использование накопленных в организации исторических данных, позволяющих сопоставить трудоемкость вашего проекта с трудоемкостью предыдущих про­ектов аналогичного размера. Однако это возможно только при следующих условиях:

- в организации аккуратно документируются реальные ре­зультаты предыдущих проектов;

- по крайней мере один из предыдущих проектов (а лучше несколько) имеет аналогичный характер и размер;

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

4. Закон Паркинсона. Согласно этому закону усилия, затра­ченные на работу, распределяются равномерно по выделенному на проект времени. Здесь критерием для оценки затрат по проек­ту являются человеческие ресурсы, а не целевая оценка самого программного проекта. Если проект, над которым работают пять человек, должен быть закончен в течение 12 месяцев, то зат­раты на его выполнение исчисляются в 60 чел.-мес.

5. Оценка с целью выиграть контракт. Затраты на проект опре­деляются наличием тех средств, которые имеются у заказчика, поэтому трудоемкость проекта зависит от бюджета заказчика, а не от функциональных характеристик создаваемого проекта. Требования приходится изменить так, чтобы не выходить за рам­ки принятого бюджета.

Каждый метод оценки имеет слабые и сильные стороны. Для работы над большими проектами необходимо применить нес­колько методов оценки для их последующего сравнения. Если при этом получаются совершенно разные результаты, значит ин­формации для получения более точной оценки недостаточно. В этом случае необходимо воспользоваться дополнительной ин­формацией, после чего повторить оценку, и так до тех пор, пока результаты разных методов не станут достаточно близкими.

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

Практика в этой области такова, что независимые оценки (т. е. выполненные людьми, которые никак не зависят от команды разработчиков) обычно неточны. Единственный способ, позво­ляющий получить заслуживающую доверия оценку, заключается в совместной работе менеджера проекта и ведущих специалистов по созданию архитектуры, разработке и тестированию. Компетентная команда выполняет несколько итераций по оценке трудоемкос­ти и анализу чувствительности модели.

Хорошая оценка трудоемкости разработки программного проекта:

- создается и поддерживается менеджером проекта и коман­дами архитекторов, разработчиков и тестировщиков, ответ­ственными за выполнение работы;

- воспринимается всеми исполнителями как амбициозная, но выполнимая;

- основывается на подробно описанной и обоснованной мо­дели оценки;

- основывается на данных по аналогичным проектам, кото­рые включают в себя аналогичные процессы, технологии, среду, требования к качеству и квалификации работников;

- подробно описывается таким образом, чтобы все ключевые области риска были хорошо видны, а вероятность успеха оценивалась объективно.

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

В алгоритмическом моделировании трудоемкости разработки программного проекта существуют в основном два подхода к моделированию: теоре­тические модели и статистические модели. Большинство моделей для определения трудо­емкости разработки программного проекта могут быть сведены к функции пяти ос­новных параметров:

- размера конечного проекта (для компонентов, написанных вручную), который обычно измеряется числом строк исход­ного кода или количеством функциональных точек, необхо­димых для реализации данной функциональности;

- особенностей процесса, используемого для получения ко­нечного проекта, в частности его способность избегать непроизводительных видов деятельности (переделок, бю­рократических проволочек, затрат на взаимодействие);

- возможностей персонала, участвующего в разработке программного проекта, в особенности его профессионального опыта и знания пред­метной области проекта;

- среды, которая состоит из инструментов и методов, исполь­зуемых для эффективного выполнения разработки программного проекта и ав­томатизации процесса;

- требуемого качества проекта, включающего в себя его функциональные возможности, производительность, на­дежность и адаптируемость.

Наиболее влиятельный фактор оценки трудоемкости в этих моделях - размер программного проекта. Процедура оценки трудоемкости разработки программного проекта состоит из следующих действий:

- оценка размера разрабатываемого проекта;

- оценка трудоемкости в человеко-часах (чел.-ч.);

- оценка продолжительности проекта в календарных месяцах;

- оценка стоимости проекта.

Оценка размера проекта базируется на знании требований к системе. Для такой оценки существуют два основных способа:

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

2. Путем подсчета размера по определенным алгоритмам на основе исходных данных - требований к системе.

Проблемы оценки размера программного проекта:

- проблема может быть недостаточно хорошо понята разра­ботчиками и (или) заказчиками из-за того, что некоторые факты были упущены или искажены;

– недостаток или полное отсутствие исторических данных не позволяет создать базу для оценок в будущем;

- проектирующая организация не располагает стандартами, с помощью которых можно выполнять процесс оценивания (либо в случае наличия стандартов их никто не придержива­ется); в результате наблюдается недостаток совместимости при выполнении процесса оценивания;

- менеджеры проектов полагают, что было бы неплохо фик­сировать требования в начале проекта, заказчики же счита­ют, что не стоит тратить время на разработку спецификации требований;

- ошибки, как правило, скрываются, вместо того, чтобы оце­ниваться и отображаться, в результате чего создается лож­ное впечатление о фактической производительности;

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

Основными единицами измерения размера программного проекта являются:

- количество строк кода (LOC - Lines of Code);

- функциональные точки (FP - Function Points).

Количество строк кода - исторически самая известная и до недавнего времени распространенная единица измерения. Одна­ко при ее использовании возникает ряд вопросов:

1. Каким образом можно определить количество строк кода до того, как они фактически будут написаны либо просто спроектированы?

2. Как показатель количества строк кода может отражать вели­чину трудозатрат, если не будет учитываться сложность проекта, способности (стиль) программиста либо возможнос­ти применяемого языка программирования?

3. Каким образом разница в количестве строк кода может быть трансформирована в объем эквивалентной работы?

Эти и другие вопросы привели к тому, что строки кода как единицы измерения получили «дурную репутацию», хотя они по-прежнему остаются наиболее широко используемыми. Взаимо­связь между LOC и затрачиваемыми усилиями не является ли­нейной. Несмотря на появление новых языков программирова­ния, средняя производительность работы программистов за двад­цать лет осталась неизменной и составляет около 3000 строк кода на одного программиста в год. Это говорит о том, что уменьше­ние времени, затрачиваемого на цикл разработки, не может быть достигнуто за счет значительного повышения производительнос­ти труда программистов. Причем это не зависит от усовершен­ствований языка программирования, усилий со стороны менед­жеров или сверхурочных работ. На самом деле первостепенное значение имеет набор функциональных свойств и качество программного продукта, а не количество строк кода.

В последнее время широкое развитие приобрели методика оценки трудоемкости на основе функциональных точек и методика оценки трудоемкости на основе вариантов использования.