Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Технологии создания программного обеспечения 421

CASE-средства ERwin и BPwin были разработаны фирмой

Logic Works, которая в 1998 г. вошла в состав PLATINUM

Technology, а затем Computer Associates.

BPwin

—

средство моделирования бизнес-процессов, реализу-

ющее метод IDEFO, а также поддерживающее диаграммы пото-

ков данных и IDEF3.

процессе моделирования BPwin позволя-

ет переключиться

нотации IDEFO

на любой

ветви модели на но-

тацию IDEF3 или DFD и создать смешанную модель. BPwin под-

держивает функционально-стоимостной анализ (ABC).

Семейство продуктов ERwin представляет собой набор

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

метод IDEF1X. ERwin реализует проектирование схемы БД, гене-

рацию ее описания на языке целевой СУБД (Oracle, Sybase, DB2,

Microsoft SQL Server

др.) и реверсный инжиниринг существую-

щей БД. ERwin выпускается в нескольких конфигурациях, ори-

ентированных на наиболее распространенные средства разработ-

ки приложений.

Для управления групповой разработкой используется сред-

ство Model Mart, обеспечивающее многопользовательский дос-

туп к моделям, созданным с помощью ERwin и BPwin. Модели

хранятся на центральном сервере

доступны

для всех

участников

группы проектирования.

Model Mart удовлетворяет ряду требований, предъявляемых к

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

• Совместное моделирование. Каждый участник проекта

имеет инструмент поиска

доступа к интересующей его мо-

дели в любое время. При совместной работе используются

три режима: незащищенный, защищенный и режим прос-

мотра. В режиме просмотра запрещается любое изменение

моделей.

защищенном режиме модель, с которой работа-

ет один пользователь, не может быть изменена другими

пользователями. В незащищенном режиме пользователи

могут работать с общими моделями в реальном масштабе

времени.

• Создание библиотек решений. Model Mart позволяет фор-

мировать библиотеки стандартных решений, включающие

наиболее удачные фрагменты реализованных проектов, на-

капливать и использовать типовые модели, объединяя их

при необходимости «сборки» больших систем. На основе

существующих

баз

данных

помощью ERwin возможно вое-

422 Глава 5

становление моделей (реверсный инжиниринг), которые в

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

объединяться с типовыми моделями из библиотек моделей.

• Управление

доступом.

Для каждого участника проекта опре-

деляются права доступа, в соответствии с которыми он по-

лучет возможность работать только с определенными моде-

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

так и для отдельных участников проекта. Роль специалис-

тов,

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

поэтому

Model Mart можно определять и управлять права-

ми доступа участников проекта к библиотекам, моделям и

даже к специфическим областям модели.

! Следует запомнить

Основным требованием, предъявляемым к современным

ТС ПО, является их соответствие стандартам и норматив-

ным документам, связанным с процессами ЖЦ ПО

оцен-

кой технологической зрелости организаций-разработчиков

(ISO 12207, ISO 9000, СММ

др.).

Процесс внедрения ТС ПО охватывает планирование

реа-

лизацию множества технических, организационных, струк-

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

ции и основан на четком понимании возможностей ТС ПО.

Основные понятия

Технология создания ПО, технологический процесс, техноло-

гическая операция, рабочий продукт, роль, руководство, инстру-

ментальное средство (CASE-средство).

? Вопросы для самоконтроля

Охарактеризуйте систему понятий, описывающих ТС ПО.

Какие понятия являются наиболее важными?

Какие из требований, предъявляемых к современным ТС

ПО,

представляются наиболее важными и почему?

Поясните смысл реалистичных и нереалистичных ожида-

ний от внедрения ТС ПО.

Какие из критериев, приведенных в табл. 5.1, представля-

ются наиболее значимыми?

Охарактеризуйте принципы и область применения методи-

ки анализа и проектирования Rational Unified Process.

ттшА

ОЦЕНКА ТРУДОЕМКОСТИ СОЗДАНИЯ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

У-У-,-^

V. ч J^,-¥«'-ii'-gei

Прочитав эту главу, вы узнаете:

•

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

ПО.

•

Какие существуют методы оценки

и в

чем они

заключаются.

•

Какие факторы и каким образом влияют на трудоемкость

созда-

ния ПО.

Оценка трудоемкости создания ПО является одним из наибо-

лее важных видов деятельности в процессе создания ПО, хотя она

и не выделена в стандарте ISO 12207 как отдельный процесс (тем

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

процесс «Измерение» (measurement)).

