Программное обеспечение

А

Б

В

Кн

1¸ 1,75

1¸ 0,8

0,7

Кт

Степень применения типовых практических решений

0,6

>60%

0,7

40–60%

0,8

20–40%

0,9

С4р). При определении затрат машинного времени исходят из нормативной для данного объекта велечины обеспечения одного раработчика машинным временем 2¸ 6 часов в сутки на одного работника (в среднем 4 часа).

Нормативная величина, как правило сопровождается затратами времени при типовых нагрузках на разработчика (этап ???). Для остальных периодов используются законы распределения машинного времени.

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

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

(Пример для задач БУ)

Далее эта норма уточняется в связи с новизной, сложностью, применением языков программирования (0,69¸ 1,58).

С1р+С3р+С4р, С1з–>Ср1–>С2р С5р С6р, С2р–>Ср

Затраты на эксплуатацию

С = Ср + Сэ +Сс

Сэ = С1э + С2э +С3э, где

С1э – затраты на непосредственно эксплуатацию ПИ;

С2э – потери эффективности функционирования ПИ вследствие задержки и потерь информации, подлежащей обработке;

С3э – потери эффективности функционирования ПИ, возникшие из–за сбоя или ошибок в работе программы.

С2э, С3э – зависит от потребительских свойств информации, обрабатываемой ПИ. Если удается установить связь между эффектом, полученным от решения задачи в в тех случаях когда это решение происходит вовремя и недополучения эффекта (а может быть штрафом или явно выраженными потерями) при задержке решения на определенное время, то разность между этими двумя величинами может составить сумму С2э и С3э.

С1э

Lмtм + Lмtп+ЗП+(ЗП)/Кз, где

Lм – затраты машинного времени (стоимость единицы машинного времени);

tм – время затраченное на решение задачи;

tп – затраты машинного времени, необходимого для поддержания программм в работоспособном состоянии.

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

Сс – затраты по сопровождению.

Сс = С1с+С2с+С3с

С1с – затраты на обнаружение и исправление программных ошибок в процессе сопровождения;

С2с – затраты на доработку и совершенствование программы (модификацию);

С3с – затарты на тиражирование и внедрение новых версий.

С1с=L1с*Пк*tc/n0, где

L1с – нормированная величина трудоемкости исправления ошибок;

Пк – объем производственного комплекса;

tс – время сопровождения;

n0 – количество ошибок.

, где

L2с – коэффициент учитывающий повышение трудоемкости работ, связанных с внесением изменений в программу (изменяется от 1 до 3);

Ср – затраты на разработку;

Pi – доля программного в комлекса переработанного при подготовке новой версии.

С3с измеряется в % от С2с.

Затраты по ЖЦПИ нужны, когда:

Оценивается эффективность (качество) создаваемого ПИ;

Определяется цена.

Показатели эффективности и качества ПИ.

Оценка потребителя для выбора ПИ;

Оценка эффективности ПИ.

Выделяют два вида показателей :

обобщенный;

часный.

(1) – хорош с точки зрения оценки результатов ПИ (в эксплуатации).

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

Обобщенные поазатели.

Должны иметь стоимостной характер.

Э = В – С

Э – эффект;

В – суммарная выгода, экономия от эксплуатации ПИ;

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

Где индекс б – относится к базовому варианту, а п – к предлагаемому.

С – текущие затраты на эксплуатацию ПИ сопоставления вариантов.

К – единовременные затраты на сопоставление вариантов.

Различают виды эффекта:

предварительный (определенный до начала разработки или на предпроектной стадии);

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

гарантированный (связан с одним конкретным потребителем);

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

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

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

При выборе базового варианта следует:

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

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

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

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

Возможна классификаци характеристик качества ПИ по различным направлениям:

Оценка надежности создаваемого изделия.

Защита от ошибок в работе ПИ;

обеспечение возможности ПИ сохранения информации в случае потери какой–либо части хранимых данных (например хранение копий);

обеспечение защиты от несанкционированного доступа.

Модифицируемость ПИ (модернизированность).

наличие ресурсов, которые позволяют разрабатывать новые версии при изменении условий эксплуатации;

мобильность (портативность, переносимость) – возможность ПИ к адаптации при переносе его на новый объект;

отношение изменения объема при переносе программного текста к общему объему программного текста.

Эффективность использования ресурсов.

Качество документирования сведения об ошибках :

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

обучающие версии программ, их представление;

наличие автоматизированной системы обучения;

