Управление программными проектами. Учебное пособие

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

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

необходимых для выражения алгоритма.

1. Подсчет количества точек свойств в каждой категории (входы, выходы, файлы, опросы)

2. Подсчет с применением точек свойств (алгоритмы)

3. Сложность взвешивания (средняя для точек свойств/ средняя/ сложная для алгоритмов)

4. Оценка факторов среды (используется лишь сложность логики и данных)

5. Вычисление фактора сложности настройки (сумма степеней сложности логики и данных)

6. Корректировка точки свойства

7. Преобразование в единицы LOC

Рисунок 4.2 – Основные шаги анализа методом точек свойств

81

Точки свойств обычно применяются в следующих случаях:

– ПО, функционирующее в режиме реального времени, например, системы

ПРО;

–системное ПО

–встроенное ПО, например, системы автоматизированного проектирования

(САПР), автоматизированного производства (АП), а также математическое ПО;

–системы искусственного интеллекта (ИИ);

–ПО, предназначенное для поддержки телекоммуникаций;

–ПО, выполняющее функции контроля над процессами.

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

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

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

Преимущества блиц – модели:

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

ориентированными классами , службы и т.д.;

–повышается степень точности при использовании хронологических данных;

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

Недостатки блиц – модели:

–требуется использование методологии дизайна;

–оценка не может начинаться до завершения разработки дизайна;

–требуются хронологические данные;

82

–не могут оцениваться факторы среды.

Метод оценивания WidebandDelphi. Еще одним популярным и простым методом, применяемым при оценке размера ПО и величины трудозатрат, является сбалансированный подход, разработанный группой WidebandDelphi.

Шаги по достижению консенсуса согласно модели WidebandDelphi:

1Представление проблемы и ответной формы на рассмотрение экспертов.

2Проведение групповой дискуссии.

3Анонимный сбор мнений экспертов.

4Обратная связь по сводке результатов с каждым экспертом.

5Поддержка других групповых дискуссий.

6Выполнение итераций до тех пор пока не будет достигнут консенсус.

Преимущества модели WidebandDelphi:

–простая и недорогая реализация на практике;

–экспертиза проводиться несколькими специалистами в своей области;

–все участники обсуждения повышают свою квалификацию в области рассмотрения ПО;

–не требуются хронологические данные;

–обеспечивается поддержка глобальной точки зрения на проект со стороны членов команды.

Недостатки WidebandDelphi:

–затруднительная повторяемость различными группами экспертов;

–существует вероятность консенсуса для некорректной оценки;

–вас можете посетить ложное чувство самоуверенности.

4.3 Влияние эффектов повторного использования на размер ПО

Многие программ происходят от предыдущих версий этих же программ. В

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

83

Повторному использованию подлежат: код, тестовый код, тестовые условия,

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

Новый код – это код, разработанный для нового приложения, который не включает большие пропорции ранее написанного кода.

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

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

либо изменений.

Наследованный код – это код, разработанный для предыдущих приложений,

использование которого ожидается новым приложением.

Первый этап при оценке систем, которые могут повторно использовать код,

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

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

После завершения оценки общего объема разработанного программного кода,

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

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

84

Множители повторного использования вычисляются на основании опыта.

Множители, равные 30% (трудозатраты на создание повторно используемого кода)

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

Типичные множители повторного использования приведены в таблице 4.1.

Таблица 4.1 – Типичные множители повторного использования

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

необходимых для выполнения задачи. Без информации относительно ее размера.

Таким образом, измерение предшествует оценке, а оценка, в свою очередь,

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

Контрольные вопросы

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

2 Опишите, каким образом структура послеоперационного перечня работ

(WBS) может оказывать влияние на способность к выполнению оценки размера ПО.

85

3Перечислите несколько моделей, которые достаточно часто используются

виндустрии производства ПО при оценке размера программ.

4Объясните смысл методов LOC, функциональных точек, точек свойств блиц – модели, а также методов оценивания размера ПО, позаимствованных в

