Работа По курсу: Предметно-ориентированные экономические информационные системы на тему: «Технико-экономические показатели разработки программных средств и их оценка»

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ЭКОНОМИКИ, СТАТИСТИКИ И ИНФОРМАТИКИ

Институт Компьютерных ТехнологийКурсовая работа

По курсу: Предметно-ориентированные

экономические информационные системына тему:

«Технико-экономические показатели разработки

программных средств и их оценка»

Выполнил студент

группы ДКЕ-302:

Михайлов М.С.

Принял преподаватель:

Данелян Т.Я.

Москва, 2008 г.

Содержание:

Введение…………………………………………………………………………………………3

1.Понятие технико-экономического обоснования программного средства. Экономика жизненного цикла ПС…………………………………………………………………………..4

2. Цели и задачи технико-экономического анализа и обоснования комплекса программ...7

3. Прогнозирование технико-экономических характеристик ПС…………………………..11

4. Технико-экономические показатели и характеристики программного средства….……18

5. Оценка технико-экономических показателей ПС…………………………………………26

Заключение……………………………………………………………………………………..37

Список использованной литературы………………………………………………………... 38

Введение

Основной задачей, стоявшей передо мной, в ходе написания этой курсовой работы, я видел изучение целей и задач технико-экономического анализа и обоснования программных средств, а также анализ характеристик программных объектов и факторов, определяющих центральное звено мой курсовой работы – технико-экономические показатели (в дальнейшем - ТЭП) при разработке программных средств (ПС). Для этого я изучил предмет технико-экономического обоснования, ознакомился с экономикой жизненного цикла программных средств, определил цели технико-экономического анализа. Изучил вопрос прогнозирования технико-экономических характеристик программных средств, посредством ознакомления с: тремя классами методов прогнозирования; сформировавшимися видами исходных данных и группами данных о ТЭП для анализа показателей, а также, что немаловажно, рассмотрел основные методы прогнозирования технико-экономических характеристик ПС и классификацию оценочной деятельности и методы оценки технико-экономических показателей разрабатываемого программного продукта.

1.Понятие технико-экономического обоснования программного средства. Экономика жизненного цикла ПС.

Приступая к разработке крупных проектов, руководители, пре­жде всего, пытаются понять целесообразно ли их создание и оценить какова будет возможная эффективность применения готового про­дукта, оправдаются ли затраты на его разработку и использование. Поэтому такие проекты традиционно начинаются с анализа и разра­ботки технико-экономического обоснования (ТЭО) предстоящего жизненного цикла (ЖЦ) проекта и эксплуатации предполагаемого продук­та.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- разработка сложных ПС требует творчества и сотрудничест­ва разных специалистов, индивидуальное и групповое поведение которых, как правило, трудно предсказать;

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

За последние несколько лет ряд исследований и работ по сбору и обобщению экономических данных о ЖЦ ПС заложили основы для методов и моделей оценивания затрат, которые обладают удов­летворительной точностью. Современная экономическая модель оценки разработки ПС считается хорошей, если с ее помощью мож­но оценить затраты на программную разработку с точностью 20 % в 70% случаев, при условии использования модели, в классе проектов, на которые она ориентирована. Имеющиеся модели не всегда столь точны, как хотелось бы, но могут весьма существенно помочь в тех­нико-экономическом анализе и обосновании решений при создании сложных ПС.

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

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

2. Цели и задачи технико-экономического анализа и обоснования комплекса программ.

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

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

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

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

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

- разработка проекта ПС и/или БД предполагается для кон­кретного потребителя-заказчика с определенным, относительно не­большим тиражом и с известной областью и внешней средой приме­нения.

Эти сценарии принципиально различаются методами техни­ко-экономического анализа и обоснования их характеристик.

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

- возможной эффективности (ценности, достоинств) после­дующего применения ПС и способности удовлетворить потребности пользователей при его использовании;

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

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

Первая цель состоит в прогнозировании реальных затрат на разработку определенного проекта компонентов и ПС в целом с уче­том их сложности и требуемого качества. Для этого должна быть изучена существующая практика разработки программ, и/или обоб­щены ТЭП современных проектов ПС. Такие обобщения должны выявить трудоемкость (стоимость) и производительность труда при разработке реальных программ определенных классов и назначения, а также основные факторы, влияющие на эти показатели при созда­нии конкретных ПС. Кроме того, необходимо определить длитель­ность всего процесса разработки программ и его отдельных этапов. Для этого должны быть разработаны и внедрены методики сбора первичных технико-экономических данных и их обработки, по завершенным или находящимся в процессе разработки проектам ПС. В результате могут быть получены современные значения основных ТЭП создания программ разных классов.

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

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

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

- развития и повышения экономической эффективности техно­логий, применяемых для создания ПС различных классов;

- рационального повышения уровня комплексной автоматиза­ции технологий разработки ПС;

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

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

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

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

Во многих случаях эффективность сложной новой техники и ПС в процессе проектирования приходится прогнозировать в условиях неопределенности целей, различных факторов и характеристик. Обычно недостаточно известны перспективы внедрения и экс­плуатации объектов разработки - новых программных продуктов. Трудно формализуемыми и оцениваемыми являются размеры (мас­штабы) и структура систем, взаимодействие основных подсистем, цели, функции и критерии оценки эффективности их функционирования. Значительные неопределенности содержатся также в технико-экономических характеристиках технологий, а также инструмен­тальных средств автоматизации проектирования и изготовления ПС. В результате экономический анализ и прогнозы могут иметь значи­тельный разброс оцениваемых показателей.

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

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

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

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

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

