SISTEMAS BASADO EN EL CONOCIMIETNO

DOCENTE : ING. FREDDY RONALD HUAPAYA CONDORIALUMNO : MANUEL ENRIQUE ALIAGA VIDURIZAGA

ADMINISTRACIÓN DE PROYECTOS

INTRODUCCIÓN

LA ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE ES UNA ACTIVIDAD DENTRO DE LA INGENIERÍA DE SOFTWARE. COMIENZA ANTES DE INICIAR CUALQUIER ACTIVIDAD TÉCNICA Y CONTINÚA A LO LARGO DEL MODELADO, CONSTRUCCIÓN Y DESPLIEGUE DEL SOFTWARE.LO QUE SE UTILIZA EN ESTE CAPÍTULO SERAN LAS 4 P, TIENEN INFLUENCIA SUSTANCIAL SOBRE LA ADMINISTRACIÓN DEL PROYECTO DE SOFTWARE: PERSONAL, PRODUCTO, PROCESO Y PROYECTO

PERSONALEN UN ESTUDIO PUBLICADO POR EL IEEE, SE PREGUNTÓ A LOS VICEPRESIDENTES DE INGENIERÍA DE TRES GRANDES COMPAÑÍAS TECNOLÓGICAS, CUÁL ERA EL ELEMENTO MÁS IMPORTANTE PARA EL ÉXITO DE UN PROYECTO DE SOFTWARE. ELLOS RESPONDIERON DE LA SIGUIENTE MANERA:• VP 1: SUPONGO QUE, SI TIENES QUE ELEGIR UNA COSA QUE SEA LA MÁS

IMPORTANTE EN NUESTRO AMBIENTE, DIRÍA QUE NO SON LAS HERRAMIENTAS QUE USAMOS, ES EL PERSONAL.

• VP 2: EL INGREDIENTE MÁS IMPORTANTE QUE FUE EXITOSO EN ESTE PROYECTO FUE TENER GENTE INTELIGENTE. LA COSA MÁS IMPORTANTE QUE HACES PARA UN PROYECTO ES SELECCIONAR AL PERSONAL.

ÉSTE ES UN TESTIMONIO CONVINCENTE ACERCA DE LA IMPORTANCIA DEL PERSONAL EN EL PROCESO DE INGENIERÍA DE SOFTWARE.

¿QUÉ SE BUSCA CUANDO SE ELIGE A ALGUIEN COMO LÍDER DE UN PROYECTO DE SOFTWARE?

• MOTIVACION• ORGANIZACIÓN• IDEAS• RESOLUCION DE PROBLEMAS• LOGROS• INFLUENCIA EN EL EQUIPO

EQUIPO DE SOFTWAREMANTEI DESCRIBE SIETE FACTORES DE PROYECTO QUE DEBEN CONSIDERARSE CUANDO SE PLANEE LA ESTRUCTURA DE LOS EQUIPOS DE INGENIERÍA DE SOFTWARE:1. DIFICULTAD DEL PROBLEMA QUE SE VA A RESOLVER.2. “TAMAÑO” DEL PROGRAMA RESULTANTE EN LÍNEAS DE CÓDIGO O PUNTOS DE

FUNCIÓN.3. TIEMPO QUE EL EQUIPO PERMANECERÁ UNIDO (VIDA DEL EQUIPO).4. GRADO EN EL QUE PUEDE DIVIDIRSE EN MÓDULOS EL PROBLEMA.5. CALIDAD Y CONFIABILIDAD REQUERIDAS POR EL SISTEMA QUE SE VA A CONSTRUIR6. RIGIDEZ DE LA FECHA DE ENTREGA.7. GRADO DE COMUNICACIÓN REQUERIDO PARA EL PROYECTO.

¿QUÉ ES UN EQUIPO “CUAJADO”?

• UN EQUIPO CUAJADO ES UN GRUPO DE PERSONAS TAN FUERTEMENTE UNIDO QUE EL TODO ES MAYOR QUE LA SUMA DE LAS PARTES. UNA VEZ QUE UN EQUIPO COMIENZA A CUAJARSE, LA PROBABILIDAD DE ÉXITO VA HACIA ARRIBA. EL EQUIPO PUEDE VOLVERSE IMPARABLE, UNA FUERZA ARRASADORA PARA EL ÉXITO. NO NECESITA SER ADMINISTRADO EN LA FORMA TRADICIONAL Y, CIERTAMENTE, NO NECESITA SER MOTIVADO.

EQUIPOS ÁGILES

• EL EQUIPO ÁGIL, ADOPTA LA MAYORÍA DE LAS CARACTERÍSTICAS DE LOS EQUIPOS DE PROYECTO DE SOFTWARE EXITOSOS Y EVITAN MUCHAS DE LAS TOXINAS QUE CREAN PROBLEMAS.

• LA FILOSOFÍA ÁGIL SUBRAYA LA COMPETENCIA INDIVIDUAL (MIEMBRO DE EQUIPO), ACOPLADA CON LA COLABORACIÓN GRUPAL COMO FACTORES DE ÉXITO VITALES PARA EL EQUIPO.

PRODUCTO

LE GUSTE O NO AL GERENTE DE PROYECTO, DEBE EXAMINAR EL PRODUCTO; SE PRETENDE QUE EL PROBLEMA SE RESUELVA DESDE EL PRINCIPIO MISMO DEL PROYECTO; CUANDO MENOS, SE DEBE ESTABLECER Y ACOTAR EL ÁMBITO DEL PRODUCTO.

ÁMBITO DE SOFTWARE

• LA PRIMERA ACTIVIDAD EN LA ADMINISTRACIÓN DEL PROYECTO DE SOFTWARE ES DETERMINAR EL ÁMBITO DEL SOFTWARE, QUE SE DEFINE AL RESPONDER LAS SIGUIENTES PREGUNTAS:

• CONTEXTO. ¿CÓMO ENCAJA EN UN SISTEMA, PRODUCTO O CONTEXTO EMPRESARIAL MÁS GRANDE EL SOFTWARE QUE SE VA A CONSTRUIR Y QUÉ RESTRICCIONES SE IMPONEN COMO RESULTADO DEL CONTEXTO?

• OBJETIVOS DE INFORMACIÓN. ¿QUÉ OBJETOS DE DATOS VISIBLES PARA EL CLIENTE SE PRODUCEN COMO SALIDA DEL SOFTWARE? ¿QUÉ OBJETOS DE DATOS SE REQUIEREN COMO ENTRADA?

• FUNCIÓN Y DESEMPEÑO. ¿QUÉ FUNCIÓN REALIZA EL SOFTWARE PARA TRANSFORMAR LOS DATOS DE ENTRADA EN SALIDA? ¿EXISTE ALGUNA CARACTERÍSTICA DE DESEMPEÑO ESPECIAL QUE DEBA ABORDARSE?

EL ÁMBITO DEL PROYECTO DE SOFTWARE NO DEBE TENER AMBIGÜEDADES NI SER INCOMPRENSIBLE EN LOS NIVELES ADMINISTRATIVO Y TÉCNICO.

DESCOMPOSICION DEL PROBLEMA

• LA DESCOMPOSICIÓN DEL PROBLEMA, EN OCASIONES LLAMADA DIVISIÓN O ELABORACIÓN DEL PROBLEMA, ES UNA ACTIVIDAD QUE SE ASIENTA EN EL CENTRO DEL ANÁLISIS DE REQUERIMIENTOS DEL SOFTWARE.

LA DESCOMPOSICIÓN SE APLICA EN DOS ÁREAS PRINCIPALES:• 1) LA FUNCIONALIDAD Y EL CONTENIDO (INFORMACIÓN) QUE DEBEN

ENTREGARSE.• 2) EL PROCESO QUE SE USARÁ PARA ENTREGARLO.

PROCESO

LAS ACTIVIDADES DEL MARCO CONCEPTUAL QUE CARACTERIZAN AL PROCESO DE SOFTWARE SON APLICABLES A TODOS LOS PROYECTOS DE SOFTWARE. EL PROBLEMA ES SELECCIONAR EL MODELO DE PROCESO QUE SEA ADECUADO PARA EL SOFTWARE QUE EL EQUIPO DEL PROYECTO SOMETERÁ A INGENIERÍA.

EL EQUIPO DEBE DECIDIR QUÉ MODELO DE PROCESO ES MÁS ADECUADO:

• 1) PARA LOS CLIENTES QUE SOLICITARON EL PRODUCTO Y EL PERSONAL QUE HARÁ EL TRABAJO

• 2) PARA LAS CARACTERÍSTICAS DEL PRODUCTO EN SÍ • 3) PARA EL ENTORNO DE PROYECTO DONDE TRABAJA EL EQUIPO DE SOFTWARE.CUANDO SE SELECCIONA UN MODELO DE PROCESO, EL EQUIPO DEFINE ENTONCES UN PLAN DE PROYECTO PRELIMINAR CON BASE EN EL CONJUNTO DE ACTIVIDADES DEL MARCO CONCEPTUAL DEL PROCESO.UNA VEZ ESTABLECIDO EL PLAN PRELIMINAR, COMIENZA LA DESCOMPOSICIÓN DEL PROCESO (PLAN COMPLETO DE TAREAS LABORALES REQUERIDAS).

FUSIÓN DE PRODUCTO Y PROCESO

• LA PLANIFICACIÓN DEL PROYECTO COMIENZA CON LA FUSIÓN DE PRODUCTO Y PROCESO. CADA FUNCIÓN QUE SE VA A SOMETER A INGENIERÍA POR PARTE DEL EQUIPO DEBE PASAR A TRAVÉS DEL CONJUNTO DE ACTIVIDADES DE MARCO CONCEPTUAL QUE DEFINA LA ORGANIZACIÓN DE SOFTWARE.

DESCOMPOSICIÓN DEL PROCESO

• UN EQUIPO DE SOFTWARE DEBE TENER UN GRADO SIGNIFICATIVO PARA ELEGIR EL MODELO DE PROCESO DE SOFTWARE QUE ES MEJOR PARA EL PROYECTO Y LAS TAREAS DE LA INGENIERÍA DE SOFTWARE QUE LLENEN EL MODELO DE PROCESO UNA VEZ ELEGIDO.

• UN PROYECTO RELATIVAMENTE PEQUEÑO QUE SEA SIMILAR A ESFUERZOS ANTERIORES PUEDE LOGRARSE MEJOR AL USAR EL ENFOQUE SECUENCIAL LINEAL.

PROYECTO

• PARA ADMINISTRAR UN PROYECTO DE SOFTWARE EXITOSO, SE DEBE COMPRENDER QUÉ PUEDE SALIR MAL, DE MODO QUE LOS PROBLEMAS PUEDAN EVITARSE. EN UN EXCELENTE ENSAYO ACERCA DE LOS PROYECTOS DE SOFTWARE, JOHN REEL DEFINE 10 SEÑALES QUE INDICAN QUE UN PROYECTO DE SISTEMAS DE INFORMACIÓN ESTÁ EN PELIGRO:

• 1. EL PERSONAL DEL SOFTWARE NO ENTIENDE LAS NECESIDADES DEL CLIENTE.• 2. EL ÁMBITO DEL PRODUCTO ESTÁ POBREMENTE DEFINIDO.• 3. LOS CAMBIOS SE GESTIONAN POBREMENTE.• 4. CAMBIA LA TECNOLOGÍA ELEGIDA.• 5. LAS NECESIDADES EMPRESARIALES CAMBIAN [O ESTÁN MAL DEFINIDAS].• 6. LAS FECHAS LÍMITE SON IRREALES.• 7. LOS USUARIOS SON RESISTENTES.• 8. PÉRDIDA DE PATROCINIO [O NUNCA OBTENIDO ADECUADAMENTE].• 9. EL EQUIPO DEL PROYECTO CARECE DE PERSONAL CON HABILIDADES ADECUADAS.• 10. LOS GERENTES [Y PROFESIONALES] EVITAN MEJORES PRÁCTICAS Y LECCIONES

APRENDIDAS.

¿CÓMO ACTÚA UN GERENTE PARA EVITAR LOS PROBLEMAS RECIÉN

ANOTADOS?• 1. COMENZAR CON EL PIE DERECHO. ESTO SE LOGRA AL TRABAJAR DURO (MUY DURO) PARA

ENTENDER EL PROBLEMA QUE DEBE RESOLVERSE Y LUEGO ESTABLECER OBJETIVOS Y EXPECTATIVAS REALISTAS PARA TODOS AQUELLOS QUE ESTARÁN INVOLUCRADOS EN EL PROYECTO..

• 2. MANTENER LA CANTIDAD DE MOVIMIENTO. MUCHOS PROYECTOS PARTEN HACIA UN BUEN COMIENZO Y LUEGO LENTAMENTE SE DESINTEGRAN.

• 3. SIGA LA PISTA AL PROGRESO. PARA UN PROYECTO DE SOFTWARE, EL PROGRESO SE RASTREA CONFORME LOS PRODUCTOS OPERATIVOS (POR EJEMPLO, MODELOS, CÓDIGO FUENTE, CONJUNTOS DE CASOS DE PRUEBA) SE PRODUCEN Y APRUEBAN (USANDO REVISIONES TÉCNICAS) COMO PARTE DE UNA ACTIVIDAD QUE ASEGURE LA CALIDAD.  

• 4. TOME DECISIONES INTELIGENTES. EN ESENCIA, LAS DECISIONES DEL GERENTE DEL PROYECTO Y DEL EQUIPO DE SOFTWARE DEBEN “MANTENERSE SIMPLES”.

• 5. REALICE UN ANÁLISIS POSTMORTEM (DESPUES DE LA MUERTE). ESTABLEZCA UN MECANISMO CONSISTENTE PARA EXTRAER LECCIONES APRENDIDAS POR CADA PROYECTO.

CONCLUSION DE LA ADMINISTRACIÓN DE PROYECTOS

EL PERSONAL DEBE ORGANIZARSE EN EQUIPOS EFICACES, MOTIVADOS PARA HACER TRABAJO DE SOFTWARE DE ALTA CALIDAD, Y COORDINARSE PARA LOGRAR COMUNICACIÓN EFECTIVA. LOS REQUERIMIENTOS DEL PRODUCTO DEBEN COMUNICARSE DE CLIENTE A DESARROLLADOR, DIVIDIRSE EN SUS PARTES CONSTITUTIVAS Y UBICARSE PARA SU TRABAJO POR PARTE DEL EQUIPO DE SOFTWARE. EL PROCESO DEBE ADAPTARSE AL PERSONAL Y AL PRODUCTO. SE SELECCIONA UN MARCO CONCEPTUAL COMÚN AL PROCESO, SE APLICA UN PARADIGMA DE INGENIERÍA DE SOFTWARE ADECUADO Y SE ELIGE UN CONJUNTO DE TAREAS DE TRABAJO PARA REALIZAR EL TRABAJO. FINALMENTE EL PROYECTO DEBE ORGANIZARSE DE FORMA QUE PERMITA TRIUNFAR AL EQUIPO DE SOFTWARE.

MÉTRICAS DE PROCESO Y DE PROYECTO

INTRODUCCION

• LA MEDICIÓN PERMITE A GERENTES Y PROFESIONALES MEJORAR EL PROCESO DE SOFTWARE; AUXILIAR EN LA PLANIFICACIÓN, RASTREO Y CONTROL DE PROYECTOS DE SOFTWARE Y VALORAR LA CALIDAD DEL PRODUCTO (SOFTWARE) QUE SE ELABORA.

• LAS MEDIDAS DE ATRIBUTOS ESPECÍFICOS DEL PROCESO, PROYECTO Y PRODUCTO SE USAN PARA CALCULAR LAS MÉTRICAS DE SOFTWARE. DICHAS MÉTRICAS PUEDEN ANALIZARSE PARA PROPORCIONAR INDICADORES QUE GUÍEN LAS ACCIONES ADMINISTRATIVAS Y TÉCNICAS.

¿QUÉ ES?

• LAS MÉTRICAS DE PROCESO Y PROYECTO DE SOFTWARE SON MEDIDAS CUANTITATIVAS QUE PERMITEN OBTENER COMPRENSIÓN ACERCA DE LA EFICACIA DEL PROCESO DEL SOFTWARE Y DE LOS PROYECTOS QUE SE REALIZAN, USANDO EL PROCESO COMO MARCO CONCEPTUAL. SE RECOPILAN DATOS BÁSICOS DE CALIDAD Y PRODUCTIVIDAD.

¿QUIÉN LO HACE?• LAS MÉTRICAS DEL SOFTWARE SE ANALIZAN Y VALORAN POR PARTE DE LOS

GERENTES DEL SOFTWARE. CON FRECUENCIA, LOS INGENIEROS DEL SOFTWARE RECOPILAN LAS MEDIDAS.

¿POR QUÉ ES IMPORTANTE?• SI NO SE MIDE, EL JUICIO PUEDE BASARSE SOLAMENTE EN LA EVALUACIÓN

SUBJETIVA. CON MEDICIÓN, PUEDEN MARCARSE LAS TENDENCIAS (BUENAS O MALAS), HACERSE MEJORES ESTIMACIONES Y, CON EL TIEMPO, LOGRARSE VERDADERA MEJORÍA.

¿CUÁLES SON LOS PASOS?

• SE DEFINE UN CONJUNTO LIMITADO DE MEDIDAS DE PROCESO, PROYECTO Y PRODUCTO, QUE SON FÁCILES DE RECOPILAR. DICHAS MEDIDAS CON FRECUENCIA SE NORMALIZAN USANDO MÉTRICAS DE TAMAÑO O DE FUNCIÓN. EL RESULTADO SE ANALIZA Y COMPARA CON PROMEDIOS ANTERIORES PARA PROYECTOS SIMILARES REALIZADOS DENTRO DE LA ORGANIZACIÓN.

¿CUÁL ES EL PRODUCTO FINAL?• UN CONJUNTO DE MÉTRICAS DE SOFTWARE QUE PROPORCIONAN

COMPRENSIÓN ACERCA DEL PROCESO Y DEL PROYECTO.

¿CÓMO ME ASEGURO DE QUE LO HICE BIEN?

• AL APLICAR UN ESQUEMA DE MEDICIÓN CONSISTENTE, AUNQUE SIMPLE, QUE NUNCA DEBE USARSE PARA VALORAR, RECOMPENSAR O CASTIGAR EL DESEMPEÑO INDIVIDUAL.

MÉTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO• LAS MÉTRICAS DE PROCESO PERMITEN QUE UNA ORGANIZACIÓN ADOPTE

UNA VISIÓN ESTRATÉGICA AL PROPORCIONAR COMPRENSIÓN ACERCA DE LA EFECTIVIDAD DE UN PROCESO DE SOFTWARE.

• LAS MÉTRICAS DE PROYECTO SON TÁCTICAS. PERMITEN QUE UN GERENTE DE PROYECTO ADAPTE EL FLUJO DE TRABAJO DEL PROYECTO Y EL ENFOQUE TÉCNICO EN TIEMPO REAL.

MEDICIÓN DEL SOFTWARE

• LAS MÉTRICAS ORIENTADAS A TAMAÑO Y A FUNCIÓN SE USAN A LO LARGO DE LA INDUSTRIA. LAS PRIMERAS USAN LA LÍNEA DE CÓDIGO COMO UN FACTOR DE NORMALIZACIÓN PARA OTRAS MEDIDAS, COMO PERSONA-MESES O DEFECTOS.

• EL PUNTO DE FUNCIÓN SE DERIVA DE LAS MEDIDAS DEL DOMINIO DE INFORMACIÓN Y DE UNA VALORACIÓN SUBJETIVA DE LA COMPLEJIDAD DEL PROBLEMA. ADEMÁS, PUEDEN USARSE MÉTRICAS ORIENTADAS A OBJETO Y A WEBAPP.

