SG #15

ViveLinux: Academia y profesionistas unen esfuerzos

sg — Wed, 20 Jun 2007 18:15:43 +0000

ViveLinux: Academia y profesionistas unen esfuerzos sg Wed, 06/20/2007 - 13:15

Publicado en

SG #15

Tierra libre

Autor

Sonia Sánchez

Si bien es cierto que cada vez más personas y organizaciones se convencen de las bondades del software libre, también es cierto que difundirlo nunca estará de más. Esta es la razón de ser del proyecto ViveLinux, al que podemos describir como una campaña de promoción y difusión del uso de GNU/Linux y el Software Libre (SL) en instituciones educativas de nivel medio superior y superior en el estado de Morelos.

Origen

Este proyecto surgió gracias al interés de una de las docentes del plantel Yecapixtla del Colegio de Estudios Científicos y Tecnológicos (CECYT) del Estado de Morelos de sembrar entre sus alumnos un interés por el software libre, ya que además de las ventajas de uso que ofrece, es una excelente herramienta de educación para el desarrollo de software. Fue así que la profesora se acercó a uno de los miembros del Grupo de Usuarios de Software Libre de Cuautla (GRUSLIC), y entonces surgió la iniciativa de este proyecto.

¿Y entonces?

El primer paso fue redactar un manifiesto donde se establecieron los lineamientos del proyecto. Esto permite alinear esfuerzos y tener una mejor organización. El siguiente paso ha sido el de desarrollar materiales para sesiones educativas orientados al ámbito del SL.

Las sesiones pueden tener alguna de las siguientes modalidades:

Pláticas de introducción.
Tutoriales.
Talleres.
Sesiones de Instalación, mejor conocido como InstallFest.
Integración a proyectos de Software Libre.
Los temas son propuestos por los mismos profesores de los planteles y miembros del Gruslic, y típicamente se enfocan en alguna de las siguientes áreas de interés:
- Introducción al SL.
- Filosofía de la comunidad de SL.
- Desarrollo Web.
- Lenguajes de Programación.
- Redes.
- Diseño Gráfico.

Dado que la audiencia de las sesiones puede tener diferentes niveles de conocimiento y experiencia, las sesiones son clasificadas de acuerdo a los siguientes niveles de complejidad:

Básico: Temas fundamentales sobre el movimiento y uso del Software Libre.
Medio: Se enfocan en el uso y configuración de tecnologías y herramientas específicas, por lo que la audiencia debe al menos estar familiarizada con éstas.
Avanzado: Orientados a temas como seguridad, compilación, configuración de servicios, combinación e integración de tecnologías.

Resultados

La primera visita a un CECYT se realizó en septiembre del 2006. A la fecha se han realizado 6 visitas a 4 diferentes planteles, siendo estos los de Yecapixtla, Tenextepango, Emiliano Zapata, y Tlayecac. Cabe destacar que en el plantel de Emiliano Zapata ya se realizó un InstallFest, y se habilitó una de sus CompuAulas con software libre.

Estas visitas y la difusión de sus logros, han tenido como consecuencia que Universidades de otros estados contacten al grupo para llevar hasta sus aulas una sesión de pláticas adaptadas a las necesidades del auditorio, tomando en cuenta los lineamientos que señala el manifiesto.

¿Dónde encuentro más información?

El wiki del manifiesto está disponible y esperando tu colaboración. Este lo puedes encontrar en http://wiki.gruslic.org.mx/Vive_linux

Así mismo, el Grupo de Usuarios de Software Libre de Cuautla (www.gruslic.org.mx) espera tu participación y que te unas a nosotros para promover este manifiesto. Todos los comentarios son bien recibidos, y la ayuda aún más. Contáctanos en
http://groups.google.com.mx/group/gruslic.

Conclusión

La inquietud de una profesora de informática a nivel bachillerato dio pauta para el nacimiento del proyecto que en poco más de 6 meses de vida ha recorrido cuatro municipios del estado de Morelos, y está generando interés en otros estados. Esta es una muestra de cómo la academia y los profesionistas pueden trabajar en conjunto para llevar nuevas opciones de aprendizaje a los estudiantes de nuestro país.