В первой части ЖЦ произ­водятся системный анализ, проектирование, разработка, тестирова­ние и испытания первой базовой версии ПС. Номенклатура работ, их трудоемкость, длительность и другие характеристики на этих этапах ЖЦ существенно зависят от создаваемого объекта, требуемых пока­зателей качества, внешней и технологической среды разработки. Изучение подобных зависимостей для различных ПС позволяет про­гнозировать состав и основные технико-экономические показатели, планы и графики работ для вновь создаваемых ПС.

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

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

3. Прогнозирование технико-экономических характеристик программных средств

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

Объектом прогноза по времени являются совокупные затраты и ихосновные составляющие, а также длительность и другие ТЭП разработки сложных комплексов программ гарантированного каче­ства коллективами специалистов. Достоверность первичных прогно­зов трудоемкости и стоимости на этапах концепции и системного анализа может составлять 30 - 50%, а уточненные оценки на этапе структурного проектирования, могут улучшаться до 20%. Жела­тельно, точность прогнозов при детальном проектировании дово­дить до 10%, однако более точные оценки пока вряд ли возможны, вследствие ограниченного опыта их проведения и малой статистики ТЭП завершенных разработок.

Глубина прогнозов соответствует длительности полного цик­ла разработки сложных ПС, которая может варьироваться в пре­делах 1 - 5 лет. При этом, как правило, объект и технология раз­работки, а также средства ее автоматизации определяются перед началом разработки и в дальнейшем практически не изменяются. Вследствие этого вновь появляющиеся технологии практически неприменимы для уже начатых разработок. Для прогнозирова­ния всегда используется более или менее представительная база данных ТЭП ранее завершенных разработок. Технология и осна­щенность инструментальными средствами автоматизации этих разработок соответствует некоторому уровню, характерному для времени их начала. Чем больше данных привлекается для полу­чения обобщенных значений ТЭП, тем больше в их составе будет результатов работ, завершенных несколько лет назад.

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

- экспертных оценок - индивидуальных и групповых;

- экстраполяции и расчета по аналогам-прототипам;

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

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

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

.

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

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

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

- обобщенные характеристики использованных ресурсов и технико-экономические показатели завершенных разработок - про­тотипов ПС, а также оценки влияния на них различных факторов объекта и среды разработки;

- реализованные планы и обобщенные перечни выполненных работ, реальные графики проведенных ранее оценок и разработок различных ПС;

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

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

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

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

Таким образом, возникает дилемма: либо использовать для про­гнозирования в качестве исходных, значения ТЭП нескольких самых последних завершенных разработок, либо привлекать большее число данных, в том числе в значительной степени устаревших разработок. В первом случае точность исходных данных обусловлена малой ве­личиной выборки, а во втором - влиянием старых разработок, вы­полненных при других технологиях и средствах автоматизации. В обоих случаях необходимо оценивать величину временного интер­вала запаздывания опорных данных для прогнозирования, относи­тельно начала новой разработки ПС. В первом случае это запазды­вание может составлять 3-5 и более лет, а во втором - может быть в 1,5-2 раза больше. Анализ факторов и условий, при которых осуще­ствлены ранее выполненные разработки, позволяет уточнять и пере­считывать их ТЭП на время начала прогнозируемого проекта. В ре­зультате повышается точность оценок для новой разработки. Следо­вательно, глубина прогноза и глубина используемых результатов предшествующих разработок являются важными факторами, влияю­щими на достоверность оценок.

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

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

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

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

Прогнозирование ТЭП нового ПС в свою очередь требует некоторых затрат. Они составляют обычно не более 1% общих затрат на проект, однако всегда эффективны и могут в ряде слу­чаев обеспечивать снижение совокупных затрат на разработку на десятки процентов. Для повышения достоверности прогнозов це­лесообразны технико-экономическое сопровождение процесса разработки ПС и последовательное поэтапное прогнозирование сроков завершения работ и соответствующих затрат. Управление процессом разработки ПС на базе фактических затрат на компо­ненты и этапы разработки и последовательно уточняемая досто­верность прогноза ТЭП позволяют не только снижать затраты на данный проект ПС, но и создавать базу аналогов и обобщенных данных для достоверного прогнозирования последующих проек­тов.

Исходные данные ТЭП и объекта разработки могут разли­чаться по полноте и достоверности, особенно в зависимости от условий и этапов разработки, что позволяет их разделить на сле­дующие группы:

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

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

- обобщенные ТЭП ряда родственных предприятий, соз­дающих близкие по классу ПС, с применением собственных тех­нологий и систем автоматизации.

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

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

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

- уточненные оценки полных ТЭП процесса разработки ПС на базе обобщенных характеристик предшествующих разрабо­ток и уточненного сценария объекта и условий разработки;

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

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

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

- приемлемый для заказчика минимум функций и требований к проекту;

- разумную вероятность успеха сточки зрения возможностей коллектива разработчиков.

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

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

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

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

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

- вследствие несовершенства методов оценивания ПС следует сравнивать оценки с действительными значениями и использовать эти результаты для улучшения методов оценивания ТЭП;

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

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

• первичная оценка ТЭП при подготовке концепции и техни­ческого задания на новый комплекс программ на основе экспертных данных размера ПС, производительности труда или стоимости раз­работки одной строки текста программ - прототипов;

• прогнозирование ТЭП при предварительном и детальном проектировании ПС на базе расчетных значений трудоемкости и длительности разработки комплекса программ по данным модели СОСОМО с учетом влияния различных дополнительных факторов;

• определение технико-экономических показателей ПС с уче­том доступных оценок множества факторов и календарное планиро­вание разработки сложного комплекса программ с использованием системы ПЛАПС.

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

