Экономическая модель разработки ПО

LOC оценка представляет собой наиболее универсальную метрику, поскольку может использоваться при создании любых программных продуктов. Она проще и понятнее как для специалистов, так и для заказчиков и инвесторов. Например, если утверждается, что один компонент программной системы, состоящей из n компонентов, в среднем потребует написания около 1000 строк программного кода, то каждый в состоянии прикинуть ее общий размер и хотя бы примерно оценить трудозатраты, требующиеся для ее создания, исходя из предположения, что средняя производительность одного программиста по-прежнему составляет около 3000 строк кода в год.

Однако многие эксперты в области разработки программного обеспечения утверждают, что это плохая единица измерения. Наиболее существенный вопрос, который возникает при использовании LOC оценок, заключается в том, что же собой представляет одна строка программного кода? Кроме того, при использовании LOC в качестве единицы измерения возникают сомнения в достоверности результатов, так как не учитывается следующее:

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

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

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

· в программистском сообществе не достигнуто соглашения о методе подсчета строк кода. Языковые конструкции, используемые, например, в Visual C++, Ассемблере, Коболе или SQL, абсолютно различны. Метод же остается общим для любых приложений, в том числе использующих комбинацию различных языков;

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

В то же время для повышения достоверности оценок есть несколько достаточно простых рекомендаций:

· Убедитесь, что каждая учитываемая строка исходного кода содержит лишь один оператор. Если в одной строке содержатся два выполняемых оператора, разделенных точкой с запятой, то они должны учитываться как две строки. Если же один оператор разбит на несколько «физических» строк, он будет учитываться как одна строка. В языках программирования допускаются различные правила кодирования, но обычно проще определять в строке один оператор, обрабатываемый компилятором или интерпретатором.

· Учитывайте все выполняемые операторы. Конечный пользователь может не иметь возможности практически использовать каждый оператор, но все операторы должны поддерживаться данным продуктом, в том числе и утилитами.

· Определения данных учитывайте лишь один раз.

· Не учитывайте строки, содержащие комментарии.

· Не учитывайте отладочный код либо другой временный код (пробное ПО, средства тестирования и пр.).

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

На практике при оценке размера больших программных систем чаще пользуются показателем тысяч строк исходного кода KSLOC. Эта метрика чаще всего используется при оценках производительности, которая рассчитывается как KSLOC/SM, где SM - staff-month (человеко-месяцы).

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

Если предположить, что структура WBS для разрабатываемого программного средства разбита на несколько уровней декомпозиции, которые позволяют выделить фактические компоненты программной системы, а также дают основания для дальнейшей детализации, то возможно создание некоторого «статистического» показателя размера, который может быть получен с использованием процессов измерения и суммирования.

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

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

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

Например, если некоторый объект, отображенный на структуре WBS, может занимать от 200 до 400 строк кода и скорее всего его размер ближе к 200, то используя предложенный подход можно получить следующую оценку:

(200+(250*4)+400)/6 = 266 LOC

Оценка количества LOC по аналогии

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

Преимущества использования LOC в качестве единицы измерения

· Эти единицы широко распространены и могут адаптироваться.

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

· Непосредственно связаны с конечным продуктом.

· Единицы LOC могут быть оценены еще до завершения проекта.

· Оценка размеров ПО производится с учетом точки зрения разработчиков.

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

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

Недостатки, связанные с применением LOC - оценок

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

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

· Применение методов оценки с помощью количества строк не регламентируется промышленными стандартами, например ISO.

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

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

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

· Показатели LOC не могут осуществляться при нормализации в случае, если использовались разные платформы или типы языков программирования.

· Единственным способом получения LOC - оценки является сравнение с аналогичными разработками или экспертные мнения, а эти оценки изначально не относятся к числу точных.

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