Delphi.

5Резюмируйте преимущества и недостатки каждой из упомянутых моделей.

6Для каждой модели опишите ее применимость, степень точности, а также величину накладных расходов.

7Объясните степень выявления повторно используемых программных компонентов при оценивании размера ПО.

Практическое занятие

Ответьте на следующие вопросы:

– каким образом можно уменьшить затраты на производство новой системы,

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

–что такое избежание затрат при среднем процентном соотношении повторного использования в семействе подобных систем?

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

сцелью окупаемости повторного использования?

–каковы ожидаемые результаты при разработке каждой системы семейства,

исходя из данной конкретной стратегии инвестиций при повторном использовании?

– какие именно инвестиции возвращаются при использовании текущей стратегии инвестиций для повторного использования?

86

5 Оценка длительности и стоимости разработки ПО

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

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

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

5.1 Модель СММ института SEI и процесс оценивания

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

87

процесса (КРА) для уровня зрелости 2, который является повторяемым. Модель КРА на уровне 2 составляет основу процессов зрелости, которые имеют место на последующих уровнях. Заметим, что планирование проектов является жизненно важным при поддержке программного инжиниринга, измерений, а также действий по непрерывному улучшению, выполняемых на уровнях: 3 (определенный), 4

(управляемый), 5 (оптимизация).

Рассмотрим цели модели SEI СММ уровня 2, ключевая область процесса

(КРА): планирование программного проекта (РР).

Цель 1. Оценки ПО документированы для применения в планировании и отслеживании программных проектов.

Возможность выполнения, ввязанная с КРА РР и целью 1.

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

Выполненные действия.

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

Данная процедура обычно определяет следующие аспекты:

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

2.Данные о производительности (хронологические и/или текущие)

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

понесенные при производстве программных продуктов. Основные затраты,

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

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

88

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

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

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

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

Критические вычислительные ресурсы могут находиться в хост-среде, в

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

Выполнение процедуры обычно подразумевает следующие аспекты:

1. Идентифицируются критические вычислительные ресурсы, требуемые для выполнения проекта. Сюда включается следующее: объем компьютерной памяти,

степень загруженности центрального процессора, пропускная способность ком-

муникационных каналов.

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

также величины трафика при реализации коммуникаций.

3.Оценки критических вычислительных ресурсов документируются,

изучаются и утверждаются.

Действие 12. График выполнений программного проекта разрабатывается в соответствии с документированной процедурой. Как правило, эта процедура включает следующее.

1. График разработки ПО связан с оценками размера программных продуктов

(либо с оценкой объема изменений), а также со всеми затратами по разработке ПО.

2.График разработки ПО основывается на прошлом опыте. По возможности,

используются похожие проекты.

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

89

критических зависимостей, а также других ограничений.

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

5.Документируются допущения, выполненные на этапе формирования графика.

6.График по разработке ПО документируется, изучается и одобряется

(утверждается).

Группа, отвечающая за инжиниринг программных процессов

(Softwareengineeringprocessgroup, SEPG), может оказать неоценимую помощь в деле улучшения оценки затрат, понесенных при разработке ПО. Часто специалисты из этой группы начинают с того, что читают краткий курс лекций по методике оценки ПО менеджерам проектов (а также специалистам по оценке). Также в задачи этой группы входит определение стандартов, применяемых для сбора всех метрических показателей, имеющих отношение к проекту, включая показатели, применяемые для оценки графика и всех затрат. Специалисты группы могут нести частичную ответственность за выполнение работ по отбору моделей по мере роста количества точек данных. Группа SEPG тесно сотрудничает со специалистами SQA/SQE при определении и документировании политик, процессов и процедур, включая те из них, которые применяются при оценке затрат. Эти рабочие группы могут выполнять задачи планирования, а также помогать менеджерам в деле обучения, а также в приобретении и лицензировании инструментов, применяемых для выполнения оценок.

5.2 Оценивание трудозатрат

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

90