В первой методике реализован метод прогноза ТЭП с учетом экспертной оценки минимального числа факторов. Данная методика экспертной оценки ТЭП может применяться, когда определены цели и общие функции проекта ПС, сформулиро­ванные в концепции и первичных требованиях с достоверностью около 30 - 40% . Основная цель оценки ТЭП - подготовить возмож­ность принять обоснованное решение о допустимости дальнейшего продвижения проекта в область системного анализа, разработки требований и предварительного проектирования. Если оказывается, что рассчитанные технико-экономические показатели и требуемые ресурсы не могут быть обеспечены для продолжения проекта, то возможны кардинальные решения: либо изменение некоторых ТЭП и выделяемых ресурсов, либо прекращение проектирования данного ПС. Учитывая полноту и достоверность доступных характеристик и требований к проекту ПС должны быть определены цели и воз­можная достоверность технико-экономического обоснования затрат на продолжение проектирования ПС.

При первичном технико-экономическом обосновании сложных проектов ПС наибольшее значение имеют три ключевых фактора:

- размер - масштаб, подлежащих разработке полностью новых программных компонентов;

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

- относительные затраты ресурсов на создание проекта: труда специалистов, времени или бюджета на единицу размера (на строку текста программ) проектируемого ПС.

Эти факторы могут быть оценены квалифицированными экс­пертами на основе имеющегося у них опыта реализации предшест­вовавших подобных проектов, а также использования опубликован­ных данных. При наличии необходимых данных важно оценить их достоверность и возможную точность (30 - 40%). Наименее точный из перечисленных факторов полностью определяет достоверность расчета технико-экономических показателей проекта ПС поэтому желательно, чтобы значения точности экспертного оценивания пе­речисленных факторов были сбалансированы.

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

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

> экспертная оценка возможной средней производительности труда специалистов при разработке программ и/или стоимости раз­работки одной сроки текста программ проекта ПС (этапы 2.1. - 2.2);

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

> обобщение основных технико-экономических показателей и полной стоимости разработки проекта ПС, анализ результатов и тех­нико-экономическое обоснование рентабельности продолжения проектирования комплекса программ (этапы 4.1 —4.2).

Таблица 4

Класс и функции проекта ПС	Цели анализа и возможная достоверность исходных данных	Выбор методики и сценария оценки технико-экономических показателей
1.1. Экспертная оценка размера - масштаба программ проекта ПС	1.2. Экспертная оценка доли готовых повторно используемых компонентов	Экспертная оценка обобщенного размера программ
2.1. Экспертная оценка производительности труда при разработке программ проекта ПС	2.2. Экспертная оценка стоимости разработки одной строки текста программы проекта ПС	Экспертная оценка удельных затрат на строку текста программы
3.1. Расчет полной трудоемкости разработки проекта ПС	3.2. Расчет полной длительности разработки проекта ПС	3.3. Расчет необходимого среднего числа специалистов для разработки проекта ПС
4.1. Обобщение основных технико-экономических показателей и полной стоимости разработки проекта ПС	4.2. Анализ результатов и технико-экономическое обоснование продолжения проектирования ПС

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

4. Характеристики и технико-экономические показатели программного средства.

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

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

Классы и характеристики программных средств по стандарту ISO 180 12182

Концептуальные требования к рассматриваемым классам программных средств

Три базовых класса комплексов программ для анализа технико- экономических показателей

Функциональная пригодность - основа определения технико-экономических показателей программных средств

Характеристики сложности программных средств при анализе технико-экономических показателей

Описания единиц размера - масштаба и качества компонентов и комплексов программ

Единицы измерения трудоемкости разработки компонентов и комплексов программ

Единицы измерения длительности разработки комплекса программ — начала и окончания проекта

Технико-экономические показатели на единицу размера программной продукции

Технико-экономические показатели на этап разработки программного средства

Числа ошибок в комплексе программ в зависимости от длительности разработки

Таблица 1

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

Для конкретизации основной области дальнейшего анализа и технико-экономического обоснования проектов целесообразно вы­делить и классифицировать обобщенные характеристики и атри­буты, рассматриваемых комплексов программ в соответствии со стандартом ISO 180 12182. В стандарте выделены три группы видов характеристик: внутренние виды; виды среды и виды данных. Для каждого вида представлен перечень классов, из которых рекомендуется выбирать подходящие характеристики для отражения особенностей конкретной системы или достаточно широ­кой сферы анализа и применения ПС. Из общего числа трех видов, 16-ти классов и около ста типов характеристик ПС вследствие уп­рощения далее будут преимущественно учитываться следующие:

• функции прикладных ПС - системы управления объектами или процессами; САПР, организационные, административные и обучающие системы;

• прикладная область системы - оборудование и аппаратура управления процессами и объектами; САПР, информационные, ад­министративные и обучающие системы;

• режим эксплуатации - обработка данных в режиме реального времени;

• масштаб, размер ПС - средний или большой;

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

• критичность ПС - высокая, должна быть предотвращена возможность больших экономических потерь, повреждения дорогой собственности или угроза человеческой жизни;

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

• стабильность ПС - маловероятное или дискретное внесение изменений в процессе регламентированного сопровождения;

• готовность программного продукта - заказное, для конкрет­ного применения в системе, или для массового распространения на рынке и среди предприятий;

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

• требования безопасности и надежности - высокие и критиче­ские;

• вычислительная система и среда — микропроцессорное управление или сложные системы реального времени;

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