Часто производительность труда программистов оценивается по числу производимых строк кода, а это не всегда верно. Если программист вместо 200 строк в месяц напишет 250, то это не значит, что он точно стал лучше работать и заслуживает поощрения. Более правильно было бы учитывать не только количество написанного кода, но и его качество, что можно сделать с помощью применения следующей формулы:

Количество дефектов / количество строк кода

Фаза кодирования в большинстве проектов занимает от 7% до 20% трудозатрат, поэтому более важным является качество кода, а не его объем.

Использование функциональных точек в качестве единиц измерения размера программ

Первой и наиболее удачной альтернативой методу подсчета исходных строк кода стала разработанная в 1979 году Алланом Альбрехтом из IBМ методология, названная «Анализ показателей функциональности» (FPA, от Function Points Analysis). В ее основе лежит взгляд на ПС извне, с позиций пользователя системы, а не «со стороны» ее внутренних свойств (таких, как LOC). В результате анализа исходных требований к ПС и выяснения реальных потребностей пользователей определяется объем функциональных возможностей системы, показателями которых служат функции обработки информации настолько низкого уровня, насколько они укладываются в систему мышления пользователей, а кроме функций - данные, которые эти функции обрабатывают. Таким образом, методология FPA базируется на идее декомпозиции функций и данных до предельно допустимого (с точки зрения пользователя) уровня. Объем функциональных возможностей ПС (далее просто функциональный размер) определяется в так называемых условных единицах функциональности FP - от Function Points.

В течение пяти лет с момента появления, методология FPA и метод расчета размера отшлифовывались А. Альбрехтом и проходили практическую апробацию, а в середине 80-х годов была создана Международная группа пользователей показателей функциональности (IFPUG, от International Function Points User Group), которая и поддерживает дальнейшую эволюцию метода.

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

· Оценивать категории пользовательских бизнес-функций.

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

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

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

1.Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.

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

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

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

5.Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

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

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

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

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

Примеры информационных характеристик приведены в таблице 1

Табл.1. Примеры информационных характеристик

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

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

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

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

Ранги и оценки уровня сложности для различных информационных элементов приведены в таблицах 3 - 7.

Табл. 3. Ранг и оценка сложности внешних вводов

Табл. 4. Ранг и оценка сложности внешних выводов

Табл. 5. Ранг и оценка сложности внешних запросов

Табл. 6. Ранг и оценка сложности внутренних логических файлов

Табл. 7. Ранг и оценка сложности внешних интерфейсных файлов

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

· Подсчитываются функции для каждой категории (вводы, выводы, запросы, структуры данных, интерфейсы).

· Устанавливаются требования для каждой категории.

· Определяется сложность каждой функции (высокая, средняя, низкая).

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

Исходные данные для расчета сводятся в табл. 8.

Табл. 8. Исходные данные для расчета FP-метрик

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

FP = Общее количество * (0,65+ 0,01 *), (2.1)

где F_i -- коэффициенты регулировки сложности.

Каждый коэффициент может принимать следующие значения: 0 -- нет влияния, 1 -- случайное, 2 -- небольшое, 3 -- среднее, 4 -- важное, 5 -- основное.

Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл. 9).

Табл. 9. Определение системных параметров приложения

Производится преобразование функциональных точек в единицы LOC с помощью таблицы 10.

Табл. 10. Пересчет FP-оценок в LOC-оценки

Экономическая модель разработки ПО

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

Трудоемкость = (Персонал)(Среда)(Качество)(Размер ^{Процесс}), где

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

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

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

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

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

Оценка затрат на разработку ПО

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

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

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

Оценка затрат на разработку ПО предполагает выполнение следующих четырех шагов:

1. оценка размера разрабатываемого продукта;

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

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

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

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

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

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

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

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

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

2. Если предыдущий подход по разным причинам оказывается неприменимым, следует использовать один из известных алгоритмических методов оценивания (например, модель СОСОМО или метод функциональных точек).

Подобным же образом (как на основе исторических данных, так и с использованием формальных методик) оцениваются продолжительность и стоимость проекта.