MÉTRICAS PARA CALIDAD DE SOFTWARE

• LAS MÉTRICAS DE CALIDAD DEL SOFTWARE, COMO LAS MÉTRICAS DE PRODUCTIVIDAD, SE ENFOCAN EN EL PROCESO, EL PROYECTO Y EL PRODUCTO. AL DESARROLLAR Y ANALIZAR UNA LÍNEA DE REFERENCIA DE MÉTRICAS PARA LA CALIDAD, UNA ORGANIZACIÓN PUEDE CORREGIR AQUELLAS ÁREAS DEL PROCESO DE SOFTWARE QUE SEAN LA CAUSA DE LOS DEFECTOS DE SOFTWARE.

CONCLUSION DE LAS MÉTRICAS DE PROCESO Y DE PROYECTO

LA MEDICIÓN DA COMO RESULTADO UN CAMBIO CULTURAL.• LA RECOPILACIÓN DE DATOS, • CÁLCULO DE MÉTRICAS Y • ANÁLISIS DE MÉTRICAS SON LOS TRES PASOS QUE DEBEN IMPLEMENTARSE PARA COMENZAR UN PROGRAMA DE MÉTRICAS. EN GENERAL, UN ENFOQUE DIRIGIDO A METAS AYUDA A UNA ORGANIZACIÓN A ENFOCARSE EN LAS MÉTRICAS CORRECTAS PARA SU EMPRESA. AL CREAR UNA LÍNEA DE REFERENCIA DE MÉTRICAS, UNA BASE DE DATOS QUE CONTENGA MEDICIONES DE PROCESO Y PRODUCTO, LOS INGENIEROS DE SOFTWARE Y SUS GERENTES PUEDEN OBTENER MEJOR COMPRENSIÓN DEL TRABAJO QUE HACEN Y DEL PRODUCTO QUE ELABORAN.

ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

• EN ESTE CAPÍTULO, SÓLO SE CONSIDERA LA ESTIMACIÓN, EL INTENTO POR DETERMINAR CUÁNTO DINERO, ESFUERZO, RECURSOS Y TIEMPO TOMARÁ CONSTRUIR UN SISTEMA O PRODUCTO ESPECÍFICO BASADO EN SOFTWARE.

EL PROCESO DE PLANIFICACIÓN DEL PROYECTO• EL OBJETIVO DE LA PLANIFICACIÓN DEL PROYECTO DE SOFTWARE ES

PROPORCIONAR UN MARCO CONCEPTUAL QUE PERMITA AL GERENTE HACER ESTIMACIONES RAZONABLES DE RECURSOS, COSTO Y CALENDARIO. ADEMÁS, LAS ESTIMACIONES DEBEN INTENTAR DEFINIR LOS ESCENARIOS DE MEJOR CASO Y PEOR CASO, DE MODO QUE LOS RESULTADOS DEL PROYECTO PUEDAN ACOTARSE.

ÁMBITO Y FACTIBILIDAD DEL SOFTWARE

• EL ÁMBITO DEL SOFTWARE DESCRIBE LAS FUNCIONES Y CARACTERÍSTICAS QUE SE ENTREGAN A LOS USUARIOS FINALES; LOS DATOS QUE SON ENTRADA Y SALIDA; EL “CONTENIDO” QUE SE PRESENTA A LOS USUARIOS COMO CONSECUENCIA DE USAR EL SOFTWARE Y EL DESEMPEÑO, LAS RESTRICCIONES, LAS INTERFACES Y LA CONFIABILIDAD QUE SE LIGAN AL SISTEMA.

• EL ÁMBITO SE DEFINE USANDO UNA DE DOS TÉCNICAS:1. UNA DESCRIPCIÓN NARRATIVA DEL ÁMBITO DEL SOFTWARE SE DESARROLLA DESPUÉS DE LA COMUNICACIÓN CON TODOS LOS PARTICIPANTES.2. LOS USUARIOS FINALES DESARROLLAN UN CONJUNTO DE CASOS DE USO.

