Базовым понятием модели СММ считается зрелость компании [61], [62]. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.

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

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

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

Рис. 1.9. Пять уровней зрелости модели СММ

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

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

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

С переходом на управляемый уровень (уровень 4) в компании принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса.

---

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

Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:

• предотвращения дефектов;

• управления изменениями технологии;

• управления изменениями процесса.

Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ.

5. Процесс руководства проектом.

Руководство программным проектом является защитной деятельностью программной инженерии, пронизывающей все виды основной деятельности – подготовку, планирование, моделирование, контруирование и развёртывание.

Цель любого программного проекта состоит в производстве определённого программного продукта. Понятие «продукт» задаёт не только текст на языки программирование и откомпилированный двоичный код. Например, туда включаются документация, отчёты по промежуточным итогам, результат проверок, оценки качества и и т.д.

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

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

---

Начало проекта

Перед планированием проекта следует:

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

• обсудить альтернативные решения;

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

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

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

Анализ риска. Исследование области неопределенности, анализ ее влияние на проект. В результате принимается решение – выполнять проект или нет.

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

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

В результате повторного планирования:

• могут быть перераспределены ресурсы;

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

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

6. Планирование проектных задач.

Эффективность руководства программным проектом целиком определяется правильностью планирования работ, которые необходимы для его выполнения. План помогает предвидеть возможные проблемы разработки ПО и ввести защитные меры для их предупреждения и решения. План создается на начальном этапе проекта (в ходе основной деятельности «планирование) и рассматривается менеджерами и инженерами-разработчиками как руководящий документ, выполнение которого должно привести к успешному завершению проекта. Этот начальный план должен максимально подробно описывать все этапы работы проекта. Как показано на рис. 2.2, планирование является многошаговым итерационным процессом. Очень важно, чтобы план регулярно пересматривался — ведь по мере работы в проект непрерывно поступают новые сведения. Важными факторами, которые должны учитываться при разработке плана, являются контрактные обязательства фирмы, требования заказчика, бюджетные и временные ограничения. Их изменения должны оперативно отражаться в плане работ программного проекта. Планирование начинается с оценки предметной области программной системы, ее размера, трудозатрат и времени на разработку. Формируется команда исполнителей, распределяются их функции. При этом учитываются ограничения по времени, бюджету, наличию и возможностям сотрудников, материально-техническому обеспечению. Затем определяются этапы разработки, контрольные вехи проекта и перечень артефактов — результатов каждого этапа. Напомним, в состав артефактов входит документация, макеты, отчеты, листинги, модели, программный код версий продукта и т. д. Составляется начальный план-график (расписание) работ команды. Далее начинается итерационная часть планирования. Выполняется текущий этап проекта. Его ход отслеживается и контролируется. Выявляются расхождения между реальным и плановым ходом работ. Если зафиксированы внутренние проблемы или заказчик изменил/расширил список требований, возможен пересмотр первоначальных оценок проекта. Такой пересмотр может привести к модификации начального (или уже промежуточно- го) графика работ. Если изменения влияют на сроки завершения или стоимость проекта, с заказчиком согласовываются новые ограничения проекта. После этого продолжают проект — переходят к следующему этапу работы. Конечно, опытные менеджеры закладывают в график резервы на случай не- приятностей. Иными словами, в планах фиксируются пессимистические графики работ. Но, разумеется, невозможно построить план, учитывающий все реальные проблемы, поэтому и возникает необходимость периодической коррекции этого руководящего документа.

---

Эмпирический закон:

30% - анализ и проектирование

40% - реализация проекта

30% - откладка и тестирование

7. Размерно-ориентированные метрики.

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Code). LOC-оценка — это количество строк в программном продукте.

Исходные данные для расчета этих метрик сводятся в таблицу (табл. 2.1).

Проект	Затраты, чел.-мес	Стоимость, тыс. $	KLOC, тыс. LOC	Прогр. док- ты, страниц	Ошибки	Люди
ааа01	24	168	12,1	365	29	3
bbb02	62	440	27,2	1224	86	5
ссс03	43	314	20,2	1050	64	6

Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте aaa01 показывает: 12 100 строк программы были разработаны за 24 человеко-месяца и стоили $168 000. Кроме того, по проекту aaa01 было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект aaa01 три человека.

На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта):

;

;

;