Модель оценки стоимости СОСОМО

На сегодняшний день для оценки стоимости ПО используется несколько различных моделей. Одной из самых популярных, открытых и хорошо документированных моделей оценки стоимости ПО является СОСОМО (COnstructive COst MOdel -- конструктивная модель стоимости), разработанная Барри Боэмом. Эволюция СОСОМО отражает то, каким образом эволюционировала экономика ПО последние 30 лет.

Оценочные уравнения СОСОМО имеют следующую форму:

Работа = С1* EAF *(Размер)^р1

Время = С2*(Работа)^р2

где Работа -- количество человеко-месяцев;

С1 -- масштабирующий коэффициент;

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

Размер -- размер конечного продукта (кода, созданного человеком), измеряемый в исходных инструкциях (DSI, delivered source instructions), которые необходимы для реализации требуемой функциональной возможности;

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

Время -- общее количество месяцев;

С2 -- масштабирующий коэффициент для сроков исполнения;

Р2 -- показатель степени, который характеризует инерцию и распараллеливание, присущие управлению разработкой ПО.

Исходная модель СОСОМО

Исходная модель СОСОМО [Boehm, 1981] явилась прорывом в разработке ПО в начале 1980-х гг. -- частично из-за присущей ей технологической составляющей, но прежде всего потому, что она представляла собой четко определенную схему взаимодействия для достижения соглашений и установки приоритетов, касающихся управления ценой и сроками создания ПО. Модель используется в том случае, когда проект требует большого объема программирования и необходимо спланировать и обосновать оценки стоимости и сроков создания ПО. Огромным преимуществом модели СОСОМО является то, что она позволяет получать оценку, подводить под нее заслуживающее доверия основание, судить о ее сильных и слабых сторонах и вести переговоры с заинтересованными сторонами.

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

Формулы для оценки основных работ и сроков

Исходные соотношения для оценки стоимости в модели СОСОМО имели следующий вид:

Обычный вариант

Работа = 3,2*ЕАF*(Размер)^1,05

Время (в месяцах) = 2,5*(Работа)^0,38

Промежуточный вариант

Работа = 3,0* ЕАF *(Размер)^1,12

Время (в месяцах) = 2,5*(Работа)^0,35

Встроенный вариант

Работа = 2,8* ЕАF *(Размер)^1,2

Время (в месяцах) = 2,5*(Работа)^0,32,

где Работа -- количество человеко-месяцев;

EAF -- результат учета 15 уточняющих факторов;

Размер -- число исходных инструкций конечного продукта (измеряемое в тысячах строк кода).

Множитель, который является уточняющим фактором работ (effort adjustment factor, EAF), представляет собой комбинацию многих параметров. Эти параметры позволяют характеризовать и нормировать проекты относительно проектов, находящихся в базе данных СОСОМО. Значения параметров приведены в таблице 3. Каждый параметр оценивается как очень низкий, низкий, номинальный, высокий или очень высокий. Влияние значения каждого параметра определяется как множитель, который обычно изменяется в диапазоне от 0.5 до 1.5. Результат учета этих 15-ти параметров и используется в качестве коэффициента в уравнении стоимости.

Допущения

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

Табл. 7.11. Значение драйверов затрат в модели COCOMO

Описание жизненного цикла в модели СОСОМО

Жизненный цикл в модели СОСОМО состоит из пяти основных стадий: планирование и определение требований, проектирование продукта, детальное проектирование, кодирование и тестирование отдельных модулей, интеграция и тестирование. Модель СОСОМО дает рекомендации по распределению работ и времени по основным стадиям традиционной «водопадной» модели. Эти рекомендации в некоторой степени зависят от варианта и масштаба; в таблице 7.12 приводится стандартное распределение для большого встроенного проекта. Модель СОСОМО позволяет оценить работу и время, необходимые для получения решения (разработки продукта с помощью итераций и тестирования). Затраты на формулировку проблемы (планирование и определение требований) оцениваются в виде дополнительного процента от и сверх работы и времени, затрачиваемых на разработку.

