Разработка программ является областью с малой материало- и энергоемкостью, и основные затраты связаны с непосредственным или овеществленным трудом специалистов различных категорий.
Наибольшее значение в составе Ср при разработке сложных комплексов программ ( КП ) имеют следующие составляющие затрат:
на непосредственное проектирование, программирование, отладку и испытания программ в соответствии с требованиями пользователя или заказчика — K1р;
на изготовление опытного образца КП как продукции производственно-технического назначения — K2р;
на разработку, подготовку и применение технологии программных средств автоматизации разработки программ — K3р;
на технологические и реализующие ЭВМ, используемые для автоматизации разработки программ — K4р;
на подготовку и повышение квалификации специалистов-разработчиков — K5р.
Первые две составляющие K1р и K2р являются непосредственными затратами на создание программных средств. Составляющие K3р и K4р можно рассматривать как затраты, обеспечивающие оснащенность процесса создания КП. Затраты на подготовку и повышение квалификации наиболее трудно формализовать и учитывать в конкретной разработке программных средств. В данном случае эта составляющая не учитывается.
Лекция 12 Оценка эффективности разработки
Затраты на непосредственную разработку кп
Затраты на непосредственную разработку комплекса программ K1р являются важнейшей составляющей в жизненном цикле КП. Наибольшее влияние на них оказывает объем КП. Затраты на разработку K1р и объем программ Пк связаны через показатель интегральной средней производительности труда разработчиков Р. Для учета влияния на K1р различных факторов удобно пользоваться коэффициентами изменения трудоемкости (КИТ) — Сij, учитывающими зависимость i-ой составляющей совокупных затрат от j-го фактора. Непосредственные затраты на разработку можно представить как частное от объема КП и производительность труда, корректируемое произведением коэффициентов изменения трудоемкости:
Выделим четыре основных группы факторов, влияющих на затраты K1р при непосредственной разработке программ:
факторы, отражающие особенности создаваемого комплекса программ как объекта разработки, и требования к его общим характеристикам;
факторы, характеризующие технологическую и программную оснащенность средствами автоматизации процесса разработки программ;
факторы, отражающие оснащенность процесса создания КП аппаратурными средствами, на которых базируются системы автоматизации разработки;
факторы, определяющие оснащенность процесса разработки программ и его обеспечение квалифицированными специалистами.
Факторы объекта разработки
Диапазон изменения параметра
Среднее значение КИТ
Сложность КП — С11
Число операторов в тексте программ на ассемблере Пк
Размер базы данных
Число типов переменных в БД
Надежность функционирования КП — С13
Быстрый курс: экономики за 30 минут
Часы проработки на отказ программ Тн
Ограничение ресурсов производительности и оперативной памяти реализующей ЭВМ — С14
Процент использования памяти и производительности Р
Длительность предполагаемой эксплуатации — С15
Годы эксплуатации Тэ
Предполагаемый тираж — С16
число предполагаемых экземпляров
Мобильность использования компонент КП из других разработок — С17
Процент возможного использования компонент
Мобильность использования КП для других разработок — С18
Процент возможного использования компонент
Источник: studfile.net
47369 (Клиентская часть технологической среды для разработки больших экономических моделей: компоненты поддержки работы эксперта-экономиста при формировании и отладке (в расчетном режиме) структурного текста модели), страница 6
Документ из архива «Клиентская часть технологической среды для разработки больших экономических моделей: компоненты поддержки работы эксперта-экономиста при формировании и отладке (в расчетном режиме) структурного текста модели», который расположен в категории » «. Всё это находится в предмете «информатика» из , которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе «остальное», в предмете «информатика, программирование» в общих файлах.
Онлайн просмотр документа «47369»
Текст 6 страницы из документа «47369»
В этом параграфе была рассмотрена упрощенная схема разработки программы в среде Delphi. Но кроме создания исходного текста необходимо помнить и об отладке программ. 2.4 Отладка программ Рис11. Инспектор классов.
Процесс отладки программ в средах быстрой разработки приложений также упрощен по сравнению с обычной схемой. После компиляции программы можно посмотреть структуру ее классов с помощью окна Browse, представленного на рис.11 Это окно дает много полезной информации об иерархии классов и их структуре в данной программе.
Кроме того, можно посмотреть значения любых полей и свойств во время работы программы, если программа запущена из-под среды. Для этого используется отладчик. Функционально отладчик ничем не отличается от стандартного отладчика, который используется во всех программных продуктах фирмы Borland.
Он имеет режим пошагового выполнения с заходом или без захода в подпрограммы, возможность установки точек останова, окно просмотра значений переменных и другие функции. Гибкость, простота и удобство работы со средствами быстрой разработки приложений, объединенные с мощью языковой поддержки, позволяют сделать вывод о перспективности таких средств в будущем. Уже сейчас практически каждый месяц в средствах массовой информации появляются сообщения о появлении новых RAD–средств, и в дальнейшем такая тенденция должна сохраниться. Глава 3Организационно — экономическая часть “Расчёт затрат на разработку программы”
Расчёт затрат на разработку программы
Введение
Цель составления любых программ состоит в получении определенных результатов в процессе эксплуатации и оценивается эффективностью программного средства. Уточним применяемое далее понятие эффективности процесса разработки программного средства.
Выбор адекватных показателей эффективности программных средств зависит от их назначения, области применения, а также от ряда характеристик программ, проявляющихся при их применении. Поэтому, для выбора технических решений могут использоваться различные критерии.
Целесообразно подразумевать под эффективностью процесса разработки минимум затрат на разработку программ при заданной экономической эффективности применения и качества программных средств. Минимизация затрат на обеспечение жизненного цикла комплекта программ (далее КП) в некоторой степени эквивалентны максимизации разности эффекта и затрат, если предположить, что экономический эффект от применения программ зафиксирован и стабилен.
Затраты в жизненном цикле ПО определяются не только этапом разработки, но и этапами эксплуатации и сопровождения, причем затраты на этих этапах могут значительно превосходить затраты на этапе проектирования и разработки и характеризуются своими особыми закономерностями. Неодновременность групп затрат не учитывается, и предполагается, что абсолютная величина и влияние затрат со временем не изменяется. Обычно, критерии качества изделий используются в совокупности, с разных сторон отражающей основные характеристики функционирования объекта. Тем не менее во многих случаях доминирует экономический эффект, который наиболее прост, и обобщенно принято описывать суммарным доходом Э от использования изделия в течении его жизненного цикла продолжительностью Тж. В первом приближении это разность между полной идеальной экономической эффективностью программы Эо и суммарными потерями и затратами K , снижающими предельный доход за весь жизненный цикл:
В качестве идеальной эффективности Эо рассматривается совокупный доход, который можно получить от использования программ за весь жизненный цикл, если бы они не требовали затрат на создание, производство и эксплуатацию, а также функционировали бы на реализующих ЭВМ без потерь и искажений.
Предполагается, что при любых затратах на разработку всегда достигается заданная идеальная эффективность последующего применения ПО в процессе его эксплуатации и необходимые показатели качества функционирования. Это предположение позволяет в дальнейшем исключить из анализа эффективность применения программных средств Эо и сосредоточить внимание на эффективности процесса их разработки. Дополнительным основанием такого допущения может служить то, что многие виды программ невозможно или очень трудно характеризовать доходом от их функционирования. Тогда исследования эффективности процесса создания ПО можно проводить, минимизируя затраты K в предположении, что обеспечены заданные функциональные характеристики программ.
Снижение эффективности Э на величину K происходит прежде всего вследствие затрат на разработку, производство, сопровождение и эксплуатацию программ, а так же вследствие различных сбоев программ и оборудования.
В соответствии с этапами жизненного цикла ПО основные затраты K, снижающие идеальную эффективность за цикл жизни Тж, можно представить следующими составляющими:
- затраты на создание КП и обеспечение решения заданных задач (в том числе на документацию, технологическое обеспечение, аппаратную оснащенность разработки) — Kр;
- затраты на эксплуатацию программных и аппаратных средств ЭВМ, реализующих КП — Sэ;
- затраты на сопровождение КП, включающие затраты на хранение и контроль его состояния, проведение модификации и разработку документации, исправление ошибок и рекламу и т.д. — Kс;
- накладные расходы Kн;
в результате совокупную реальную эффективность функционирования ПО за весь жизненный цикл длительностью Тж можно представить в виде:
Составляющие затрат на разработку программ Kр
Разработка программ является областью с малой материало- и энергоемкостью, и основные затраты связаны с непосредственным или овеществленным трудом специалистов различных категорий.
Наибольшее значение в составе Ср при разработке сложных комплексов программ ( КП ) имеют следующие составляющие затрат:
- на непосредственное проектирование, программирование, отладку и испытания программ в соответствии с требованиями пользователя или заказчика — K1р;
- на изготовление опытного образца КП как продукции производственно-технического назначения — K2р;
- на разработку, подготовку и применение технологии программных средств автоматизации разработки программ — K3р;
- на технологические и реализующие ЭВМ, используемые для автоматизации разработки программ — K4р;
- на подготовку и повышение квалификации специалистов-разработчиков — K5р.
Первые две составляющие K1р и K2р являются непосредственными затратами на создание программных средств. Составляющие K3р и K4р можно рассматривать как затраты, обеспечивающие оснащенность процесса создания КП. Затраты на подготовку и повышение квалификации наиболее трудно формализовать и учитывать в конкретной разработке программных средств. В данном случае эта составляющая не учитывается.
Затраты на непосредственную разработку КП
Затраты на непосредственную разработку комплекса программ K1р являются важнейшей составляющей в жизненном цикле КП. Наибольшее влияние на них оказывает объем КП. Затраты на разработку K1р и объем программ Пк связаны через показатель интегральной средней производительности труда разработчиков Р. Для учета влияния на K1р различных факторов удобно пользоваться коэффициентами изменения трудоемкости (КИТ) — Сij, учитывающими зависимость i-ой составляющей совокупных затрат от j-го фактора. Непосредственные затраты на разработку можно представить как частное от объема КП и производительность труда, корректируемое произведением коэффициентов изменения трудоемкости:
Выделим четыре основных группы факторов, влияющих на затраты K1р при непосредственной разработке программ:
- факторы, отражающие особенности создаваемого комплекса программ как объекта разработки, и требования к его общим характеристикам;
- факторы, характеризующие технологическую и программную оснащенность средствами автоматизации процесса разработки программ;
- факторы, отражающие оснащенность процесса создания КП аппаратурными средствами, на которых базируются системы автоматизации разработки;
- факторы, определяющие оснащенность процесса разработки программ и его обеспечение квалифицированными специалистами.
Факторы объекта разработки
Диапазон изменения параметра
Среднее значение КИТ
Число операторов в тексте программ на ассемблере Пк
Источник: studizba.com
Реального времени
— факторы, отражающие особенности создаваемого комплекса программ, как объекта разработки, требования к его функциональным характеристикам и к качеству;
— факторы, определяющие организацию процесса разработки комплексов программ и его обеспечение квалифицированными специалистами;
— факторы, характеризующие технологическую среду и оснащенность инструментальными средствами автоматизации процесса разработки программ;
— факторы, отражающие оснащенность процесса создания ПС аппаратурными вычислительными средствами, на которых реализуются комплексы программ и базируются инструментальные системы автоматизации разработки.
В представленных четырех группах распределены факторы, которые наиболее важны при анализе основных затрат на проекты ПС. В эти группы включены факторы, которые могут изменять оценку производительности труда при создании ПС не менее чем на 10% в ту или иную сторону. В то же время имеющийся опыт показывает, что отсутствуют отдельные факторы или методы, способные изменять на порядок или более основные ТЭП процесса разработки программ. Большинство факторов изменяет экономические характеристики разработки программ на десятки процентов и не более чем в 1,5 раза. Для оценивания ТЭП ниже в п. 5.2— 5.4 последовательно рассмотрены и рекомендуются три методики:
— Методика 1 — экспертного технико-экономического обоснования проектов программных средств при подготовке концепции и технического задания на новый комплекс программ на основе экспертных данных разработки одной строки текста программ-прототипов;
— Методика 2 — оценка технико-экономических показателей проектов программных продуктов с учетом совокупности основных факторов предварительной модели СОСОМО II (см. Boehm B.W. et al. Software cost estimation with СОСОМО II. Prentice Hall PTR. New Jersey. 2000);
— Методика 3 — уточненная оценка технико-экономических показателей проектов программных продуктов с учетом полной совокупности факторов детальной модели СОСОМО II.2000 (там же).
В качестве основных критериев выбора методик прогнозирования ТЭП разработки ПС целесообразно учитывать возможность их использования как на начальных, так и на более поздних этапах разработки. Для практического применения модели СОСОМО II опубликован пакет прикладных программ и руководство по его применению. Оно иллюстрировано формами экранов и несколькими обширными практическими примерами применения для технико-экономического анализа конкретных проектов сложных комплексов программ.
Важнейшим фактором при технико-экономическом обосновании, определяющим создание программных средств, являются люди — специалисты, с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Быстрый рост сложности и повышение ответственности за качество комплексов программ привели к появлению новых требований к специалистам, обеспечивающим все этапы жизненного цикла ПС. При проектировании ПС различных классов разделение труда специалистов по квалификации при разработке программ и данных, организация коллективов и экономика таких разработок стали важнейшей частью выбора, обучения и подготовки специалистов для обеспечения всего ЖЦ ПС (см. лекцию 9).
В детальной модели СОСОМО значительное внимание уделено влиянию организации и взаимодействия коллектива разработчиков на трудоемкость создания сложных программных средств. В составе организационных характеристик коллектива рекомендуется учитывать согласованность целей специалистов, участвующих в проекте, их психологическую совместимость и способность к дружной коллективной работе, наличие опыта работы в данном коллективе и другие объективные и субъективные свойства участников проекта.
При этом большое значение могут иметь личная мотивация и психологические особенности поведения разных специалистов при комплексной работе над сложным проектом. Эти характеристики могут быть обобщены в качественный показатель влияния сложности взаимодействия специалистов в коллективе, которому сопоставлены коэффициенты изменения трудоемкости разработки ПС. Наилучшим считается продолжительное корректное взаимодействие организованных специалистов с большим опытом работы в данном коллективе при полной согласованности их целей, планов и методов работы. При разработке программ большими коллективами значительно повышается роль квалификации руководителей разработки, что непосредственно отражается на средней производительности труда всего коллектива. Однако формализовать и учесть влияние руководителя разработки и ведущих специалистов на затраты и ТЭП комплекса программ пока трудно.
Уровень квалификации заказчика и определенность технического задания на разработку ПС может весьма сильно влиять на суммарные затраты и длительность создания программ. Изменения технического задания и объем переделок непосредственно отражаются на средней производительности труда специалистов, рассчитанной по конечному размеру созданного комплекса программ. Особенно сильно на достоверность технического задания и возрастание затрат влияет попытка заказчика форсировать сроки разработки. При этом первоначальное техническое задание оказывается недостаточно квалифицированным и подвергается в дальнейшем многократным изменениям. Этому же может способствовать различие между заказчиком и разработчиком в квалификации, уровне понимания целей разработки и необходимых затрат на реализацию дополнительных требований.
При проектировании и создании высококачественных комплексов программ, прежде всего, необходимы организация и тесное взаимодействие представителей заказчика и разработчиков проекта. Взгляды и требования заказчика в основном отражаются в функциональных и потребительских характеристиках ПС. Устремления разработчиков направлены на возможность и способы их реализации с требуемым качеством. Эти различия исходных точек зрения на проект приводят к тому, что некоторые неформализованные представления тех и других имеют зоны неоднозначности и взаимного непонимания, что может приводить к конфликтам.
Затраты и труд специалистов при реализации крупномасштабного проекта ПС можно распределить по двум категориям специалистов, разрабатывающим компоненты и ПС в целом и обеспечивающим технологию и качество программного продукта (см. лекцию 9). Организационное разделение специалистов, осуществляющих разработку ПС (первая категория), и специалистов, контролирующих и управляющих его качеством в процессе разработки и всего ЖЦ (вторая категория), должно обеспечивать эффективное достижение заданных характеристик, а также независимый, достоверный контроль затрат и качества результатов разработки.
Затраты на технологию и инструментальные программные средства автоматизации разработки ПС обычно являются весьма весомыми при использовании высокоэффективных автоматизированных технологий. При технико-экономическом обосновании проекта следует учитывать, что размер и сложность создаваемого ПС значительно влияют на выбор инструментальных средств и уровня автоматизации технологии, а также на долю этих затрат в общих затратах на разработку.
Встречаются ситуации, при которых затраты на технологию достигают 30—50% общих затрат на разработку. Такие затраты могут быть оправданы повышением производительности труда, сокращением сроков разработки и последующим снижением затрат на множество базовых версий ПС. Однако чаще всего эта группа затрат при создании первой версии сложных ПС находится в пределах 30% от суммарных затрат. В первом приближении степень автоматизации разработки программ отражает размер программных средств, используемых в технологических системах. Этот показатель соответствует сложности систем автоматизации разработки программ и пропорционален затратам на их приобретение (или создание) и эксплуатацию.
Стремление уменьшить технологические затраты в период разработки без учета последующего использования ПС, его компонентов и всего жизненного цикла может оказаться мало полезным, а в некоторых случаях привести к значительному увеличению совокупных затрат в ЖЦ. При применении сложных ПС эти затраты исчисляются сотнями человеко-лет, что определяет особую актуальность их снижения. Поэтому необходим системный анализ распределения и использования технологических ресурсов на разработку программ с учетом всего их жизненного цикла, включая сопровождение и возможный перенос на другие платформы.
Уровень автоматизации и качество технологии и инструментальных средству используемых для поддержки всего жизненного цикла ПС, обычно сильно коррелирован с достигаемым качеством комплексов программ, а также с качеством средств автоматизации для оценивания этого качества. Поэтому определение уровня зрелости технологической поддержки процессов жизненного цикла, организационного и инструментального обеспечения качества ПС, непосредственно связано с выбором и оцениванием реальных или возможных характеристик качества конкретного комплекса программ.
В модели СОСОМО для оценивания технико-экономических показателей при разработке ПС рекомендуется методология сложных программных средств СММ — система и модель оценки зрелости комплекса, применяемых технологических процессов жизненного цикла ПС (см. лекцию 3). Эти уровни зрелости характеризуются степенью формализации, адекватностью измерения и документирования процессов и продуктов ЖЦ ПС, широтой применения стандартов и инструментальных средств автоматизации работ, наличием и полнотой реализации функций системой обеспечения качества технологических процессов и их результатов. В модели СОСОМО приводятся количественные рекомендации коэффициентов влияния уровней зрелости СММ на трудоемкость реализации сложных проектов ПС. Влиянию технологической зрелости разработки ПС в детальной модели СОСОМО сопоставлены уровни СММ, для каждого из которых приводятся коэффициенты изменения трудоемкости разработки.
Для приближенной оценки влияния на трудоемкость некоторых характеристик процессов разработки ПС в детальной модели СОСОМО выделены небольшая группа показателей и соответствующие им наборы рейтингов. Инструментальные системы, поддерживающие разработку, описаны качественными характеристиками и рейтингами, изменяющими трудоемкость в пределах приблизительно 20% от средней — номинальной. Уровень технологии и комплекса инструментальных средств особенно сильно влияет на ТЭП крупных проектов ПС. Поэтому затраты на их реализацию и применение целесообразно учитывать конкретно с использованием функций и характеристик проекта.
В модели и таблицах отмечено значительное влияние на трудоемкость ПС директивного ограничения сроков разработки относительно типовых — номинальных. При ограничении сроков сокращению трудоемкости может сопутствовать значительное снижение качества ПС и увеличение рисков реализации проекта. Для уменьшения сроков разработки есть ряд путей, с помощью которых руководство может добиваться некоторого ускорения разработки за счет увеличения трудоемкости и стоимости проекта, для чего рекомендуется:
— обеспечить детальные структурирование комплекса программ на модули и спецификации интерфейса для обеспечения максимального параллелизма работы специалистов;
— приобрести и освоить технологические, инструментальные средства для более быстрого кодирования, контроля и тестирования и обучить разработчиков их использованию;
— обеспечить дополнительную подготовку программистов и группы тестирования к работе в тематической области функций проекта;
— привлечь дополнительный вспомогательный персонал;
— отложить на время несущественное документирование проекта.
Тем не менее есть предел сокращению сроков разработки с помощью увеличения числа специалистов и приобретения оборудования. При максимально возможном сокращении сроков разработки до 75% от оптимального затраты возрастают на 25%.
При разработке комплексов программ систем реального времени большие затраты могут потребоваться для обеспечения тестирования и испытаний ПС, которые непосредственно не учитываются моделью СОСОМО. Основные усилия сосредоточивались на процессах программирования и автономной отладки компонентов. На этих этапах выявлялась основная масса дефектов и ошибок, хотя при использовании ПС и сопровождении обнаруживалось некоторое их количество. В последнее время центр тяжести разработки сложных ПС сдвинулся к начальным этапам и внимание акцентировано на предотвращение ошибок, прежде всего путем тщательного системного проектирования ПС из готовых программных компонентов, а также на комплексной отладке и испытаниях в реальном времени.
Этапы комплексной отладки, испытаний и модификации программ имеют много общего, в основе которого лежит широкое применение их тестирования для обнаружения ошибок и удостоверения функциональной корректности ПС. Разработка детерминированных тестов при отладке модулей и некоторых групп программ в большинстве случаев производится вручную. Однако их доля может составлять заметную часть общих затрат на отладку компонентов. Достаточно автономными и локализуемыми обычно являются затраты на стохастические тесты и тесты в реальном времени, используемые при комплексной отладке и испытаниях (см. лекцию 14).
При технико-экономическом обосновании проектов комплексов программ на оценку трудоемкости их разработки может оказать существенное влияние ограниченность вычислительных ресурсов специализированных, реализующих ЭВМ реального времени. Это привело к необходимости разрабатывать методы эффективного использования аппаратных ресурсов ЭВМ. Одним из важнейших и наиболее общих показателей, характеризующих возможность применения таких ЭВМ, является их производительность для конкретных задач реального времени. При этом существенным ограничивающим фактором являются длительность, в течение которой ЭВМ может быть предоставлена для решения данной задачи, или то реальное время, в пределах которого целесообразно получить результаты для их практического использования. При ограничениях ресурсов вследствие требований минимизации весов и габаритов специализированных, реализующих ЭВМ в авиационных, ракетных и космических системах, их экономное использование остается актуальным и его следует учитывать при обосновании соответствующих проектов ПС.
Быстрый рост в мире масштабов — размеров комплексов программ и баз данных, решающих единую целевую задачу, потребовал создания новых, более эффективных методов разработки сложных систем. Возникла проблема разработки функционально законченных ПС и БД и их компонентов, потенциально готовых к многократному применению в различной внешней и операционной среде, а также в различных сочетаниях их взаимодействия. Унификация всегда требует некоторых ресурсов, которые в данном случае выражаются в дополнительной трудоемкости создания повторно используемых программ и данных, а также в увеличении необходимой памяти и производительности ЭВМ для их реализации. Сохранение и развитие довольно широкого спектра архитектур ЭВМ, естественно, привело к повторному использованию компонентов (ПИК) не только на однотипных платформах, но и к разработке ПС и БД, переносимых на различные аппаратные и операционные платформы. При этом выделились две технологические проблемы:
— создание программных компонентов и баз данных, которые рентабельно повторно применять и/или переносить на различные операционные и аппаратные платформы;
— проблема реализации повторного использования и/или переноса ПС и БД для создания из них новых систем на иных платформах.
Увеличение затрат при решении первой проблемы должно компенсироваться сокращением затрат при создании комплексов программ и баз данных на базе готовых компонентов. Освоение методов и средств решения этих проблем позволило качественно изменить процессы создания сложных комплексов программ и резко повысить производительность труда специалистов при их разработке. Это активизировало в последние годы интерес к проблеме мобильности программ и данных во всех отраслях применения вычислительной техники. Создание новых ПС и БД путем переноса их с других аппаратных и операционных платформ стало особенно актуальным для современных административных систем государственного и регионального управления, управления отраслями и предприятиями, а также банковскими системами и в социальной сфере.
На практике при создании нового ПС не всегда имеется полный набор готовых, и пригодных для применения программных компонентов. Тогда при сборке версии ПС может потребоваться доработка отдельных компонентов, их сопряжение в новых сочетаниях и создание новых программ для решения дополнительных задач.
Поэтому целесообразно оценивать трудоемкость сборочного программирования с учетом частичных затрат на новые компоненты. Относительное снижение трудоемкости разработки в первом приближении пропорционально доле готовых ПИК. В пределе при создании базовой версии ПС полностью из многократно применяемых готовых компонентов трудоемкость может сократиться в 3—5 раз. В промежуточных случаях, когда готовые компоненты используются частично, оценку изменения трудоемкости можно провести по степени сокращения затрат на программирование и автономную отладку всех необходимых компонентов.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru