ESCUELA POLITCNICA DEL EJRCITO ESPE

III CONGRESO 2008 Ciencia y Tecnologa

TEMA: ESTIMACION DE PROYECTOS DE SOFTWARE BASADOS EN TECNICAS RAD

Autores: Ing. Jorge Geovanny Raura Ruiz Tatiana Valenzuela Varela

AGENDA
1. Introduccin 2. La Planificacin 3. El Proceso de Estimacin 4. Modelos de Estimacin 5. La Realidad del Desarrollo de Software en el Ecuador 6. Conclusiones y recomendaciones

1. INTRODUCCION
Es necesario construir en un tiempo corto, sin un costo excesivo, aplicaciones complejas, de calidad y que soporten las necesidades del usuario. Estas aplicaciones deberan ser fciles y rpidas de modificar.

2. PLANIFICACION
El software se desarrolla, no se fabrica en un sentido clsico. Un proyecto comienza con la estimacin del trabajo a realizar, estimacin de recursos necesarios, tiempo y costo de desarrollo. La estimacin conlleva un grado de incertidumbre. Un buen planificador debe reducir esa incertidumbre.

Planificacin de Proyecto con la Herramienta Project

3. EL PROCESO DE ESTIMACION CASO PRACTICO

EL disk Jockey

ESPECIFICACION DE REQUISITOS
R1: El sistema permitir la administracin (Ingreso, Modificacin, eliminacin) de CD. R2: Un CD contiene la siguiente Informacin:
Ttulo del CD. Grupo Musical Productor Fecha de Produccin Ttulo de la Cancin Nombre del Cantante Autor de la Cancin Tiempo de duracin

R3: El sistema permitir consultar los datos del CD por su Ttulo. R4: El sistema generar un reporte del total de CD por grupo musical. R5: Se generar un reporte sobre el tiempo de reverberacin tomando como coeficiente de absorcin el promedio de los materiales del local y asumiendo un volumen cbico.

SELECCIN DEL CICLO DE VIDA

Cascada. Iterativo. Evolutivo. (Espiral)

CRITERIOS DE SELECCIN DEL CICLO DE VIDA

No se conocen bien todos los requisitos. Es ideal para proyectos pequeos, donde se justifica la realizacin de un PROTOTIPO. Es decir presencia de INCERTIDUMBRE.

MODELO DE CASOS DE USO Primera Iteracin

DEFINICION DE CASOS DE USO DE ALTO NIVEL

CASO DE USO 1
Caso de Uso Actor Tipo Propsito Visin General: Referencias: AGREGAR CD Disk Jockey Primario y esencial Registrar un CD en el Sistema. Permite que el Disk Jockey efecte el alta de un CD en el sistema. Req 1, 2

Curso Tpico De Eventos

Accin del Actor

Respuesta del Sistema

1. El Disk Jockey ingresa los datos 2. Incorpora la informacin del CD en su base de datos, del CD: Ttulo del CD. Grupo Musical Productor, Fecha de Produccin, Ttulo de la Cancin, Nombre del Cantante, Autor de la Cancin, Tiempo de duracin

CASOS DE USO 2
Caso de Uso Actor Tipo Propsito Visin General: Referencias: ENCONTRAR CD Disk Jockey Primario y esencial Localizar un CD en el Sistema. Permite que el Disk Jockey encuentre un CD en el sistema. Req 3

Curso Tpico De Eventos

Accin del Actor 1. El usuario ingresa el Ttulo del CD.

Respuesta del Sistema 2. Ubica el CD y muestra el Ttulo del CD. Grupo Musical, Ttulo de la Cancin, Nombre del Cantante, Autor de la Cancin, Tiempo de duracin

CASO DE USO 3
Caso de Uso Actor Tipo Propsito Visin General: Referencias: MODIFICAR CD Disk Jockey Primario y esencial Registrar un CD en el Sistema. Permite que el Disk Jockey modifique la informacin de CD en el sistema. Req 1, 2

Curso Tpico De Eventos