Bio

Sonia Sánchez es Licenciada en Informática, dedicada al desarrollo de soluciones basadas en Software Libre. Es miembro activo del Grupo de Usuarios de Software Libre de Cuautla y ha sido ponente en congresos como ENLI en Puebla y CICOL en Morelos, y participa frecuentemente en los festivales de instalación de software libre que se realizan en estas entidades.

Reglas de negocio: Administrando la operación con reglas

Anonymous — Tue, 19 Jun 2007 21:56:35 +0000

Reglas de negocio: Administrando la operación con reglas

Anonymous Tue, 06/19/2007 - 16:56

Publicado en

SG #15

Fundamentos

Autor

Jorge Becerril

Los sistemas de información empresariales, están orientados a automatizar la operación de una organización. La operación de toda organización cuenta con condicionantes, políticas o restricciones que ayudan al sistema de información a ejecutar alguna operación de manera correcta, de acuerdo a la exigencia del negocio. Por ello, parte fundamental dentro de los requerimientos de cualquier sistema de información, son las denominadas “reglas del negocio”, las cuales dan orden y disciplina a las operaciones de la organización.

Las reglas del negocio son tan importantes que en los últimos años se han presentando diversas iniciativas y esfuerzos para estandarizarlas y automatizarlas a través de motores de reglas de negocio como es el caso de Biztalk Server de Microsoft, o de Oracle Business Rules.

¿Qué son?

La siempre útil Wikipedia define las reglas de negocio como una descripción de las operaciones, definiciones y restricciones aplicables a una organización para lograr sus metas.

Por otro lado, el Business Rules Group, que es una organización cuyo propósito es fomentar el entendimiento y estandarización del concepto de reglas de negocio, se basa en dos perspectivas para definir una regla de negocio:
• Desde la perspectiva del negocio, es una orientación en la cual hay una obligación conducida por una acción, práctica o proceso, dentro de una particular actividad o giro.
• Desde la perspectiva de sistemas de información, es una declaración que define o restringe algunos aspectos del negocio. Intenta hacer valer la estructura del negocio, o controlar o influir en la conducta del negocio.

Rol dentro de la estructura de requerimientos
Es importante saber ubicar a las reglas del negocio dentro de una estructura de requerimientos. Veamos la siguiente imagen.

En la imagen se puede apreciar una estructura que inicia desde los requerimientos de negocio y termina en la especificación de requerimientos. Como se puede observar, las reglas del negocio son consideradas un aspecto no funcional y se clasifica como requerimiento de usuario.

Características
El mismo Business Rules Group, ha redactado un manifiesto de reglas del negocio. De acuerdo con éste, una regla del negocio deberá cumplir con las siguientes características:
• Se deben expresar de manera que pueda ser validada su exactitud por el personal conocedor del negocio.
• Se deben expresar de manera que se pueda verificar recíprocamente su coherencia.
• Las lógicas formales, como la lógica de predicados, son fundamentales para la expresión formal de reglas en términos de negocio, así como para las tecnologías que implementan dichas reglas.

¿Cómo encontrarlas?
El identificar las reglas del negocio es parte de la labor del Ingeniero de Requerimientos, éste deberá tener la habilidad para poder encontrarlas dentro de un mar de información. Una buena fuente para encontrar reglas del negocio es la información provista por personal directivo o de gerencia, ya que son ellos quiénes definen y avalan las reglas. Otra fuente importante son organismos por los que se rige una emprea, como puede ser el caso de la secretaría de salud que rige a los laboratorios farmacéuticos o como la secretaría de comunicaciones y transportes que rige a las empresas transportistas.

¿Donde especificarlas?
Las reglas del negocio son parte de la columna vertebral del sistema de información, por lo cual deben estar perfectamente especificadas dentro del documento de requerimientos, y deben ser tomadas en cuenta para la fase de pruebas. Si alguna regla del negocio no está siendo aplicada se corre el riesgo de que el sistema arroje resultados incorrectos o permita errores que se traduzcan en perdidas para el negocio.

