• No se han encontrado resultados

Estimación del esfuerzo y costos necesarios para el desarrollo de un proyecto de software

N/A
N/A
Protected

Academic year: 2021

Share "Estimación del esfuerzo y costos necesarios para el desarrollo de un proyecto de software"

Copied!
14
0
0

Texto completo

(1)

www.sgcampus.com.mx @sgcampus

www.sgcampus.com.mx

@sgcampus

Carlos Eduardo Vázquez

Estimación del esfuerzo y costos

necesarios para el desarrollo de un

proyecto de software

www.sgcampus.com.mx @sgcampus

Objetivos

1. Despertar en el público la conciencia sobre la

problemática en la elaboración de estimaciones

en el desarrollo de software

2. Presentar el concepto de unidad de producto y

de cómo aplicarlo en la medición de software para

la planeación y monitoreo de la productividad en su

desarrollo

3. Introducir el método de COSMIC para la medición

del tamaño funcional y su papel en la generación de

unidades de producto a partir de los requerimientos

funcionales

(2)

www.sgcampus.com.mx @sgcampus

1. La problemática de la

estimación

Cuando se solicita una medición a un desarrollador para entregar un programa probado y brinda una estimación de 12 horas, lo más probable es que esté en lo cierto

Esto porque se trata de un programa cuya dificultad de estimación es menor o su impacto de error es pequeño.

Estimar pequeños elementos es fácil

Programar una Transacción

Probar una Transacción

Estimar la realización de una actividad de

12 horas Pequeño! Dificuldad Impacto www.sgcampus.com.mx @sgcampus

1. La problemática de la

estimación

La solución para todos los problemas de estimación es

descomponer un proyecto en sus partes y hacer las

estimaciones en estos mismos modelos

Los escenarios en los que la

estimación del todo es difícil y que el impacto de

los errores es demasiado grande no serían un problema y todo el mundo estaría feliz

Un gran elemento como la suma de pequeñas partes

Estimar la entrega de un

producto final a lo largo de dos años

Fase 01 Fase 02 Fase 03 Fase 04 Grande!

Dificultad

(3)

www.sgcampus.com.mx @sgcampus

1. La problemática de la

estimación

Al inicio no sé sabe cuáles son todos los programas Hay trabajo que no es una

función de esa cantidad de

programas

El nivel de información disponible no permite usar la lógica de la estimación de abajo hacia arriba como solución para los desafíos de la estimación

El fallo en esta lógica

Evolución del desarrollo

Decisiones y acuerdos sobre la solución Proceso de la Ingeniería de Requierimientos Alcance

preliminar

Necesidades de negocio

?

No se pueden identificar cuáles son esas

actividades de 12 horas durante las fases iniciales del desarrollo

?

?

?

?

www.sgcampus.com.mx @sgcampus

1. La problemática de la

estimación

#NoEstimates ¿Por qué estimar si al final

del trabajo ya estoy seguro de la información de interés? Al final, son apenas entre 15 o 30 días en un ambiente donde se hace uso de

enfoques ágiles de desarrollo Se puede esperar por ese momento para “saber” en lugar de simplemente creer.

De igual forma, no se puede decidir sobre los cambios que deben ser

priorizados dentro del 20% de las demandas que consumen el 80% de

(4)

www.sgcampus.com.mx @sgcampus

1. La problemática de la

estimación