Имеющаяся статистика технико-экономических показателей разработки ПС различных классов позволила выявить основные факторы, от которых они зависят. Изучены тенденции изменения ТЭП от важнейших параметров. Доказано, что трудоемкость разра­ботки ПС почти линейно зависит от масштаба - размера создавае­мых программ. Для учета классов ПС с позиции их ТЭП проведено ранжирование экспериментальных данных и выделены три доста­точно различающихся базовых класса (см. табл.1) при одном и том же размере, характеризующиеся:

- максимальной трудоемкостью - встроенные ПС сложных систем реального времени (СРВ);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технико-экономические показатели на этап разработки программного средства целесообразно оценивать аддитивными эко­номическими показателями (см. табл.1). Такими ТЭП, могут слу­жить суммарные трудозатраты на выполнение этапа работ при пла­нировании и создании ПС определенного размера и класса или по­этапные трудозатраты на одну команду - строку текста. Эти харак­теристики позволяют выявить наиболее трудоемкие этапы и помо­гают рационально распределять затраты по этапам работ. В поэтап­ных затратах целесообразно выделять совокупные затраты на средства автоматизации разработки, что позволяет выявлять эффектив­ные технологии и средства с учетом стоимости их приобретения и эксплуатации.

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

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

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

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

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

Неопределенность единиц измерения размера комплексов и компонентов программ значительно влияет на численные значения показателей и их разброс в опубликованных работах. Этому также способствует неоднозначность учитываемых этапов разработки про­грамм икатегорий специалистов, трудозатраты которых заметно влияют на ТЭП. При одних и тех же процессах измерения объектов разработки и затрат на их создание методики определения количест­венных значений основных показателей пока не формализованы, что вносит дополнительную дисперсию в их значения, приводимые в различных исследованиях. В результате могут делаться различные и даже принципиально неверные выводы, например, об очень высокой эффективности некоторых частных технологических методов или инструментальных систем автоматизации разработки ПС. Для уменьшения этих неопределенностей и возможных методиче­ских ошибок в ТЭП программ необходимо определить основные понятия и единицы измерения: размера или масштаба программ, трудозатрат на их разработку, производительности труда специали­стов и некоторых частных характеристик (см. табл.1).

Оценку размера комплекса программ и трудозатрат приходится выполнять неоднократно во время жизненного цикла, причем после каждого оценивания повышается уровень доверия к полученным ре­зультатам. Точность оценки значительно повышается после форму­лирования начальных требований и спецификаций заказчиков, про­ведения анализа требований, после завершения разработки проекта. Хороший менеджер проекта обязан взять себе за правило оценивать (повторно) размеры ПС, используя результата оценивания в качест­ве выходных критериев для каждого этапа. Известно, что программи­сты весьма плохо справляются с проблемами оценивания результа­тов своего труда. К этому выводу приводит факт, что около 15% программных проектов не доводятся до завершения, так как прогнозы по поводу предполагаемой производительности разработчиков весьма далеки от совершенства. Несоответствие производительности изна­чально предполагаемым показателям, может иметь две следующие причины: плохая работа специалистов или некорректная техника и методы оценки ТЭП. Имеется множество свидетельств плохо вы­полненной оценки, однако практически невозможно доказать, что персонал не трудился усердно над разрешением проблемы, либо не является в достаточной степени компетентным. Разработчиков зачас­тую нельзя призвать к ответственности за такие результаты. Все начинается с прогнозирования размеров ПС, оценивание и досто­верность которых обусловлены следующими факторами:

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

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

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

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

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

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

Исследованию различных единиц измерения, используемых при оценке размеров ПС, посвящены рассмотрению некоторых наиболее часто используемых из них. Выбор этих единиц зависит от конкретного проекта и потребностей организации. За рубежом чаще всего размер ПС определяется в терминах строк кода (Lines of Code - LОС), функциональных точек и точек свойств. Вне зависимости от того, оценивается ли конечный продукт, как в случае с применением показателя LОС, либо некоторая его абст­ракция или модель, в данном случае оценке подвергаете то, чего еще нет в природе. Поэтому оценивание размеров ПС представля­ет значительные трудности.

Размер или масштаб программ в настоящее время приводит­ся в публикациях в различных единицах, что может изменять их численные значения для одних и тех же программ в несколько раз. В качестве таких единиц чаще всего используются чис­ленные значения: строк текста программы на языке программирова­ния, предложений на ассемблере, символов в тексте программы, байт или команд в объектном коде после трансляции (табл.1). Каждая из этих единиц измерения имеет некоторые преимущества при определенных целях исследования. Однако при сравнительном технико-экономическом анализе различных проектов применение в каждом из них отличающихся единиц для характеристики объекта разработки приводит к дополнительному разбросу численных зна­чений размеров и к несопоставимости измеренных технико-экономических показателей.

Важная задача при оценивании ТЭП состоит в выборе базо­вых унифицируемых единиц измерения исходного текста и испол­няемых (объектных) программ, при применении которых имеется наибольшая корреляция этих видов измеряемых размеров про­грамм. Для остальных единиц измерения необходимы методы пере­счета к базовым единицам с учетом особенностей языков програм­мирования, применяемых трансляторов и архитектуры ЭВМ. Кроме того, следует определять коэффициенты корреляции с базовыми единицами измерения при применении остальных единиц. С этих позиций наиболее адекватной единицей измерения объема программ является число операторов на машино-ориентироваином ассемб­лере, которое имеет корреляцию с числом команд в объектном коде реализующей ЭВМ, близкую к единице. В этом случае при сопос­тавлении измеренных объемов программ влияет единственный фак­тор - архитектура реализующих ЭВМ. Этот фактор может учиты­ваться путем небольших коэффициентов перевода, определяемых путем анализа особенностей структуры и системы команд ЭВМ, а также конкретного ассемблера. Для сопоставления численных зна­чений объемов программ следует выделять базовый, наиболее ши­роко применяемый ассемблер.

