Pf Aplicado A Casos De Uso

Calidad del Software - Content

Inicio

Gestión de calidad Gestión de proyectos Gestión de requisitos Gestión de la configuracion Eventos Mejora de proceso Métricas Otros Libros Enlaces

Usuarios

Page 1 of 4

Pruebas

Puntos Función aplicados a Casos de Uso

Usuario Contraseña

Introducción

Código de Seguridad: Copia Código de Seguridad Login

¿Todavía no tienes una cuenta? REGISTRATE !

ACTIVIDADES ·Resumen Eventos ·Empresas Evaluadas CMMI ·Exposición Virtual

Aplicar el Análisis de Puntos función a Casos de Uso no sólo es fácil sino que es una conexión natural. Los Puntos Función continúan siendo el método más popular de medir aplicaciones software, los Casos de Uso están siendo utilizados ampliamente para describir los requisitos de una aplicación software. Los Puntos Función son un método para medir el software desde una perspectiva de los requisitos y los Casos de Uso son un método para desarrollar requisitos. Los Puntos Función y los Casos de uso intentan ser independientes de la tecnología utilizada para implantar una solución software. Los Casos de Uso sirven para validar un diseño propuesto y asegurar que cumple todos los requisitos. Un objetivo de los Casos de Uso es intentar definir los requisitos lo antes posible en el ciclo de vida. Si los Casos de uso se definen tempranamente y se aplican puntos función, las estimaciones de los proyectos serán mucho más seguras. Dado que los Puntos Función tienen una gran base histórica, podremos comparar la productividad de utilizar métodos de Casos de uso con otros métodos.

BUSCAR En la pagina:

En la web:

Glosario:

Qué son los puntos función? El análisis de Puntos Función está fundamentado en la teoría de que las funciones de una aplicación son la mejor medida del tamaño de una aplicación software. Los Puntos Función miden el software cuantificando la funcionalidad del mismo pedida por el usuario y apoyándose en el diseño lógico. Un diseño lógico especifica el flujo de información a través de un sistema sin tener en cuenta la implantación física. El “usuario” en el análisis de puntos función es alguien que entiende el sistema desde una perspectiva funcional, alguien que entrega requisitos o ejecuta pruebas de aceptación. Es decir, los Puntos Función miden el tamaño de un sistema de información según la forma en que estos usuarios ven e interactúan con dicho sistema. El análisis de Puntos Función parte el sistema en pequeños componentes de modo que los usuarios, desarrolladores y directores pueden entender mejor las funciones de un sistema, algo parecido a los casos de uso. En el mundo de los PF, los sistemas se dividen en componentes. Los primeros tres componentes son las entradas externas, salidas externas y consultas externas al sistema. Cada una de esas transacciones agregan cambian, borran o recuperan información contenida en archivos, de allí que se les denomine transacciones. Los otros dos componentes son archivos del sistema: archivos lógicos internos y archivos de interfaz externa. Estos almacenan información lógica como por ejemplo: nombre, dirección y número de teléfono de un cliente. Beneficios El método de Casos de Uso captura los requisitos considerando la forma en que el usuario usará realmente el sistema, en lugar de hacerlo desde la perspectiva de las características que se pide al sistema que incorpore. Este brillantemente simple concepto significa que la documentación de los requisitos puede también usarse como base para los manuales de formación de los usuarios y para establecer los criterios de las pruebas de aceptación. Esto significa también que el mismo documento puede utilizarse para contar Puntos Función (o medir el proyecto).La utilización del mismo documento garantiza un alto nivel de seguridad. Es mucho mejor comunicar al director que un proyecto ha crecido desde 300 a 900 PF, tres veces más, que decir que el proyecto “ha crecido mucho”. Si se conoce la medida del proyecto lo antes posible en el ciclo de vida, mejor se estimará el tiempo y coste del desarrollo. También, si los datos de los Casos de Uso y los Puntos Función se guardan, se facilitará la estimación de los proyectos y se entenderán las variaciones. Límites de la aplicación Uno de los primeros pasos que se describen en Casos de Uso y en Análisis de Puntos Función es identificar los límites del sistema. Un límite es algo que representa una interfaz entre el sistema y sus actores. Los límites pueden ser una pantalla o una interfaz de usuario o la llamada a otro sistema. IFPUG define un límite como la frontera entre el software que va a medirse y el dominio del usuario. Los dos métodos, Análisis de Puntos Función y CU, definen los límites del sistema de una forma muy parecida. En artículos anteriores, he descrito un “usuario” como una persona que entiende el flujo de eventos. En CU, se examinan desde una perspectiva de “actores”. Cuando el autor crea un Casos de Uso necesita determinar, entre otras cosas, los actores que podrán crear, leer, actualizar o borrar información. Lo mismo es aplicable en el Análisis de Puntos Función, sólo que en Análisis de Puntos Función hablamos de “usuarios” en lugar de “actores”. Resumiendo, actor y usuario son sinónimos en los dos métodos. Frecuentemente, los autores de Casos de Uso

