SISTEMAS BASADO EN EL

CONOCIMIETNO
DOCENTE: ING. FREDDY RONALD HUAPAYA CONDORI
ALUMNO : MANUEL ENRIQUE ALIAGA VIDURIZAGA

ADMINISTRACIN DE
PROYECTOS

INTRODUCCIN
LA ADMINISTRACIN DE PROYECTOS DE SOFTWARE ES UNA ACTIVIDAD
DENTRO DE LA INGENIERA DE SOFTWARE. COMIENZA ANTES DE INICIAR
CUALQUIER ACTIVIDAD TCNICA Y CONTINA A LO LARGO DEL
MODELADO, CONSTRUCCIN Y DESPLIEGUE DEL SOFTWARE.
LO QUE SE UTILIZA EN ESTE CAPTULO SERAN LAS 4 P, TIENEN INFLUENCIA
SUSTANCIAL SOBRE LA ADMINISTRACIN DEL PROYECTO DE SOFTWARE:
PERSONAL, PRODUCTO, PROCESO Y PROYECTO

PERSONAL
EN UN ESTUDIO PUBLICADO POR EL IEEE, SE PREGUNT A LOS
VICEPRESIDENTES
DE
INGENIERA
DE
TRES
GRANDES
COMPAAS
TECNOLGICAS, CUL ERA EL ELEMENTO MS 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 MS
IMPORTANTE EN NUESTRO AMBIENTE, DIRA QUE NO SON LAS HERRAMIENTAS
QUE USAMOS, ES EL PERSONAL.
VP 2: EL INGREDIENTE MS IMPORTANTE QUE FUE EXITOSO EN ESTE
PROYECTO FUE TENER GENTE INTELIGENTE. LA COSA MS 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 INGENIERA DE SOFTWARE.

QU SE BUSCA CUANDO SE ELIGE A ALGUIEN

COMO LDER DE UN PROYECTO DE SOFTWARE?
MOTIVACION
ORGANIZACIN
IDEAS
RESOLUCION DE PROBLEMAS
LOGROS
INFLUENCIA EN EL EQUIPO

EQUIPO DE SOFTWARE
MANTEI DESCRIBE SIETE FACTORES DE PROYECTO QUE DEBEN CONSIDERARSE
CUANDO SE PLANEE LA ESTRUCTURA DE LOS EQUIPOS DE INGENIERA DE SOFTWARE:
1. DIFICULTAD DEL PROBLEMA QUE SE VA A RESOLVER.
2. TAMAO DEL PROGRAMA RESULTANTE EN LNEAS DE CDIGO O PUNTOS DE
FUNCIN.
3. TIEMPO QUE EL EQUIPO PERMANECER UNIDO (VIDA DEL EQUIPO).
4. GRADO EN EL QUE PUEDE DIVIDIRSE EN MDULOS EL PROBLEMA.
5. CALIDAD Y CONFIABILIDAD REQUERIDAS POR EL SISTEMA QUE SE VA A
CONSTRUIR
6. RIGIDEZ DE LA FECHA DE ENTREGA.
7. GRADO DE COMUNICACIN 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 MAYORA DE LAS CARACTERSTICAS DE LOS
EQUIPOS DE PROYECTO DE SOFTWARE EXITOSOS Y EVITAN MUCHAS DE LAS
TOXINAS QUE CREAN PROBLEMAS.
LA FILOSOFA GIL SUBRAYA LA COMPETENCIA INDIVIDUAL (MIEMBRO DE
EQUIPO), ACOPLADA CON LA COLABORACIN 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 ADMINISTRACIN DEL PROYECTO
DE SOFTWARE ES DETERMINAR EL MBITO DEL SOFTWARE, QUE
SE DEFINE AL RESPONDER LAS SIGUIENTES PREGUNTAS:

 CONTEXTO. CMO ENCAJA EN UN SISTEMA, PRODUCTO O CONTEXTO