5. Оценка технико-экономических показателей программных средств.

Основными ресурсами у разработчиков при создании слож­ных комплексов программ являются: допустимые трудозатраты на разработку ПС стребуемым качеством; время - длительность полного цикла создания программного продукта; необходимое и доступное число специалистов соответствующей квалификации. Потребность в этих ресурсах в наибольшей степени зависит от раз­мера - масштаба и сложности разрабатываемого ПС. Когда впервые рассматривается масштаб нового проекта ПС, интуитивные и экспертные оценки его трудоемкости могут отличаться от конечного значения при­мерно в полтора раза в ту или другую сторону. Рисунок 1 иллю­стрирует достоверность, с которой могут быть получены оценки трудоемкости или стоимости ПС, представленные в виде функции этапа ЖЦ (горизонтальная ось), или уровень знаний о предполагае­мой работе над ПС. Такая достоверность оценок обусловлена уровнем неопределенности на данном этапе знаний о конечном содержании и возможном размере программного продукта. Хотя на рис.1 представлена симметричная картина, общая тенден­ция состоит в том, что на начальных этапах оценки затрат чаще всего занижаются.

Эта неопределенность уменьшается по мере детализации и углубления содержания и функций проекта, как только фиксируются конкретные принципы функционирования и концепция ПС. На этом этапе оценка достоверности размера уменьшается приблизительно до 40%.

Рис.1

Это вполне объяснимо, поскольку еще не уточнены структу­ра и многие детали проекта. Эти вопросы могут быть раз­решены во время разработки структуры и спецификаций требова­ний к ПС и тогда можно оценить размер ПС с точностью до 15 -20%. После завершения разработки и подтверждения проектных спецификаций при детальном проектировании комплекса про­грамм может быть определена структура внутренних данных и функции программных компонентов. На этом этапе оценка раз­мера и трудоемкости проекта может составить около 10%. Неоп­ределенности оценок могут быть обусловлены: особенностями конкретных алгоритмов, управления их работой, обработки оши­бок, инициализации и завершения сеансов работы и т.д. Эти уточнения размеров ПС и компонентов могут быть решены к концу детального проектирования, однако при этом сохраняется неопределенность оценки размера комплекса программ и его трудоемко­сти порядка 5 - 10%, связанная с тем, насколько хорошо про­граммисты понимают спецификации, в соответствии с которыми они должны кодировать программу. Основной вывод, выте­кающий из рис.1, состоит в необходимости быть последова­тельным при определении исходных данных при оценке ТЭП для различных компонентов программного продукта и этапов проек­тирования.

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

Рис.2

При оценках ТЭП целесообразно учитывать:

- цели оценивания ТЭП должны быть согласованы с по­требностями в информации, способствующей принятию решений на соответствующем этапе проекта ПС;

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

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

Измерение размера, оценка и составление графика разработки сложным образом переплетаются в процессе планирования проекта. На самом деле довольно сложно создать реальный график (учиты­вающий обязанности исполнителей, их зависимости, перекрытие действий, а также дату поставки продукта) без информации об объ­еме трудозатрат, требуемых для выполнения каждой задачи (напри­мер, определения нагрузки сотрудников на месяц). Достаточно трудно оценить объем трудозатрат, необходимых для выполнения задачи, без достоверной информации относительно ее размера. Та­ким образом, измерение размера (сложности) предшествует оценке ТЭП, а эта оценка, в свою очередь, предшествует составлению гра­фика работ. Каждое из этих важных действий проекта может быть выполнено с помощью различных методик. Недостаточно достоверные оценки влекут проблемы взаимодействия разработчика с заказчиком и увеличивают степень риска проекта.

В индустрии ПС часто обращаются к использованию метрики LОС, единицы измерения, хорошо знакомой практикам в области разработки ПС. Они находят ее комфортной и простой в примене­нии. Какая бы технология не использовалась, оценка размера буду­щего продукта является весьма важной, поскольку она является ча­стью одной наиболее важной задачи проекта: установка реальных ожиданий. Нереальные ожидания, основанные на неточных оцен­ках, представляют собой одну из частых причин провала проек­тов. Зачастую причина кроется не в недостаточной производи­тельности команды проекта, а в неточном предвидении уровня этой производительности и размера проекта. Точное оценивание ТЭП обеспечивает улучшенный контроль над проектом и является жиз­ненно важным в деле проектного менеджмента. Для обеспечения точного оценивания в первую очередь следует иметь представление относительно размера продуцируемого ПС. Эта величина должна определяться на ранних стадиях цикла разработки и выражаться в единицах, которые являются достаточно простыми.

Исходные данные реальных завершенных разработок для оценивания ТЭП, собираются, накапливаются и обрабатываются, с начала 70-х годов в разных отечественных организациях и за рубе­жом. Они позволили получать и прогнозировать основные обобщенные технико-экономические показатели процессов разра­ботки ПС. При этом компоненты операционных систем, драйверы, средства контроля и тестирования, а также повторно используемые компоненты обычно не учитывались при оценке размера вновь соз­данных комплексов программ и трудоемкости их полной разработ­ки. Поэтому технико-экономические показатели проектов этого пе­риода можно отнести к полностью оригинальным разработкам ком­плексов программ. При этом обычно рассматривался полный техно­логический процесс разработки ПС от начала подготовки техниче­ского задания (ТЗ) до завершения испытаний базовой версии ПС. Учитывались все категории специалистов, участвующих в создании программ и обеспечивающих разработку, а также все виды работ, связанные с созданием программного продукта на выделенном ин­тервале времени. Теоретические работы и системный анализ до под­готовки ТЗ в значениях ТЭП не учитывались.