http://www.calidaddelsoftware.com/modules.php?name=Content&pa=showpage&pid=40

27/02/2009

Calidad del Software - Content

Page 2 of 4

mezclan los términos actor y usuario. Cuál es el tamaño medio de un Caso de Uso Depende de cuán grande se haga el Casos de Uso. Es mejor poner un límite al tamaño del Casos de Uso para poder controlarlo. Normalmente, el tamaño máximo de Casos de Uso no debería ser mayor de 50 Puntos Función. Cuando un Casos de Uso se hace demasiado grande se vuelve difícil de entender. Poniendo unos límites adecuados, se verá claramente cuando un Casos de Uso es demasiado grande y necesita ser dividido en Casos de Uso más pequeños. La aplicación de Puntos Función mejora la calidad los Casos de Uso. Si el Análisis de Puntos Función se utiliza mientras se lee un Caso de Uso, el Caso de Uso se lee con un propósito en el cabeza (lectura activa en lugar de lectura pasiva). La aplicación de Análisis de Puntos Función ayuda a determinar si los Casos de Uso tienen el nivel de detalle adecuado. Es decir, si es posible describir la forma en que los datos pasan el límite entre actor y sistema y como fluyen desde el sistema hacia el actor, entonces se tiene el nivel de detalle correcto. Por otra parte, si no se puede describir este nivel de funcionalidad, entonces el Casos de Uso necesita más detalle. Lo esencial es que si se pueden contar puntos función se tiene el nivel de detalle adecuado. Definiciones IFPUG creó las definiciones para cada tipo de transacción apoyándose en una gran variedad de términos de la industria. Las siguientes definiciones han sido adaptadas para el método de Casos de Uso, pero cumplen con los estándares de IFPUG y otros estándares de la industria. Hay 5 componentes principales que se usan en Análisis de Puntos Función (transacciones y archivos) Transacciones

Hazme tu pagina de inicio Ponme en favoritos

Encuesta Necesitamos su opinión para mejorar el portal. ¿Cuáles son sus contenidos preferidos?

Uno o más pasos en el flujo de eventos definen las transacciones Un Casos de Uso puede tener una o más transacciones Los escenarios secundarios ayudan a entender la transacción Las transacciones son entradas externas, salidas externas o consultas externas. Entrada externa (EI). Proceso elemental que introduce dentro de los límites de la aplicación un conjunto de datos o información de control. Pantallas, formularios, cuadros de diálogo, controles o mensajes. (IFPUG) Los datos vienen desde el actor. El actor puede agregar, cambiar y borrar información de un fichero lógico interno. El dato puede ser información de control o información de negocio. Si el dato es información de control no se almacena en un fichero lógico interno. Salida externa(EO). Proceso elemental que envía fuera de los límites de la aplicación un conjunto de datos o información de control. Los datos han sido derivados o calculados. (IFPUG) El dato es enviado a un actor del sistema. Los datos figuran en informes o archivos de salida que se crean desde información contenida en uno o más archivos lógicos internos o archivos de interfaz externa. Consulta Externa (EQ) Proceso elemental que envía fuera de los límites de la aplicación un conjunto de datos o información de control. Los datos se extraen y presentan sin manipulación previa. (IFPUG) Un proceso elemental con componentes de entrada y salida donde un actor recibe datos desde uno o más ficheros lógicos internos y ficheros de interfaz externa. El proceso de entrada no actualiza ni mantiene ningún fichero y la salida no contiene datos derivados o calculados.