Accin del Actor 1. El usuario localiza el CD e ingresa los datos que desea modificar (Ttulo del CD, Grupo Musical Productor, Fecha de Produccin, Ttulo de la Cancin, Nombre del Cantante, Autor de la Cancin, Tiempo de duracin)

Respuesta del Sistema 2. Modifica la informacin del CD en su base de datos.

CASO DE USO 4
Caso de Uso Actor Tipo Propsito Visin General: Referencias: ELIMINAR CD Disk Jockey Primario y esencial Eliminar un CD en el Sistema. Permite que el Disk Jockey elimine un CD del sistema. Req 1,2

Curso Tpico De Eventos

Accin del Actor 1. El usuario localiza el CD a eliminar y confirma el borrado del mismo

Respuesta del Sistema 2. Elimina la informacin del CD en su base de datos,

CASO DE USO 5
Caso de Uso Actor Tipo Propsito Visin General: Referencias: OBTENER TOTAL CD Disk Jockey Primario y esencial Obtener un reporte del total de CD registrados en el Sistema. Permite mostrar un reporte con el total de CD producidos por un grupo musical Req 3

Curso Tpico De Eventos

Accin del Actor 1. El usuario pide al sistema el total de CD registrados.

Respuesta del Sistema 2. Muestra un reporte con el nombre del Grupo Musical y el total de CD por grupo.

PREGUNTAS INMEDIATAS DEL CLIENTE

Cunto cuesta? En qu tiempo me entrega?

PREGUNTAS INMEDIATAS DEL DESARROLLADOR

Trabajar con la Intuicin. (ojmetro) ? Basarme en mi experiencia (si la tengo).? Basarme en datos histricos (si realic mediciones). ? Preguntar a un experto. (tipo Delphi)? Utilizar un modelo de estimacin (???).

ES NECESARIO DECIDIR
No tengo experiencia, no hay expertos en el tema, no tengo datos histricos, no quiero ser adivino La nica alternativa: Qu modelos de estimacin existen?

4. COCOMO
Acrnimo de COnstructive COst MOdel. Es uno modelo estndar aceptado por la industria. Tiene algunos aos de continuo desarrollo, propuesto por Barry Boem en 1.981 (COCOMO 81). Ultima versin COCOMO II 2000. Permite la estimacin de esfuerzo, tiempo y costo de los proyectos de desarrollo de software.

Provee un modelo de estimacin de esfuerzo y tiempo para las etapas de Elaboracin y Construccin propuestos por RUP/MBASE.

MODELOS DE ESTIMACION COCOMO II

El modelo de Composicin de aplicaciones. El modelo de Diseo anticipado. El modelo Post-Arquitectura.

El modelo de Composicin de Aplicaciones

Indicado para proyectos construidos con herramientas modernas de construccin de interfaces grficos para usuario. Meta: Programacin de Usuario Final. Medida: Puntos Objeto

El modelo de Diseo anticipado

Este modelo puede utilizarse para obtener estimaciones aproximadas del coste de un proyecto antes de que est determinada por completo su arquitectura. Utiliza un pequeo conjunto de drivers de coste nuevo y nuevas ecuaciones de estimacin. Medida: Puntos de Funcin sin ajustar o KSLOC (Miles de Lneas de Cdigo Fuente)(lenguaje).

El modelo Post-Arquitectura
Este es el modelo COCOMO II ms detallado. Se utiliza una vez que se ha desarrollado por completo la arquitectura del proyecto. Tiene nuevos drivers de coste, nuevas reglas para el recuento de lneas y nuevas ecuaciones. Medida: Puntos de Funcin sin ajustar o KSLOC (Miles de Lneas de Cdigo Fuente)(lenguaje)

CONCEPTO OPERACIONAL COCOMO II

Proceso de estimacin con COCOMO II

ECUACIN DE CLCULO DE ESFUERZO

Donde: A = constante tomada por defecto del modelo, ajustado en 2.94 Size = tamao del software (SLOC) B = factores de escala

EL TAMAO IMPORTA?