Наиболее полно и подробно основные закономерности и влияние факторов на технико-экономические показатели про­цессов разработки сложных ПС в 70 - 80 годы, представлены в материалах Б.У. Боэма под названием «Инженерное проектирование программного обеспечения» для более десяти моделей прогнозирования. В 1981 году на основе исследования процессов разработки 63 проектов ПС опубликована модель прогнозирования ТЭП под названием КОМОСТ. В по­следующем, эта модель развита, детализирована и опубликована как СОСОМО, а в 2000 году под названием СОСОМО II. В этой модели на основе анализа более 160 реальных проектов разработки комплексов программ различной сложности уточнены рейтинги влияния выделенных факторов на основные ТЭП. Эти данные ниже используются и рекомендуются как базовые для прогнозирования затрат при создании ПС.

Кроме того, в 1988 году опубликованы результаты анализа ТЭП комплексного проекта ПРОМЕТЕЙ на основе обобщения ре­зультатов разработки свыше 250 отечественных проектов сложных ПС, отдельные фрагменты которых также использованы ниже. В общем случае для оценки технико-экономических характеристик новых проектов необходимы исходные данные:

- обобщенные характеристики использованных ресурсов и технико-экономические показатели завершенных разработок - прототипов ПС, а также оценки влияния на их характеристики различ­ных факторов объекта и среды разработки;

- реализованные и обобщенные перечни выполненных работ и реальные графики проведенных ранее разработок различных клас­сов ПС;

- цели и содержание частных работ в процессе создания слож­ных комплексов программ и требования к их выполнению для обес­печения необходимого качества ПС в целом;

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

Наиболее важен учет и анализ факторов на начальных этапах разработки, когда прогнозируются первичные совокупные затраты Ср на создание ПС (табл.1). На этих этапах неопределенность оценки параметров и факторов наибольшая (рис.1), тем не менее применение приводимых характеристик позволяет избегать наиболее крупных ошибок при оценке затрат, которые делаются экс­пертами без детального анализа влияния факторов. Подобный анализ является базой для рационального распределения ресурсов и для управления их использованием по мере развития проекта. Учет и прогнозирование возможного изменения затрат в зависимости от основных параметров способствует упорядочению процесса разра­ботки ПС и концентрации усилий на тех факторах, которые могут дать максимальный эффект уменьшения затрат в конкретных усло­виях создания комплекса программ. После проведения структурного проектирования и распределения ресурсов ПС возможна ошибка в оценке затрат на разработку приблизительно в полтора-два раза меньше, а перед программированием она может уменьшаться до 10 - 15%. Такие достоверности можно получить, конечно, только при подробном анализе и оценке влияния важнейших факторов.

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

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

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

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

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

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

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

В качестве базового варианта целесообразно принять статисти­ческие данные ТЭП, перечень работ и документов жизненного цикла создания наиболее сложного встроенного комплекса программ ре­ального времени (табл.1). На основе этих исходных данных могут быть оценены ТЭП для полного цикла разработки ПС конкретного вида в более простых случаях путем исключения из базового варианта работ и документов, в которых отсутствует необ­ходимость. По оставшимся работам могут быть оценены ТЭП для вариантов и выбран из них предпочтительный. Для технико-экономического анализа процесса создания программ важнейшей составляющей являются совокупные трудовые затраты - трудоем­костьС на непосредственную разработку ПС.

Трудоемкость разработки программных средств наиболее сильно зависит отразмера — масштаба программ, выраженного числом операторов на ассемблере или строк на языке программи­рования высокого уровня. В п. 4 обсуждался вопрос о способах и единицах измерения размера разрабатываемых программ и обосно­вана целесообразность проводить эти оценки в числе операторов (команд) на языке ассемблера. Реальное изменение создаваемых в настоящее время сложных ПС от 104 до 107 строк (LОС) определяет диапазон трудоемкости разработки таких программ от человеко-года до десятков тысяч человеко-лет. Широкий диапазон изменения раз­мера создаваемых программ в наибольшей степени определяет значения суммарной трудоемкости их разработки. Подтверждена по большому числу проектов высокая статистическая корреляция между размером комплексов программ в операторах на ассемблере и трудоемкостью их разработки. С другой стороны, отсутствуют какие либо данные о значительном преимуществе других мер размера и сложности при прогнозировании затрат на разработку сложных и сверхсложных ПС. Объем программ в числе операторов на ассемб­лере характеризуется простотой и экономичностью определения, а также удобством для расчетов и прогнозирования.

Опыт подсказывает, что по мере увеличения размера комплекса программ возрастают не только абсолютные, но и относительные затраты на разработку каждой строки текста в программе. Вследст­вие этого затраты труда при разработке одной строки текста в программах разного объема могут различаться в несколько раз. Согласно материалам М.Х. Холстеда («Начала науки о программах»), трудоемкость разработки программного модуля пропорциональна квадрату размера программы. Модульно-иерархическое построение крупных ПС позволяет замедлить квадратичный рост сложности и соответствующей ей трудоемкости разработки при увеличении размера программ. Суммарную трудоемкость разра­ботки сложного ПС можно представить двумя сомножителями. Первый сомножитель является доминирующим, он прямо пропор­ционален размеру программ П и отражает практически линейное возрастание трудоемкости создания любых программ при увеличе­нии их размера.

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

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

Хотя размеры базы данных для сложных ПС по числу типов имен переменных изменяются в очень широких пределах, приблизи­тельно от 103 до 108 , их непосредственное влияние на трудо­емкость разработки строки в программе даже при числе перемен­ных, в десятки раз превышающем размер программы, оценивается на уровне 10%. При этом степень этого влияния трудно форма­лизовать, так как большую роль играет структура базы данных и ее функциональное назначение. Поэтому далее этот фактор отдельно не учитывается и только для очень больших и сложных структур баз данных рекомендуется увеличивать трудоемкость на десяток про­центов.

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

Для совокупностей ПС первого и второго классов, исследовалась зависимость трудоемкости разработки программ С от их объемов - П. Для аппро­ксимации зависимости трудоемкости от размера ПС наиболее часто использована степенная функция вида:

С = АхПЕ(1)

При разработке ПС большого размера в значительной степени, должна возрастать сложность разработки по сравнению с ПС малого объема, так как в больших программах существенно усложняются взаимосвязи компонентов по информации и управлению, а также становятся более трудоемкими процессы планирования и управле­ния проектом в ходе разработки. Выдвинутая гипотеза, о возраста­нии трудоемкости разработки с ростом размера ПС быстрее, чем по линейному закону, справедлива, если показатель степени в получен­ном уравнении регрессии Е > 1. По методу наименьших квадратов в ряде работ определены коэффициенты A и Е в уравнениях степенной регрессии, показывающие характер зависимости трудо­емкости от размера ПС. В таблице 3.1. представлены значения коэффициентов регрессии для моделей КОМОСТ, СОСОМО и ПРОМЕТЕЙ, для основных классов проектов программных средств. Выражение (1) с использованием этих коэффициентов и значений П размера ПС в тысячах строк ассемблера рекомен­дуется для прогнозирования трудоемкости полной разработки в человеко-месяцах.

Таблица 2

Коэффициенты моделей для оценки трудоемкости разработки

программных средств

Коэффициент А	Коэффициент Е	Модель и тип программных средств
2,4	1,05	Базовая - КОМОСТ
3,6 3,0 2,4	1,20 1,12 1,05	Детализированная модель СОСОМО: - встроенный; - полунезависимый; - независимый.
2,94	1,15	СССОМО 11.2000 Крупный проект 100 KSLOC
10,0 6,1	1,21 1,17	ПРОМЕТЕЙ Системы реального времени; Информационно-поисковые системы.

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

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

На рис. 3 по уравнениям регрессии (1) построены в лога­рифмическом масштабе зависимости трудозатрат от размера для ПС двух классов. Первый (встроенные - СРВ) и второй (ИПС) классы ПС, отчетливо различаются по трудоемкости разработки. Более высокой точности оценки трудоемкости разработки только по одной переменной - размеру ПС, по-видимому, невозможно получить, так как процесс разработки зависит от большого числа факторов, которые следует учитывать при оценке трудоемкости. Наиболь­шие трудозатраты обычно необходимы для разработки крупномас­штабных комплексов программ реального времени, так как данный класс программ используется в наиболее ответственных автоматизи­рованных системах.

Затраты на разработку С и объем программ П могут быть свя­заны через показатель интегральной средней производительности труда разработчиков Р.

Рис.3

Для учета влияния на С различных факторов удобно пользо­ваться коэффициентами (рейтингами) изменения трудоемкости (КИТ) - M(i, j), учитывающими зависимость j-го фактора от i-й со­ставляющей совокупных затрат. В них входят факторы процесса не­посредственной разработки, факторы программной и аппаратурной оснащенности, а также квалификация специалистов. Не­посредственно затраты на разработку можно представить как част­ное от размера ПС и производительности труда Р = 1 / А, корректи­руемой произведением коэффициентов изменения трудоемкости (КИТ - М (i, j) ):

П Е

C= хПM(i, j) = Aх ПЕ хПМ(i, j) (2)

Р i,j i,j

Длительность разработки программных средств является важнейшим технико-экономическим показателем, поскольку часто она определяет общие сроки разработки систем, а значит, быстроту реализации идей в различных областях автоматизации. В таблице 3 за начало разработки ПС принят момент начала создания технического задания (Т3), а за окончание — завершение испытаний программного продукта в целом или момент предъявления его на испытания.

Таблица 3

Коэффициенты моделей для оценки трудоемкости разработки

программных средств

Коэффициент	Коэффициент	Модель и тип
G	Н	программных средств
2,5	0,38	Базовая - КОМОСТ
		Детализированная модель СОСОМО:
2,5	0,32	- встроенный;
2,5	0,35	- полунезависимый;
2,5	0,38	- независимый.
		СССОМО 11.2000
3,67	0,328	Крупный проект 100 KSLOC
		ПРОМЕТЕЙ
3,51	0,31	Системы реального
		времени;
3,78	0,28	Информационно-поисковые системы.

Диапазону размеров современных ПС в три-четыре порядка (до 10 млн. строк) соответствуют приблизительно такие же диапазоны изменения трудоемкостей и стоимостей их разработок. Однако, очевидна принципиальная нерентабельность разработки даже очень сложных ПС более 5 лет. С другой стороны, программы даже в несколько тысяч строк по полному технологическому циклу с испытаниями как продукции редко создаются за время, меньшее, чем полгода-год. Таким образом, вариация длительностей разрабо­ток ПС много меньше, чем вариация их трудоемкостей, и не превы­шает десятикратный диапазон. Длительности разработок Т ограни­чены сверху и снизу, и одним из основных факторов, определяющих эти границы, является объем программ – П.

Относительный «консерватизм» значений длительностей по сравнению с трудоемкостью определяется объективной необходи­мостью создавать ПС в рациональные сроки.

Любые ПС должны поступать на эксплуатацию до того, как в