Модели и методы оценки трудоемкости используются для ре-

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

• разработка бюджета проекта (здесь прежде всего требуется

точность общей оценки);

• анализ степени риска и выбор компромиссного решения

(решение данной задачи позволяет уточнить такие характе-

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

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

оборудование и т. д.);

• планирование и управление проектом (полученные резуль-

таты обеспечивают распределение и классификацию расхо-

дов по компонентам, этапам и операциям);

• анализ затрат на улучшение качества ПО (это позволяет

оценить затраты и прибыль от стратегии инвестирования в

совершенствование аппаратных средств, технологий и воз-

можности повторного использования).

При отсутствии адекватной и достоверной оценки невозмож-

но обеспечить четкое планирование и управление проектом. В

424 Глава 6

целом ситуация

данной области, сложившаяся в индустрии ин-

формационных технологий, выглядит далеко не блестящей.

Недооценка стоимости, времени и ресурсов, требуемых для

создания ПО, влечет за собой недостаточную численность про-

ектной команды, чрезмерно сжатые сроки разработки и, как ре-

зультат, утрату доверия к разработчикам в случае нарушения фа-

фика. С другой стороны, перестраховка и переоценка могут ока-

заться ничуть не лучше. Если для проекта выделено больше ре-

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

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

не приходится. Такой проект окажется

более

дорогостоящим, чем

должен был быть при грамотной оценке, и приведет к запаздыва-

нию с началом следующего проекта.

6.1.

МЕТОДЫ ОЦЕНКИ И ИХ КЛАССИФИКАЦИЯ

Алгоритмическое моделирование. Метод основан на анализе

статистических данных

ранее выполненных проектах, при этом

определяется зависимость трудоемкости проекта от какого-ни-

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

но это размер программного кода). Проводится оценка этого по-

казателя для данного проекта, после чего с помощью модели

прогнозируются будущие затраты.

Экспертные оценки. Проводится опрос нескольких экспер-

тов

по

технологии разработки ПО, знающих область применения

создаваемого программного продукта. Каждый из них дает свою

оценку трудоемкости проекта. Потом все оценки сравниваются и

обсуждаются. Этот процесс повторяется до тех

пор,

пока не будет

достигнуто согласие по окончательному варианту предваритель-

ной трудоемкости.

Оценка по аналогии. Этот метод используется в том случае,

если

данной области применения создаваемого ПО уже реали-

зованы аналогичные проекты. Метод основан на сравнении пла-

нируемого проекта с предыдущими проектами, имеющими по-

добные характеристики. Он использует экспертные данные или

сохраненные данные о проекте. Эксперты вычисляют высокую,

низкую и наиболее вероятную оценку трудоемкости, основыва-

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

Оценка может быть достаточно детальной в зависимости от глу-

Оценка трудоемкости создания программного обеспечения 425

бины аналогий. Слабость модели заключается

том, что степень

подобия нового проекта

предыдущих, как

правило,

не слишком

велика.

Самый лучший вариант - это использование накопленных в

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

трудоемкость вашего проекта с трудоемкостью предыдущих про-

ектов аналогичного размера. Однако это возможно только при

следующих условиях:

• в организации аккуратно документируются реальные ре-

зультаты предыдущих проектов;

• по крайней мере, один из предыдущих проектов (а лучше

несколько) имеет аналогичный характер и размер;

• жизненный цикл, используемые методы и средства разра-

ботки, квалификация и опыт проектной команды нового

проекта также подобны тем, которые имели место в преды-

дущих проектах.

Закон Паркинсона. Согласно этому закону усилия, затра-

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

на проект времени. Здесь критерием для оценки затрат по проек-

ту являются человеческие ресурсы, а не целевая оценка самого

профаммного продукта. Если проект, над которым работают

пять человек, должен быть закончен

течение

месяцев, то зат-

раты на его выполнение исчисляются в 60 человеко-месяцев.

5. Оценка с

целью выиграть

контракт.

Затраты на проект опре-

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

Поэтому трудоемкость проекта зависит от бюджета заказчика, а

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

Требования приходится изменить так, чтобы не выходить за рам-

ки принятого бюджета.

Каждый метод оценки имеет слабые и сильные стороны. Для

работы над большими проектами необходимо применить нес-

колько методов оценки для их последующего сравнения. Если

при этом получаются совершенно разные результаты, значит, ин-

формации для получения более точной оценки недостаточно. В

этом случае необходимо воспользоваться дополнительной ин-