COMO MEDIR EL TAMAO DEL SOFTWARE

Lneas de Cdigo (LOC).
Es factible si se tiene cdigo desarrollado.

Puntos de Funcin (PF)

Permite medir la funcionalidad del sistema desde la perspectiva del usuario. Existen algunos mtodos de conteo (Albrecht IFPUG, MKII, NESMA, COSMIC-FFP.)

ES NECESARIO DECIDIR
Se utilizar el mtodo de conteo de puntos de funcin propuesto por Albrecht. Es un estndar de la industria (ISO/IEC 20926:2003 Software engineering). Actualmente es el ms conocido y utilizado. Se ajusta a las caractersticas del proyecto a desarrollar.

CONTEO DE PUNTOS DE FUNCION ARCHIVOS LOGICOS INTERNOS (ILF)

TOTAL ILF
Tipos de Registros Elementos de Datos 1-19 1 2-5 >5 Baja Baja Media 20-50 Baja Media Alta >50 Media Alta Alta

ILF CD

#DETs #RETs 8 2

Complejidad Baja

CONTEO DE PUNTOS DE FUNCION ENTRADAS EXTERNAS (EI)

TOTAL EI
Archivos referenciados 0-1 2 3 ms EI AGREGAR CD MODIFICAR CD ELIMINAR CD Elementos de Datos 1-4 Baja Baja Media 5-15 Baja Media Alta >15 Media Alta Alta

#DETs #FTRs Complejidad 9 9 9 1 1 1 Baja Baja Baja

CONTEO DE PUNTOS DE FUNCION SALIDAS EXTERNAS (EO)

TOTAL EO
Archivos referenciados 0-1 2-3 >3 Elementos de Datos 1-5 Baja Baja Media 6-19 Baja Media Alta >19 Media Alta Alta

EO OBTENER TOTAL CD

#DETs #FTRs Complejidad 2 1 Baja

CONTEO DE PUNTOS DE FUNCION CONSULTAS EXTERNAS (EQ)

TOTAL EQ
Archivos referenciados 0-1 2-3 >3 Elementos de Datos 1-5 Baja Baja Media 6-19 Baja Media Alta >19 Media Alta Alta

EQ (Entrada) ENCONTRAR CD (Salida) ENCONTRAR CD

#DETs #FTRs Complejidad 2 6 1 1 Baja BAJA Baja

RESUMEN PF

TOTAL PUNTOS DE FUNCION SIN AJUSTAR

COMPLEJIDAD BAJA Entradas Externas (EI) Salidas Externas (EO) Consultas Externas (EQ) Archivos Lgicos Internos (ILF) Archivos de Interface Externa (EIF) 3 1 1 1 0 MADIA 0 0 0 0 0 ALTA 0 0 0 0 0 TOTAL UPF APORTE 9 4 3 7 0 23

TRANSFORMACIN PF A SLOC

Size = 32 (VB) x 23 UPF = 736 SLOC = 0.736 KSLOC

CALCULO DE ESFUERZO NOMINAL

Ecuacin COCMO con resultados:

PMnominal= 2.94 x (0.736)?

AJUSTE DE FACTORES DE ESCALA (B)

CALCULO DE ESFUERZO NOMINAL

Ecuacin COCOMO con resultados:

PMnominal= 2.94 x (0.736)1.05 PMnominal= 2.13 Meses-persona

AJUSTE DE DRIVERS DE COSTO

CALCULO DE ESFUERZO AJUSTADO

Ecuacin COCMO con resultados:

PMajustado= 2.13 x 1.004 PMajustado= 2.14 Meses-persona

CALCULO DEL TIEMPO DE DESARROLLO

TDEV= [3.67 X 2.14 (0.278+0.2x(1.05-1.01))] x 1 TDEV= [3.67 X 2.140.286] x 1 = 4.56 Meses

CLCULO MEDIANTE HERRAMIENTA COCOMO

ANALISIS DE RESULTADOS
El esfuerzo y tiempo de desarrollo obtenido se ajusta a la realidad?

