ОПИ-2. Министерство науки и образования рф
 Скачать 1.52 Mb.
|
|
систему программ управления данными и совокупность данных, упорядоченных по некоторым правилам. Поэтому при анализе качества базу данных целесообразно делить на два компонента: программные средства системы управления базой данных (СУБД), независимые от сферы их применения, структуры и смыслового содержания накапливаемых и обрабатываемых данных; информацию базы данных (ИБД), доступную для накопления, упорядочивания, обработки и использования в конкретной проблемно- ориентированной сфере применения. При комплексном анализе качества баз данных, не всегда удается четко разделить требования и значения характеристик качества для каждого из этих объектов. При этом одна и та же система управления базой данных (СУБД) может обрабатывать различные по структуре, составу и содержанию данные, а одни и те же данные могут управляться программными средствами различных СУБД. Хотя эти компоненты тесно взаимодействуют при реализации конкретной прикладной БД, первоначально при проектировании они создаются или выбираются практически независимо и могут рассматриваться в их жизненном цикле (ЖЦ) как два объекта, которые различаются: номенклатурой и содержанием показателей качества, определяющих их назначение, функции и потребительские свойства; технологией и средствами автоматизации разработки и обеспечения всего ЖЦ каждого объекта; категориями специалистов, обеспечивающих: создание, эксплуатацию или применение компонентов БД; комплектами эксплуатационной и технологической документации, поддерживающими жизненный цикл объектов. Первым компонентом для системного анализа и требований к качеству является комплекс программ СУБД. Практически весь набор характеристик и атрибутов качества ПС, изложенный в стандарте ISO- 9126, в той или иной степени, может использоваться при формировании требований к качеству СУБД. Особенности состоят в адаптации и изменении акцентов при выборе и упорядочении этих показателей. Во всех случаях важнейшими характеристиками качества СУБД являются требования функциональной пригодности для процессов формирования и изменения информационного наполнения БД администраторами, а также доступа к данным и представления результатов пользователям БД. Качество интерфейса специалистов с БД, обеспечиваемого средствами СУБД, определяется, в значительной степени, субъективно, однако имеется ряд характеристик, которые можно оценивать достаточно корректно. Различия требований к характеристикам качества привели к созданию весьма широкого спектра локальных, специализированных и распределенных СУБД. Значения ряда показателей качества ПС, составляющих СУБД, существенно зависят от характеристик и организации информации в БД. Специализированные СУБД характеризуются относительно узкой сферой применения и более четким выделением группы требований к приоритетным показателям качества. В универсальных СУБД спектр характеристик качества шире, что позволяет соответственно расширять сферу применения конкретного типа СУБД. Однако и для них существуют области приоритетного, наиболее эффективного использования. За основу принята номенклатура и содержание стандартизированных характеристик сложных комплексов программ, которые адаптируются применительно к понятиям и особенностям компонентов баз данных. В зависимости от конкретной проблемно-ориентированной области применения СУБД, приоритет при системном анализе требований качеству может отдаваться различным, конструктивным характеристикам: либо надежности и защищенности применения (финансовая сфера), либо удобству использования малоквалифицированными пользователями (социальная сфера), либо эффективности использования ресурсов (сфера материально- технического снабжения). Однако, практически во всех случаях сохраняется некоторая роль ряда других конструктивных показателей качества. Для каждого из них необходимо анализировать и определять его приоритет для конкретной сферы применения, меры и шкалы необходимых и допустимых характеристик качества. Вторым компонентом БД является собственно накапливаемая и обрабатываемая информация. В системах баз данных доминирующее значение приобретают сами данные, их хранение и обработка. Ниже сделан акцент на системный анализ требований и составляющих характеристик качества этого объекта - на информацию баз данных с предположением, что средства СУБД способны их обеспечить. Для оценивания качества информации БД может сохраняться общий, методический подход к выделению адекватной номенклатуры стандартизированных в ISO 9126 базовых характеристик и субхарактеристик качества ПС. Однако их содержание для применения к качеству ИБД при проектировании требуется уточнить и пояснить. Выделяемые показатели качества должны иметь практический интерес для пользователей БД и быть упорядочены в соответствии с приоритетами практического применения. Кроме того, каждый выделяемый показатель качества ИБД должен быть пригоден для достаточно достоверного оценивания или измерения, а также для сравнения с требуемым значением при испытаниях. При проектировании каждой БД в контракте, техническом задании и в спецификации должны селектироваться и формализоваться представительный набор функциональных требований к качеству ИБД, адекватный ее назначению и области применения, а также требованиям заказчика и потенциальных пользователей. Так же как для ПС, характеристики качества ИБД можно разделить на функциональные и конструктивные. Их номенклатура, содержание и субхарактеристики ниже базируются на описаниях, рекомендуемых стандартом ISO 9126. Они представляются достаточно универсальными и применимыми для систематизации характеристик качества информации баз данных. Тем самым может быть заложена основа для стандартизированного формирования требований к качеству баз данных. Однако номенклатура показателей качества не всегда может ограничиваться только характеристиками информации в БД, а должна включать ряд уточнений, отражающих комплексную эффективность и функциональную пригодность совместного применения СУБД и ИБД пользователями в реальных условиях. Функциональная пригодности ИБД при системном проектировании может представлять сложную проблему для определения соответствия требований реальным значениям необходимых атрибутов качества особенно, для больших распределенных БД при циркулировании разнообразной и сложной информации об анализируемых объектах. Мерой качества функциональной пригодности может быть степень покрытия целей, назначения и функций БД доступной пользователям информацией. Так же как для ПС, для баз данных в составе функциональной пригодности целесообразно использовать группу субхарактеристик, определяющих функциональные и структурные требования к базам данных, основное содержание которых подобно приведенным для ПС выше. Дополнительно функциональная пригодность многих ИБД может отражаться: полнотой накопленных описаний объектов – относительным числом объектов или документов, имеющихся в БД, к общему числу объектов по данной тематике или по отношению к числу объектов в аналогичных БД того же назначения; идентичностью данных - относительным числом описаний объектов, не содержащих дефекты и ошибки, к общему числу документов об объектах в ИБД; актуальностью данных - относительным числом устаревших данных об объектах в ИБД к общему числу накопленных и обрабатываемых данных. Разнообразие назначения и функций ИБД ограничивает возможность стандартизации требований к ним только общими правилами их организации и структурирования, которые достаточно подробно изложены выше и далее не рассматриваются. К конструктивным характеристикам качества информации БД в целом можно отнести, с некоторой корректировкой и уточнением понятий, субхарактеристик и атрибутов, практически все стандартизированные показатели качества ПС, которые представлены в ISO 9126. Требования к информации баз данных так же должны содержать особенности обеспечения ее надежности, эффективности использования ресурсов ЭВМ, практичности, применимости, сопровождаемости, мобильности. Содержание и атрибуты этих конструктивных характеристик в данном случае несколько отличаются от применяемых для программ, однако, их сущность, как базовых понятий и характеристик качества объектов, целесообразно использовать при проектировании для систематизации и регламентированного формирования требований к этим компонентам информационных систем. Меры и шкалы для оценивания конструктивных характеристик, в значительной степени, могут применяться те же, что при анализе качества программных средств. Корректность или достоверность данных - это степень соответствия информации об объектах в БД реальным объектам вне ЭВМ в данный момент времени, определяющаяся изменениями самих объектов, некорректностями записей о их состоянии или некорректностями расчетов их характеристик. При системном проектировании выбор и установление требований к корректности данных в БД, можно оценивать по степени покрытия накопленными, актуальными и достоверными данными состояния и изменения внешних объектов, которые они отражают. Кроме того, к корректности БД можно отнести некоторые объемно-временные характеристики сохраняемых и обрабатываемых данных: объем базы данных - относительное число записей описаний объектов или документов в базе данных, доступных для хранения и обработки, по сравнению с полным числом реальных объектов во внешней среде; оперативность - степень соответствия динамики изменения описаний данных в процессе сбора и обработки, состояниям реальных объектов или величина допустимого запаздывания между появлением или изменением характеристик реального объекта, относительно его отражения в базе данных; глубина ретроспективы - максимальный интервал времени от даты выпуска и/или записи в базу данных самого раннего документа до настоящего времени; динамичность - относительное число изменяемых описаний объектов к общему числу записей в БД за некоторый интервал времени, определяемый периодичностью издания версий БД. Защищенность информации БД реализуется, в основном, программными средствами СУБД, однако в сочетании с поддерживающими их средствами организации и защиты данных. Цели, назначение и функции защиты тесно связаны с особенностями функциональной пригодности каждой ИБД. При проектировании свойства защищать информацию баз данных от негативных воздействий описываются обычно составом и номенклатурой методов и средств, используемых для защиты от внешних и внутренних угроз. Косвенным показателем ее качества может служить относительная доля вычислительных ресурсов, используемых непосредственно средствами защиты информации БД. Основное внимание в практике обеспечения безопасности применения БД сосредоточено на защите от злоумышленных разрушений, искажений и хищений информации баз данных. Основой такой защиты является аудит санкционирования доступа, а также контроль организации и эффективности ограничений доступа. В реальных БД возможны и не всегда учитываются катастрофические последствия и аномалии информации БД, отражающиеся на безопасности применения, при которых их источниками являются случайные, непредсказуемые, дестабилизирующие факторы или дефекты, и отсутствуют непосредственно заинтересованные лица в подобных нарушениях. Качество защиты ИБД можно характеризовать величиной предотвращенного ущерба, возможного при проявлении дестабилизирующих факторов и реализации конкретных угроз безопасности, а также средним временем между возможными проявлениями угроз, преодолевающих защиту данных. Надежностьинформации баз данных может основываться на применении при системном проектировании понятий и методов теории надежности, которая позволяет получить ряд четких, измеряемых интегральных показателей их качества. Надежная ИБД, прежде всего, должна обеспечивать достаточно низкую вероятность потери работоспособности - отказа, в процессе ее функционирования в реальном времени. Быстрое реагирование на потерю или искажение данных и восстановление их достоверности и работоспособности за время меньшее, чем порог между сбоем и отказом, обеспечивают высокую надежность БД. Если в этих ситуациях происходит достаточно быстрое восстановление, такое что не фиксируется отказ, то такие события не влияют на основные показатели надежности – наработку на отказ и коэффициент готовности ИБД. Непредсказуемость вида, места и времени проявления дефектов ИБД в процессе эксплуатации приводит необходимости создания специальных, дополнительных систем оперативной защиты от непредумышленных, случайных искажений данных. Надежность должна повышаться за счет средств обеспечения помехоустойчивости, оперативного контроля и восстановления ИБД. Стандартом ISO 9126 рекомендуется анализировать и учитывать надежность комплексов программ четырьмя субхарактеристиками, которые могут быть применены также для формирования требований к характеристикам качества информации БД. Завершенность - свойство ИБД, состоящее в способности не попадать в состояния отказов вследствие потерь, искажений, ошибок и дефектов в данных. Они могут быть обусловлены не полным тестовым покрытием при испытаниях компонентов и ИБД в целом, а также недостаточной завершенностью их тестирования и защищенностью от искажений. Устойчивостьк дефектам и ошибкам - свойство ИБД автоматически поддерживать заданный уровень качества данных в случаях проявления дефектов и ошибок или нарушения установленного интерфейса по данным с внешней средой. Для этого в ИБД рекомендуется вводить оперативное обнаружение дефектов и ошибок информации, их идентификацию и автоматическое восстановление (рестарт) нормального функционирования ИБД. Относительная доля вычислительных ресурсов, используемых непосредственно для быстрой ликвидации последствий отказов и оперативного восстановления данных (рестарт) определяет значение устойчивости и снижается на повышении надежности ИБД. Восстанавливаемость - свойство ИБД в случае отказа возобновлять требуемый уровень качества информации, а также корректировать поврежденные данные. Для этого необходимы вычислительные ресурсы и время на выявление неработоспособного состояния, диагностику причин отказа, а также на реализацию процессов восстановления. Основными показателями процесса восстановления данных являются его длительность и верояностные характеристики ИБД в процессе ручного или автоматического их перезапуска - рестарта. Доступность или готовность - свойство ИБД быть в состоянии полностью выполнять требуемую функцию в данный момент времени при заданных условиях использования информации базы данных. Обобщением характеристик отказов и восстановления производится в критерии коэффициент готовности ИБД. Этот показатель отражает вероятность иметь восстанавливаемые данные в работоспособном состоянии в произвольный момент времени. Нижние границы шкал атрибутов надежности могут быть отражены значениями, при которых использование конкретной ИБД становится неудобным, опасным или нерентабельным. Эффективность использования ресурсов ЭВМ при системном анализе реального функционирования БД отражается временными характеристиками взаимодействия конечных пользователей и администраторов ИБД в процессе эксплуатации базы данных по прямому назначению. Временная эффективность БД определяется длительностью выполнения заданных функций и ожидания результатов от ИБД в средних и/или наихудших случаях, с учетом приоритетов задач. Она зависит от объема, структуры и скорости обработки данных, влияющих непосредственно на интервал времени завершения конкретного вычислительного процесса, и от пропускной способности - производительности, т.е. от числа заданий, которое можно реализовать на данной ЭВМ в заданном интервале времени. Используемость ресурсов или ресурсная экономичность в стандартах отражается занятостью ресурсов центрального процессора, оперативной, внешней и виртуальной памяти, каналов ввода-вывода, терминалов и каналов сетей связи. Эта величина определяется структурой, функциями и объемом ИБД, а также архитектурными особенностями и доступными ресурсами ЭВМ. В зависимости от конкретных задач и особенностей ИБД и ЭВМ при системном проектировании и выборе атрибутов качества ИБД может доминировать либо абсолютная величина занятости ресурсов различных видов, либо относительная величина использования ресурсов каждого вида при нормальном функционировании ИБД. Практичность-применимость - зачастую значительно определяет функциональную пригодность и полезность применения ИБД для квалифицированных пользователей. В число пользователей могут быть включены администраторы, конечные и косвенные пользователи, которые находятся под влиянием или зависят от качества информации БД. В эту группу показателей качества входят субхарактеристики и атрибуты с различных сторон отражающие функциональную понятность, удобство освоения, системную эффективность и простоту использования данных. Некоторые субхарактеристики можно оценивать экономическими показателями - затратами труда и времени специалистов на реализацию некоторых функций взаимодействия с данными. Практичность зависит не только от собственных характеристик ИБД, но также от организации и адекватности документирования процессов их эксплуатации. Понятность зависит от качества документации и субъективных впечатлений потенциальных пользователей от функций и характеристик ИБД. В системном проекте ее можно представить качественно четкостью функциональной концепции, широтой демонстрационных возможностей, полнотой, комплектностью и наглядностью представления в эксплуатационной документации возможных функций и особенностей реализации данных в БД. Она должна обеспечиваться корректностью и полнотой описания исходной и результирующей информации, а также всех деталей применения ИБД для пользователей. Простота использования ИБД - возможность удобно и комфортно ее эксплуатировать и управлять данными. Для этого должны быть обеспечены: достаточный объем параметров управления, реализуемых по умолчанию, информативность сообщений пользователям, наглядность унифицированность управления экраном, а также доступность изменений функций ИБД в соответствии с квалификацией пользователей и минимум операций, необходимых для реализации определенного задания и анализа результатов. Некоторые атрибуты этой субхарактеристики доступны при установлении количественных требований путем указания трудоемкости длительности соответствующих процессов подготовки и обучения квалифицированных пользователей к эффективной эксплуатации ИБД. Изучаемость может определяться требованиями ограниченной трудоемкости и длительности подготовки пользователя к полноценной эксплуатации информации БД. Изучаемость ИБД зависит от внутренних свойств и сложности структуры информации БД, а также от субъективных характеристик квалификации конкретных пользователей. Она может также характеризоваться объемом эксплуатационной документации и/или объемом и качеством электронных учебников. Сопровождаемость информации БД в системном проекте может отражаться удобством и эффективностью исправления, усовершенствования или адаптации структуры и содержания описаний данных в зависимостисти от изменений во внешней среде применения, а также в требованиях и функциональных спецификациях заказчика. Обобщенно качество сопровождаемости ИБД можно представить потребностью трудовых и временных ресурсов для ее обеспечения и для реализации. Возможные затраты экономических, трудовых и временных ресурсов на развитие и совершенствование качества ИБД зависят не только от внутренних свойств данных, но также и от запросов и потребностей пользователей на новые функции и от готовности заказчика и разработчика удовлетворить эти потребности. По объему предполагаемых изменений, а также вновь вводимых в очередную версию данных с учетом сложности и новизны их разработки могут быть сформулированы требования на их реализацию. Совокупность субхарактеристик сопровождаемости ПС, представленная в стандарте ISO 9126, вполне применима для описания требований к этому показателю качества информации БД, в основном, теми же организационно- технологическими субхарактеристиками. Анализируемость ИБД зависит от стройности архитектуры, унифицированности интерфейса, полноты и корректности технологической и эксплуатационной документации на БД. Изменяемость состоит в приспособленности структуры и содержания данных к реализации специфицированных изменений и к управлению конфигурацией данных. Изменяемость зависит не только от внутренних свойств ИБД, но также от организации и инструментальной оснащенности процессов сопровождения и конфигурационного управления, на которые ориентирована в проекте архитектура, внешние и внутренние интерфейсы данных. Тестируемостьзависит от величины области влияния изменений, которые необходимо тестировать при модификациях структуры и содержания данных в ИБД, от сложности тестов для проверки их характеристик. Ее атрибуты зависят от четкости формализации в системном проекте правил структурного построения компонентов и всего комплекса ИБД, от унификации межмодульных и внешних интерфейсов, от полноты и корректности технологической документации. Субхарактеристики изменяемость и тестируемостьданных доступны количественному определению по величине трудоемкости и длительности реализации этих функций при типовых операциях с данными при применении различных методов и средств автоматизации. Мобильность данных БД, так же как для программ, можно характеризовать в системном проекте в основном длительностью и трудоемкостью их инсталляции, адаптации и замещаемости при переносе ИБД на иные аппаратные и операционные платформы. Информация о процессах, происходящих во внешней среде, может иметь большие объем и трудоемкость первичного накопления и актуализации, что определяет необходимость ее тщательного хранения и регламентированного изменения. Формирование и заполнение информацией баз данных достаточно сложный и трудоемкий процесс, технико-экономические показатели которого сильно зависит от структуры, состава, объема, связности и других характеристик исходной информации. Особенности и трудоемкость переноса ИБД зависят, прежде всего, от характеристик совместимости архитектуры и содержания информации переносимой БД между рассматриваемыми платформами: форматная совместимость характеризуется степенью соответствия данных в ИБД анализируемых платформ требованиям стандартов на форматы представления данных для документальных, фактографических, словарных и иных БД; лингвистическая совместимость определяется степенью использования в рассматриваемых ИБД единых лингвистических средств (классификаторов, рубрикаторов, словарей), формализованных соответствующими стандартами этих платформ; физическая совместимость заключается в степени соответствия кодировки информации БД одинаковым стандартам на машиночитаемые носители информации. Так как перенос БД часто обусловлен необходимостью увеличения ресурсов ЭВМ, доступных для решения новых перспективных задач, их системный проект становится естественным расширением функций ИБД относительно исходной версии проекта. Для оценки качества и определения требований к мобильности ИБД, так же как для ПС, следует решать задачу сравнения достигаемого эффекта и затрат для методов переноса или повторной разработки компонентов и наполнения базы данных в конкретных условиях с учетом всех перечисленных факторов и затрат. Эти задачи значительно упрощаются при одновременном сокращении затрат при применении идеологии и концепции открытых компьютерных систем, поддержанных комплексом международных стандартов, а также современных версий ОС и СУБД, как стандартов де-факто. МОДЕЛИ ОЦЕНКИ ХАРАКТЕРИСТИК КАЧЕСТВА И НАДЕЖНОСТИ ПО Размерно-ориентированные метрики. Функционально- ориентированные метрики. Пример применения метрик. Достоинства и недостатки размерно – ориентированных и функционально-ориентированных метрик. РАЗМЕРНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно- ориентированные метрики на LOC – оценках (Lines Of Code). LOC - оценка – это количество строк в программном продукте. Исходные данные для расчета этих метрик сводятся в таблицу (табл.3). Исходные данные для расчета LOC- метрик Табл. 3. Проект Затраты, чел.-мес. Стоимость тыс. $ КLOC, тыс. LOC Страниц Ошибки Количество человек А01 24 168 12,1 365 29 3 В02 62 440 27,2 1224 86 5 С03 43 314 20,2 1050 64 6 Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте А01 показывает: 12100 строк программы были разработаны за 24 чел.-мес. И стоили $168 000. Кроме того, по проекту было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект три человека. На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества проекта: Производительность = Длина / Затраты (тыс.LOC/чел.-мес.); Качество = Ошибки / Длина (Единиц/тыс. LOC); Удельная стоимость = Стоимость /Длина (тыс.$/LOC); Документированность = Страниц_Документа / Длина (Страниц/тыс.LOC) Достоинства размерно-ориентированных метрик: широко распространены; просты и легко вычисляются. Недостатки размерно-ориентированных метрик: зависимы от языка программирования; требуют исходных данных, которые трудно получить на начальной стадии проекта; не приспособлены к непроцедурным языкам программирования. ФУНКЦИОНАЛЬНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC – оценки при этом рассматривается не размер, а функциональность или полезность продукта. Используется 5 информационных характеристик. 1. Количество внешний вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно. 2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных отчета отдельно не подсчитываются. 3. Количество внешних запросов. Под запросами понимают диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует вычислений. Подсчитываются все запросы – каждый учитывается отдельно. 4. Количество внутренних логических файлов. Подсчитываются все логические файлы (т.е. логические группы данных, которые могут быть частью базы данных или отдельным файлом). 5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение. Выводы, вводы, запросы относятся к категории транзакция. Транзакция – это элементарный процесс, различаемый пользователем и перемещающий данные между внешней средой и программным приложением. В своей работе транзакции используют внутренние и внешние файлы. Приняты следующие определения. Внешний ввод – элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать с экрана ввода или из другого приложения. Данные могут использоваться для обновления внутренних логических файлов. Данные могут содержать как управляющую, так и деловую информацию. Управляющие данные не должны модифицировать внутренний логический файл. Внешний вывод - элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуюткритерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле. Внешний запрос – элементарный процесс, работающий как с вводимыми, так и с выводимыми данными. Его результат – данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует внутренние логические файлы, а выходная не несет данных, вычисляемых приложением (в этом и состоит отличие запроса от вывода). Внутренний логический файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы. Внешний интерфейсный файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении. Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для транзакций ранжирование основано на количестве ссылок и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов-элементов записей и типов элементов данных, входящих в файл. Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла. Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП). Примеры элементов данных Табл.4. Информационная характеристика Элементы данных Внешние вводы Поля ввода данных, сообщения об ошибках, вычисляемые значения, кнопки Внешние выводы Поля данных в отчетах, вычисляемые значения, сообщения об ошибках, заголовки столбцов, которые читаются из внутреннего файла Внешние запросы Вводимые элементы: поле, используемое для списка, щелчок мыши. Выводимые элементы: отображаемые на экране поля. Правила учета элементов данных из ГИП Табл.5. Элемент данных Правило учета Группа радиокнопок Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных Группа флажков (переключатели) Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных Командные кнопки Командная кнопка может определять действия добавления, изменения, запроса. Кнопка ОК может вызвать транзакции (различных типов). Кнопка Next может быть входным элементом запроса или вызвать другую транзакцию. Каждая кнопка считается отдельным элементом данных. Списки Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего вида. Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка). Обычно этому экрану ГИП соответствует несколько транзакций. Типичный экран включает несколько внешний запросов, сопровождающих внешний ввод. Обсудим порядок учета сообщений. В приложении с ГИП генерируются три типа сообщений: сообщение об ошибке, сообщение подтверждения и сообщение уведомления. Сообщения об ошибке (например, «Требуется пароль») и сообщение подтверждения (например, «Вы действительно хотите удалить запись о клиенте?») указывают, что произошла ошибка или что процесс может быть завершен. Эти сообщения не образуют самостоятельного процесса, они являются частью другого процесса, то есть считаются элементом данных соответствующей транзакции. С другой стороны, уведомление является независимым элементарным процессом. Например, при попытке получить от банкомата сумму денег, превышающую их количество на счете, генерируется сообщение «Не хватает средств для завершения транзакции». Оно является результатом чтения информации из файла счета и формирования заключения. Сообщение уведомления рассматривается как внешний вывод. Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл.6-10 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4. Ранг и оценка сложности внешних вводов Табл.6. Ссылки на файлы Элементы данных 1-4 5-15 >15 0-1 Низкий (3) Низкий (3) Средний (4) 2 Низкий (3) Средний (4) Высокий (6) >2 Средний (4) Высокий (6) Высокий (6) Ранг и оценка сложности внешних выводов Табл.7. Ссылки на файлы Элементы данных 1-4 5-19 >19 0-1 Низкий (4) Низкий (4) Средний (5) 2-3 Низкий (4) Средний (5) Высокий (7) >3 Средний (5) Высокий (7) Высокий (7) Ранг и оценка сложности внешних запросов Табл.8. Ссылки на файлы Элементы данных 1-4 5-19 >19 0-1 Низкий (3) Низкий (3) Средний (4) 2-3 Низкий (3) Средний (4) Высокий (6) >3 Средний (4) Высокий (6) Высокий (6) Ранг и оценка сложности внутренних логических файлов Табл.9. Ссылки на файлы Элементы данных 1-19 20-50 >50 0-1 Низкий (7) Низкий (7) Средний (10) 2-5 Низкий (7) Средний (10) Высокий (15) >5 Средний (10) Высокий (15) Высокий (15) Ранг и оценка сложности внешних интерфейсных файлов Табл.10. Ссылки на файлы Элементы данных 1-19 20-50 >50 0-1 Низкий (5) Низкий (5) Средний (7) 2-5 Низкий (5) Средний (7) Высокий (10) >5 Средний (7) Высокий (10) Высокий (10) Отметим, что если во внешнем запросе ссылка на файл используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется на элемент данных (однократный учет). После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (Function Points). Автором этой метрики является А. Альбрехт (1979). Исходные данные для расчета сводятся в табл. 11. В таблицу заносится количественное значение характеристики каждого вида (по всем уровням сложности). Места подстановки значений отмечены прямоугольником (этот символ играет роль метки - заполнителя). Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения суммируются по вертикали, формируя общее количество. Исходные данные для расчета FP – метрик Табл.11. Имя характеристики Ранг, сложность, количество Низкий Средний Высокий Итого Внешние вводы *3=_ *4=_ *6=_ = Внешние выводы *4=_ *5=_ *7=_ = Внешние запросы *3=_ *4=_ *6=_ = Внутренние логические файлы *7=_ *10=_ *15=_ = Внешние интерфейсные файлы *5=_ *7=_ *10=_ = Общее количество = Количество функциональных указателей вычисляется по формуле: FP= Общее количество*(0,65+0,01* F i ), (1) Где F i – коэффициент регулировки сложности (I=1..14). Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.12). После вычисления FP на его основе формируются метрики производительности, качества и другие оценки. Производительность = ФункцУказатель / Затраты (FP/чел.-мес.); Качество = Ошибки / ФункцУказатель (Единиц/FP); Удельная Стоимость = Стоимость / ФункцУказатель (Тыс.$/FP); Документированность=СтраницДокумента/ФункцУказатель (Страниц/FP) Определение системных параметров приложения Табл.12. № Системный параметр Описание 1 Передачи данных Сколько средств данных требуется для пердачи или обмена информацией с приложением или системой? 2 Распределенная обработка данных Как обрабатываются распределенные данные и функции обработки? 3 Производительность Нуждается ли пользователь в фиксации времени ответа или производительности? 4 Распространенность используемой конфигурации Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? 5 Скорость транзакций Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)? 6 Оперативный ввод данных Какой процент информации нужно вводить в режиме онлайн? 7 Эффективность работы конечного пользователя Приложение проектировалось для обеспечения эффективной работы конечного пользователя? 8 Оперативное обновление Как много внутренних файлов обновляется в онлайновой транзакции? 9 Сложность Выполняет ли приложение интенсивную обработки логическую или математическую обработку? 10 Повторная используемость Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? 11 Легкость инсталляции Насколько трудны преобразования и инсталляция приложения? 12 Легкость эксплуатации Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? 13 Разнообразные условия размещения Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? 14 Простота изменений Была ли спроектирована, разработана и поддержана в приложении простота изменения? Область применения функциональных указателей – коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики свойств (Features Points). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика – количество алгоритмов. Алгоритм здесь определяется как ограниченная программа вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 13. Исходные данные для расчета указателя свойств Табл.13. № Характеристика Количество Сложность Итого 1 Вводы *4 = 2 Выводы *5 = 3 Запросы *4 = 4 Логические файлы *7 = 5 Интерфейсные файлы *7 = 6 Количество алгоритмов *3 = Общее количество = После заполнения таблицы по формуле (1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей. Достоинства функционально-ориентированных метрик: не зависят от языка программирования; Легко вычисляются на любой стадии проекта. Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения. FP – оценки легко пересчитать в LOC – оценки. Как показано в табл.14, результаты пересчета зависят от языка программирования, используемого для реализации ПО. Пересчет FP – оценок в LOC – оценки Табл.14. Язык программирования Количество операторов на 1 FP Ассемблер 320 С 128 Паскаль 90 С++ 64 Java 53 Visual Basic 32 Visual С++ 34 Delphi Pascal 29 HTML 3 15 LISP 64 Prolog 64 |