них пропадает необходимость. Их цели, концептуальная основа и алгоритмы не должны устареть за время разработки. Отсюда появляется верхний предел допустимых длительностей разработки. Этот верхний предел не может иметь единственное значение для любых классов и объемов ПС. Однако недопустима его вариация в том же диапазоне, что и размер. Поэтому на практике по мере возрастания размеров ПС увеличиваются коллективы специалистов-разработчиков, что обеспечивает основной прирост необходимой трудоемкости. Чем крупнее создаваемое ПС, тем большие усилия обычно прилагаются для автоматизации и совершенствования технологии разработки. Это также способствует замедлению роста длительностей разработки, однако по мере увеличения сложности программ, длительность их разработки все же заметно возрастает.

Стремление ограничивать длительность реальных разработок ПС приводит к объективному формированию верхнего предела, за которым распространяется зона «нерациональных» длительностей, зависящих от размера и трудоемкости ПС. Даже для довольно сложных ПС, имеющих размер свыше 500 тыс. строк, вряд ли допустима длительность разработки более 3-5 лет. Большие длительности, иногда имеющиеся на практике, обусловлены в основном низкой квалификацией разработчиков и заказчиков, не­достаточной автоматизацией технологии, малым коллективом спе­циалистов и рядом других, преимущественно организационных и технологических причин. Подобные ситуации чаще встречаются при относительно небольших разработках (10 - 50 тыс. строк), когда у руководителей и коллектива мал опыт их проведения, следствием чего является избыточный оптимизм в начале разработки, а также пренебрежение технологией и организацией работ.

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

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

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

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

Обобщенные данные длительности разработки Т по классам программ в ряде работ аппроксимировались уравнениями регрессии по методу наименьших квадратов в зависимости от размера ПС и от трудоемкости их разработки (таблица 2):

T = Gx CН. (3)

Зависимости Т от размера программ П значительно разли­чаются для классов ПС. Это определяется различием сложности классов программ, применяемых языков программирования и единиц измерения объема ПС, следствием чего является различие значений размера созданных программ при одной и той же длительности и трудоемкости разработки. Чтобы исключить ошиб­ки, связанные с неопределенностью измерения размера программ, исследована зависимость длительности разработки от ее трудо­емкости. Учитывалась только трудоемкость непосредст­венной разработки программ С без затрат на средства автоматизации разработки. Обработка тех же, что выше, наборов данных позволила получить коэффициенты уравнения регрессии представленные в таблице 2. Средние значения длительности разработки классов ПС практически не различаются в зависимости от трудоемкости разработки программ.

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

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

При разработке программных модулей и компонентов отдель­ными специалистами или небольшими группами производитель­ность труда при написании одних и тех же текстов автономных про­грамм может различаться в десяток раз в зависимости от их таланта и трудоспособности и достигать тысяч строк за человеко-месяц. Од­нако достаточно полное тестирование, документирование, комплексирование и оформление в крупные комплексы программного про­дукта, приводят к снижению интегральной производительности до величин в несколько сотен строк текста за человеко-месяц. Для крупных проектов класса СРВ 80-е годы приводятся величины 100 - 150 строк на человеко-месяц, в отечественных проектах в те же годы эта величина приближалась к 80 - 100. Совершенство­вание технологии, квалификации специалистов и инструменталь­ных средств автоматизации разработки позволили в последние годы повысить среднюю производительность труда при создании полно­стью новых оригинальных программных продуктов СРВ в несколь­ко раз по экспертным оценкам до величин 300 - 500 строк на чело­веко-месяц.

При разработке ПС необходимо учитывать, что экономические, временные, вычислительные и другие ресурсы па разработку и весь ЖЦ программ всегда ограниченны и используемые затраты дляулучшения каждой характеристики должны учитывать эти ограни­чения. Для рационального распределения этих ресурсов необходимо знать как отражается изменение затрат на улучшении каждой характеристики качества ПС. Эта взаимосвязь затрат ресурсов и значений каждой характеристики зависит от назначения, а также от ряда свойств и других особенностей комплекса программ, что ус­ложняет учет влияния таких связей. Тем не менее, выявлены основ­ные тенденции такого взаимодействия, которые могут служить ори­ентирами при выборе и установлении требований к определенным характеристикам качества в конкретных проектах ПС.

Схема работы программы по вычислению ТЭП:

Заключение

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

Список литературы:

1.Вендров А.М, Проектирование программного обеспечения экономических информационных систем. Учебник. – М.:Финансы и статистика, 2002.

2.Кантор М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения. Пер с англ. – М.:Вильямс, 2002

3.Ковалевская Е.В. Метрология, качество и сертификация программного обеспечения, М., МЭСИ, 2004.

4.Липаев В.В. Выбор и оценивание характеристик качества программных средств, М.:СИНТЕГ, 2001.-224с.

5.Липаев В.В. Методы обеспечения качества крупномасштабных программных средств. – М.: СИНТЕГ, 2004

6.Липаев В.В. Технико-экономическое обоснование проектов сложных программных средств / - М.: СИНТЕГ, 2004.

7.Оценка и аттестация зрелости процессов создания и споровождения программных средств и информационных систем (ISOIEC TR 15504 - СММ).-М.:Книга и бизнес. 2001

8.Фатрелл Р.Т., Шафер Д.Ф., Шафер Л.И. Управление программными проектам: достижение оптимального качества при минимальных затратах. Пер с англ. – М.:Вильямс, 2003.

Практические сведения по оценке технико-экономических показателей существующих экономических комплексов из интернет-ресурсов:

9. http://www.cultinfo.ru/fulltext/1/001/008/110/382.htm

10. http://www.informost.ru/ss/18/os3.shtml

11. http://www.okclub.org/ctsc/etp_ogks2/5.htm