ES NECESARIO DECIDIR
El modelo de estimacin utilizado no se ajusta a la realidad, hay que buscar otras alternativas. Buscar alternativas muchas veces implica el hacer un anlisis ms exhaustivo del modelo empleado y hallar posibles limitaciones y alternativas de adaptacin.

LIMITACIONES DE COCOMO II
Est basado en un ciclo de vida en cascada. (hemos elegido un modelo en espiral) El modelo NO sirve para proyectos pequeos, esfuerzo < 16 PM, menos de 2 programadores por ao (nuestro proyecto es pequeo).

ALTERNATIVAS DERIVADAS DE COCOMO

Modelo COPSEMO
(Constructive Phased Schedule & Effort Model) COCOMO II lleva a cabo un proceso de modelo en cascada y es poco razonable para pequeos proyectos que tienen esfuerzos menores de 2 aospersona. COPSEMO se centra en el coste de desarrollo de software (menor de 64 meses-persona) mediante una mayor complejidad de clculo para el bajo esfuerzo. COPSEMO asume que los datos se encuentran en el Modelo COCOMO II. No tiene drivers diferentes. El modelo permite aplicarse a las distintas fases especificando el esfuerzo y el calendario en porcentajes.

COPSEMO utiliza el MBSE (Model-Based Systems Engineering) y RUP. Aunque en realidad este modelo esta desarrollada como parte del modelo CORADMO, COPSEMO es ahora reconocida como un modelo independiente que se utilizar como base para otro modelo de extensiones COCOMO II.

Modelo CORADMO (COCOMO RAD MODEL)

Aplicable a proyectos basados en estrategias de desarrollo rpido de aplicaciones (RAD). Introduce 5 nuevos indicadores:
RVHL (Reutilizacin y Lenguajes de Muy Alto Nivel) DPRS (Reingeniera en el proceso de desarrollo) CLAB (Eficiencia en la colaboracin) PPOS (Preposicionamiento de activos) RESL (Arquitectura y Resolucin de Riesgos = COCOMOII).

Orientado a proyectos pequeos, esfuerzo < 16PM Tiempo:

CORADMO= 2 (PM) COCOMO Tiempo= 3* 3 (PM)

COMPARACION DE CALCULO DE TIEMPO COCOMO vs COPSEMOCORADOMO

Modelo Lgico CORADMO

Clculo del Esfuerzo y

Calendario
Tiempo estimado: 4.56 Meses Esfuerzo: 2.14 PM (PF: 23) (SLOC 736) (Calculado con COCOMO)

APLICACION DE CORADMO AL PROBLEMA

ANALISIS DE RESULTADOS
De acuerdo a la experiencia, se podra concluir que el modelo CORADMO mejora la estimacin, aunque esto debera igualmente validarse. Los PF introducen un grado de subjetividad en funcin de cmo se los cuente. La experiencia demuestra que para un mismo modelo Entidad Relacin, se pueden obtener diferentes PF. La diferencia en resultados conduce a estimaciones de esfuerzo, costo y plazos drsticamente distintas. Para realizar el clculo de los puntos de funcin debe existir un consenso dentro de la organizacin para el tratamiento de los requisitos, adems de realizar un pre diseo para que este tamao sea una buena estimacin del tamao real de la aplicacin.

SIGUIENTE ITERACION

LA DURA REALIDAD
Creencias habituales: No hay un mtodo para desarrollar software que no sea ponerse delante de una pantalla y empezar a programar. Nuestro trabajo consiste en escribir un programa y hacer que funcione como sea. La documentacin es esa idea de los jefes para perder tiempo e incumplir los plazos de manera justificada. No existe Ingeniera del Software, es una moda. El desarrollar Software es una arte. La reusabilidad y los estndares recortan la libertad de los informticos.