наличие инструкций в эксплуатационной документации.

Доступность (легкость освоения). Требования к квалификации пользователя.

Корректность (степень адекватности реализованных в ППП методов требованиям предметной области).

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

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

Пример:

Ä - 7¸ 10; Æ - 5¸ 6,9; Å - 0,8 ближе к 1.

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

а) специалисты разработки (службы разработки);

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

в) специалисты по испытанию изделий. Соответствие результатов разработки ТЗ. (Сами работы по испытаниям требуют других навыков);

Работы по испытанию могут переходить в работы по сертификации (исследование чужого программного продукта с целью предоставления сертификата). Для этого необходимо выработать стандарты и выпустить документ с требованиями стандарта.

г) Работы по подготовке и выпуску документации. Документация в большей степени поддается стандартизации, чем работы по программированию. Желательна разработка стандартов в рамках отрасли …

д) Специалисты по поддержке ПИ. Изучение требований потребителей, реклама, консультации, обучение, установка ПИ у пользователей.

е) Специалисты по сопровождению. Получает сведения об ошибках, пожеланиях, исправляет ошибка или ведет доработку ПИ.

ж) Специалисты технологического профиля.

В крупных специализированных организациях соотношение объемов работ разработки, испытаний, документирования (в чел.):

10 – 3 – 2

Во временных организациях:

10 – 5 – 3

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

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

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

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

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

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

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

Определяют последовательность разработки продуктов;

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

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

Оценка потребности в ресурсах для выполнения работ и распределение имеющихся ресурсов по исполнителям;

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

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

Эти работы могут выполнятся в двух разрезах:

тематический;

организационно-временной.

В (1) все планы связаны с конкретным ПИ. Указываются все исполнители, ресурсы необходимые для разработки этого конкретного изделия (горизонтальный разрез матрицы ((*) см. выше).

ТЕМА … ППП …

ИНФОРМАЦИЯ ПО ТЕМЕ (руководитель, сроки, ресурсы …)

Во (2) случае все сведения приводятся по отдельному исполнителю (вертикальный разрез).

ИСПОЛНИТЕЛЬ (бригада, человек)

ПЛАН ПЕРИОД

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

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

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

t - время, затраченное с начала разработки;

ta - момент появления изделия в состоянии операционной готовности (может функционировать как единое целое)

К - объем ресурсов, выделяемых на разработку.

Если значение а брать достаточно большим и наклон кривой на участке 0-ta становится большим (крутым), то руководство разработкой усложняется. Руководитель не всегда может достаточно эффективно загрузить исполнителей работой. Это вызвано тем, что не все работы можно выполнять параллельно. Помимо функционально сложности разработки можно ввести понятие организационной сложности (оно вытекает из вопросов руководства).

(**) , где чем меньше значение t0, тем проще разработка.

Анализ эмпирической зависимости позволяет вывести соотношение связывающее производительность труда разработчика со сложностью.

Р - производительность труда:

(***)

С - зависит от применяемого инструментария (коэффициент пропорциональности). Например: С = 10 000 - язык высокого уровня исходящего из структурного программирования: С = 1, Д = 1, Р = 1; Д = 2, Р = 1,6)

S - объем программного изделия:

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

(*) , следовательно сокращение времени разработки требует увеличение затрат ресурсов (в степенной зависимости). Желание резко увеличить задействование ресурсов не дает линейного увеличения производительности требуется и пропорциональное этому сокращение затрат времени на разработку. При концентрации ресурсов во много раз увеличивается сложность, теряется эффективность взаимодействия множества программистов => не рекомендуется увеличивать затраты ресурсов более чем на 30% за полгода.

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

Соотношение (*) используется как основа для управления разработкой. Из соотношений (**) и (***) по значениям задаваемых параметров разрабатывается определенное значение выбираемых параметров разработки.

S,t0 - задаваемые значения (S - не явная характеристика, задана через функциональную нагрузку).

С - выбираемое значение разработчиком исходя из наиболее предпочтительного варианта технологии.

Результатные параметры (трудоемкость разработки) и исходя из срока разработки определяется количество исполнителей:

N=F/ta

В процессе разработки могут меняться некоторые характеристики:

меняются функциональные требования к ПИ;

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

В любом случае часть функций разрабатывается за время меньше, чем ta, при этом может не меняться S.

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

S = (d+4m+b)/6

d - минимально возможный объем разработки по мнению экспертов;

b - максимально