Каталог статей
| Главная » Статьи » Мои статьи | [ Добавить статью ] |
Методика оценки трудоемкости разработки ПО на основе функциональных точек.
| МЕТОДИКА ОЦЕНКИ ТРУДОЕМКОСТИ РАЗРАБОТКИ ПО НА ОСНОВЕ ФУНКЦИОНАЛЬНЫХ ТОЧЕК Определение числа функциональных точек является методом количественной оценки ПО, применяемым для измерения функ циональных характеристик процессов его разработки и сопро вождения независимо от технологии, использованной для его ре ализации. Подсчет функциональных точек, помимо средства для объек тивной оценки ресурсов, необходимых для разработки и сопро вождения ПО, применяется также в качестве средства для опре деления сложности приобретаемого продукта с целью принятия решения о покупке или собственной разработке. Метод разработан на основе опыта реализации множества проектов создания ПО и поддерживается международной орга низацией IFPUG (International Function Point User Group). Рас сматриваемый в данном разделе сокращенный вариант методики оценки трудоемкости разработки ПО основан на материалах IFPUG и компании SPR (Software Productivity Research), которая является одним из лидеров в области методов и средств оценки характеристик ПО. Согласно данной методике трудоемкость вычисляется на ос нове функциональности разрабатываемой системы, которая, в свою очередь, определяется на основе выявления функциональных типов — логических групп взаимосвязанных данных, использмых и поддерживаемых приложением, а также элементарных про цессов, связанных с вводом и выводом информации. Порядок расчета трудоемкости разработки ПО: • определение количества и сложности функциональных ти пов приложения; • определение количества связанных с каждым функциональ ным типом элементарных данных (DET), элементарных за писей (RET) и файлов типа ссылок (FTR); • определение сложности (в зависимости от количества DET, RET и FTR); • подсчет количества функциональных точек приложения; • подсчет количества функциональных точек с учетом общих характеристик системы ; • оценка трудоемкости разработки (с использованием различ ных статистических данных). ОПРЕДЕЛЕНИЕ ФУНКЦИОНАЛЬНЫХ ТИПОВ В состав функциональных типов (function type) включаются следующие элементы приложений разрабатываемой системы. \, Внутренний логический файл (internal logicalfiky ILF) — иден тифицируемая совокупность логически взаимосвязанных запи сей данных, поддерживаемая внутри приложения посредством элементарного процесса. 2. Внешний интерфейсный файл (external interface file, Elf) — идентифицируемая совокупность логически взаимосвязанных за писей данных, передаваемых другому приложению или получае мых от него и поддерживаемых вне данного приложения. 3. Входной элемент приложения (external input, EI) — элемен тарный процесс, связанный с обработкой входной информации приложения — входного документа или экранной формы. Обра батываемые данные могут соответствовать одному или более ILF. 4. Выходной элемент приложения (external output, ЕО) — эле ментарный процесс, связанный с обработкой выходной инфор мации приложения — выходного отчета, документа, экранной формы.5. Внешний запрос (external query, EQ) ~ элементарный про цесс, состоящий из комбинации «запрос/ответ», не связанный с вычислением производных данных или обновлением ILF (базы данных). ОПРЕДЕЛЕНИЕ КОЛИЧЕСТВА И СЛОЖНОСТИ ФУНКЦИОНАЛЬНЫХ ТИПОВ ПО ДАННЫМ Количество функциональных типов по данным (внутренних логических файлов и внешних интерфейсных файлов) определя ется на основе диафамм «сущность-связь» (для структурного подхода) и диаграмм классов (для объектно-ориентированного подхода). В последнем случае в расчете участвуют только устой чивые (persistent) классы, или классы-сущности. Устойчивый класс соответствует ILF (если его объекты обяза тельно создаются внутри самого приложения) или EIF (если его объекты не создаются внутри самого приложения, а получаются в результате запросов к базе данных). Примечание. Если операции класса являются операциями-запроса ми, то это характеризует его принадлежность к EIE Для каждого выявленного функционального типа (ILF и EIF) определяется его сложность (низкая, средняя или высокая). Она зависит от количества связанных с этим функциональным типом элементарных данных (data element types, DET) и элементарных записей (record element types, RET), которые в свою очередь оп ределяются следующим образом: • DET — уникальный идентифицируемый нерекурсивный элемент данных (включая внешние ключи), входящий в ILF или EIF; • RET — идентифицируемая подфуппа элементов данных, входящая в ILF или EIE На диаграммах «сущность-связь» такая подгруппа обычно представляется в виде сущности- подтипа в связи «супертип-подтип». Один DET соответствует отдельному атрибуту или связи класса. Количество DET не зависит от количества объектов клас са или количества связанных объектов. Если данный класс свя зан с некоторым другим классом, который обладает явно задан ным идентификатором, состоящим более чем из одного атрибу та, то для каждого такого атрибута определяется один отдельный DET (а не один DET на всю связь). Производные атрибуты могут игнорироваться. Повторяющиеся атрибуты одинакового форма та рассматриваются как один DET. Одна RET на диаграмме устойчивых классов соответствует либо абстрактному классу в связи обобщения (generalization), ли бо классу - «части целого» в композиции, либо классу с рекур сивной связью «родитель-потомок» (афегацией). Зависимость сложности функциональных типов от количест ва DET и RET определяется следующей таблицей. ОПРЕДЕЛЕНИЕ КОЛИЧЕСТВА И СЛОЖНОСТИ ТРАНЗАКЦИОННЫХ ФУНКЦИОНАЛЬНЫХ ТИПОВ Количество транзакционных функциональных типов (вход ных элементов приложения, выходных элементов приложения и внешних запросов) определяется на основе выявления входных и выходных документов, экранных форм, отчетов, а также по ди аграммам классов (в расчете участвуют граничные классы). Далее для каждого выявленного функционального типа (EI, ЕО или EQ) определяется его сложность (низкая, средняя или высокая). Она зависит от количества связанных с этим функцио нальным типом DET, RET и файлов типа ссылок (file type refer enced, FTR) ~ ILF или EIF, читаемых или модифицируемых функциональным типом. Правила расчета DET для EI: • каждое нерекурсивное поле, принадлежащее (поддерживае мое) ILF и обрабатываемое во вводе; • каждое поле, которое пользователь хотя и не вызывает, но оно через процесс ввода поддерживается в ILF; • логическое поле, которое физически представляет собой множество полей, но воспринимается пользователем как единый блок информации; • группа полей, которые появляются в ILF более одного раза, но в связи с особенностями алгоритма их использования воспринимаются как один DET; • фуппа полей, которые фиксируют ошибки в процессе об работки или подтверждают, что обработка закончилась ус пешно; • действие, которое может быть выполнено во вводе. Правила расчета DET для ЕО: • каждое распознаваемое пользователем нерекурсивное поле, участвующее в процессе вывода; • поле, которое физически отображается в виде нескольких полей его составляющих, но используемое как единый ин формационный элемент; • каждый тип метки и каждое значение числового эквивален та при графическом выводе; • текстовая информация, которая может содержать одно сло во, предложение или фразу; • литералы не могут считаться элементами данных; • переменные, определяющие номера страниц или генериру емые системой логотипы не являются элементами данных. Правила расчета DET для EQ. Правила определения ОЕТдля вводной части: • каждое распознаваемое пользователем нерекурсивное поле, появляющееся во вводной части запроса; • каждое поле, которое определяет критерий выбора данных; • группа полей, в которых выдаются сообщения о возникаю щих ошибках в процессе ввода информации в DET или подтверждающих успешное завершение процесса ввода; • фуппа полей, которые позволяют выполнять запросы. Правила определения ОЕТдля выводной части: • каждое распознаваемое пользователем нерекурсивное поле, которое появляется в выводной части запроса; • логическое поле, которое физически отображается как группа полей, однако воспринимается пользователем как единое поле; • группа полей, которые в соответствии с методикой обработ ки могут повторяться в ILF; • литералы не могут считаться DET. • колонтитулы или генерируемые системой иконки не могут считаться DET. Сложность EQ определяется как максимальная из сложнос тей EI и ЕО, связанных с данным запросом. ПОДСЧЕТ КОЛИЧЕСТВА ФУНКЦИОНАЛЬНЫХ ТОЧЕК Для каждого функционального типа подсчитывается количе ство входящих в его состав функциональных точек (function point, FP) — условных элементарных единиц. Коммуникации данных 0 Полностью пакетная обработка на локальном ПК 1 Пакетная обработка, удаленный ввод данных или удаленная печать 2 Пакетная обработка, удаленный ввод данных и удаленная печать Сбор данных в режиме «онлайн» или дистанционная обработка, свя занная с пакетным процессом 4 Несколько внешних интерфейсов, один тип коммуникационного протокола 5 Несколько внешних интерфейсов, более одного типа коммуникаци онного протокола Распределенная обработка данных 0 Передача данных или процессов между компонентами системы от сутствует 1 Приложение готовит данные для обработки на ПК конечного поль зователя 2 Данные готовятся для передачи, затем передаются и обрабатываются на другом компоненте системы (не на ПК конечного пользователя) 3 Распределенная обработка и передача данных в режиме «онлайн» только в одном направлении 4 Распределенная обработка и передача данных в режиме «онлайн» в обоих направлениях 5 Динамическое выполнение процессов в любом подходящем компо ненте системы Производительность 0 К системе не предъявляется специальных требований, касающихся производительности 1 Требования к производительности определены, но не требуется ни каких специальных действий 2 Время реакции или пропускная способность являются критически ми в пиковые периоды. Не требуется никаких специальных решений относительно использования ресурсов процессора. Обработка мо жет быть завершена в течение следующего рабочего дня 3 Время реакции или пропускная способность являются критически ми в обычное рабочее время. Не требуется никаких специальных ре шений относительно использования ресурсов процессора. Время обработки ограничено взаимодействующими системами 4 То же, кроме того, пользовательские требования к производитель ности достаточно серьезны, чтобы ее необходимо было анализиро вать на стадии проектирования 5 То же, кроме того, на стадиях проектирования, разработки и (или) реализации для удовлетворения пользовательских требований к производительности используются специальные средства анализа Эксплуатационные ограничения 0 Какие-либо явные или неявные ограничения отсутствуют 1 Эксплуатационные офаничения присутствуют, но не требуют ника ких специальных усилий 2 Должны учитываться некоторые ограничения, связанные с безопас ностью или временем реакции 3 Должны учитываться конкретные требования к процессору со сто роны конкретных компонентов приложения 4 Заданные эксплуатационные ограничения требуют специальных ог раничений на выполнение приложения в центральном или выделен ном процессоре 5 То же, кроме того, специальные офаничения затрагивают распреде ленные компоненты системы Частота транзакций 0 Пиковых периодов не ожидается 1 Ожидаются пиковые периоды (ежемесячные, ежеквартальные, еже годные) 2 Ожидаются еженедельные пиковые периоды 3 Ожидаются ежедневные пиковые периоды 4 Высокая частота транзакций требует анализа производительности на стадии проектирования 5 То же, кроме того, на стадиях проектирования, разработки и (или) внедрения необходимо использовать специальные средства анализа производительности Ввод данных в режиме «онлайн» 0 Все транзакции обрабатываются в пакетном режиме 1 От 1% до 7% транзакций требуют интерактивного ввода данных 2 От 8% до 15% транзакций требуют интерактивного ввода данных 3 От 16% до 23% транзакций требуют интерактивного ввода данных 4 От 24% до 30% транзакций требуют интерактивного ввода данных 5 Более 30% транзакций требуют интерактивного ввода данных Эффективность работы конечных пользователей^ О Ни одной из перечисленных функциональных возможностей^ ^ От одной до трех функциональных возможностей 2 От четырех до пяти функциональных возможностей 3 Шесть или более функциональных возможностей при отсутствии конкретных пользовательских требований к эффективности ^ То же, кроме того, пользовательские требования к эффективности требуют специальных проектных решений для учета эргономичес ких факторов (например, минимизации нажатий клавиш, максими зации значений по умолчанию, использования шаблонов) Эффективность работы конечных пользователей 5 То же, кроме того, пользовательские требования к эффективности требуют применения специальных средств и процессов, демонстри рующих их выполнение ^Эффективность работы конечных пользователей определяется наличи ем следующих функциональных возможностей. • Средства навигации (например, функциональные клавиши, дина мически генерируемые меню). • Меню. • Онлайновые подсказки и документация. • Автоматическое перемещение курсора. • Скроллинг. • Удаленная печать. • Предварительно назначенные функциональные клавиши. • Выбор данных на экране с помощью курсора. • Использование видеоэффектов, цветового вьщеления, подчерки вания и других индикаторов. • Всплывающие окна. • Минимизация количества экранов, необходимых для выполнения бизнес-функций. • Поддержка двух и более языков. Онлайновое обновление 0 Отсутствует 1 Онлайновое обновление от одного до трех управляющих файлов Объем обновлений незначителен, восстановление несложно 2 Онлайновое обновление четырех или более управляющих файлов Объем обновлений незначителен, восстановление несложно 3 Онлайновое обновление основных внутренних логических файлов 4 То же, плюс необходимость специальной защиты от потери данных 5 То же, кроме того, большой объем данных требует учета затрат на процесс восстановления. Требуются автоматизированные процеду ры восстановления с минимальным вмешательством оператора Сложная обработка^ 0 Ни одной из перечисленных функциональных возможностей^ 1 Любая одна из возможностей 2 Любые две из возможностей ^ Любые три из возможностей ^ Любые четыре из возможностей 5 Все пять возможностей • повышенная реакция на внешние воздействия и (или) специаль ная защита от внешних воздействий; • экстенсивная логическая обработка; • экстенсивная математическая обработка; • обработка большого количества исключительных ситуаций; • поддержка разнородных типов входных/выходных данных. Повторное использование 0 Отсутствует 1 Повторное использование кода внутри одного приложения 2 Не более 10% приложений будут использоваться более чем одним пользователем 3 Более 10% приложений будут использоваться более чем одним поль зователем 4 Приложение оформляется как продукт и (или) документируется для облегчения повторного использования. Настройка приложения вы полняется пользователем на уровне исходного кода. 5 То же, с возможностью параметрической настройки приложений Простота установки 0 К установке не предъявляется никаких специальных требований. 1 Для установки требуется специальная процедура 2 Заданы пользовательские требования к конвертированию (переносу существующих данных и приложений в новую систему) и установке, должны быть обеспечены и проверены соответствующие руковод ства. Конвертированию не придается важное значение 3 То же, однако конвертированию придается важное значение. 4 То же, что и в случае 2, плюс наличие автоматизированных средств конвертирования и установки 5 То же, что и в случае 3, плюс наличие автоматизированных средств конвертирования и установки Простота эксплуатации О К эксплуатации не предъявляется никаких специальных требова ний, за исключением обычных процедур резервного копирования 1—4 Приложение обладает одной, несколькими или всеми из перечис ленных далее возможностей. Каждая возможность, за исключением второй, обладает единичным весом: 1) наличие процедур запуска, копирования и восстановления с участием оператора; 2) то же, без участия оператора; 3) минимизируется необходимость в монтирова нии носителей для резервного копирования; 4) минимизируется не обходимость в средствах подачи и укладки бумаги при печати 5 Вмешательство оператора требуется только при запуске и заверше нии работы системы. Обеспечивается автоматическое восстановле ние работоспособности приложения после сбоев и ошибок Количество возможных установок на различных платформах 0 Приложение рассчитано на установку у одного пользователя 1 Приложение рассчитано на много установок для строго стандартной платформы (технические средства + программное обеспечение) 2 Приложение рассчитано на много установок для платформ с близ кими характеристиками 3 Приложение рассчитано на много установок для различных плат форм 4 То же, что в случаях 1 или 2, плюс наличие документации и планов поддержки всех установленных копий приложения 5 То же, что в случае 3, плюс наличие документации и планов под держки всех установленных копий приложения П|бкость^ 0 Ни одной из перечисленных возможностей^ 1 Любая одна из возможностей 2 Любые две из возможностей 3 Любые три из возможностей 4 Любые четыре из возможностей 5 Все пять возможностей ^ Гибкость характеризуется наличием у приложения следующих воз можностей: • поддержка простых запросов, например, логики и (или) в приме нении только к одному ILF (вес — 1); • поддержка запросов средней сложности, например, логики и (или) в применении более чем к одному ILF (вес - 2); • поддержка сложных запросов, например, комбинации логических связок и (или) в применении к одному или более ILF (вес — 3); • управляющая информация хранится в таблицах, поддерживаемых пользователем в интерактивном режиме, однако эффект от ее из менений проявляется на следующий рабочий день; • то же, но эффект проявляется немедленно (вес — 2). После определения всех значений GSC и вычисления попра вочного коэффициента VAF вычисляется итоговая оценка коли чества функциональных точек (Adjusted Function Points, AFP): AFP = UFP * VAF. | |
| Просмотров: 6712 | |
| Всего комментариев: 0 | |