1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

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 возможно вое-

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

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

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

1.Основным требованием, предъявляемым к современным ТС ПО, является их соответствие стандартам и норматив­ ным документам, связанным с процессами ЖЦ ПО и оцен­ кой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, СММ и др.).

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

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

Технология создания ПО, технологический процесс, техноло­ гическая операция, рабочий продукт, роль, руководство, инстру­ ментальное средство (CASE-средство).

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

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

2.Какие из требований, предъявляемых к современным ТС ПО, представляются наиболее важными и почему?

3.Поясните смысл реалистичных и нереалистичных ожида­ ний от внедрения ТС ПО.

4.Какие из критериев, приведенных в табл. 5.1, представля­ ются наиболее значимыми?

5.Охарактеризуйте принципы и область применения методи­ ки анализа и проектирования Rational Unified Process.

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

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

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

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

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

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

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

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

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

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

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

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

4.Закон Паркинсона. Согласно этому закону усилия, затра­ ченные на работу, распределяются равномерно по вьщеленному на проект времени. Здесь критерием для оценки затрат по проек­ ту являются человеческие ресурсы, а не целевая оценка самого профаммного продукта. Если проект, над которым работают пять человек, должен быть закончен в течение 12 месяцев, то зат­ раты на его выполнение исчисляются в 60 человеко-месяцев.

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

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

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

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

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

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

•создается и поддерживается менеджером проекта и коман­ дами архитекторов, разработчиков и тестировщиков, ответ­ ственными за выполнение работы;

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

•основывается на подробно описанной и обоснованной мо­ дели оценки;

•основывается на данных по аналогичным проектам, кото­ рые включают в себя аналогичные процессы, технологии, среду, требования к качеству и квалификации работников;

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

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

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

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

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

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

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

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

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

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

Трудоемкость = (Персонал) • (Среда) • (Качество) • (Размер^^^^^^^^).

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

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

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

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

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

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

• По аналогии. Если в прошлом приходилось иметь дело с по­ добным проектом, и его оценки известны, то можно, оттал­ киваясь от них, приблизительно оценить свой проект.

• Путем подсчета размера по определенным алгоритмам на основе исходных данных — требований к системе.

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

•Проблема может быть недостаточно хорошо понята разра­ ботчиками и (или) заказчиками из-за того, что некоторые факты были упущены или искажены.

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

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

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

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

•Возможности оценивания существенно зависят от субъек­ тов, вовлеченных в процесс оценивания.

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

Точность оценки стоимости и размера ПО в зависимости от стадии проекта определяется следующим графиком (рис. 6.1).

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

•количество строк кода (LOC — Lines of Code);

•функциональные точки (FP — Function Points).

Количество строк кода — исторически самая известная и до недавнего времени распространенная единица измерения. Одна­ ко при ее использовании возникает ряд вопросов:

•Каким образом можно определить количество строк кода до того, как они фактически будут написаны либо просто спроектированы?

•Как показатель количества строк кода может отражать вели­ чину трудозатрат, если не будет учитываться сложность про­ дукта, способности (стиль) программиста либо возможнос­ ти применяемого языка программирования?

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

Рис. 6.1. Точность оценки стоимости и размера ПО в зависимости от стадии проекта

• Каким образом разница в количестве строк кода может быть трансформирована в объем эквивалентной работы?

Эти и другие вопросы привели к тому, что строки кода как единицы измерения получили «дурную репутацию», хотя они попрежнему остаются наиболее широко используемыми. Взаимо­ связь между LOC и затрачиваемыми усилиями не является ли­ нейной. Несмотря на появление новых языков программирова­ ния, средняя производительность работы профаммистов за двад­ цать лет осталась неизменной и составляет около 3000 строк кода на одного программиста в год. Это говорит о том, что уменьше­ ние времени, затрачиваемого на цикл разработки, не может быть достигнуто за счет значительного повышения производительнос­ ти труда программистов. Причем это не зависит от усовершен­ ствований языка программирования, усилий со стороны менед­ жеров или сверхурочных работ. На самом деле первостепенное значение имеет набор функциональных свойств и качество ПО, а не количество строк кода.

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

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

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

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

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

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

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

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

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

•применение методов оценки с помощью подсчета количест­ ва строк кода не регламентируется промышленными стан­ дартами (например, ISO);

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

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

•при подсчете количества LOC следует различать автомати­ чески и вручную созданный код — эта задача является бо­ лее сложной, чем простой подсчет, который может быть выполнен на основе листинга, сгенерированного компи­ лятором, либо с помощью утилиты, выполняющей подсчет строк кода;

•показатели LOC не могут применяться при осуществлении нормализации в случае, если применяемые платформы раз­ работки или языки являются различными;