EMPRESARIAL MS GRANDE EL SOFTWARE QUE SE VA A CONSTRUIR Y QU
RESTRICCIONES SE IMPONEN COMO RESULTADO DEL CONTEXTO?
OBJETIVOS DE INFORMACIN. QU OBJETOS DE DATOS VISIBLES PARA EL
CLIENTE SE PRODUCEN COMO SALIDA DEL SOFTWARE? QU OBJETOS DE
DATOS SE REQUIEREN COMO ENTRADA?
FUNCIN Y DESEMPEO. QU FUNCIN REALIZA EL SOFTWARE PARA
TRANSFORMAR LOS DATOS DE ENTRADA EN SALIDA? EXISTE ALGUNA
CARACTERSTICA DE DESEMPEO ESPECIAL QUE DEBA ABORDARSE?
EL MBITO DEL PROYECTO DE SOFTWARE NO DEBE TENER AMBIGEDADES NI
SER INCOMPRENSIBLE EN LOS NIVELES ADMINISTRATIVO Y TCNICO.

DESCOMPOSICION DEL PROBLEMA

LA DESCOMPOSICIN DEL PROBLEMA, EN OCASIONES LLAMADA DIVISIN O
ELABORACIN DEL PROBLEMA, ES UNA ACTIVIDAD QUE SE ASIENTA EN EL
CENTRO DEL ANLISIS DE REQUERIMIENTOS DEL SOFTWARE.
LA DESCOMPOSICIN SE APLICA EN DOS REAS PRINCIPALES:
1) LA FUNCIONALIDAD Y EL CONTENIDO (INFORMACIN) 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 INGENIERA.

EL EQUIPO DEBE DECIDIR QU MODELO DE

PROCESO ES MS ADECUADO:
1) PARA LOS CLIENTES QUE SOLICITARON EL PRODUCTO Y EL PERSONAL QUE
HAR EL TRABAJO
2) PARA LAS CARACTERSTICAS 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 DESCOMPOSICIN DEL
PROCESO (PLAN COMPLETO DE TAREAS LABORALES REQUERIDAS).

FUSIN DE PRODUCTO Y PROCESO

LA PLANIFICACIN DEL PROYECTO COMIENZA CON LA FUSIN DE PRODUCTO
Y PROCESO. CADA FUNCIN QUE SE VA A SOMETER A INGENIERA POR PARTE
DEL EQUIPO DEBE PASAR A TRAVS DEL CONJUNTO DE ACTIVIDADES DE
MARCO CONCEPTUAL QUE DEFINA LA ORGANIZACIN DE SOFTWARE.

DESCOMPOSICIN 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 INGENIERA DE SOFTWARE QUE LLENEN EL
MODELO DE PROCESO UNA VEZ ELEGIDO.
UN PROYECTO RELATIVAMENTE PEQUEO 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 SEALES QUE INDICAN QUE UN
PROYECTO DE SISTEMAS DE INFORMACIN 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 TECNOLOGA ELEGIDA.
5. LAS NECESIDADES EMPRESARIALES CAMBIAN [O ESTN MAL DEFINIDAS].
6. LAS FECHAS LMITE SON IRREALES.
7. LOS USUARIOS SON RESISTENTES.
8. PRDIDA DE PATROCINIO [O NUNCA OBTENIDO ADECUADAMENTE].
9. EL EQUIPO DEL PROYECTO CARECE DE PERSONAL CON HABILIDADES ADECUADAS.
10. LOS GERENTES [Y PROFESIONALES] EVITAN MEJORES PRCTICAS Y LECCIONES
APRENDIDAS.

CMO ACTA UN GERENTE PARA

EVITAR LOS PROBLEMAS RECIN
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 ESTARN 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, CDIGO
FUENTE, CONJUNTOS DE CASOS DE PRUEBA) SE PRODUCEN Y APRUEBAN (USANDO
REVISIONES TCNICAS) 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 ANLISIS POSTMORTEM (DESPUES DE LA MUERTE). ESTABLEZCA UN
MECANISMO CONSISTENTE PARA EXTRAER LECCIONES APRENDIDAS POR CADA PROYECTO.