PROBLEMAS DERIVADOS
Mantenimiento de alto costo y alto riesgo Gran dependencia del individuo. Incumplimiento de plazos de entrega. No se tiene tiempo de recoger datos sobre el proceso de desarrollo de software que permitan estimaciones y planificaciones fiables. Insatisfaccin de los usuarios con el producto terminado (cuando se termina). Dudosa calidad del software desarrollado. Poca importancia a las pruebas.

LA REALIDAD DEL DESARROLLO DE SOFTWARE EN EL ECUADOR

Definicin del Sector de mercado El sector de mercado al cual estamos orientados son empresas desarrolladoras de SW a nivel nacional, que realicen proyectos de Gestin o Especializados. Como base de muestreo para el anlisis de mercado se ha considerado varias empresas de las ciudades principales del pas Guayaquil y Quito.

Intergrupo Creative Works Extremo Software Infoelect Kruger Corporation Logicstudio Macosa Sdconsult Vimeworks Represensa Corporacin Latinoamericana De Software Agrosoft S.A.

TIPOS DE PROYECTOS DE SOFTWARE DESARROLLADOS

29% 42% Softw are a Medida Softw are con Especificacin Softw are Genrico 29%

La mayora de empresas de software del pas desarrollan proyectos de software a la medida, de acuerdo a la especificacin de requerimientos del cliente. Existen algunas reas de desarrollo de sistemas software que no se explotan en el Ecuador, como son: Sistemas de Automatizacin y Control, Sistemas de Inteligencia Artificial, Sistemas Empotrados, etc.

M ETODOLOGA DE SOFTWARE
MSF (Microsoft Solution Framework)
12% 35% 24%

XP (eXtreme Programming) RUP

29%

Metodologa propia

MSF es la metodologa ms utilizada por las empresas desarrolladoras de software a nivel nacional, ya que les garantiza soporte, certificaciones y tcnicas de fcil implementacin. Microsoft ha monopolizado las pequeas empresas de desarrollo en el Ecuador. En la actualidad se utiliza la metodologa RUP, porque realiza el ciclo de vida del software de forma interactiva, reemplazando a la metodologa en cascada que se convierte en una forma tediosa y larga para desarrollar. Las ltimas tendencias para el desarrollo de proyectos de software, est dividida de forma equitativa entre la metodologa XP y la metodologa de proyectos PMI, ya que XP se basa en la especificacin de requisitos para la satisfaccin del cliente del software a desarrollar; mientras PMI asigna mayor tiempo a la fase de planificacin dentro de los proyectos de software a desarrollar.

UTILIZACIN DE TCNICA DE MODELADO PARA DESCRIPCIN DE REQUISITOS

SI 4 3 2 AMBOS 1 0 Serie1 NO

La utilizacin de una tcnica de modelado para la descripcin de requisitos esta dividida, ya que existen empresas que no consideran imprescindible su uso, ya que emplean la especificacin de requerimientos inicial. Mientras que otras empresas consideran que si es necesario para que los requisitos sean mejor definidos y aplicados al momento del desarrollo del proyecto de software. Las pocas empresas que consideran que algunas veces se debe utilizar la tcnica y otras veces no, se debe a la complejidad y tamao del proyecto de software a desarrollar.

CERTIFICACIN EN ESTNDARES DE CALIDAD DE SOFTWARE

4 3 2 1 0 ISO 9001:2000 Proceso CMMI nivel 3 Certificacin Microsoft Serie1 Ninguna

CMMI nivel 2

Muy pocas empresas de software tienen inters en obtener una certificacin de calidad de software, ya que el personal deber estar dedicado a tiempo completo para el desarrollo de cada fase en la obtencin de una certificacin, lo cual genera grandes prdidas para la empresa.

CUMPLIMIENTO DE LA ESTIMACIN INICIAL DEL PROYECTO

AMBOS 5 4 3 2 1 0 NO SI Serie1

La variacin en el cumplimiento de la estimacin inicial de proyectos se debe principalmente a dos factores; primero la insatisfaccin del cliente y por esta razn se debe reestimar proyectos continuamente, y fallas en la asignacin de recursos, tiempo y costos para cada proyecto. Es decir, no existe un anlisis de la gestin de riesgos adecuado.