Artículos técnicos Noticias Noticias de América de habla hispana Libros Eventos Cursos Boletín a mi correo Grupo Calidad del Software Noticias del SEI Enlaces voto

Resultados Encuestas votos 94

Archivos Los archivos que deben incluirse en el conteo de puntos función son Archivos Lógicos Internos y Archivos de Interfaz externa. Estos pueden reconocerse fácilmente en el modelo lógico de datos (diseño de base de datos relacionales). Frecuentemente los Casos de Uso incluyen una sección titulada “Casos de Uso Subordinados “ que incluyen una lista de todos loa CUs. Hay una fuerte relación entre el modelo lógico de datos y los archivos lógicos internos. Archivo Lógico Interno (ILF) Es un grupo de datos relacionados lógicamente o de información de control identificable por el usuario, mantenido dentro de los límites de la aplicación. (IFPUG) Archivo de Interfaz Externo (EIF) Es un grupo de datos relacionados lógicamente o de información de control identificable por el usuario, utilizado por la aplicación pero mantenido dentro de los límites de otra aplicación. (IFPUG) La diferencia principal entre EIF e ILF es que a un EIF lo mantienen otras aplicaciones, no la que se está analizando. Los archivos contribuyen al conteo de Puntos Función según el número de elementos de datos (o atributos) y el tipo de registros. Normalmente, la mayoría de las tablas tienen sólo un tipo de registro. Ejemplo UML .

http://www.calidaddelsoftware.com/modules.php?name=Content&pa=showpage&pid=40

27/02/2009

Calidad del Software - Content

Page 3 of 4

. El diagrama muestra la forma en que un actor puede mantener las citas. Los primeros tres Casos de Uso: agregar cita, modificar cita y borrar cita, representan tres entradas externas (EI). Buscar cita es una consulta externa (EQ). En este nivel de detalle es imposible asignar el número correcto de elementos de datos y tipos de archivos referenciados, pero en este punto del ciclo de vida lo más importante es aclarar y presentar un inventario de todas las transacciones. Según se avanza, puede establecerse el número real de DET’s y FTR’s y aplicar el factor de complejidad adecuado a las transacciones, en este momento es suficiente calcular las transacciones como media. En sitio web www.SoftwareMetrics.Com contiene todas las tablas que pueden ayudar a valorar las transacciones en detalle. El número estimado de Puntos Función sin ajustar podría ser 3 EI’s x 4 = 12 1 EQ x 4 = 3 El número total de Puntos Función sin ajustar es aproximadamente 15. Un problema potencial con el conteo de Puntos Función desde UML es que no hay suficiente detalle. Hay que tener en cuenta que el actor interactúa con muchos casos de usos y cada caso de uso puede incluir varias transacciones, no sólo una. Una transacción es un una entrada interna (EI) , una salida externa (EO) o una consulta externa (EQ). EJEMPLO CASO DE USO Los Puntos Función resultan evidentes en el flujo de eventos dentro del Caso de Uso. Cada paso dentro del flujo de eventos puede ser una transacción única o varios pasos combinados pueden constituir una transacción única. Los escenarios al final de los casos de uso pueden ayudar a definir las transacciones. Casos de Uso Buscar pedido. 1 - El usuario puede introducer el ID del pedido, el ID del cliente o el nombre del cliente. 2 - El usuario presiona “Buscar” 3 - Si el usuario introduce el ID del pedido 3 - a - El sistema muestra ese pedido 4 - Si el usuario introduce el nombre o el ID del cliente 4 - a - El sistema devuelve una lista de todos los pedidos de ese cliente y muestra fecha e ID del pedido. 4 - b - El usuario selecciona un pedido desde la lista 4 - c - El sistema buscará por ID de pedido 4 - d - El sistema mostrará el pedido Aplicación de los PF Pasos 1 y 2 definen el lado de las entradas de las EQ’s mientras que los pasos 3 y 4 definen el lado de las salidas. El paso 3 describe una consulta externa. En el lado de las entradas esta la ID del pedido, en el lado de las salidas está el detalle del pedido. Esta combinación constituye la consulta externa. El paso 4 describe dos consultas externas, pero la segunda consulta es una repetición de la consulta descripta en el paso 3a. Los pasos 4 y 4ª describen la segunda consulta externa. El Caso de Uso Buscar pedidos incluye dos Consultas externas (resumen y detalle) A la vez que se van actualizando los Caso de Uso incluyendo elementos como capturas de pantallas, el número de Puntos Función puede actualizarse y mejorar la estimación. Desde el tamaño al esfuerzo El mejor método para estimar es utilizar los datos de la bases de datos históricos de la propia