> 2.000 HH 18% < 2.000 HH 82% CANTIDAD (#) > 2.000 HH 61% < 2.000 HH 39% ESFUERZO (HH)

Las decisiones ejecutivas de inversión deben ser justificadas a quien mantiene el gobierno de aquella organización

¿Cómo hacer esto con #NoEstimates?

www.sgcampus.com.mx @sgcampus

2. Unidad de producto para

producción de software

A partir de esto, tuve la oportunidad de tomar varias decisiones:

• Es más caro (proporcionalmente) construir un baño que un cuarto • Cuando tuve que estimar el costo

únicamente del baño, ya tenía elementos para realizar estimaciones de abajo para arriba…

• Los desembolsos ocurridos no excedieron la estimación inicial basada en la cantidad de metros cuadrados y en la productividad media

Casa en el estilo Santa Fé de Cadu

Presupuesto disponible

1 m 1 m

Costo unitario medio de

construcción por m2

(5)

www.sgcampus.com.mx @sgcampus

2. Unidad de producto para

producción de software

1 m 1 m US$ 500,00/ m2 Productividad Casa construída 300 m2 Producto Costo Desembolso con las inversiones US$ 150.000,00 Arquitectos Ingenieros Maestro de obras Albañiles Ayudantes Impuestos y tasas Aprobaciones y registros Diversos materiales Apropiación indirecta de costos Apropiación directa de costos www.sgcampus.com.mx @sgcampus

2. Unidad de producto para

producción de software

?

?

Unidad de Producto

¿Cuál sería la métrica que cumple el papel de unidad de

producto para la planificación

y seguimiento del desempeño para el desarrollo de

software?

Permite aproximar o medir el tamaño del software a partir de sus requerimientos

Permite comparar la productividad entre las diferentes técnicas y tecnologías disponibles

Apoya en la estimación del

esfuerzo del proyecto o en la cuantificación del desempeño a

partir de la perspectiva del usuario o dueño para fines del análisis de productividad

Es independiente del desarrollo técnico y decisiones de

(6)

www.sgcampus.com.mx @sgcampus Dimensión del

diseño y calidad

2. Unidad de producto para

producción de software

Otras métricas permiten

cuantificar el desempeño técnico de

productos y servicios a partir de su implementación

Análisis de eficiencia del diseño

Apoyo a la verificación y validación Mejora en el rendimiento del diseño

Apoyo a la Ingeniería de Requerimientos

www.sgcampus.com.mx @sgcampus

2. Unidad de producto para

producción de software

Tipos de Requerimientos

Requerimientos Funcionales

Requerimientos que están específicamente asociados a una tarea o

servicio del usuario y

que describen lo que el software debe hacer

independientemente de cómo lo haga Manipulación y movimiento de datos  Transferencia  Transformación  Almacenamiento  Recuperación Cualquier otro tipo de requerimientos o de restricción de

orden general para el producto

las tecnologías de desarrollo, mantenimiento, soporte y ejecución como: herramientas de programación y pruebas, sistemas operativos, sistemas de gestión de bases de datos, sistemas de gestión de la interfaz gráfica con el usuario, etc. La im p le m e n ta c ió n desempeño, compatibilidad, usabilidad, confiabilidad, seguridad, mantenibilidad y portabilidad La c a lid a d La o rg a n iz a c ió n equipos de destino, la adhesión a las normas y los lugares para la operación

la interoperabilidad, privacidad y la

protección contra daños incidentales o accidentales Al a m b ie n te

(7)

www.sgcampus.com.mx @sgcampus

2. Unidad de producto para

producción de software

Requerimientos Funcionales del Usuário

(‘RFU’) en los artefatos del software a ser medido

artefatos con definición de requerimientos

artefatos del modelo /análisis de datos artefatos con decomposición funcional de los requerimientos pré-implementación artefatos de almacenamiento físico de datos Procedimentos y manuales

operacionales del software

pós-implementación

programas físicos

¿Dónde están los requerimientos funcionales?

www.sgcampus.com.mx @sgcampus

Artefactos de Software

Primera versión de los Requerimientos

Versión posterior de los Requerimientos Puede ser medido por COSMIC Debería ser registrado, puede ser cuantificable Requerimientos Funcionales del Usuario Requerimientos no Funcionales ‘Verdaderos’ RFN Requerimientos Funcionales del Usuario

Evolución de la Línea del Tiempo del Proyecto

2. Unidad de producto para

producción de software

La relación entre los requerimientos funcionales y no funcionales a lo largo del desarrollo

(8)

www.sgcampus.com.mx @sgcampus

Inicialmente, RNF RFU a ser desenvolvido ou adquirido

RNF após requisitos iniciais evoluírem em RFU

El tiempo de respueta medio en horarios pico no debe exceder X segundos

 Proveer datos externos en tiempo real

 Monitorar y reportar tiempo medio de respuesta

 Equipo apropriado

 Parte del software escrito en lenguaje de bajo nivel

La disponibilidad debe aumentar Y% en relación a la media anual pasada

 Habilitar el cambio rápido de procesamiento para un procesador alternativo sin interrupción del servico

 Procesador alternativo operando en‘hot stand by’

2. Unidad de producto para

producción de software

La relación entre los requerimientos funcionales y no funcionales a lo largo del desarrollo

www.sgcampus.com.mx @sgcampus

 ISO/IEC 14143 define los principios de la medición del tamaño funcional

 Implementados en métodos de medición del tamaño funcional por:

COSMIC (ISO/IEC 19761:2011)

– IFPUG APF (ISO/IEC 20926:2009) – UKSMA Mk II (ISO/IEC 20968:2002) – NESMA APF (ISO/IEC 24570:2005) – FISMA (ISO/IEC 29881:2010)

2. Unidad de producto para

producción de software

(9)

www.sgcampus.com.mx @sgcampus

 2ageneración de métodos de medición del tamaño funcional

 Nivel de confiabilidad compatible con todos los tipos de

software

 Accesible al público y su documentación no tiene costo  Tiene reconocimiento total de la ISO/IEC

 Proyecto es simple y posee una base conceptual compatible con la Ingeniería de Software moderna:

– Los métodos anteriores no siempre tienen una aplicación amplia

suficiente para atender las necesidades del mercado, o funcionan apenas con acceso restringido

 Planificación y medición del desempeño tiene mayor exactitud  Tiene la habilidad de capturar el tamaño a partir de múltiples

perspectivas

3. El método de medición de

tamaño funcional de COSMIC

www.sgcampus.com.mx @sgcampus Conjunto de:  Modelos  Principios  Reglas  Procesos

3. El método de medición de

tamaño funcional de COSMIC

Visión general del método de medición COSMIC

objetivos

1

4

Independiente de

implementación

relacionada con los artefactos del software a ser medido Es un valor de una magnitud de acuerdo con el método de COSMIC Expresado en unidades: Puntos de Función COSMIC o PFC tamaño funcional de la parte del software

Describe lo que el software debe hacer para los usuarios, quienes son los destinatarios y remitentes de los datos

Excluye requerimientos técnicos

o de calidad que expresan cómo el software funciona

La función es relativa al proceso de información que el software debe ejecutar para sus usuarios Requerimientos funcionales

del usuario en los artefactos del software a ser medido

2

(10)

www.sgcampus.com.mx @sgcampus

3. El método de medición de

tamaño funcional de COSMIC

Las fases en la medición COSMIC

Tamaño funcional del software en unidades de PFC Objetivos 1 4 3 Estrategia de medición 6

Definición de cada parte del software a ser medido de la

medición exigida 7 Fase de mapeo 9 Modelo de contexto de software 5 Modelo general de software 8 Requerimientos Funcionales del Usuario en la forma del modelo general de software 10 Fase de medición 11 Requerimientos funcionales del Usuario en artefatos del software a ser medido 2 www.sgcampus.com.mx @sgcampus

3. El método de medición de

tamaño funcional de COSMIC

Usuario funcional Usuario funcional humano aplicación siendo medida Aplicación para usuario funcional de la

aplicación siendo medida

Usuarios funcionales de una parte del software a ser medido identificados a partir de sus RFU,

como fuentes y/o destinos pretendidos para datos

En la visión lógica para una parte del software de aplicaciones de negocio, los RFU acostumbran a describir sólo la funcionalidad requerida desde el punto de vista de usuarios

humanos y, tal vez, otras aplicaciones pares que envíen o reciban datos

Cualquier camada de software y dispositivos de hardware que soporten la interación de los usuarios funcionales con la aplicación son facilitadores de las transferencias de datos y no remitentes o destinatarios

(11)

www.sgcampus.com.mx @sgcampus

3. El método de medición de

tamaño funcional de COSMIC

Frontera

Frontera definida como interfaz conceptual entre software y usuario funcional

Frontera no debe ser confundida con qualquier línea diseñada en un diagrama para delimitar o

alcance de una parte del software o camada

Frontera permite hacer distinción clara entre cualquier parte del software medido (dentro) y

cualquier parte del ambiente de los usuarios funcionales (fuera)

fronteraaplicación frontera

siendo medida

Aplicación par

www.sgcampus.com.mx @sgcampus

3. El método de medición de

tamaño funcional de COSMIC

Movimientos de datos

Usuarios funcionales interactuan con el software a través de la frontera via dos tipos de movimientos de datos (entries y exits)

Software también intercambia datos con el dispositivo de almacenamiento persistente via dos tipos de movimientos de datos (reads y writes)

El dispositivo de almacenamiento no es considerado como un usuario del software y, por tanto, está dentro de la frontera del software

aplicación siendo medida aplicación par entradas salidas exits entries exits entries armazenamento persistente cam a d a d e a p lic a c ió n lecturas grabaciones Movimientos de datos

(12)

www.sgcampus.com.mx @sgcampus pedido

item del pedido

cliente

producto pedido

item del pedido usuario

funcional processo

funcional

objetos de interés

cliente producto pedido items

de pedido

confirmación del pedido

Ejemplo de Movimientos de datos

3. El método de medición de

tamaño funcional de COSMIC

www.sgcampus.com.mx @sgcampus Editar y gerenciar pedidos de vacaciones 100 PFCG1 incluir, alterar, excluir, apreciar... 150 PFCG2 1 PFCG1 = 1,5 PFCG2 ± 25% especificación completa 200 PFCG3 1 PFCG2 = 1,33 PFCG3 ± 15% Estimar/Aproximar Medir

propuesta requerimientos proyecto construcción implementación

1. Evaluar el desempeño por la relación entre la cantidad de horas invertidas y la cantidad de puntos función COSMIC medidos

2. Re-evaluar los indicadores de productividad para que pasen a incluir el desempeño de los proyectos que terminan

3. Re-evaluar la cantidad de puntos función COSMIC que corresponden en promedio a los procesos y a los conceptos de negocio

Medición Vs Aproximación del tamaño

3. El método de medición de

tamaño funcional de COSMIC

(13)

www.sgcampus.com.mx @sgcampus Benchmarking

3. El método de medición de

tamaño funcional de COSMIC

Aproximación del Tamaño:

150 CFP

Esfuerzo estimado por otros métodos:

1000 HH 07 HH/CFP o menos de 8% de probabilidad www.sgcampus.com.mx @sgcampus Conócete a ti mismo

3. El método de medición de

tamaño funcional de COSMIC

(14)

www.sgcampus.com.mx @sgcampus

Conclusión

De algo que estoy seguro es sobre la diferencia de las respuestas para la siguiente pregunta:

"¿Por qué me pides 5.000 HH para el proyecto y no 2.000 HH?”

 Porque yo lo sé

 Porque sólo hay un 2% de probabilidad de entregar el proyecto de este tamaño con 2.000 HH de acuerdo a nuestros datos históricos. No hay un proyecto de la base de datos internacional de evaluación comparativa que indique esto como algo posible

Referencias

Documento similar

En la base de datos de seguridad combinados de IMFINZI en monoterapia, se produjo insuficiencia suprarrenal inmunomediada en 14 (0,5%) pacientes, incluido Grado 3 en 3

En este ensayo de 24 semanas, las exacerbaciones del asma (definidas por el aumento temporal de la dosis administrada de corticosteroide oral durante un mínimo de 3 días) se

En un estudio clínico en niños y adolescentes de 10-24 años de edad con diabetes mellitus tipo 2, 39 pacientes fueron aleatorizados a dapagliflozina 10 mg y 33 a placebo,

• Descripción de los riesgos importantes de enfermedad pulmonar intersticial/neumonitis asociados al uso de trastuzumab deruxtecán. • Descripción de los principales signos

En junio de 1980, el Departamento de Literatura Española de la Universi- dad de Sevilla, tras consultar con diversos estudiosos del poeta, decidió propo- ner al Claustro de la

E Clamades andaua sienpre sobre el caua- 11o de madera, y en poco tienpo fue tan lexos, que el no sabia en donde estaña; pero el tomo muy gran esfuergo en si, y pensó yendo assi

[r]

SVP, EXECUTIVE CREATIVE DIRECTOR JACK MORTON