MEDIDA DE TAMAO DE PROYECTOS

8% 17% Datos Histricos Puntos de Funcin Ninguna 75%

Las empresas ecuatorianas de desarrollo software en su totalidad utilizan datos histricos para realizar la estimacin de proyectos, ya que son apegados a la realidad, sin desperdiciar mucho tiempo y responden a la experiencia profesional de su recurso humano.

DETERMINACIN DE TIEMPO, COSTO Y RRHH ESTIMADO

33% Experiencia Profesional Datos Histricos 67%

Para la determinacin de tiempo, costo y recurso humano dentro de la planificacin de proyectos, se considera la experiencia y capacitacin profesional como primera opinin al momento de decidir y asignar recursos al desarrollo de proyectos, sin considerar los mrgenes de riesgos y errores que se pueden presentar en desarrollo de proyectos.

UTILIZACIN DE MODELOS CONCEPTUALES PARA ESTIMACIN

NO 7 6 5 4 3 2 1 0 SI Serie1

La mayora de empresas desarrolladores no utiliza los modelos conceptuales como base para una buena estimacin de proyectos, ya que ha sido reemplazado por Datos Histricos y Experiencia profesional principalmente.

CONOCIMIENTO DE SISTEMA AUTOMATICO DE PREDICCION DE TIEMPO, COSTO Y RRHH

NO 5 4 3 2 1 0 Serie1 SI (Cocomo II)

La mayora de empresas desarrolladoras no conocen de ningn sistema automtico de estimacin; cabe sealar que el porcentaje afirmativo solo conoce a Cocomo II como una herramienta de nmeros fros que no se apegan a la realidad, por ello su respuesta se limita a una conceptualizacin del mismo.

6. CONCLUSIONES Y RECOMENDACIONES
El desarrollo basado en una metodologa orientada a objetos y el uso de una herramienta RAD, permite ahorrar un tiempo considerable en la construccin del sistema, al aplicar los conceptos de generalizacin, reutilizacin, encapsulamiento propios de la orientacin a objetos, as como al aprovechar la generacin automtica de cdigo especialmente en la construccin de un prototipo rpido en la fase de anlisis de requisitos, ya que se puede mantener esta especificacin sin mayor variacin, debido a que el usuario ve el sistema funcionando antes de ser realmente construido.

CONCLUSIONES Y RECOMENDACIONES
y El tiempo y esfuerzo de desarrollo se consideran mucho ms prximos a la realidad al utilizar el modelo COCOMO II en conjuncin con el modelo CORADMO, lo que permite estimar y planificar con un grado de error considerablemente inferior al que se alcanzara con la sola aplicacin del primer modelo; conclusin que lgicamente est sesgada a las condiciones particulares y estrategias de desarrollo aqu utilizadas, aunque se espera que esta experiencia sea validada en otros proyectos similares.

CONCLUSIONES Y RECOMENDACIONES
y Hasta que las herramientas RAD no terminen de evolucionar y alcanzar un mayor nivel de madurez, se recomienda su uso principalmente para el prototipado rpido en la obtencin de requisitos, y posteriormente en la generacin de interfaces de usuario en especial de tipo Web, que es donde actualmente tienen un alto nivel de desarrollo, no as en la generacin de reglas de negocio y modelos de diseo integrados con el cdigo que aun dejan muchas tareas de programacin pura y dura.

CONCLUSIONES Y RECOMENDACIONES
y Se destaca el hecho de que para proyectos pequeos resulta efectivo el lograr un prototipo rpido como tcnica de educcin de requisitos, que si bien al inicio demanda de un esfuerzo y tiempo adicional, esto se ve claramente compensando al momento de desarrollar el producto final, ya que redunda en conseguir una planificacin ms real, el tener una documentacin efectiva y poco cambiante, arquitecturas y diseos mejor logrados, pero por sobre todo, una mayor certeza de alcanzar lo que el usuario final realmente desea y por lo que est dispuesto a pagar.