Se trata de clientes satisfechos

Hay muchas cosas que nos distraen de lo que se trata: clientes satisfechos. Por ejemplo, la elección de utilizar scrum ágil o cascada como entorno de desarrollo., Piense en movimientos organizativos o intereses comerciales..
Al final lo más importante es la funcionalidad requerida! Funcionalidad que soporta los procesos de forma satisfactoria permitiendo a los clientes alcanzar los objetivos. En los últimos años hemos experimentado que el Análisis de Puntos de Función Indicativo (FPA_yo) en las primeras fases del desarrollo de software actúa como un buen catalizador para mantenerse enfocado en la funcionalidad del cliente.

la propiedad intelectual(Suministro de información) La cadena de la Administración Tributaria y Aduanera holandesa consta de un lado de la demanda y un lado de la oferta.. La demanda representa a los clientes internos.; el suministro se da cuenta de las provisiones de TI. En 2013 un FPA_yo se ejecutó un piloto a pedido. Este piloto se originó por la necesidad de la demanda de contar con un método propio, temprano, aplicable y objetivo para la estimación de costos.. Otra necesidad era mejorar la justificación de las opciones en la cartera a largo plazo.. En la cartera a largo plazo todos los cambios de (partes de) Se han incluido los sistemas de información en los elementos de la cartera.. Dentro de la organización tenemos que hacer elecciones bien fundamentadas entre estos elementos de la cartera, porque tenemos que trabajar con presupuestos anuales generalmente decrecientes.

FPA_yo es un complemento a la medición FPA tradicional que ya ha realizado con éxito el suministro durante muchos años. El resultado también es un tamaño funcional expresado en puntos de función. fpa, fpa.

En línea con la publicación NESMA sobre tLa aplicación del análisis de puntos de función en las primeras fases del ciclo de vida de la aplicación la demanda aplica cuatro pistas de dimensionamiento: 1una, 1segundo, 2una, 2segundo. Vea el plan a continuación de La estructura de FPA_yo. El camino que sigamos depende de la fase de la etapa preliminar en la que se encuentre el elemento de la cartera.. Cuanto más avanzamos en el tiempo -de izquierda a derecha- cuanto más (detallado) la información sobre el artículo de la cartera está disponible.

Diferentes pistas al tamaño adecuado

Siempre y cuando el elemento de la cartera se encuentre en la fase de concepto y aún nos falten muchos meses para su realización., el resultado en puntos de función se aborda sobre la base de la analogía (pista 1a). Esto requiere la disponibilidad de recuentos de sistemas o productos de similar, artículos de cartera ya realizados. Potencialmente para este sistema cuenta un FPA_yo delta validado (+ o -) se agrega el conteo de tamaño. De esta forma se consigue un primer tamaño en un corto periodo de tiempo.

El momento en que un conjunto de necesidades y requisitos, una descripción de la situación deseada o una primera cartera de productos está disponible, se organiza un taller en el que varios expertos -facilitados por nosotros- contar las funciones de usuario que conducen a los puntos de función (pista 1b).

Si un primer modelo de datos está disponible, por ejemplo, un modelo de objeto, podemos ejecutar la próxima recalibración (pista 2a). Con la disponibilidad de información sobre los procesos, seremos aún más capaces de acercarnos al tamaño (pista 2b)!

Para reducir la incertidumbre de los resultados del dimensionamiento, aumentando así la fiabilidad, la consistencia y la trazabilidad son aspectos importantes durante la evolución de un requisito. En la práctica: Se determina y valora un requisito para registrar empresarios durante un APG_yo sesión con expertos en track 1b. Esto conduce a una indicación de los puntos de función y un resumen de los costes.. En un momento posterior en el tiempo en la pista 2a, uno espera encontrar un archivo de datos lógicos para poder registrar los datos de los empresarios. La próxima recalibración hace lógico descubrir los procesos de registro de emprendedores que ingresan, cambiando y eliminando. Si este no fuera el caso, se harán preguntas. En esto vemos un spin-off extra de FPA_yo y una victoria para los diseñadores y desarrolladores: mejora de calidad.