Табл. 7.12. Распределение работ и времени по стадиям жизненного цикла при традиционном походе

Декомпозиция работ по созданию ПО

Основной задачей при планировании проекта является определение WBS-Work Breakdown Structure (структуры распределения работ). Декомпозиция работ при традиционном подходе обычно строится вокруг подсистем продукта на более высоких уровнях и вокруг подробного плана работ на более низких. К стандартным видам деятельности, оцениваемым по модели СОСОМО и включаемым в WBS по созданию ПО, относятся: анализ требований, проектирование продукта, программирование, планирование тестирования, верификация и аттестация, канцелярские функции проекта (управление и администрирование), управление конфигурацией, обеспечение качества и создание руководств. Модель СОСОМО также рекомендует самый верхний уровень распределения работ по различным видам деятельности WBS. Еще раз обращаем внимание на то, что эти значения зависят от варианта и масштаба. В таблице 7.13 показаны примерные ожидаемые затраты на каждый вид деятельности WBS для большого проекта (вариант встроенного ПО). Важное предостережение: в модели СОСОМО вид деятельности, называемый «программированием», включает в себя детальное проектирование, кодирование, тестирование модулей и интеграцию.

Таблица 7.13. Стандартное распределение работ по видам деятельности WBS в модели СОСОМО

Подобные документы

• Разработка программного продукта

  Подсчет количества функциональных точек. Расчет трудозатрат на разработку программного средства и ориентировочного времени его разработки, модель жизненного цикла. Разработка технического задания на создание автоматизированной системы, требования к ней.
  
  курсовая работа [2,0 M], добавлен 11.01.2014
  

• Выполнение оценки в ходе руководства проектом разработки программного обеспечения концерна "Суперавто"

  Модель этапа пост-архитектуры. Предварительная оценка программного проекта на основе LOC-метрик. Расчет затрат на разработку ПО. Стоимость, длительность разработки проекта на основе модели этапа пост-архитектуры конструктивной модели стоимости СОСОМО II.
  
  курсовая работа [89,9 K], добавлен 29.09.2009
  

• Модели жизненного цикла программного обеспечения

  Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.
  
  презентация [874,4 K], добавлен 19.09.2016
  

• Модели жизненного цикла разработки программного обеспечения

  Общая характеристика основных моделей жизненного цикла: каскадная, инкрементная, спиральная. Стадия как часть процесса создания программного обеспечения, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта.
  
  презентация [159,1 K], добавлен 27.12.2013
  

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

  Характеристика программного продукта и стадий разработки. Расчет затрат на разработку и договорной цены, эксплуатационных расходов, связанных с использованием нового программного продукта. Оценка конкурентоспособности. Изучение, оценка рыночного спроса.
  
  курсовая работа [139,0 K], добавлен 22.09.2008
  

• Моделирование при разработке программного обеспечения

  Понятие технологии разработки программного обеспечения и модели жизненного цикла. Сущность объектно-ориентированного подхода. Строительные блоки, общие механизмы языка моделирования UML, диаграммы классов, состояний, взаимодействий и компонентов.
  
  курсовая работа [262,5 K], добавлен 10.07.2014
  

• Модели жизненного цикла программного обеспечения

  Понятие и этапы жизненного цикла программного обеспечения как некоторых событий, которые происходят с системой компьютера в процессе ее создания, внедрения и сопровождения. Модели данного процесса: каскадная, спиральная, их отличительные особенности.
  
  доклад [33,5 K], добавлен 06.04.2015
  

• Качественное программное обеспечение и пути его достижения. Стандарты качества программного обеспечения. Современные модели качества программного обеспечения

  Схемы взаимодействия между заказчиком и разработчиком программного обеспечения. Качество программного обеспечения и определение основных критериев его оценка на современном этапе, особенности управления на стадиях жизненного цикла, анализ достаточности.
  
  презентация [114,7 K], добавлен 14.08.2013
  