формацией, после чего повторить оценку, и так до тех пор, пока

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

Описанные методы оценки применимы, если документиро-

ваны требования будущей системы. В таком случае существует

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

426 Глава 6

рабатываемой системы. Однако во многих проектах оценка зат-

рат проводится только на основе предварительных требований к

системе. В этом случае лица, участвующие в оценке стоимости

проекта, будут иметь минимум информации для работы. Проце-

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

доро-

гостоящи. Поэтому менеджерам следует составить смету на их

выполнение еще до утверждения бюджета для всего проекта.

Практика

этой области такова, что независимые оценки (т.е.

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

разработчиков) обычно неточны. Единственный способ, позво-

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

—

это когда

компетентная команда

—

менеджер проекта вместе с ведущими

специалистами по созданию архитектуры, разработке и тестиро-

ванию

—

выполняют несколько итераций по оценке трудоемкос-

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

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

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

Хорошая оценка трудоемкости разработки ПО:

• создается и поддерживается менеджером проекта и коман-

дами архитекторов, разработчиков и тестировщиков, ответ-

ственными за выполнение работы;

• воспринимается всеми исполнителями как амбициозная, но

выполнимая;

• основывается на подробно описанной и обоснованной мо-

дели оценки;

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

рые включают в себя аналогичные процессы, технологии,

среду, требования к качеству и квалификации работников;

• подробно описывается таким образом, чтобы все ключевые

области риска были хорошо видны, а вероятность успеха

оценивалась объективно.

Идеальную оценку можно получить путем экстраполяции хо-

рошей оценки, полученной на основе устоявшейся модели трудо-

емкости

использующей опыт выполнения множества аналогич-

ных проектов, подготовленных той же командой, которая ис-

пользовала те же зрелые процессы и инструментарий. Хотя такая

ситуация на практике встречается редко, когда команда присту-

пает к осуществлению нового проекта, хорошие оценки могут

быть получены обычным путем на более поздних этапах жизнен-

ного цикла проекта.

Оценка трудоемкости создания программного обеспечения 427

В алгоритмическом моделировании трудоемкости разработки

ПО существует в основном два подхода к моделированию: теоре-

тические модели и статистические модели, которые будут рас-

смотрены ниже. Большинство моделей для определения трудо-

емкости разработки ПО могут быть сведены к функции пяти ос-

новных параметров:

• размера конечного продукта (для компонентов, написанных

вручную), который обычно измеряется числом строк исход-

ного кода или количеством функциональных точек, необхо-

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

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

нечного продукта, в частности его способность избегать

непроизводительных видов деятельности (переделок, бю-

рократических проволочек, затрат на взаимодействие);

• возможностей персонала, участвующего в разработке ПО, в

особенности его профессионального опыта и знания пред-

метной области проекта;

• среды, которая состоит из инструментов и методов, исполь-

зуемых для эффективного выполнения разработки ПО и ав-

томатизации процесса;

• требуемого качества продукта, включающего в себя его

функциональные возможности, производительность, на-

дежность и адаптируемость.

Соотношение между этими параметрами, с одной стороны, и

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

следующим образом:

Трудоемкость = (Персонал)

•

(Среда)

•

(Качество)

•

(Размер^^^^^^^^).

Наиболее влиятельный фактор оценки трудоемкости в этих

моделях

—

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

трудоемкости разработки ПО состоит из следующих действий:

1) оценка размера разрабатываемого продукта;

2) оценка трудоемкости в человеко-месяцах или человеко-часах;

3) оценка продолжительности проекта в календарных месяцах;

4) оценка стоимости проекта.

Оценка размера продукта базируется на знании требований к

системе. Для такой оценки существуют два основных способа.

• По аналогии. Если в прошлом приходилось иметь дело с по-

добным проектом, и его оценки известны, то можно, оттал-

киваясь от них, приблизительно оценить свой проект.

428 Глава 6

• Путем подсчета размера по определенным алгоритмам на

основе исходных данных

—

требований к системе.

Проблемы оценки размера ПО.

• Проблема может быть недостаточно хорошо понята разра-

ботчиками и (или) заказчиками из-за того, что некоторые

факты были упущены или искажены.

• Недостаток или полное отсутствие исторических данных не

позволяет создать базу для оценок в будущем.

• Проектирующая организация не располагает стандартами, с

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

(либо

случае наличия стандартов их никто не придержива-

ется);

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

при выполнении процесса оценивания.

• Менеджеры проектов полагают, что было бы неплохо фик-