Por supuesto, la organización a menudo está interesada en la medida en que los costos de TI – deducido de los puntos de función- puede estar relacionado con aspectos tales como objetivos, lanzamientos, paquetes de trabajo, epopeyas, artículos atrasados ​​o (Moscú- basado en el método) priorizaciones. Otros perfiles solicitados con frecuencia son la categorización para diseñar trabajos., conectar el trabajo y configurar el trabajo. O una idea del tamaño funcional que se pretende realizar por medio de bloques de construcción, paquetes, software subcontratado o hecho a la medida. Podemos ofrecer cualquiera de estos perfiles.. sin embargo, Los analistas de FPA no son magos! La información fuente que describe la funcionalidad vinculada a los aspectos mencionados anteriormente, necesita estar disponible; ya sea en forma documentada o en la mente de expertos a quienes podemos interrogar. Si esta información estuviera disponible en un momento posterior, podemos incluirlo en una recalibración y en ese momento proporcionar a la organización estos conocimientos.

La demanda coopera con la oferta. Comparamos conteos de puntos de función de la etapa preliminar con conteos al inicio y al final de la realización. El círculo de aprendizaje de dimensionamiento durante la cadena IP ha demostrado que se deben aplicar ciertas correcciones en la etapa preliminar. Entre otras cosas, nuestra FPA_yo los informes tienen en cuenta los siguientes efectos:

• Fluencia del alcance, una corrección que podemos aplicar dependiendo de la dinámica que se espera en la funcionalidad (mas o menos trabajo). Desde la perspectiva de la cartera, nuestro objetivo es limitar esto tanto como sea posible..
• Crecimiento autónomo, una adicion, dependiendo del nivel de detalle de la funcionalidad esperada que la fuente nos pueda proporcionar en esa fase inicial. Una mayor elaboración en el tiempo, a menudo revela funcionalidades adicionales.
• Producción escalonada, una corrección positiva relacionada con la realización en varios lanzamientos. El hecho es, que trabajar en módulos de software varias veces de nuevo, toma más tiempo que tener la oportunidad de terminar el trabajo consecutivamente.

Hemos realizado el dimensionamiento de los puntos de función en la etapa preliminar durante algunos años.. Las experiencias son:

• FPA_yo es el medio objetivo para permitir la continua (costos)recalibraciones, para mejorar la transparencia y apoyar la función de cartera para hacer elecciones y priorizaciones de cartera a largo plazo relativamente rápidas junto con otras carteras.
• El método también es excelente para investigar si "obtenemos una buena relación calidad-precio".” y tomar medidas si es necesario. La realización de las funcionalidades planificadas dentro de un cierto período de tiempo está precedida por una declaración de costos basada en puntos de función. Este reclamo se cumple total o parcialmente mediante la asignación de presupuesto. Por supuesto, es bastante valioso analizar al final del período de realización., si lo que se pide, realmente ha sido entregado! Y si este no fuera el caso, ayudar a determinar las consecuencias y definir las acciones. Los puntos de función también pueden usarse para estos fines..
• Los costos de realización de TI están determinados solo por dos factores: por un lado el tamaño (expresado en puntos de función); por el otro la productividad realizada (expresado en costo u horas por punto de función). A pesar de esta claridad, a menudo resulta difícil señalar esta distinción a los expertos. El factor tamaño se refiere exclusivamente a la funcionalidad deseada por el cliente, el número de funciones de usuario. El dimensionamiento funcional no tiene nada que ver con la complejidad de producir cierta funcionalidad, la necesidad de incluir muchos controles o tablas técnicas que contengan una gran variedad de datos, millones de mensajes para ser procesados ​​o desarrollados de forma ágil scrum. Tienen todo que ver con la productividad.!

FPA_yo contribuye a desempeñar nuestro papel de representante del cliente de manera profesional. En cooperación con el suministro, la FPA_yo El método respalda nuestra capacidad para determinar una vista común del costo de los artículos de la cartera.. En proceso de licitación, pueden tener lugar negociaciones destinadas a controlar los costos.

FPA_yo es un medio de estimación relativamente simple -por sí mismo un gran mérito en el complejo mundo en el que nos encontramos- poniendo en primer lugar la funcionalidad solicitada por los clientes. Apoya a las organizaciones de fabricación de software para que puedan fundamentar mejor las opciones de cartera., para hacer estimaciones de costos objetivas y vincularlas a aspectos tales como lanzamientos o paquetes de trabajo. También puede determinar si la funcionalidad esperada por el cliente realmente se entrega o no.

FPA_yo; para las organizaciones de fabricación de software, el segundo mejor método de estimación y análisis de costos! El mejor todavía tiene que ser inventado.

 

Sobre los autores:

Margreet Renshof es arquitecta táctica. Herman Buitenhuis es consultor táctico. Ambos trabajan para el departamento de Gestión de Cartera de la Dirección de Gestión de Información Tributaria de la Administración de Impuestos y Aduanas de los Países Bajos.

Una publicación de blog representa la opinión personal de los autores.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.