• Разработка инструментария для расчета трудоемкости и стоимости разработки программного продукта по методике CETIN

  Обзор и анализ существующих методик управления проектами и оценки трудоемкости. Разработка алгоритма задания параметров и вычисления трудоемкости и стоимости программного продукта. Отладка и тестирование продукта. Разработка руководства пользователя.
  
  дипломная работа [2,5 M], добавлен 18.11.2017
  

• Объектно-ориентированная технология разработки программного обеспечения будильника

  Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
  
  курсовая работа [355,8 K], добавлен 26.09.2014
  

• Использование модели проектирования программного обеспечения "Библиотечный фонд Николаевской библиотеки им. Шуры Кобера и Вити Хоменко"

  Общий календарный план выполнения этапов проекта программного обеспечения. Последовательность разработки согласно классической каскадной модели. Изображение хода работ по спиральной модели согласно Боему. Технические требования на продукт, WBS-структура.
  
  лабораторная работа [614,1 K], добавлен 17.01.2014
  

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

  Краткая характеристика программного средства и стадии ее разработки, предъявляемые требования и функциональные особенности. Определение трудоемкости и состава группы исполнителей. Вычисление затрат на разработку программного продукта и договорной цены.
  
  курсовая работа [464,5 K], добавлен 05.02.2016
  

• Жизненный цикл программы

  Понятие технологии разработки программы. Основа проектирования программного обеспечения. Модели жизненного цикла, возникшие исторически в ходе развития теории проектирования программного обеспечения. Спиральная (spiral), каскадная и итерационная модели.
  
  презентация [1,0 M], добавлен 11.05.2015
  

• Модели жизненного цикла автоматизированных информационных систем

  Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.
  
  курсовая работа [1,8 M], добавлен 20.11.2010
  

• Разработка программного продукта Delphi для моделирования логнормального распределения

  Создание программного продукта, представляющего моделирование на компьютере логнормального распределения, определение вероятностной оценки стоимости актива. Описание работы программного продукта. Работа с графиками, таблицами, математическими функциями.
  
  курсовая работа [742,7 K], добавлен 08.01.2009
  

• Разработка программных модулей программного обеспечения для компьютерных систем

  Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
  
  отчет по практике [296,1 K], добавлен 19.04.2015
  

• Разработка электронного сайта для фирмы

  Характеристика программных средств, использованных при разработке сайта. Параметры аппаратных средств для демонстрации ПП. Особенности архитектуры программного обеспечения. Анализ модели жизненного цикла программного продукта. Построение Gant-диаграммы.
  
  курсовая работа [886,9 K], добавлен 30.05.2015
  

• ИТ-индустриия и разработка ПО

  Экономическая роль индустрии информационных технологий. Методы оценки трудозатрат на разработку программного обеспечения. Модель Путнэма жизненного цикла ПО. Принципы, которыми нужно пользоваться при оценке трудозатрат проекта. Роль ИТ-индустрии в мире.
  
  курсовая работа [91,0 K], добавлен 02.12.2012
  

• Драйвер клавиатуры, реализующий функции музыкального синтезатора на клавиатуре для Windows NT 5

  Архитектура Windows NT 5. Приоритеты выполнения программного кода. Описание формата MIDI-данных. Установка драйвера в системе. Выбор средств разработки программного обеспечения. Обработка запросов драйверной модели WDM. Использование библиотеки DirectKS.
  
  курсовая работа [498,8 K], добавлен 24.06.2009
  

• Разработка подсистемы прогнозирования трудоемкости и стоимости создания программного продукта по методике CETIN

  Архитектура программного продукта и требования к платформе, обоснование выбора разработки. Закономерности и основные этапы алгоритмизации и программирования, а также отладка и тестирование продукта. Разработка и содержание руководства пользователя.
  
  дипломная работа [2,3 M], добавлен 19.01.2017
  

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