Algunos ejemplos
Imaginemos un negocio de renta de autos. En este caso, vienen a la mente un par de reglas que podrían ser:
• Los carros rentados en una sucursal pueden ser entregados en otra sucursal.
• Un cliente puede tener varias reservaciones, pero solamente un carro rentado a la vez.

Conclusión
Al momento de hacer el trabajo de requerimientos, es de vital importancia encontrar las reglas del negocio, ya que estas harán del sistema de información un repositorio de datos más seguro y confiable. Al buscar las reglas del negocio, debemos visualizar todo el ambiente que gira en torno al sistema, instituciones u organismos externos, reglamentos y hasta condiciones ambientales.

Referencias
• Business Rules Group
www.businessrulesgroup.org/home-brg.shtml

Bio

Jorge Becerril actualmente se desempeña como consultor en Pounce Consulting, tiene 15 años de experiencia desarrollando software en donde ha desempeñado los roles de programador, analista y líder de proyecto, es egresado de la Universidad del Valle de Atemajac de la carrera de Sistemas Computacionales. bec.jorge@gmail.com, http://ingsoftware.blogspot.com

Caso práctico sobre análisis de punto de función, parte 2

Anonymous — Tue, 19 Jun 2007 19:43:17 +0000

Caso práctico sobre análisis de punto de función, parte 2

Anonymous Tue, 06/19/2007 - 14:43

Publicado en

SG #15

Gestión de Proyectos

Autor

Aquiles Santana

Bienvenidos a la segunda parte de este caso práctico sobre análisis de puntos de función. Como podrán recordar, el objetivo de este ejercicio es mostrar como se utiliza la técnica de puntos de función aplicada a un caso real. En nuestro caso, la aplicación consiste en un sistema para administrar las ventas de automóviles que realiza una empresa de compra-venta de autos usados.

En la parte 1, publicada en el número de Marzo-Abril 2007, planteamos los requerimientos iniciales, en los cuales nos basaremos para realizar el análisis. Para poder dar seguimiento a este caso, es necesario tener a la mano dicho artículo, así que por favor rescaten su ejemplar impreso, o descarguen el PDF del sitio web de SG.

Como se comentó en la parte anterior, el proceso para el análisis de puntos funcionales está formado por los siguientes pasos:
1. Determinar el tipo de conteo
2. Identificar el alcance, propósito y límites de la aplicación
3. Contar las funciones de datos
4. Contar las funciones transaccionales
5. Determinar los puntos de función no ajustados
6. Determinar el valor del factor de ajuste
7. Determinar los puntos de función ajustados

1. Determinar el tipo de Conteo
El IFPUG distingue entre 3 tipos de conteos:
• Conteo de Proyectos de Nuevo Desarrollo
• Conteo de Proyectos de Mantenimiento
• Conteo de Aplicaciones

En el caso de nuestro ejemplo, no existe una aplicación ya desarrollada que se vaya a complementar o modificar, así que estamos hablando de un nuevo desarrollo.

2. Identificar el alcance, propósito y límites de la aplicación
La identificación del alcance, es normalmente establecida en la fase de inicio o planeación del proyecto, y típicamente está documentada en forma de requerimientos de alto nivel, especificaciones funcionales, casos de uso, etc. Es común que al inicio del proceso no tengamos los requerimientos completos, pero esto no significa que no podamos continuar con el conteo. Lo que se hace en estas situaciones es complementar o llenar los vacíos de los requerimientos estableciendo supuestos que deberán ser documentados y validados con el experto de la aplicación o del negocio. La idea final es que el conteo de Puntos de Función sea reflejo fiel de los requerimientos y los supuestos. Si estos cambian, el conteo también deberá ser actualizado.
Los límites de la aplicación, establecerán la funcionalidad que será considerada externa a la aplicación. Para establecer dichos límites se tomará el punto de vista del usuario y nunca un criterio técnico o de implementación. De esta forma, si tenemos una aplicación en donde la parte batch, obtiene y procesa información para crear tablas temporales que después serán utilizadas para generar reportes on-line, dicha aplicación será considerada como una sola aplicación para este propósito.