RECURSOS• LA SEGUNDA TAREA EN LA PLANIFICACIÓN ES LA ESTIMACIÓN DE LOS

RECURSOS REQUERIDOS PARA LOGRAR EL ESFUERZO DE DESARROLLO DEL SOFTWARE.

ESTIMACIÓN DE PROYECTOS DE SOFTWARE

• LA ESTIMACIÓN DE COSTO Y ESFUERZO DEL SOFTWARE NUNCA SERÁ UNA CIENCIA EXACTA. DEMASIADAS VARIABLES (HUMANAS, TÉCNICAS, AMBIENTALES, POLÍTICAS) PUEDEN AFECTAR EL COSTO FINAL DEL SOFTWARE Y EL ESFUERZO APLICADO PARA SU DESARROLLO. SIN EMBARGO, LA ESTIMACIÓN DEL PROYECTO DE SOFTWARE PUEDE TRANSFORMARSE DE UN ARTE OSCURO A UNA SERIE DE PASOS SISTEMÁTICOS QUE PROPORCIONEN ESTIMACIONES CON RIESGO ACEPTABLE. PARA LOGRAR ESTIMACIONES CONFIABLES DE COSTO Y ESFUERZO, SURGEN ALGUNAS OPCIONES:

• 1. RETRASE LA ESTIMACIÓN HASTA AVANZADO EL PROYECTO (OBVIAMENTE, ¡PUEDE LOGRAR ESTIMACIONES 100 POR CIENTO PRECISAS DESPUÉS DE QUE EL PROYECTO ESTÉ COMPLETO!).

• 2. BASE LAS ESTIMACIONES EN PROYECTOS SIMILARES QUE YA ESTÉN COMPLETOS.• 3. USE TÉCNICAS DE DESCOMPOSICIÓN RELATIVAMENTE SIMPLES PARA GENERAR ESTIMACIONES

DE COSTO Y ESFUERZO DE PROYECTO.• 4. USE UNO O MÁS MODELOS EMPÍRICOS PARA ESTIMACIÓN DE COSTO Y ESFUERZO DE SOFTWARE.

TÉCNICAS DE DESCOMPOSICIÓN

• LA ESTIMACIÓN DEL PROYECTO DE SOFTWARE ES UNA FORMA DE RESOLUCIÓN DE PROBLEMAS Y, EN LA MAYORÍA DE LOS CASOS, EL PROBLEMA POR RESOLVER; ES DECIR, DESARROLLAR UNA ESTIMACIÓN DE COSTO Y ESFUERZO PARA UN PROYECTO DE SOFTWARE ES MUY COMPLEJO COMO PARA CONSIDERARSE EN UNA SOLA PIEZA.

• POR ESTA RAZÓN, DEBE DESCOMPONERSE EL PROBLEMA Y VOLVER A CARACTERIZARLO COMO UN CONJUNTO DE PROBLEMAS MÁS PEQUEÑOS Y MÁS MANEJABLES.

• DIMENSIONAMIENTO DEL SOFTWARELA PRECISIÓN DE UNA ESTIMACIÓN DE PROYECTO DE SOFTWARE SE BASA EN ALGUNAS COSAS: 1) EL GRADO EN EL QUE SE ESTIMÓ ADECUADAMENTE EL TAMAÑO DEL PRODUCTO QUE SE VA A CONSTRUIR, 2) LA HABILIDAD PARA TRADUCIR LA ESTIMACIÓN DE TAMAÑO EN ESFUERZO HUMANO, TIEMPO CALENDARIO Y DINERO 3) EL GRADO EN EL QUE EL PLAN DEL PROYECTO REFLEJA LAS HABILIDADES DEL EQUIPO DE SOFTWARE Y 4) LA ESTABILIDAD DE LOS REQUISITOS DEL PRODUCTO Y EL ENTORNO QUE SOPORTA EL ESFUERZO DE INGENIERÍA DE SOFTWARE.

• ESTIMACIÓN BASADA EN PROBLEMALOS DATOS LOC Y PF SE USAN EN DOS FORMAS DURANTE LA ESTIMACIÓN DEL PROYECTO DE SOFTWARE: 1) COMO VARIABLES DE ESTIMACIÓN PARA “DIMENSIONAR” CADA ELEMENTO

