- Este tema tiene 5 respuestas, 6 voces, y fue actualizado por última vez 6 años, 10 meses hace por
.
-
Publicaciones
-
Le escribo con respecto al método que debemos usar al contar FPA en proyectos que usan servicios web. Tal vez puedas ayudarme con alguna idea.
Describiré dos escenarios hipotéticos para explicar la situación..1. Escenario estándar: sin servicios web
Requisitos:
El usuario debe poder crear, ver y editar información del producto. En esta situación contaríamos:Transacción Tipo Complejidad Puntos de función Producto ILF Bajo 7 Crear producto NO Promedio 4 Ver el producto EQ Promedio 4 Editar producto NO Promedio 4 Total 19 2. Nuestro escenario: se deben utilizar los servicios web
Requisitos:
El usuario debe poder crear, ver y editar información del producto.
Los datos sobre el producto se almacenan en otra aplicación.. La aplicación a desarrollar debe enviar y recuperar datos a través de servicios web.En esta situación, podemos considerar que la segunda aplicación que almacena la información del Producto es un segundo usuario.
Contamos una transacción para cada conjunto de datos que cruza el límite de la aplicación..Transacción Tipo Complejidad Puntos de función Crear producto NO Promedio 4 Solicitud: Crear producto EQ Promedio 4 Respuesta: Crear producto NO Promedio 4 Ver detalles del producto EQ Promedio 4 Solicitud: Detalles de producto EQ Promedio 4 Respuesta: Detalles de producto NO Promedio 4 Actualizar detalles del producto NO Promedio 4 Solicitud: Actualizar detalles del producto EQ Promedio 4 Respuesta: Actualizar detalles del producto NO Promedio 4 Total 36 ¿Es correcto este enfoque?? ¿Qué tipo de experiencia tienes con este tipo de situaciones??
Hola ilie,
Trato una situación como esta como se indica a continuación.
• Punto de partida: Nesma FPA.
Escenario estándar
Aquí tenemos un sistema y un límite de sistema para considerar. Cuente esto como se indica.servicios web
Aquí tenemos dos sistemas y dos límites de sistema para considerar (no consideramos posible ESB como sistema independiente en el medio para este ejemplo).Sistemas:
• Interfaz (FE) para el usuario final
• Backend (SER) para el almacenamiento de datosLa FE envía mensajes a BE y recibe mensajes de BE. Los servicios web manejan los mensajes y son parte de la FE. El FE puede considerarse como un usuario del BE (la FE tiene la delantera).
El sistema a contar es el FE, se supone que el BE existe y no cambia.En base a esto podemos afirmar que:
• La FE no tiene ILF, están en el BE.
• Los servicios web no tienen su propio límite..
• BE: nada que contar.
• Para contar: solo la FE, incluidos los servicios web.Entonces, en el FE estamos buscando funciones transaccionales. Una función transaccional es única, función elemental desde el punto de vista del usuario. Tenga en cuenta que los mensajes hacia y desde el BE no son elementales. Son parte de las transacciones del usuario..
Entonces contamos:
• Crear Producto EI Promedio 4
• Ver producto EQ Promedio 4
• Editar producto EI Promedio 4
Total 12
En tus 2. Nuestro escenario, tampoco cuenta para la segunda aplicación, como lo consideras como usuario. Entonces considera que los mensajes de ese usuario son únicos, funciones elementales. Según las definiciones de Nesma (por ejemplo. 7.1) sin embargo, no son elementales, para que no se cuenten.Si el BE cambia, entonces se deben contar los mensajes y / o ILF, para este BE, todavía no es para la FE.
Espero que esto ayude!
Saludos,
Martin Jacobs
QSM EuropeHola ilie,
Esta no es una pregunta fácil de responder.
Ante todo: Con FPA, mide el tamaño de la funcionalidad que una aplicación proporciona a un usuario (Pautas de Nesma; v2.1; sección 3.1.2).
Ahora, agreguemos un tercer escenario.
Requisitos:
El usuario debe poder crear, ver y editar información del producto.
Los datos sobre el producto se almacenan en otra aplicación., directamente por la aplicación que necesita ser medida.En el escenario 1, tienes una aplicación con el tamaño de 19 FP.
En el escenario 3, la aplicación hace exactamente lo mismo desde el punto de vista de los usuarios finales (el usuario que debe poder crear, ver y editar información del producto). Entonces, en ambos escenarios, a este usuario se le ofrece exactamente la misma funcionalidad. Esto significa que el tamaño de la funcionalidad (desde el punto de vista de los usuarios finales) en ambos escenarios debería ser lo mismo (en este caso: 19 FP).Ahora mi pregunta es: que es, lógicamente, la diferencia entre tu escenario 2 y mi escenario 3?
Los servicios web mencionados son parte de la primera aplicación y pueden almacenar y editar los datos directamente en el archivo lógico., así que no hay ninguna diferencia. Y eso significa que el tamaño funcional de la primera aplicación sigue siendo 19 FP, si usa servicios web o no (los servicios web son una implementación técnica de la funcionalidad requerida).
O, por decirlo de otro modo, Los requisitos que tiene el usuario final no cambian cuando decide utilizar servicios web para cumplir con estos requisitos.Entonces Martin y Edwin,Qué contar para el desarrollo de los servicios web en el backend BE?
Digamos que el BE ya tiene las tablas de productos en su lugar, pero no tiene los servicios web para proporcionar la funcionalidad para admitir Front End?
Para esto el BE obtendrá 3 servicios web:
* Crear producto
* GetProduct
* UpdateProductQué contar para esa funcionalidad?
Hola, por favor dime en el escenario 3, ¿La aplicación que se está dimensionando posee el archivo del producto? Entonces, en ese caso, puedo ver que el tamaño es el mismo. sin embargo, si el archivo del producto es propiedad de una aplicación fuera del sistema que se está contando, se consideraría un EIF y, por lo tanto, cambiaría el tamaño.
Sin embargo, veo claramente cómo escenario 1 y 2 en la primera conversación resultaría en lo mismo 19 FP asume que el archivo del producto es propiedad de la aplicación que se está dimensionando.
Ahora, hagamos esta pregunta, ¿Qué pasa si el servicio web hace referencia a un archivo fuera del límite como en el caso de Google Maps?, entonces mantendríamos todo igual excepto que en lugar de un ILF sería un EIF?
En el escenario 3, según lo propuesto por Edwin, los servicios web son parte de la aplicación a contar. No tengo problema con el conteo.
La respuesta de Alexander se refiere a algo que veo con bastante frecuencia., es decir, el sistema de back-end ofrece servicios web para manejar solicitudes de datos. Cuando estos servicios se deben construir en el sistema de fondo, se contarán de manera similar al escenario 3.
El tamaño funcional de un sistema front-end no cambiará, si los servicios web están disponibles o no. La funcionalidad que se debe proporcionar al usuario es la misma.. La productividad será muy diferente cuando se pueda proporcionar la funcionalidad llamando a los servicios web existentes en lugar de construir el mecanismo completo para manejar los datos en el sistema de fondo.
Con respecto al primer comentario de Sue: Cuando la aplicación puede cambiar o crear los datos en el sistema de fondo, el archivo del producto es, por definición, un ILF, independientemente del hecho de que los arquitectos dicen que los datos del producto pertenecen al sistema de fondo.
- Debes iniciar sesión para responder a este tema.