Aplicación al caso
Alcance. El alcance es todo lo documentado en la parte 1 de este artículo (pantallas y descripciones). Así mismo, hay cosas que no están documentadas y que deberán ser asumidas con base a nuestra experiencia. Por ejemplo, en los requerimientos no se indica si habrá un login y administración de usuarios y perfiles, entonces nuestro supuesto asociado al alcance será:
• Se asume que no se requerirá funcionalidad para el manejo de seguridad.

Este supuesto será documentado y se le dará seguimiento durante el ciclo de vida, con el fin de validarlo e identificar aquellas situaciones que lo invaliden, para que en su caso, se haga una actualización del conteo.

Propósito. El conteo de puntos de función será utilizado como herramienta para la estimación, ejecución y control y cierre del proyecto. Precisamente, el propósito quedaría planteado de la forma siguiente:
1. Estimar el esfuerzo, duración y personal requeridos por el proyecto de desarrollo, utilizando algún modelo de estimación estadístico y una Base de Datos de Proyectos Históricos.
2. Controlar el crecimiento de tamaño a lo largo del ciclo de vida.
3. Controlar la cantidad de producto que es generado a lo largo del proyecto.
4. Evaluar productividad (Puntos de Funcion / Personas-Mes) y Calidad (Defectos / Puntos de Función) para dar información a los procesos de Mejora Continua del Desarrollo de Software y alimentar la Base de Datos de Proyectos Históricos que será utilizada en futuras estimaciones.

Límites de la aplicación. En la descripción del caso práctico, se describe la funcionalidad para la venta de artículos por Internet y también se hace referencia al Sistema de Inventario de Vehículos. Desde el punto de vista del usuario, se trata de aplicaciones independientes, puesto que las necesidades de negocio son diferentes e incluso los usuarios que atienden son distintos. De esta forma, tenemos 2 aplicaciones:
•Aplicación de Venta de Vehículos por Internet (la que vamos a desarrollar)
•Aplicación de Inventario de Vehículos (será referenciada por nuestra aplicación)

Aunque parezca trivial, el correcto establecimiento de las fronteras es crítico para validar la completitud y consistencia del conteo.

3. Contar las Funciones de Datos
En este paso, primero debemos identificar los almacenamientos lógicos (también conocidos como entidades de información), en cuanto a que sean totalmente independientes y que tengan un significado para el usuario. Por ejemplo, índices, tablas temporales son considerados almacenamientos técnicos creados con propósitos de implementación y no contribuyen al tamaño funcional de la aplicación. Así mismo, catálogos que contienen sólo un ID y una descripción, son almacenamientos considerados como “Code Table” y tampoco tendrán una contribución en el tamaño funcional. El punto clave para agrupar los almacenamientos lógicos, es verificando la dependencia entre ellos. Una pregunta clave, es respondernos si dicho almacenamiento puede existir de manera aislada, o si para tener significado debe formar parte de otro almacenamiento. Por ejemplo: Si tenemos la tabla de empleado, y la tabla telefonos_empleado, ambas son consideradas como un solo almacenamiento lógico, ya que telefonos_empleado no tiene significado por si sola.

Otra forma de ver esta independencia es preguntarnos: Si desaparece un registro de la tabla de empleado ¿tiene sentido para el negocio conservar el registro asociado en telefonos_empleado?. Si la respuesta es positiva, entonces se considera que cada entidad puede existir de manera independiente y por lo tanto serán dos almacenamientos lógicos. Por el contrario, si la respuesta es negativa, los almacenamientos no existen de manera independiente, y por lo tanto son un solo almacenamiento lógico.

Una vez agrupado e identificado el almacenamiento lógico, lo clasificaremos en ILF (Internal Logical File) o un EIF (External Interface File). Será ILF si dicho almacenamiento es mantenido por al menos una funcion transaccional dentro de la aplicación que contamos. Por otro lado, será un EIF si dicho almacenamiento es UNICAMENTE referenciado y no mantenido por la aplicación que estamos contando.

Para determinar la complejidad de un almacenamiento, ya sea ILF o EIF, se debe hacer un conteo de lo que se conoce como DETs y RETs. Los DETs son los campos de datos únicos e identificables por el usuario y por otro lado, los RETs, son los subgrupos de datos en el mismo almacenamiento y que son identificables por el usuario, cuando en el almacenamiento no hay subgrupos de datos, se considera que el almacenamiento tiene un solo RET.
Por último, la contribución en function points del almacenamiento, será obtenido con base a la complejidad y tipo de almacenamiento, utilizando las siguientes tablas:

Tabla 1. Tabla para determinar complejidad de funciones de datos

Tabla 2. Puntos de función correspondientes a funciones de datos de acuerdo a su complejidad

Aplicación al caso
En nuestro caso práctico, vemos que el Sistema de Inventario de Vehículos, tiene responsabilidad de mantener las tablas de “vehículo” y “accesorios_vehículo”. Dichos almacenamientos forman un solo almacenamiento lógico llamado “vehículo”, puesto que el almacenamiento de “accesorios_vehículo” no tiene significado por sí solo. Dicho almacenamiento de “vehículo” es referenciado por nuestra aplicación, pero no es mantenido por esta, por lo cual es catalogado como un “EIF”.

La complejidad de nuestro almacenamiento está en función de sus DETs y RETs. Para ver el número de DETs debemos ver los campos que son únicos e identificables por el usuario. En este caso tenemos número de serie, marca, modelo, año-modelo, color, kilometraje, condición, foto, precio, disponibilidad y nombre accesorio, para un total de 11 DETs. Para este almacenamiento, no existen subgrupos de información, por lo que el almacenamiento tendrá un solo RET. De acuerdo a esto, usando los valores de las tablas 1 y 2 determinamos que nuestro almacenamiento corresponde a una complejidad baja, y una contribución de 5 puntos de función.

Por otro lado, existe otro almacenamiento que debemos considerar, y es el de “Compra”. En dicho almacenamiento, son guardados los datos del comprador, su financiera, su aseguradora, el ID de la compra y el número de serie del vehículo comprado. Al ser mantenido por la aplicación que estamos contando, dicho almacenamiento se clasifica como “ILF”, y al contar sus campos únicos identificables por el usuario, llegamos a un total de 13 DETs. No tenemos subgrupos de información identificables por el usuario, así que tenemos un solo RET. Buscando en las tablas, encontramos que dicho almacenamiento corresponde a una complejidad baja y corresponde a 7 puntos.

4. Contar las Funciones Transaccionales
Este es uno de los pasos que tienen mayor impacto en el conteo de los Puntos de Función y comienza con la identificación de los Procesos Elementales. Un proceso elemental es la unidad mínima de actividad significativa al usuario, que deja al negocio en un estado consistente y es autocontenido.

Una vez identificado el proceso elemental, éste debe ser clasificado para convertirse en una función transaccional. Existen 3 tipos de funciones transaccionales: EI (External Input), EQ (External Inquiry), y EO (External Output). Dicha clasificación se hace con base al propósito principal de la función. Si el propósito principal de la función es recibir información para administrar (crear, modificar, eliminar) un almacenamiento, el tipo de función sera EI. Si, por el contrario, el propósito principal fuera sólo presentar información y no realizar ningún procesamiento adicional, la función es clasificada como EQ, y por último, si el propósito principal es presentar información y además realizar algún procesamiento adicional (como cálculos matemáticos, derivación de datos, etc) entonces la función se clasifica como un EO.

La complejidad de las funciones transaccionales depende del número de DETs y FTRs. Los DETs, en las funciones transaccionales, son campos únicos de información que son identificables por el usuario y que entran o salen de la función transaccional. Por mencionar sólo algunos criterios de conteo, aplicables al conteo de DETs para las funciones transaccionales, se tienen los siguientes:
•Para ser contado el DET debe entrar o salir de la aplicación, es decir un campo que sea utilizados internamente y que no entre o salga de la aplicación no es contado como DET.
•Las etiquetas, nombres de campo, nombres de columna y variables de sistema como (fecha de sistema, número de página, número de columna, etc) no son contados.
•En aplicaciones on-line, contamos 1 DET para la capacidad de ejecución sin importar de cuantas formas distintas se pueda ejecutar el proceso elemental. Por ejemplo, si podemos ejecutar la función de “Insertar Empleado” presionando el botón “Salvar” o presionando Ctrl-I o dando click en una opción de menú, sólo contaremos un DET por la capacidad para ejecutar dicha función.
•En aplicaciones on-line, contamos 1 DET para la capacidad de envio de mensajes, sin importar cuantos mensajes sean enviados dentro de la misma función transaccional. Por ejemplo, en la función “Insertar Empleado”, por ejemplo, podrían hacerse diversas validaciones sobre cada uno de los datos capturados (longitud del campo, formato de la fecha, etc), sin importar cuantas validaciones sean realizadas, sólo se contará un DET por la capacidad de generar mensajes en dicha función transaccional.

Por otro lado los FTRs, son el número de funciones de datos que son mantenidas y/o referenciadas por la Función Transaccional.

Con el número de DETs y FTRs y además el tipo de cada función transaccional, se consultará en las siguientes tablas la complejidad:

Tabla 3. Tabla para determinar complejidad de External Input (EI)

Tabla 4. Tabla para determinar complejidad de E xternal Inquiry (EQ) y External Output (EO)

Una vez obtenida la complejidad, la contribución de la función transaccional en Puntos de Función No Ajustados, se obtiene con la siguiente tabla:

Tabla 5. Puntos de función correspondientes a funciones transaccionales

Aplicación al caso
El primer proceso elemental identificado en nuestro caso de estudio es “Consultar Listado de Vehículos”, el cual está implementado por las pantallas 1 y 2. La pantalla 1 no es un proceso elemental por sí sola, debido a que no tiene sentido para el usuario el solo ingresar los parámetros de consulta y no hacer nada más. El ingresar los parámetros de consulta y mostrar los resultados de dicha consulta forman un solo proceso elemental, puesto que es la unidad mínima de actividad que tiene significado para el usuario, deja al negocio en un estado consistente y es autocontenido. Este proceso elemental tiene el propósito principal de presentar información y no incluye procesamiento adicional, por lo que es catalogado como un EQ. Los campos únicos que son presentados en las pantallas 1 y 2 y que corresponden a la función “Consultar Listado de Vehículos” son 7: año_modelo, marca, modelo, accesorios, precio, color y condición. Adicionalmente, se cuenta un DET para la capacidad de ejecución (cuando se presiona el botón de “buscar”), y otro DET para la capacidad de envío de mensajes (cuando no es encontrado ningún vehículo con las características indicadas), resultando en un total de 9 DETs. La información requerida por esta función transaccional es obtenida de la Función de Datos “Vehículo”, por lo tanto el número de FTR es uno. La complejidad resultante de esta función EQ, con 9 DETs y 1 FTR, es “Baja” según lo indicado en la tabla 4 y su contribución es de 3 puntos, según lo indicado en la tabla 5.
El segundo proceso elemental identificado es “Consultar Detalle de Vehículo”, el cual corresponde a una parte de la pantalla 2 (cuando se selecciona un vehículo y se presiona el botón “Ver Detalle”) y la pantalla 3. Dado que no se realiza procesamiento adicional, esta función se clasifica como un EQ con 7 DETs, correspondientes a: color, kilometraje, condición, número de serie, precio, accesorios (aunque el campo se repite, sólo se cuenta como un DET) y la capacidad de ejecución (cuando en la pantalla 2 se presiona el botón “Ver Detalle”). Toda la información se obtiene de la función de datos “Vehículo”, así que solo es un FTR. De esto, obtenemos que la complejidad de esta función tipo EQ, con 7 DETs y 1 FTR es baja y tiene una contribución de 3 Puntos de Función.