DEL SOFTWARE Y2) COMO MÉTRICAS DE REFERENCIA RECOPILADAS DE PROYECTOS PASADOS

Y UTILIZADAS EN CONJUNTO CON VARIABLES DE ESTIMACIÓN PARA DESARROLLAR PROYECCIONES DE COSTO Y ESFUERZO.

• ESTIMACIÓN BASADA EN PROCESO

LA TÉCNICA MÁS COMÚN PARA ESTIMAR UN PROYECTO ES BASAR LA ESTIMACIÓN SOBRE EL PROCESO QUE SE USARÁ. ES DECIR, EL PROCESO SE DESCOMPONE EN UN CONJUNTO RELATIVAMENTE PEQUEÑO DE TAREAS Y SE ESTIMA EL ESFUERZO REQUERIDO PARA LOGRAR CADA TAREA.

• ESTIMACION CON CASOS DE USOSLOS CASOS DE USO BRINDAN A UN EQUIPO DE SOFTWARE COMPRENSIÓN ACERCA DEL ÁMBITO Y LOS REQUISITOS DEL SOFTWARE. SIN EMBARGO, DESARROLLAR UN ENFOQUE DE ESTIMACIÓN CON CASOS DE USO ES PROBLEMÁTICO POR LAS SIGUIENTES RAZONES :• LOS CASOS DE USO SE DESCRIBEN USANDO MUCHOS FORMATOS Y ESTILOS DIFERENTES; NO EXISTE

UNA FORMA ESTÁNDAR.• LOS CASOS DE USO REPRESENTAN UNA VISIÓN EXTERNA (LA VISIÓN DEL USUARIO) DEL SOFTWARE Y,

POR TANTO, PUEDEN ESCRIBIRSE EN MUCHOS NIVELES DE ABSTRACCIÓN DIFERENTES.• LOS CASOS DE USO NO ABORDAN LA COMPLEJIDAD DE LAS FUNCIONES Y DE LAS CARACTERÍSTICAS

QUE SE DESCRIBEN.• LOS CASOS DE USO PUEDEN DESCRIBIR COMPORTAMIENTO COMPLEJO (POR EJEMPLO,

INTERACCIONES) QUE INVOLUCRAN MUCHAS FUNCIONES Y CARACTERÍSTICAS.A DIFERENCIA DE UNA LOC O DE UN PUNTO DE FUNCIÓN, EL “CASO DE USO” DE UNA PERSONA PUEDE REQUERIR MESES DE ESFUERZO, MIENTRAS QUE EL DE OTRA PUEDE IMPLEMENTARSE EN UN DÍA O DOS.

MODELOS DE ESTIMACIÓN EMPÍRICOS

• LA ESTRUCTURA DE LOS MODELOS DE ESTIMACIÓNUN MODELO DE ESTIMACIÓN TÍPICO SE INFIERE USANDO ANÁLISIS DE REGRESIÓN SOBRE LOS DATOS RECOPILADOSDE PROYECTOS DE SOFTWARE ANTERIORES. LA ESTRUCTURA GLOBAL DE TALES MODELOS TOMA LA FORMA

DONDE A, B Y C SON CONSTANTES DERIVADAS EMPÍRICAMENTE, E ES ESFUERZO EN PERSONA-MESES Y EV ES LA VARIABLE DE ESTIMACIÓN (LOC O PF).

CONCLUSION DE ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

• UN PLANIFICADOR DE PROYECTO DE SOFTWARE DEBE ESTIMAR TRES COSAS ANTES DE COMENZAR UN PROYECTO: CUÁNTO TARDARÁ, CUÁNTO ESFUERZO SE REQUERIRÁ Y CUÁNTAS PERSONAS SE INVOLUCRARÁN. ADEMÁS, EL PLANIFICADOR DEBE PREDECIR LOS RECURSOS (HARDWARE Y SOFTWARE) QUE SE REQUERIRÁN Y EL RIESGO INVOLUCRADO.