.

Достоинства размерно-ориентированных метрик:

1) широко распространены;

2) просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

1) зависимы от языка программирования;

2) требуют исходных данных, которые трудно получить на начальной стадии проекта;

3) Меньшее число строк кода проще поддерживать. Программа с меньшим количеством строк может быстрее работать. Мера не отражает реальную сложность решения.

8. Функционально-ориентированные метрики.

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

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

Функциональная точка – работа, которую сотрудник может выполнить за 1-2 дня. Функциональные точки выполняют не только программисты.

100 строк кода на С++

8 страниц документации – для редактора

Нарисованных изображений – для дизайнера

1 ф.т – небольшая утилита. Работа она 1-2 дня. Тот, кто не может справить с функциональной точкой, не может претендовать на полноценного члена команды

10 ф.т – небольшое приложение ( до месяца работы)

100 ф.т – это приложение (6 месяцев в команде, считается, что это предел для одиночки.

Американский программист пишет в год порядка 7,7 тыс. строк кода, выполняя при этом в среднем 63 функциональных точек. Европейский программист пишет 16,7 тысяч строчек кода, проходя при этом менее 30 функциональных точек. Основное отличие заключается в качестве сопровождаемости полученного кода и распределении обязанностей. Дело том, что программист не только разрабатывает программное обеспечение, но и сам должен его документировать, в европе для таких целей принято нанимать технических писателей. Вся зависит от того, как мы именно определим функциональную точку в рамках нашего проекта.

---

Достоинства функционально-ориентированных метрик:

1. Не зависят от языка программирования.

2. Легко вычисляются на любой стадии проекта.

Недостаток функционально-ориентированных метрик:

1. Результаты основаны на субъективных данных

FP=UI*(0.65+0.01*E[F(i)])

1. UI - оценка сложности пользовательского интерфейса,

2. F(i) ("эф итое") – коэффициенты регулировки сложности, основанные на эмпирической оценке ряда системных параметров и принимающие целые значения в диапазоне от 0 до 5.

3. E[F(i) - сумма всех коэффициентов по i параметру.

9. Выполнение оценки проекта на основе LOC- и FP метрик.

Цель этой деятельности — сформировать предварительные оценки, которые позволят:

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

• составить план программного проекта.

При выполнении оценки возможны два варианта использования LOC- и FP-данных:

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

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

Обсудим шаги процесса оценки.

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

f₁, f₂,…,f_n.

• Шаг 2. Для каждой функции f_i, планировщик формирует лучшую LOC_лучшi (FР_лучшi), худшую LOC_худшi (FР_худшi) и вероятную оценку LOC_{вероятнi} (FР_{вероятнi}). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.

• Шаг 3. Для каждой функции/ в соответствии с -распределением вычисляется ожидаемое значение LOC- (или FP-) оценки:

LOC_ожi =(LOC_лучшi + LOC_худшi +4x LOC_{вероятнi} )/ 6.

• Шаг 4. Определяется значение LOC- или FP-производительности разработки функции.

Используется один из трех подходов:

1) для всех функций принимается одна и та же метрика средней производительности ПРОИЗВ_ср, взятая из метрического базиса;

2) для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

ПРОИЗВ_i =ПРОИЗВ_срх(LOC_ср /LOC_ожi),

где LOC_cp — средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности);

3) для i-й функции настраиваемая величина производительности вычисляется по аналогу, взятому из метрического базиса:

ПРОИЗВ_i =ПРОИЗВ_анiх(LOC_анi /LOC_ожi).

Первый подход обеспечивает минимальную точность (при максимальной простоте вычислений), а третий подход — максимальную точность (при максимальной сложности вычислений).

• Шаг 5. Вычисляется общая оценка затрат на проект: для первого подхода

;

для второго и третьего подходов

.

• Шаг 6. Вычисляется общая оценка стоимости проекта: для первого и второго подходов

,

где УД_СТОИМОСТЬ_ср — метрика средней стоимости одной строки, взятая из метрического базиса.

---

Смотрите также файлы

• Рабочая тетрадь по теоретической механике 3.pdf

• Информационные технологии. Лекции.docx

• Инструктаж по технике безопасности на уроках информатики.docx

• Тема 1.1 Основные понятия теории множеств.docx

• ЧМ Контрольная работа 1.docx