Professional Documents
Culture Documents
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Administracin de proyectos de software Grficas PERT y GANTT Mtricas del proyecto Mediciones del software Mtricas orientadas al tamao (LDC) Modelo de Estimacin de Costos COCOMO Mtricas orientadas a los puntos de funcin Anlisis de riesgos Conclusiones Referencias
2
1. Administracin de proyectos
La administracin de proyectos consiste en gestionar la produccin de un producto dentro del tiempo dado y los lmites de fondos. Requiere recursos humanos Involucra l no slo l la l organizacin tcnica y las l habilidades organizacionales, sino tambin el arte de administrar personas.
El costo total del proyecto Por ejemplo, aumentar los gastos Las capacidades del producto Como eliminar una lista de caractersticas La calidad del producto Como aumentar el tiempo medio entre fallas La duracin del proyecto Por ejemplo, reducir el tiempo programado 20% O posponer un mes la fecha de terminacin
Estructura (elementos organizacionales involucrados) Proceso administrativo (responsabilidades y supervisin de los participantes) Proceso de desarrollo (mtodos, herramientas, lenguajes, documentacin y apoyo) Programa (tiempos en los que deben realizarse las porciones del trabajo)
2.
Comprender el contenido, alcance y marco del tiempo del proyecto Identificar el proceso de desarrollo
(modelos, mtodos, herramientas, lenguajes, documentacin y apoyo) (elementos organizacionales involucrados) (responsabilidades de los participantes) (tiempos en los que deben realizarse las porciones del trabajo) TSP, PSP, CMM, MOPROSOFT
3.
4 4.
5.
6.
7. 8. 9.
Iniciar la administracin de riesgo Identificar los documentos que se producirn Iniciar el proceso
Planeacin de proyectos
Se refiere a la identificacin de actividades, hitos y entregas producidas por un proyecto Para eso, se requiere un plan del proyecto: fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo El plan del proyecto, puede contener otros tipos de planes
Siempre hay plazos, algunos ms ajustados y otros mas holgados. Son exigibles. Responden a compromisos (verbales o escritos) cmo enfrentarlos?
Buena estimacin de tiempo, p , esfuerzo y costos. Especialmente p Ruta Crtica. Se recomienda uso de modelos incrementales. Conversarlos con el Jefe (lograr un acuerdo) y luego con el usuario(s)/cliente lograr un consenso). Afinar la planificacin. Comunicarla : que todos los involucrados la conozcan
Principios bsicos
Calidad v/s plazos Origen de los retrasos Compromisos poco realistas (presiones). Cambios de requisitos. Subestimacin de esfuerzos y/o recursos requeridos. Errores predecibles e impredecibles no considerados en la planificacin. Dificultades tcnicas imprevistas. Dificultades humanas imprevistas. Falta de comunicacin dentro del equipo del proyecto. Subestimar los retrasos y no administrar medidas correctivas
9
Compartimentacin: El proyecto debe dividirse en un nmero de actividades y tareas manejables. Interdependencia: Cmo dependen unas tareas de otras para su ejecucin? Asignacin g de tiempo: p a cada tarea. Ej. j Personas-da de esfuerzo Validacin del esfuerzo: Verificar que no se ha asignado ms horas de trabajo que las disponibles. Responsabilidades definidas: Cada tarea que se programe debe asignarse a un miembro del equipo especfico. Resultados definidos: Cada tarea programada debe tener un resultado definido. Hitos definidos: Momentos de control global o por mdulo. 10
Camino Crtico
Es la secuencia de tareas cuyo atraso provoca atrasos en el fin del proyecto Las herramientas lo calculan automticamente (grafos PERT y Gantt) Una tarea no crtica tiene un margen de tiempo a partir del cual se convierte en crtica Por lo tanto:
El mayor esfuerzo de la estimacin debe ser en las tareas crticas Para comprimir tareas en el cronograma, debe comenzar el anlisis por las tareas crticas
11
Se utilizan notaciones grficas para ilustrar la planificacin del proyecto. Muestra la particin del proyecto en tareas. Las tareas no deben ser muy pequeas. Estas deben de tener una duracin de una semana o dos dos. Las grficas de actividades muestran las dependencias entre tareas y la ruta crtica. Las grficas de barras muestran la planificacin contra el tiempo del calendario de actividades.
12
Diagramas GANTT
Diagramas GANTT
Tcnica de control de proyectos, que puede ser utilizada para Scheduling y Plan de recursos Cada barra representa una actividad Se dibujan contra una lnea de tiempo La longitud de cada barra representa la longitud de tiempo de esa actividad A las tareas se le puede asignar los recursos
Pueden ser derivados automticamente de los grafos PERT Los GANTT ayudan a planear la utilizacin de recursos
13
14
15
16
Grafos PERT
Grafos PERT
Program Evaluation and Review Technique Grafo dirigido etiquetado Los nodos representan actividades y los ejes dependencias Los nodos pueden tener varios tipos de informacin Nombre, fecha de inicio y finalizacin Algunos nodos pueden ser definidos como milestones (hitos, puntos de control)
Que se puede calcular? Fecha ms temprana y tarda de comienzo Fecha ms temprana y tarda de finalizacin Se puede determinar el camino crtico de un proyecto Ventajas de los grafos PERT Fuerza al lder del proyecto a planear (debe definir que tareas son necesarias) Expone claramente las actividades crticas del proyecto Expone paralelismo de tareas y por lo tanto ayuda a la asignacin de recursos Permite al lder del proyecto a monitorear y controlar el proyecto
17
Los PERT son mejores para monitorear el progreso y el retraso de las actividades 18
Ejemplo 1. PERT
Ej 2. PERT
19
20
21
22
23
24
3. Introduccin Mtricas
3. Introduccin Mtricas
Medicin proceso por el cual nmeros smbolos son asignados a atributos de entidades en el mundo real, de manera semejante como se les atribuye
reglas definidas
Mtricas son estndares (i.e., escalas comunmente aceptadas) que definen atributos medibles de entidades, sus unidades y sus alcances Medida es una relacin entre un atributo y una escala de medicin
3. Introduccin Mtricas
Las mtricas de software son medidas que se usan para cuantificar el software, los recursos del desarrollo de software, y/o el proceso de desarrollo de software. Esto incluye elementos que son medibles de forma directa, tal como las lneas de cdigo, as como tambin elementos que son calculados de mediciones, tal como la calidad del software.
Se puede aplicar al proceso con la intencin de mejorarlo La eficacia de un proceso de sw se mide indirectamente. Se extrae un conjunto de mtricas de los resultados que provienen del proceso
Errores detectados antes de la entrega del sw Defectos detectados e informados por los usuarios finales Productos de trabajo entregados Esfuerzo humano y tiempo consumido
PSP, TSP, CMM, MOPROSOFT Las mtricas del proceso de software se utilizan para propsitos estratgicos
Finalmente para evaluar la calidad de productos tcnicos para ayudar en la toma de decisiones tcticas a medida que el proyecto evoluciona.
Esto es, las mtricas de proyectos y los indicadores derivados de ellos los utiliza un gestor de proyectos y un equipo de sw para adaptar el flujo de trabajo del proyecto y las actividades tcnicas
ndices de produccin: pginas de documentacin, horas de revisin, puntos de funcin y lneas fuentes entregadas Minimizar la planificacin de desarrollo Evaluar la calidad de los productos en el momento actual
La primera aplicacin de las mtricas de proyectos de sw ocurre durante la estimacin, para esto se utilizan las mtricas de proyectos anteriores Estimaciones del esfuerzo y del tiempo para el trabajo actual
31
Sin mediciones no hay forma de determinar si el proceso esta mejorando. Las mtricas permiten el establecimiento de metas significativas para la mejora. Se puede establecer una lnea de inicio de la cual las mejoras pueden ser medidas Las mtricas permiten identificar las causas de defectos que tienen mayores efectos en el desarrollo de software Cuando se aplican mtricas a un producto pueden ayudar a identificar:
Que requerimientos del usuario son probables de cambiar Que mdulos son ms propensos a errores Cuanta prueba debera ser planeada para cada modulo
Administradores
Que cuesta cada proceso? Que tan productivo es el personal? Que tan bueno es el cdigo que esta siendo desarrollado? Estar satisfecho el usuario con el p producto? Como podemos mejorarlo? Son comprobables los requerimientos? Se han encontrado todas las fallas? Conocemos las metas del producto o proceso? Que podemos predecir de nuestro producto software en el futuro?
35
Ingenieros
La medicin directa de un atributo de una entidad no involucra otros atributos o entidades La medicin indirecta es til en hacer visible la interaccin entre mediciones directas La medicin d indirecta d es favorable f bl cuando d el l tamao de medidas empricas es bastante grande (i.e., muchas relaciones y muchas entidades)
36
Errores por KLDC (miles de lneas de cdigo) Defectos por KLDC Pginas de doc. Por KLDC Errores/persona-mes LDC/persona mes
Uno de los atributos ms tiles es el tamao de un producto software, que puede ser medido estticamente, i.e., sin ejecutar el sistema Es necesario definir el tamao del sw., en trminos de ms de un atributo interno interno, que cada uno capture un aspecto clave del tamao del sw. La medicin del tamao debe reflejar esfuerzo, costo
y productividad.
38
El tamao del sw., puede ser descrito por la longitud, funcionalidad y complejidad. Longitud es el tamao fsico del producto. Funcionalidad es una medida de las funciones
suministradas al producto Complejidad es un atributo que puede ser interpretado de muchas maneras
Reuso tambin es un atributo que tiene que ver con el tamao, especficamente la cantidad o tamao de reuso dentro de un programa
39
En el desarrollo de sw., hay tres productos principales de desarrollo: especificacin, diseo y codificacin La longitud de la especificacin puede indicar cunto tiempo se necesita para que se realice el diseo, qu a su vez es un predictor de longitud del cdigo. cdigo Tradicionalmente, la longitud de cdigo se refiere a la longitud de cdigo basado en texto.
40
Longitud: Cdigo-LOC
La medida ms comnmente usada de la longitud del programa fuente es el nmero de lneas de cdigo (LOC)
NCLOC CLOC
Longitud total:
Conforme el desarrollo de software utiliza ms herramientas automatizadas, la medicin de lneas de cdigo es cada vez menos significativa Herramientas que generan cdigo a partir de p especificaciones Herramientas de programacin visual Cual puede ser la medida de longitud para objetos que no son textuales? Como puede uno contar componentes que son construidos externamente? (libreras, repositorios, funciones heredadas, patrones de diseo, etc.)
42
41
La medicin del tamao LOC necesita ser reemplazada por otras medidas tales como:
Puntos de objetos (usados en COCOMO 2.0) Medir la longitud tomando en cuenta la porcin de cdigo reutilizado
Las mtricas orientadas al tamao son medidas directas del software. Esas mtricas incluyen esfuerzo (personas-tiempo), dinero gastado, LOC, # de pginas de documentos creados, errores y nmero de personal La medida bsica para la longitud es LOC. Las mtricas simples orientadas al tamao pueden ser generadas de LOC como sigue: Productividad = KLOC/persona-mes Calidad = defectos/KLOC Documentacin = pginas de documentos / KLOC
44
43
COCOMO (Constructive Cost Model) (Boehm, 1981): Es un modelo que se basa en entradas que relacionan al tamao del sistema y un nmero de conductores de costo que afectan la productividad COCOMO II, la versin actualizada, considera cambios en la tecnologa de ingeniera de sw, incluyendo sw OO, sw creado va modelos de desarrollo evolutivos o espiral, reuso de sw y nuevas construcciones de sistemas usando componentes sw del estante (COTS-Commercial off the shelf)
45
Modelo bsico. Se aplica cuando se conoce poco del proyecto. El esfuerzo (persona-mes) se calcula en funcin del tamao del programa (KLOC) Modelo intermedio. Se aplica despus de la adquisicin de requerimientos. Calcula el esfuerzo como una funcin del tamao del programa y un conjunto de conductores de costo (para el producto producto, hw, personal y proyecto) Modelo avanzado. Se aplica despus de que el diseo es completado. Calcula el esfuerzo en funcin del tamao del programa y un conjunto de conductores de costo valorados en cada fase del ciclo de vida del software.
46
tiende a usar base de datos y se centra en operaciones y recuperacin de datos. Ej. Sistemas de contabilidad o bancarios Modo empotrado: Contiene sw de tiempo real, que es parte integral de sistemas grandes, basados en hw. Ej. sistema de misiles guiados, sw de control de navegacin para un avin. Modo semi-acoplado: Algn sistema entre orgnico y empotrado. Ej. Un sistema de procesamiento de transacciones con requisitos fijos para un hw de terminal, un sw de gestin de base de datos.
47
T = cE d
Donde: E es el esfuerzo en persona-mes T es el tiempo de desarrollo S es el tamao medido en KLOC F es el factor de ajuste del esfuerzo (1 en el modelo bsico) Los factores a, b dependen del tipo de modelo de COCOMO, y los factores c y d dependen del tipo de proyecto
48
COCOMO: Bsico
COCOMO: Intermedio
El factor de ajuste del esfuerzo (F) vale 1 en este modelo Valores de los factores a, b, c y d|
El factor de ajuste del esfuerzo (F) se calcula usando 15 conductores de costo Valores de los factores a, b, c y d
49
50
COCOMO: Intermedio
Conductores de costos
Conductores de costo:
RELY Required software reliability DATA Database size CPLX Product complexity
Basado en la valoracin, se determina el multiplicador de esfuerzo (ME) a partir de las tablas publicadas por Boehm, 1981. El producto de todos los multiplicadores de esfuerzo es (F)
F =
15
ME
i
51
Execution time constraint Main store constraint Virtual machine volatility Computer turnaround time
52
i =1
Conductores de costos
Analyst capability Applications experience Programmer capability Virtual Machine experience Language experience
MODP Modern programming practices TOOL Software tools SCED Development schedule
53 54
55
56
COCOMO: Avanzado
Ejemplo
Las 4 fases usadas en el modelo detallado de COCOMO son: planeacin de requerimiento y diseo del producto (RDP), diseo detallado (DD), pruebas de cdigo y por unidad (CUT), e integracin y pruebas (IT) Cada conductor de costo se descompone por cada fase como se ve en la tabla La estimacin realizada para cada mdulo se combinan en subsistemas y eventualmente se estima todo el proyecto
valor very Low low Nominal High Very High RDP 1.80 0.85 1.00 0.75 0.55 DD 1.35 0.85 1.00 0.90 0.75 CUT 1.35 0.85 1.00 0.90 0.75 IT 1.50 1.20 1.00 0.85 0.70
57
Para predecir el esfuerzo requerido para implementar el sw para un mejor sistema de conmutacin telefnica, se ha determinado que el sistema requerir 5000 KLOC. El software es empotrado, dado que es un sistema de tiempo real, real que es parte de un gran sistema hw complejo. Determine el esfuerzo y la duracin utilizando COCOMO, as como, el nmero de personas en el total del tiempo de desarrollo.
58
La funcionalidad es otro atributo del tamao del sw. La idea es que un producto con ms funcionalidad ser ms grande en tamao. Estas mtricas son medidas indirectas del sw., que se centran en la funcionalidad y la utilidad Las 1er Mtrica orientada a la funcin fue propuesta por Albrecht (19791983) quien sugiri una aproximacin a la medicin de la productividad llamado el mtodo de Punto de Funcin (FP) Los puntos de funcin (FPs) miden la cantidad de funcionalidad en un sistema basado en la especificacin del sistema
59
60
External Inputs (Entradas externas) External Outputs (Salidas externas) External Inquiry (Consultas externas) Internal Logical File (Archivo lgico interno) External Interface File (Archivo de interfase externa)
61
62
Clculo de los Puntos de Funcin Sin Ajustar(UFC, Unadjusted Function point Count) Clculo del Factor Tcnico de Complejidad(TCF, Technical Complexity Factor)
Se listan todos los tipos de funcin encontrados en el sistema Se le asigna a cada tipo de funcin una complejidad(baja, media o alta), con su correspondiente valor en puntos de funcin funcin. Se suman todos los puntos de funcin, dando como resultado los puntos de funcin sin ajustar.
FP=UFC*TCF
63
64
External Inputs
65
66
Complejidad
Determinado por:
Los DET's son campos que no se repiten, reconocibles por el usuario, contenidos en el ILF
Ej. Los campos fsicamente almacenados en campos mltiples (como nmeros de cuenta, fechas, hora) deberan ser contados como un campo cuando el usuario se refiere a ellos como un elemento.
67
68
Componente funcional EI
Ejemplos EIs
El conteo se hace para las siguientes categoras, como procesos elementales: External Inputs (EI): Los datos cruzan los lmites de afuera hacia adentro. Estos datos pueden venir de una pantalla de entrada o de otra aplicacin aplicacin. Los datos son usados para mantener uno o ms archivos lgico internos (ILFs). Los datos pueden ser datos orientados a la aplicacin informacin de control. Si los datos son info. de control, no se tiene que actualizar un ILF
69
Ejemplos EIs
A/B/C
inventario
Parte: ________________________ Descripcin: _______________ Origen: _________________ Cantidad: _______________ Precio: _____________ Colocacin: ______________ Mensaje ____________________________
auditoria
72
Ejemplos EIs
74
Componente funcional EO
Contar todos los elementos de datos nicos o archivos lgicos usados. No incluir nmeros de pginas, literales o encabezados de columnas en la cuenta de elementos de datos. Contar un solo DET para todos los campos que muestren mensajes de error (o mensajes de confirmacin), campos de control o almacenamiento multiple del mismo campo de datos. El conteo de los puntos de funcin es una medida estadstica. Se basa en un gran nmero de observaciones diferentes.
75
External Outputs (EO): Los datos derivados cruzan los lmites de adentro hacia fuera. Los datos crean reportes o archivos de salida enviados a otras aplicaciones. Estos reportes y archivos son creados de uno o mas ILFs o archivos de interfase externos (EIF s). (EIFs) Los datos derivados son datos que son procesados ms all de la edicin directa de informacin de ILFs. Los datos derivados son usualmente el resultado de algoritmos o clculos. Los datos derivados ocurren cuando uno o ms elementos de datos son combinados con una frmula para generar o derivar elementos de datos adicionales
Ejemplos EOs
Ejemplos EOs
Anlisis de la EO anterior.
tarifas
ahorros
empleados
Impuestos
seguros
79
Un reporte tpico de nmina accedera a mas de 3 archivos de negocios (archivo de empleados, de tasas, de seguros, de ahorros, de tarifas de salarios). El total para los campos tasas, seguros, pago bruto, pago neto ya determina que el tipo de funcin es una EO. La EO tendra 15 DET DET's s y ms de 3 RET's, RET s, por tanto se clasifica como complejidad high. Los DET's incluiran todas las 8 columnas. Adicionalmente, el total de una columna se cuenta como un DET separado. Adems la fecha y el campo departamento se incluiran en el conteo de los DET's. Sin embargo el nmero de pgina no se contara como un DET separado. Los diferentes formatos de impresin causados por las diferentes caractersticas de las impresoras no se contaran como EO's separadas.
80
Componente funcional EQ
combinaciones de entradas/salidas que resultan de la adquisicin de datos de uno o ms ILFs o EIFs. El proceso de entrada no actualiza ningn ILF, y el proceso de salida no contiene datos derivados.
Nota: los campos totales de un DET son contados como un nico DET de su propio campo. Esta interpretacin est bajo Debate.
81
Ejemplos EQ
Ejemplos EQ
85
86
Complejidad EQ
Determinar la complejidad del lado de entrada EI Determinar la p j del lado complejidad de salida EO La complejidad de EQ es la ms alta de las dos
87
88
El conteo se hace para las siguientes categoras: Internal Logical File (ILF) : Un ILF es un grupo de datos definidos por el usuario que estn relacionados lgicamente, que residen en su totalidad dentro de los lmites de la aplicacin y que son actualizados a travs de entradas externas. External Interface File (EIF): Un EIF es un grupo de datos definidos por el usuario que estn relacionados lgicamente y que solo son usados para propsitos de referencia. Los datos residen enteramente fuera de la aplicacin y son mantenidos por otra aplicacin. Este archivo(s) es un ILF para otra aplicacin
Nota: los campos totales de un DET son contados como un nico DET de su propio campo. Esta interpretacin est bajo Debate.
89 90
Subgrupo de elementos de datos en ILF Reconocibles por el usuario Ningn proceso elemental propio Tipos
Obligatorio Opcional
En la prctica sin embargo, las mayora de ILFs tendrn solo un tipo de RET y menos de 50 DETs. Por tal razn, las reglas de conteo NEFPUG han reducido la matriz de complejidad ILF al primer rengln.
91
92
Ejemplo
FP: Ejemplo /1
Espec., de un corrector ortogrfico: El corrector acepta como entrada un archivo con el documento y un archivo del diccionario personal opcional. El corrector, lista todas las palabras que no estn contenidas en alguno de los archivos archivos. El usuario puede consultar el nmero de palabras procesadas y el nmero de errores ortogrficos encontrados en alguna etapa durante el procesamiento.
93
94
Suponer que:
F1=F2=F6=F7=F8=F14=3; F4=F10=5 y el resto son cero. TCF=0.65+0.01(18+10)=0.93 FP=58x0.9354
95
F1 Comunicacin de los datos F2 Procesamiento distribuido F3 Rendimiento F4 Configuracin del equipo F5 Volumen de transacciones F6 Entrada de datos On-line F7 interfase con el usuario
0 1 2 3 4 5
= = = = = =
97
EL TCF vara de 0.65 (si todos los Fj son asignados a cero) a 1.35 (si todos los Fj son asignados a 5)
98
Cuntas herramientas de comunicacin hay para ayudar en la transferencia o intercambio de informacin de la aplicacin o sistema?
1. Comunicacin de datos
8. Anlisis de Riesgos
Qu tan efectivos y/o automatizados son los procedimientos de inicio, respaldo y recuperacin?
La aplicacin se dise, desarroll y soport especficamente para ser instalada en mltiples sitios para varias organizaciones?
Una tarea importante del administrador de proyectos es anticipar los riesgos que podran afectar la programacin del proyecto o la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. riesgos Los resultados del anlisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el anlisis de consecuencias cuando el riesgo ocurra. Identificarlos y crear planes para minimizarlos, se le llama administracin de riesgos.
Manejo de Riesgos
Categoras de Riesgos
La tarea principal del administrador consiste en minimizar riesgos. El riesgo inherente en una actividad se mide en base a la incertidumbre que presenta el resultado de esa actividad. actividad Las actividades con alto riesgo causan sobre-costes en cuanto a planeacin y costos El riesgo es proporcional al monto de la calidad de la informacin disponible. Cuanto menos informacin, mayor el riesgo.
103
RIESGOS DEL PROYECTO. Afectan la calendarizacin o los recursos del proyecto. RIESGOS DEL PRODUCTO: Afectan la calidad o desempeo del software que se est desarrollando. RIESGOS SGOS DEL NEGOCIO: GOC O Afectan f a la l organizacin que desarrolla el software.
TIP O
RIESGO
PROBABILIDA D
EFECTOS
O P P T R O T E H R P E E H
Los problemas financieros de la organizacin fuerzan a reducciones en el Baja presupuesto del proyecto. Es imposible reclutar personal con las habilidades requeridas para el Alta proyecto. El personal clave est enfermo y no disponible en momentos crticos. Moderada Los componentes de software a reutilizarse contienen defectos que limitan Moderada la funcionalidad. Se proponen cambios en los requerimientos que requieren rehacer el Moderada diseo. La organizacin i i se reestructura de d tal l forma f que una administracin d i i i Alta l diferente se responsabiliza del proyecto. La base de datos que se utiliza en el sistema no puede procesar muchas Moderada transacciones por segundo como se esperaba. El tiempo requerido para desarrollar el software est subestimado. Alta Las herramientas CASE no se pueden integrar. Alta Los clientes no comprenden el impacto de los cambios en los Moderada requerimientos. La capacitacin solicitada para el personal no est disponible. Moderada La tasa de reparacin de defectos est subestimada. Moderada El tamao del software est subestimado. Alta Es ineficiente el cdigo generado por las herramientas CASE. Moderada
Catastrfico Catastrfico Serio Serio Serio Serio i Serio Serio Tolerable Tolerable Tolerable Tolerable Tolerable
Insignificante
La probabilidad de que el riesgo se valore como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%). Los efectos del riesgo pueden ser valorados como catastrficos serio catastrficos, serio, tolerable o insignificante insignificante.
9. Conclusiones
9. Conclusiones
La planificacin temporal es de suma importancia para llevar un control de la terminacin a tiempo de la tareas de un proyecto. Las herramientas PERT y GANTT ayudan a la realizacin de la planificacin temporal PERT, para monitorear el progreso y el retraso de las actividades, tomando como base la ruta crtica GANTT, ayudan a planear la utilizacin de recursos, as tambin, muestra de forma grfica el calendario del proyecto.
109
Las mtricas de software es una parte de la Ingeniera de software que proporcionan productos cuantitativos orientados a medidas de caractersticas de sistemas de informacin, as como sus procesos de desarrollo y operacin. Permiten la estimacin de esfuezo, duracin, productividad, calidad, documentacin, as como tambin costo de desarrollo del sw. En todo desarrollo de software, siempre es indispensable hacer un presupuesto para desarrollar, comprar o aplicar outsourcing
110
9. Conclusiones
10. Referencias
1.
Hemos visto que el mtodo de Puntos de Funcin y COCOMO se complementan. Mientras COCOMO mediante LDC y otros parmetros calcula el esfuerzo y duracin, los puntos de funcin mediante funciones de usuario calcula puntos de funcin ajustados, los cuales para cierto lenguaje de programacin le corresponde un nmero de LDC LDC, que son la entrada para COCOMO. Debido a que los mtodos COCOMO y FP son mtodos comnmente usados por la comunidad de mtricas de software; la mayora de herramientas como BYL, COSMOS, COSTAR, Jmetric, etc., contienen estos dos mtodos.
2.
3.
McGraw-Hill. Somerville, Ian (2002) Ingeniera de software. 6a edicin. Addison Wesley. Braude Eric J. (2003) Ingeniera de Software Una perspectiva orientada a objetos, Alfaomega
111
112
10. Referencias
1.
2.
3.
4.
Software Metrics: A Rigorous and Practical Approach, (2nd ed.) (638p.), N.E. Fenton and S.L. Pfleeger, PWS Publishing, 1998. Eric J. Braude. (2003) Ingeniera de Software: una perspectiva orientada a objetos. objetos Alfaomega Alfaomega, Mxico Roger S. Pressman. (2005) Ingeniera de software. Un enfoque prctico. 6 edicin, McGraw Hill, Mxico Ian Somerville (2002) Ingeniera de Software. 6 edicin, Addison Wesley, Mxico
Preguntas? Gracias!
114