CONCLUSION DE LA ADMINISTRACIN DE
PROYECTOS
EL PERSONAL DEBE ORGANIZARSE EN EQUIPOS EFICACES, MOTIVADOS PARA HACER
TRABAJO DE SOFTWARE DE ALTA CALIDAD, Y COORDINARSE PARA LOGRAR
COMUNICACIN 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 COMN AL PROCESO, SE APLICA UN PARADIGMA DE INGENIERA
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.

MTRICAS DE PROCESO Y DE PROYECTO

INTRODUCCION
LA MEDICIN PERMITE A GERENTES Y PROFESIONALES MEJORAR EL PROCESO
DE SOFTWARE; AUXILIAR EN LA PLANIFICACIN, RASTREO Y CONTROL DE
PROYECTOS DE SOFTWARE Y VALORAR LA CALIDAD DEL PRODUCTO
(SOFTWARE) QUE SE ELABORA.

LAS MEDIDAS DE ATRIBUTOS ESPECFICOS DEL PROCESO, PROYECTO Y

PRODUCTO SE USAN PARA CALCULAR LAS MTRICAS DE SOFTWARE. DICHAS
MTRICAS PUEDEN ANALIZARSE PARA PROPORCIONAR INDICADORES QUE
GUEN LAS ACCIONES ADMINISTRATIVAS Y TCNICAS.

QU ES?
LAS MTRICAS DE PROCESO Y PROYECTO DE SOFTWARE SON MEDIDAS
CUANTITATIVAS QUE PERMITEN OBTENER COMPRENSIN ACERCA DE LA
EFICACIA DEL PROCESO DEL SOFTWARE Y DE LOS PROYECTOS QUE SE
REALIZAN, USANDO EL PROCESO COMO MARCO CONCEPTUAL. SE RECOPILAN
DATOS BSICOS DE CALIDAD Y PRODUCTIVIDAD.

QUIN LO HACE?
LAS MTRICAS 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 EVALUACIN
SUBJETIVA. CON MEDICIN, PUEDEN MARCARSE LAS TENDENCIAS (BUENAS O
MALAS), HACERSE MEJORES ESTIMACIONES Y, CON EL TIEMPO, LOGRARSE
VERDADERA MEJORA.

CULES SON LOS PASOS?

SE DEFINE UN CONJUNTO LIMITADO DE MEDIDAS DE PROCESO, PROYECTO Y
PRODUCTO, QUE SON FCILES DE RECOPILAR. DICHAS MEDIDAS CON
FRECUENCIA SE NORMALIZAN USANDO MTRICAS DE TAMAO O DE
FUNCIN. EL RESULTADO SE ANALIZA Y COMPARA CON PROMEDIOS
ANTERIORES PARA PROYECTOS SIMILARES REALIZADOS DENTRO DE LA
ORGANIZACIN.

CUL ES EL PRODUCTO FINAL?

UN CONJUNTO DE MTRICAS DE SOFTWARE QUE
COMPRENSIN ACERCA DEL PROCESO Y DEL PROYECTO.

PROPORCIONAN

CMO ME ASEGURO DE QUE LO HICE

BIEN?
AL APLICAR UN ESQUEMA DE MEDICIN CONSISTENTE, AUNQUE SIMPLE, QUE
NUNCA DEBE USARSE PARA VALORAR, RECOMPENSAR O CASTIGAR EL
DESEMPEO INDIVIDUAL.

MTRICAS EN LOS DOMINIOS DE

PROCESO Y PROYECTO
LAS MTRICAS DE PROCESO PERMITEN QUE UNA ORGANIZACIN ADOPTE
UNA VISIN ESTRATGICA AL PROPORCIONAR COMPRENSIN ACERCA DE LA
EFECTIVIDAD DE UN PROCESO DE SOFTWARE.
LAS MTRICAS DE PROYECTO SON TCTICAS. PERMITEN QUE UN GERENTE
DE PROYECTO ADAPTE EL FLUJO DE TRABAJO DEL PROYECTO Y EL ENFOQUE
TCNICO EN TIEMPO REAL.

MEDICIN DEL SOFTWARE

LAS MTRICAS ORIENTADAS A TAMAO Y A FUNCIN SE USAN A LO LARGO
DE LA INDUSTRIA. LAS PRIMERAS USAN LA LNEA DE CDIGO COMO UN
FACTOR DE NORMALIZACIN PARA OTRAS MEDIDAS, COMO PERSONA-MESES
O DEFECTOS.

EL PUNTO DE FUNCIN SE DERIVA DE LAS MEDIDAS DEL DOMINIO DE

INFORMACIN Y DE UNA VALORACIN SUBJETIVA DE LA COMPLEJIDAD DEL
PROBLEMA. ADEMS, PUEDEN USARSE MTRICAS ORIENTADAS A OBJETO Y A
WEBAPP.

MTRICAS PARA CALIDAD DE

SOFTWARE
LAS MTRICAS DE CALIDAD DEL SOFTWARE, COMO LAS MTRICAS DE
PRODUCTIVIDAD, SE ENFOCAN EN EL PROCESO, EL PROYECTO Y EL
PRODUCTO. AL DESARROLLAR Y ANALIZAR UNA LNEA DE REFERENCIA DE
MTRICAS PARA LA CALIDAD, UNA ORGANIZACIN PUEDE CORREGIR
AQUELLAS REAS DEL PROCESO DE SOFTWARE QUE SEAN LA CAUSA DE LOS
DEFECTOS DE SOFTWARE.

CONCLUSION DE LAS MTRICAS DE

PROCESO Y DE PROYECTO
LA MEDICIN DA COMO RESULTADO UN CAMBIO CULTURAL.
LA RECOPILACIN DE DATOS,
CLCULO DE MTRICAS Y
ANLISIS DE MTRICAS
SON LOS TRES PASOS QUE DEBEN IMPLEMENTARSE PARA COMENZAR UN
PROGRAMA DE MTRICAS. EN GENERAL, UN ENFOQUE DIRIGIDO A METAS AYUDA
A UNA ORGANIZACIN A ENFOCARSE EN LAS MTRICAS CORRECTAS PARA SU
EMPRESA. AL CREAR UNA LNEA DE REFERENCIA DE MTRICAS, UNA BASE DE
DATOS QUE CONTENGA MEDICIONES DE PROCESO Y PRODUCTO, LOS
INGENIEROS DE SOFTWARE Y SUS GERENTES PUEDEN OBTENER MEJOR
COMPRENSIN DEL TRABAJO QUE HACEN Y DEL PRODUCTO QUE ELABORAN.

ESTIMACIN PARA PROYECTOS DE

SOFTWARE

 EN ESTE CAPTULO, SLO SE CONSIDERA LA ESTIMACIN, EL INTENTO POR

DETERMINAR CUNTO DINERO, ESFUERZO, RECURSOS Y TIEMPO TOMAR
CONSTRUIR UN SISTEMA O PRODUCTO ESPECFICO BASADO EN SOFTWARE.

EL PROCESO DE PLANIFICACIN DEL

PROYECTO
EL OBJETIVO DE LA PLANIFICACIN DEL PROYECTO DE SOFTWARE ES
PROPORCIONAR UN MARCO CONCEPTUAL QUE PERMITA AL GERENTE HACER
ESTIMACIONES RAZONABLES DE RECURSOS, COSTO Y CALENDARIO.
ADEMS, 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 CARACTERSTICAS
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 DESEMPEO, LAS
RESTRICCIONES, LAS INTERFACES Y LA CONFIABILIDAD QUE SE LIGAN AL
SISTEMA.
EL MBITO SE DEFINE USANDO UNA DE DOS TCNICAS:
1. UNA DESCRIPCIN NARRATIVA DEL MBITO DEL SOFTWARE SE DESARROLLA
DESPUS DE LA COMUNICACIN CON TODOS LOS PARTICIPANTES.
2. LOS USUARIOS FINALES DESARROLLAN UN CONJUNTO DE CASOS DE USO.

RECURSOS
LA SEGUNDA TAREA EN LA PLANIFICACIN ES LA ESTIMACIN DE LOS
RECURSOS REQUERIDOS PARA LOGRAR EL ESFUERZO DE DESARROLLO DEL
SOFTWARE.

ESTIMACIN DE PROYECTOS DE
SOFTWARE
LA ESTIMACIN DE COSTO Y ESFUERZO DEL SOFTWARE NUNCA SER UNA CIENCIA EXACTA.
DEMASIADAS VARIABLES (HUMANAS, TCNICAS, AMBIENTALES, POLTICAS) PUEDEN AFECTAR EL
COSTO FINAL DEL SOFTWARE Y EL ESFUERZO APLICADO PARA SU DESARROLLO. SIN EMBARGO,
LA ESTIMACIN DEL PROYECTO DE SOFTWARE PUEDE TRANSFORMARSE DE UN ARTE OSCURO A
UNA SERIE DE PASOS SISTEMTICOS QUE PROPORCIONEN ESTIMACIONES CON RIESGO
ACEPTABLE. PARA LOGRAR ESTIMACIONES CONFIABLES DE COSTO Y ESFUERZO, SURGEN
ALGUNAS OPCIONES:
1. RETRASE LA ESTIMACIN HASTA AVANZADO EL PROYECTO (OBVIAMENTE, PUEDE LOGRAR
ESTIMACIONES 100 POR CIENTO PRECISAS DESPUS DE QUE EL PROYECTO EST COMPLETO!).
2. BASE LAS ESTIMACIONES EN PROYECTOS SIMILARES QUE YA ESTN COMPLETOS.
3. USE TCNICAS DE DESCOMPOSICIN RELATIVAMENTE
ESTIMACIONES DE COSTO Y ESFUERZO DE PROYECTO.

SIMPLES

PARA

GENERAR

4. USE UNO O MS MODELOS EMPRICOS PARA ESTIMACIN DE COSTO Y ESFUERZO DE

SOFTWARE.

TCNICAS DE DESCOMPOSICIN
LA ESTIMACIN DEL PROYECTO DE SOFTWARE ES UNA FORMA DE RESOLUCIN
DE PROBLEMAS Y, EN LA MAYORA DE LOS CASOS, EL PROBLEMA POR RESOLVER;
ES DECIR, DESARROLLAR UNA ESTIMACIN DE COSTO Y ESFUERZO PARA UN
PROYECTO DE SOFTWARE ES MUY COMPLEJO COMO PARA CONSIDERARSE EN UNA
SOLA PIEZA.

POR ESTA RAZN, DEBE DESCOMPONERSE EL PROBLEMA Y VOLVER A

CARACTERIZARLO COMO UN CONJUNTO DE PROBLEMAS MS PEQUEOS Y MS
MANEJABLES.

 DIMENSIONAMIENTO DEL SOFTWARE

LA PRECISIN DE UNA ESTIMACIN DE PROYECTO DE SOFTWARE SE BASA EN
ALGUNAS COSAS: 1) EL GRADO EN EL QUE SE ESTIM ADECUADAMENTE EL
TAMAO DEL PRODUCTO QUE SE VA A CONSTRUIR, 2) LA HABILIDAD PARA
TRADUCIR LA ESTIMACIN DE TAMAO 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 INGENIERA DE SOFTWARE.

 ESTIMACIN BASADA EN PROBLEMA

LOS DATOS LOC Y PF SE USAN EN DOS FORMAS DURANTE LA ESTIMACIN DEL
PROYECTO DE SOFTWARE:
1) COMO VARIABLES DE ESTIMACIN PARA DIMENSIONAR CADA ELEMENTO
DEL SOFTWARE Y
2) COMO MTRICAS DE REFERENCIA RECOPILADAS DE PROYECTOS PASADOS
Y UTILIZADAS EN CONJUNTO CON VARIABLES DE ESTIMACIN PARA
DESARROLLAR PROYECCIONES DE COSTO Y ESFUERZO.

 ESTIMACIN BASADA EN PROCESO

LA TCNICA MS COMN PARA ESTIMAR UN PROYECTO ES BASAR LA
ESTIMACIN SOBRE EL PROCESO QUE SE USAR. ES DECIR, EL PROCESO SE
DESCOMPONE EN UN CONJUNTO RELATIVAMENTE PEQUEO DE TAREAS Y SE
ESTIMA EL ESFUERZO REQUERIDO PARA LOGRAR CADA TAREA.

 ESTIMACION CON CASOS DE USOS

LOS CASOS DE USO BRINDAN A UN EQUIPO DE SOFTWARE COMPRENSIN ACERCA DEL MBITO Y LOS
REQUISITOS DEL SOFTWARE. SIN EMBARGO, DESARROLLAR UN ENFOQUE DE ESTIMACIN CON
CASOS DE USO ES PROBLEMTICO POR LAS SIGUIENTES RAZONES :
LOS CASOS DE USO SE DESCRIBEN USANDO MUCHOS FORMATOS Y ESTILOS DIFERENTES; NO
EXISTE UNA FORMA ESTNDAR.
LOS CASOS DE USO REPRESENTAN UNA VISIN EXTERNA (LA VISIN DEL USUARIO) DEL SOFTWARE
Y, POR TANTO, PUEDEN ESCRIBIRSE EN MUCHOS NIVELES DE ABSTRACCIN DIFERENTES.
LOS CASOS DE USO NO ABORDAN LA COMPLEJIDAD DE LAS FUNCIONES Y DE LAS CARACTERSTICAS
QUE SE DESCRIBEN.
LOS CASOS DE USO PUEDEN DESCRIBIR COMPORTAMIENTO COMPLEJO (POR EJEMPLO,
INTERACCIONES) QUE INVOLUCRAN MUCHAS FUNCIONES Y CARACTERSTICAS.
A DIFERENCIA DE UNA LOC O DE UN PUNTO DE FUNCIN, EL CASO DE USO DE UNA PERSONA
PUEDE REQUERIR MESES DE ESFUERZO, MIENTRAS QUE EL DE OTRA PUEDE IMPLEMENTARSE EN UN
DA O DOS.

MODELOS DE ESTIMACIN EMPRICOS

LA ESTRUCTURA DE LOS MODELOS DE ESTIMACIN
UN MODELO DE ESTIMACIN TPICO SE INFIERE USANDO ANLISIS DE
REGRESIN SOBRE LOS DATOS RECOPILADOS
DE PROYECTOS DE SOFTWARE ANTERIORES. LA ESTRUCTURA GLOBAL DE
TALES MODELOS TOMA LA FORMA
DONDE A, B Y C SON CONSTANTES DERIVADAS EMPRICAMENTE, E ES
ESFUERZO EN PERSONA-MESES Y EV ES LA VARIABLE DE ESTIMACIN (LOC O
PF).

CONCLUSION DE ESTIMACIN PARA

PROYECTOS DE SOFTWARE
UN PLANIFICADOR DE PROYECTO DE SOFTWARE DEBE ESTIMAR TRES COSAS
ANTES DE COMENZAR UN PROYECTO: CUNTO TARDAR, CUNTO ESFUERZO
SE REQUERIR Y CUNTAS PERSONAS SE INVOLUCRARN. ADEMS, EL
PLANIFICADOR DEBE PREDECIR LOS RECURSOS (HARDWARE Y SOFTWARE)
QUE SE REQUERIRN Y EL RIESGO INVOLUCRADO.