сировать требования в начале проекта, заказчики же счита-

ют,

что не стоит тратить время на разработку спецификации

требований.

• Ошибки, как правило, скрываются, вместо

того,

чтобы оце-

ниваться и отображаться, в результате чего создается лож-

ное впечатление о фактической производительности.

• Возможности оценивания существенно зависят от субъек-

тов,

вовлеченных в процесс оценивания.

• Менеджеры, аналитики, разработчики, тестеры и те, кто

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

цессах оценивания и о возможностях совершенствования

продукта.

Точность оценки стоимости и размера ПО в зависимости от

стадии проекта определяется следующим графиком (рис. 6.1).

Основными единицами измерения размера ПО являются:

• количество строк кода (LOC

—

Lines of

Code);

• функциональные точки (FP

—

Function Points).

Количество строк кода

—

исторически самая известная и до

недавнего времени распространенная единица измерения. Одна-

ко при ее использовании возникает ряд вопросов:

• Каким образом можно определить количество строк

кода до

того,

как они фактически будут написаны либо просто

спроектированы?

• Как показатель количества строк кода может отражать вели-

чину

трудозатрат,

если не будет учитываться сложность про-

дукта, способности (стиль) программиста либо возможнос-

ти применяемого языка программирования?

Оценка трудоемкости создания программного обеспечения 429

Стоимость пройкт

(объем и затраты)

4)с

\25к

I.Ox

0.8х

0М

О.Вж

'' ' (

>——<

> '• • 6''

• •

' •' '6

Календарный

график проекта

16х

1.2SX

ОМ

0В5х

ОМ

Баэоазя Концепция Анализ Плйны проекта Готовность

концепция гцкю^ста требований утвер5*едвны решения

решения утв«ржд«нй лт^рат» утеерждена

Рис.

6.1.

Точность оценки

стоимости

размера

ПО в

зависимости от

стадии проекта

• Каким образом разница

количестве строк кода может быть

трансформирована в объем эквивалентной работы?

Эти и другие вопросы привели к тому, что строки кода как

единицы измерения получили «дурную репутацию», хотя они по-

прежнему остаются наиболее широко используемыми. Взаимо-

связь между LOC и затрачиваемыми усилиями не является ли-

нейной. Несмотря на появление новых языков программирова-

ния, средняя производительность работы профаммистов за двад-

цать

лет осталась неизменной и составляет около

3000

строк кода

на одного программиста в год. Это говорит о том, что уменьше-

ние времени, затрачиваемого на цикл разработки, не может быть

достигнуто за счет значительного повышения производительнос-

ти труда программистов. Причем это не зависит от усовершен-

ствований языка программирования, усилий со стороны менед-

жеров или сверхурочных работ. На самом деле первостепенное

значение имеет набор функциональных свойств

качество ПО, а

не количество строк кода.

430 Глава 6

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

рения:

• широкое распространение

легкая адаптируемость;

• возможность сопоставления методов измерения размеров и

производительности

различных фуппах разработчиков;

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

• легкая оценка до завершения проекта;

• оценка размеров ПО на основе точки зрения разработчика

—

физическая оценка созданного продукта (количество напи-

санных строк кода).

Недостатки применения LOC:

• LOC затруднительны в применении при оценке размера ПО

на ранних стадиях разработки;

• строки исходного кода могут различаться в зависимости от

типов языков программирования, методов проектирования,

стиля и способностей программиста;

• применение методов оценки с помощью подсчета количест-

ва строк кода не регламентируется промышленными стан-

дартами (например, ISO);

• разработка ПО может быть связана с большими затратами,

которые прямо не зависят

от

размеров программного кода

—

«фиксированными затратами», такими, как спецификации

требований и пользовательские документы, не включенны-

ми в прямые затраты на кодирование;

• профаммисты могут быть незаслуженно премированы за

достижение высоких показателей LOC в случае, если руко-

водство по ошибке посчитает это признаком высокой про-

дуктивности, но при этом будет отсутствовать тщательно

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

целью при создании продукта

—

главную роль ифают функ-

циональные свойства и показатели производительности;

• при подсчете количества LOC следует различать автомати-

чески и вручную созданный код

—

эта задача является бо-

лее сложной, чем простой подсчет, который может быть

выполнен на основе листинга, сгенерированного компи-

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

строк кода;

• показатели LOC не могут применяться при осуществлении

нормализации в случае, если применяемые платформы раз-

работки или языки являются различными;