http://www.calidaddelsoftware.com/modules.php?name=Content&pa=showpage&pid=40

27/02/2009

Calidad del Software - Content

Page 4 of 4

organización. Esto es, establecer una base de datos histórica de proyectos que registre tamaño, coste y duración. Los datos históricos serán la mejor fuente para la estimación de proyectos futuros. Esto es verdad incluso si los datos históricos fueron desarrollos sobre aplicaciones heredadas. En la ausencia de datos históricos propios, pueden utilizarse medias de la industria. El problema con estas medias es que pueden tener grandes variaciones debido a factores no conocidos. En un entorno de aplicaciones heredadas COBOL, el cálculo está entre 4-12 Puntos Función por mes de trabajo mientras que en aplicaciones desarrolladas en entornos GUI la productividad puede ser 20 veces mayor. La mayoría de los entornos de CU, por no decir todos, son GUI y utilizan lenguaje como Visual Basic, Forte o Dynasty. Tamaño en PF 10 100 1000 5,000 10,000

Horas por PF 1-2 3-5 9 - 11 15-18 25-35

Nro. probable CUs 1o2 5 - 10 20 - 35 50 – 65 200 - 350

Resumen El método de Casos de Uso y el análisis de Puntos Función no son métodos contradictorios sino complementarios. El Análisis de Puntos Función puede aplicarse al método de Casos de Uso muy fácilmente. Uno de los problemas para calcular los puntos función es no tener un conjunto de requisitos completo y consistente. Adoptando el método de Casos de Uso y el Análisis de Puntos Función la calidad del documento de requisitos puede mejorarse, y también el cálculo del tamaño y la estimación en general. Ahora que se puede aplicar el Análisis de Puntos Función e los CU, se puede empezar a estimar el proyecto en las fases tempranas del ciclo de vida. También se puede actualizar el conteo de Puntos Función cuando cambia el CU. Esto permite detallar Casos de Uso individuales y recalcular el tamaño total del proyecto. Con los ajustes adecuados se puede calcular el tamaño de las aplicaciones software, monitorizar la productividad y calidad. Con suerte, se puede mejorar el proceso y ver una mejora en calidad y productividad.

Copyright Longstreet Consulting Inc. 1995 -2003 www.SoftwareMetrics.Com [email protected] Longstreet Consulting Inc. 2207 S. West Walnut St. Blue Springs, MO 64015 (816) 739-4058 Traducción: Equipo www.CalidaddelSoftware.com

Copyright © por Calidad del Software . Todos los Derechos Reservados. Publicado en: 2007-11-06 (3753 Lecturas)

[ Volver Atrás ] Content © CalidaddelSoftware.com © 2004-2009 Publicidad en el portal Soportado por CAELUM (Information & Quality Technologies)

http://www.calidaddelsoftware.com/modules.php?name=Content&pa=showpage&pid=40

27/02/2009