El tercer proceso elemental identificado corresponde a la funcionalidad de comprar el vehículo o “Insertar Compra”. Dicha función está formada por el procesamiento que incluye permitir la captura, salvar la compra, actualizar el campo de estado en el inventario de vehículos y además enviar el correo al comprador. Aunque estos procesos parecieran ser funciones independientes, al analizarlos nos damos cuenta que no tienen sentido por sí solos o no dejan al negocio en un estado consistente. El proceso elemental de “Insertar Compra” se encarga de mantener la función de datos “Compra”, y por ello es clasificado como un “EI”. Los DETs únicos que entran o salen en los diferentes procesamientos que conforman esta función son: capturar los datos, salvar, almacenar el campo de estado del vehículo, y enviar el e-mail. Cuando se capturan los datos tenemos 11 DETs que aparecen en la pantalla 4, a lo que agregamos la capacidad de ejecución, para un total de 12 DETs. En el procesamiento de envío del e-mail al comprador, se tiene un DET que no ha sido contado en la función transaccional, que es: “número de compra”. Este nuevo DET mas los 12 previos, nos da un total de 13 DETs para esta función. Ahora bien, “Insertar Compra” requiere usar la función de datos “Compra” para insertar el nuevo registro y también requiere de la función de datos “Vehículo”, para actualizar el valor del campo “Estado de disponibilidad del Vehículo”, así que el FTR será igual a 2. La complejidad de la función EI con 13 DETs y 2 FTRs es igual a “Media” y su contribución es de 4 Puntos de Función.

Por último, se cuentan los drop-downs como funcionalidades de “Consultar Listado de…”. Por lo que consideraremos los siguientes procesos elementales:
•Consultar Listado de Año_Modelo. Drop Down
•Consultar Listado de Marca/Modelo. Drop Down
•Consultar Listado de Accesorios. Drop Down
•Consultar Listado de Rango de Precios. Drop Down

Los primeros 3 procesos solo presentan información y no realizan ningún procesamiento adicional, por lo que quedan clasificados como “EQs”. En cambio, “Consultar Listado de Rango de Precios”, requiere adicionalmente hacer algún procesamiento (calcular los rangos con base a los valores mínimos y máximos) para luego presentar los datos, por lo tanto dicho proceso es clasificado como un “EO”.

Para calcular la complejidad de los drop-downs, se considera un DET para la capacidad de ejecución (cuando se presiona la flechita y se despliega el drop down) y los DETs de datos que son mostrados. En el caso del drop-down de año modelo contamos 2 DETs (capacidad de ejecución y el DET año-modelo), para el drop down de Marca-Modelo, contamos 3 DETs (Capacidad de ejecución, marca y modelo), para el de Accesorios contamos 2 DETs (capacidad de ejecución y el DET de accesorio) y para el de Rango de Precios contamos 2 DETs (capacidad de ejecución y rango). Todos estos drop downs tendrán un FTR igual a 1 dado que sólo consultan la función de datos “Vehículo”.

Así que según nuestras tablas, los 3 procesos elementales tipo EQ que tenemos, tienen una complejidad baja que corresponde a 3 puntos cada uno, mientras que “Consultar Listado de Rango de Precios” también tiene complejidad baja, pero al ser una función del tipo “EO” contribuirá en 4 puntos de función.

5. Determinar los puntos de función no ajustados
En este paso, simplemente determinamos el total de puntos de función no ajustados, sumando los puntos correspondientes a las funciones de datos encontradas en el paso 3, y las funciones transaccionales encontradas en el paso 4. La siguiente tabla refleja el total de puntos de función no ajustados para nuestro caso:

Tabla 6. Total de puntos función

Próximos pasos
En el próximo artículo de esta serie, aprendemos a determinar el factor de ajuste, para poder determinar la cantidad de puntos de función ajustados que corresponde a nuestra aplicación. ¡Hasta entonces!

Acerca del autor
Aquiles Santana Álvarez es Certified Function Points Specialist por parte del IFPUG y Project Manager Professional por parte del PMI. Ha sido responsable de la estimación de proyectos de software críticos para EDS de México y Latinoamérica. Ha impartido entrenamiento en la técnica de Puntos de Función y estimaciones a más de 300 personas en 5 países latinoamericanos y Canadá. Actualmente se desempeña como consultor en Project Management e Ingeniería de Software.