Эмпирические оценочные модели 
";


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Эмпирические оценочные модели



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

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

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

Одной из наиболее распространенных и используемых на прак­тике является Конструктивная модель стоимости — СОСОМО (Constructive Cost Model). Эта модель применима к трем типам про­граммных систем:

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

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

3. Встроенный тип — когда проект разрабатывается внутри очень строгих ограничений и требований.

Конструктивная модель стоимости представлена иерархией мо­делей:

1. Базовая модель — основная — это статическая модель с одной переменной. Модель позволяет рассчитать усилия и стои­мость разработки программного изделия. Параметром модели слу­жит размер изделия в тысячах строк кода (KLOC).

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

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

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

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

Для оценки стоимости и затрат усилий на разработку исполь­зуются следующие уравнения базовой модели СОСОМО:

Е = а • (KLOC) • ехр (Ь);

D = с - (Е) • exp (d),

где Е — требуемые усилия (в человеко-месяцах);

D — хронологическое время разработки (в месяцах);

а, Ь, с, d — коэффициенты, представленные в табл. 11.1.

Таблица 11.1

Тип программного проекта а b с d
1. Изолированный 2. Полуизолированный 3. Встроенный 2,4 3,0 3,6 1,05 1,12 1.20 2,5 2.5 2.5 0,38 0,35 0,32

 

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

1. Атрибуты программного продукта:

• требуемая надежность;

• размер прикладной базы данных;

• сложность программного продукта.

2. Атрибуты технических средств:

• ограничения на время прогона программы;

• ограничения на объем памяти;

• требуемое время цикла обработки.

3. Атрибуты персонала разработчиков:

• квалификация системного аналитика;

• опыт в данной прикладной области;

• опыт работы с принятой в проекте средой разработки.

4. Атрибуты среды проектирования:

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

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

Каждый из перечисленных атрибутов располагается в пределах шкалы значений, диапазон которой изменяется от "очень низкий" до "чрезвычайно высокий". На основе специально составленной таблицы, основанной на опыте разработки подобных проектов, оп­ределяется множитель корректировки усилий. Типичные значения этих множителей лежат в пределах от 0,9 до 1,4.

Управление рисками

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

Важным моментом при планировании является анализ риска. Примерами областей возможного риска служат:

• качество и стабильность требований пользователя;

• стабильность и полнота описания внешних интерфейсов;

• опыт и квалификация кадров;

• техническая новизна проекта и т.п.

Анализ риска включает четыре разных вида деятельности:

1. Идентификация риска.

2. Описание риска.

3. Оценка риска.

4. Управление риском.

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

• риск проектирования;

• технический риск;

• бизнес-риск (деловой риск).

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

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

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

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

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

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

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

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

• определить причины текучести (оплата, условия работы);

• наметить действия, смягчающие эти причины;

• постоянно контролировать ситуацию;

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

• организовать рабочие бригады и т.д.

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

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

Планирование разработки программного изделия

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

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

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

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



Поделиться:


Последнее изменение этой страницы: 2017-02-07; просмотров: 161; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 35.153.106.141 (0.004 с.)