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

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

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

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

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

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

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

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

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

71

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

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

Вице-президент отдела маркетинга одобрил выпуск многофункционального набора CASE-технологий. Ниже приведены самые важные характерные черты этого набора функциональных возможностей.

Программа xTRemeObjectMaker:

–способствует выполнению более результативного и эффективного процесса разработки:

–поддерживает командную разработку;

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

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

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

–совместима с ведущими инструментальными средствами;

–поддерживает языки XML, DTD и DDL. Являясь прикладной программой,

написанной на языке Java, выполняется в операционной системах Windows, Linux.

Возникает естественный вопрос: располагая такими свойствами, зачем тратить время на определение жизненного цикла?

72

4 Оценка размера и возможности повторного использования ПО

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

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

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

Цели модели SEI СММ уровня2:

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

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

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

Действие 5 – идентифицируется либо определяется жизненный цикл разработки ПО, который включает предопределенные стадии, имеющие

управляемый размер.

73

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

Действие 9 – оценивается размер программных рабочих продуктов, которые производятся согласно документированной процедуре:

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

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

3 Применяются исторические данные.

4 Документированные гипотезы относительно результатов оценивания размеров.

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

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

стоимости работ и графиков по их выполнению. В основе этих рисков лежат проблемы, связанные с оцениванием.

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

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

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

включая выполнение действий, поддержку и сопровождение;

–поддерживать тесное сотрудничество с разработчиками других системных компонентов;

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

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

74

4.2 Определение размеров программного продукта

Впроцессе оценивания выполняется прогнозирование трудозатрат,

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

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

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

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

оценивается и отслеживается на протяжении выполнения всего проекта.

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

Примеры единиц измерения:

–количество строк кода (LinesOfCode, LOС);

–функциональные точки;

–точки свойств;

–количество точек на диаграмме потока данных (Dataflowdiagram, DFD);

75

–количество сущностей на диаграмме сущностей (Entityrelationshipdiagram,

ERD);

–количество точек соответствующих процессу/контролю (PSPEC/CSPEC)на структурном графике;

–количество различных элементов в составе управленческой спецификации объем документации;

–количество объектов, атрибутов и служб на объектной диаграмме.

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

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

обрабатываемый компилятором либо интерпретатором;

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

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

–не учитывайте строки, содержащие комментарии;

–не учитывайте отладочный код либо любой другой временный код;

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

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

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

76

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

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

– непосредственно связаны с конечным продуктом;

–единицы LOС легко оцениваются еще до завершения проекта;

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

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

Недостатки, связанные с применением метода LOС:

–единицы измерения LOС, затруднительны в применении при оценке размера ПО на ранних стадиях жизненного цикла разработки;

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

–применение методов оценки с помощью подсчета количества строк кода не регламентируется промышленными стандартами;

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

–программисты могут быть незаслуженно премированы за достижение высоких показателей LOС в случае, если служба менеджмента по ошибке посчитает это признаком высокой продуктивности, но при этом будет отсутствовать тщательно разработанный проект;

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

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

который может быть выполнен на основе листинга, сгенерированного

77

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

–показатели LOС не могут применяться при осуществлении нормализации в случае, если применяемые платформы или языки являются различными;

–единственный способ применения учета с помощью единиц измерения LOС

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

–генераторы кода зачастую продуцируют чрезмерный объем кода, в

результате чего искажаются показатели LOС.

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

–оценивать категории пользовательских бизнес-функции;

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

LOС на ранних стадиях жизненного цикла разработки;

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

Ниже приводиться краткий обзор процесса применения функциональных точек:

1 Подсчитываются функции в каждой категории (перечень категории: вывод,

ввод, опросы, структуры данных, интерфейс).

2Определяется сложность каждой функции – простая, средняя, сложная.

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

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

78

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

LOC.

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

1. Подсчет количества функций в каждой категории

2. Применение весовых множителей сложности

3. Применение множителей среды

4. Вычисление корректирующего множителя сложности

5. Вычисление скорректированных функциональных точек

6.

Преобразование в строки кода

Рисунок 4.1 – Базовые шаги анализа методом функциональных точек

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

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

79

–он не зависит от используемого языка программирования, технологии, а

также техники, исключая некоторые корректировки, выполняемые на заключительной стадии;

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

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

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

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

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

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

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

–учитываются факторы среды.

Недостатки анализа метода функциональных точек:

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

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

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

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

–этот метод лучше применять после создания спецификации дизайна;

–данный метод не очень хорошо применять после создания спецификации дизайна.

80