Методология информационного моделирования данных IDEF1x

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

Данная нотация применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, разработки на её основе базы данных. В настоящий момент существует новая версия IDEF1 - IDEF1X. В частности данная нотация предназначена для разработки реляционных баз данных. Основные объекты нотации:

• Сущности (Entities). Отражают совокупность экземпляров со схожими свойствами, но отличаемых по одному или нескольким признакам
• Связи (Relations). Отражают соотношение сущностей между собой

Графическая нотация

Методы оценки трудоемкости создания ПО ИС и их классификация

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

Примеры базовых показателей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

⇐ Предыдущая123456789Следующая ⇒

Поделиться: