1 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
ACI491:ACI491:Ingeniería de SoftwareIngeniería de Software
Unidad 6:Administración de Proyectos
de Software
2 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Contenidos
• Recursos, productividad y calidad de software.• Métricas como herramientas de software.• Técnicas de estimación de costos, Planificación y
control de proyectos de Software.• Plan de proyectos de software, Organización del
equipo de Proyecto.• El administrador de proyecto y sus roles, El líder de
proyecto y sus roles, Selección del equipo de proyecto.
3 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Objetivos específicos
• Conocer y manejar las diferentes herramientas de administración.
• Manejar en forma eficiente los recursos asociados al software.
• Conformar un equipo de trabajo, siendo capaz de identificar las labores mas adecuadas para cada uno de los integrantes
4 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Introducción• Uno de los principales motivos de fallas en los
proyectos de software tiene su origen en la mala administración de los mismos. – Definición de alcance incorrecto, – estimaciones erróneas, – manejo deficiente de los recursos humanos, – escasa administración de los riesgos,
son sólo algunas de las actividades que frecuentemente se subestiman al momento de gestionar un proyecto de software.
• Las empresas buscan y valoran la productividad. • Las personas que utilizan las mejores prácticas para
el trabajo en equipo, donde cada una de ellas toma un rol preponderante en la cadena tienen la de ganar.
5 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Calidad de Software
Administración de la Calidad del Software
6 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Planificación de Proyectos de Software• Aunque la estimación es más un arte que una ciencia, es una
actividad importante que no debe llevarse a cabo de forma descuidada.
• Existen técnicas Útiles para la estimación del esfuerzo y del tiempo.
• Las métricas del proyecto y del proceso proporcionan una perspectiva histórica y una potente introducción para generar estimaciones cuantitativas.
• La experiencia anterior (de todas las personas involucradas) puede ayudar en gran medida al de las estimaciones.
• Y, dado que la estimación es la base de todo desarrollo y revisión de las demás actividades de planificación del proyecto, y que sirve como guía para una buena ingeniería del software, no es en absoluto aconsejable embarcarse sin ella.
7 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Preguntas claves• ¿Cómo establezco las actividades del proyecto de
software?• ¿Cómo llego a conocer el contexto del proyecto de
software?• ¿cómo manejo los riesgos?• ¿Cómo manejo los proyectos iterativos e
incrementales?• ¿En qué consiste el método de la cadena crítica?• ¿Cómo influye el factor humano en la
administración de proyectos de software?• ¿Cómo influyen la comunicación, la calidad y los
“stakeholders” en la administración de proyectos de software?
8 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
El Modelo COCOMO
9 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Introducción
• El Modelo Constructivo de Costes (COnstructive COst MOdel) fue desarrollado por B. W. Boehm (creador además del modelo de desarrollo en espiral) a finales de los 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics”.
• COCOMO es una jerarquía de modelos de estimación de costes software que incluye submodelos básico, intermedio y detallado.
10 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Modelo Básico
• Este modelo trata de estimar, de una manera rápida y más o menos burda, la mayoría de proyectos pequeños y medianos.
• En este modelo se consideran tres modos de desarrollo:
1.orgánico, 2.semiencajado y 3.empotrado.
11 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Ecuaciones de estimación del esfuerzo de desarrollo• Las ecuaciones de estimación del
esfuerzo de desarrollo tienen la forma:
con • S el número de miles de líneas de
código fuente, • m(X) es un multiplicador que depende
de 15 atributos.
12 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Tabla con los coeficientes para los diferentes modos
Básico IntermedioModo ai bi ai bi
Orgánico 2.4 1.05 3.2 1.05Semiencajado 3.0 1.12 3.0 1.12Empotrado 3.6 1.2 2.8 1.2
13 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Modo Orgánico• En este modo, un pequeño grupo de programadores
experimentados desarrollan software en un entorno familiar.
• El tamaño del software varía de unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio), mientras que en los otros dos modos el tamaño varía de pequeño a muy grandes (varios cientos de miles de líneas).
• En este modo, al igual que en los otros, el coste se incrementa a medida que el tamaño lo hace, y el tiempo de desarrollo se alarga.
• Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo.
14 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Modo Orgánico (2)• El coste es
Km = 2.4 Sk1.05
donde Km se expresa en personas-mes y
Sk es el tamaño expresado en miles de líneas de código fuente.
• El tiempo de desarrollo se da portd = 2.5 Km
0.38
donde Km se obtiene de la ecuación anterior y
td es el tiempo de desarrollo en meses.
• Estas ecuaciones se obtuvieron por Boehm, ajustando curvas en TRW sobre 63 proyectos.
15 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Modo Empotrado• En este modo, el proyecto tiene unas fuertes
restricciones, que pueden estar relacionadas con el procesador y el interface hardware.
• El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.
• Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo orgánico, pero con diferentes constantes.
• Así, el coste se da porKm = 3.6 Sk
1.20
y el tiempo de desarrollo por td = 2.5 Km
0.32
16 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Modo Semiencajado
• Es un modo intermedio entre los dos anteriores.
• Dependiendo del problema, el grupo puede incluir una mezcla de personas experimentadas y no experimentadas.
• Las ecuaciones sonKm = 3.0 Sk
1.12
y el tiempo de desarrollo por td = 2.5 Km
0.35
17 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Notas al Modelo Básico
• Se puede observar que a medida que aumenta la complejidad del proyecto, las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal.
• Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas características del entorno.
18 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Modelo Intermedio
• En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo.
• Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real, incrementando la precisión de la estimación.
• Este modelo proporciona una manera potente de capturar la influencia del entorno en el proyecto.
19 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Ecuaciones nominales de coste• Para cada modo de desarrollo, los 15
atributos del coste intervienen como multiplicadores en el coste nominal, Kn, para producir el coste ajustado.
• Las ecuaciones nominales de coste para el modelo intermedio son:modo orgánico Kn = 3.2 Sk
1.05
modo semiencajado Kn = 3.0 Sk1.12
modo empotrado Kn = 2.8 Sk1.20
20 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Ecuaciones nominales de coste (2)Notemos que:• los exponentes son los mismos que los del
modelo básico, confirmando el papel que representa el tamaño;
• los coeficientes de los modos orgánico y empotrado han cambiado, para mantener el equilibrio alrededor del semiencajado con respecto al efecto multiplicador de los atributos de coste.
21 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atributos de coste
• Estos atributos tratan de capturar el impacto del entorno del proyecto en el coste de desarrollo.
• De un análisis estadístico de más de 100 factores que influencian el coste, Boehm retuvo 15 de ellos para COCOMO.
• Estos atributos se agrupan en cuatro categorías: atributos del producto, atributos del ordenador, atributos del personal y atributos del proyecto.
22 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atributos …(2)Atributos del producto
A. RELY: garantía de funcionamiento requerida al software.
B. DATA: tamaño de la base de datos.
C. CPLX: complejidad del producto.
Atributos del computador
D. TIME: restricción de tiempo de ejecución.
E. STOR: restricción del almacenamiento principal.
F. VIRT: volatilidad de la máquina virtual.
G. TURN: tiempo de respuesta del computador.
23 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atributos …(3)Atributos del personal
H. ACAP: capacidad del analista.
I. AEXP: experiencia en la aplicación.
J. PCAP: capacidad del programador.
K. VEXP: experiencia en máquina virtual.
L. LEXP: experiencia en lenguaje de programación.
Atributos del proyecto
M. MODP: prácticas de programación modernas.
N. TOOL: utilización de herramientas software.
O. SCED: plan de desarrollo requerido.
24 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atributos… (4)
• Cada atributo se cuantifica para un entorno de proyecto.
• La escala tiene seis niveles cualitativos: 1. muy bajo 2. bajo3. nominal4. alto 5. muy alto6. extremadamente alto.
25 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atrtibutos…(5)
• En la tabla se muestran los valores del multiplicador para cada uno de los 15 atributos.
• Estos 15 valores se multiplican al Kn, y proporcionan el esfuerzo ajustado al entorno.
26 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Significado de los atributos
A. RELY
• Indica las posibles consecuencias para el usuario en el caso que todavía existan defectos en el producto.
• Una puntuación 'muy baja' indica que solamente hace falta eliminar los defectos sin ninguna otra consecuencia.
• "very low": el efecto de un fallo del software simplemente trae como consecuencia la inconveniencia de corregir el fallo.
27 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
A. RELY (continuación)
• "low": el efecto de un fallo software es una pérdida fácilmente recuperable para los usuarios.
• "nominal": el efecto es una moderada pérdida para los usuarios, pero es una situación de la que se puede salir sin excesiva dificultad.
• "high": el efecto es una gran pérdida financiera o una inconveniencia masiva humana.
• "very high": el efecto es una pérdida de vidas humanas.
28 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
B. DATA• Indica el tamaño de la base de datos a desarrollar
en relación con el tamaño del programa. • Tenemos cuatro segmentos con la razón 10-100-
1000, que determinan las puntuaciones de 'bajo' a 'muy alto'.
• Se define por el cociente
donde D es la cantidad de datos a ser articulada y almacenada en memoria secundaria (cintas, discos, etc.) hasta el tiempo de entrega del producto software.
29 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
C. CPLX
• Indica la complejidad de cada módulo y se utiliza para determinar la complejidad compuesta del sistema.
• Entonces la puntuación puede variar de 'muy bajo' si el módulo está compuesto de expresiones matemáticas simples a 'extremadamente alto' para módulos que utilizan muchos recursos de planificación.
30 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
D. TIME
• Siempre será más exigente para un programador escribir un programa que tiene una restricción en el tiempo de ejecución.
• Esta puntuación se expresa en el porcentaje de tiempo de ejecución disponible.
• Es 'nominal' cuando el porcentaje es el 50%, y 'extremadamente alto' cuando la restricción es del 95%.
31 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
E. STOR• Se espera que un cierto porcentaje del
almacenamiento principal sea utilizado por el programa.
• El esfuerzo de programación se incrementa si el programa tiene que correr en un volumen menor del almacenamiento principal.
• STOR captura este esfuerzo extra de 'nominal' cuando la reducción del almacenamiento principal es del 50% a 'extremadamente alto' cuando la reducción es del 95%.
32 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
F. VIRT
• Durante el desarrollo del software la máquina (hard y soft) en la que el programa se va a desarrollar puede sufrir algunos cambios.
• VIRT lo refleja desde 'bajo' a 'muy alto'.
33 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
G. TURN
• Cuantifica el tiempo de respuesta del ordenador desde el punto de vista del programador.
• Cuanto mayor sea el tiempo de respuesta, más alto será el esfuerzo humano.
• TURN puede variar desde 'bajo' para un sistema interactivo a 'muy alto', cuando el tiempo medio de respuesta es de más de 12 horas.
34 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
H. ACAP
• La capacidad del grupo de analistas, en términos de habilidad de análisis, eficiencia y capacidad para cooperar tiene un impacto significativo en el esfuerzo humano.
• Cuanto más capaz sea el grupo, menos esfuerzo será necesario. ACAP puede variar desde 'muy bajo' a 'muy alto'.
35 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
I. AEXP• La experiencia del grupo en una aplicación similar
tiene una gran influencia en el esfuerzo. • Puede variar desde 'muy bajo' (menos de cuatro
meses de experiencia) a 'muy alto' (mayor de 12 años de experiencia).
• "very low": < 4 meses experiencia media• "low": 1 año de experiencia media• "nominal": 3 años de experiencia media• "high": 6 años de experiencia media• "very high": > 12 años, o reimplementación de un
subsistema
36 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
J. PCAP
• La cuantificación es similar a la de ACAP, pero en este caso relacionado con los programadores.
• Se aplica a los programadores como grupo, pero no a los programadores individuales.
37 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
K. VEXP
• Cuanto mayor sea la experiencia del grupo de programación con el procesador, menor será el esfuerzo necesario.
• VEXP puede variar desde 'muy bajo', cuando la experiencia es menor de un mes, a 'alto' cuando esta experiencia es mayor de 3 años.
• "very low": < 1 mes experiencia media• "low": 4 meses• "nominal": 1 año• "high": > 3 años
38 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
L. LEXP• Un grupo de programadores con amplia
experiencia en un lenguaje determinado programará de una manera mucho más segura, generando un menor número de defectos y de requerimientos humanos.
• Puede variar desde 'muy bajo' a 'alto' para un grupo de un mes a tres años de experiencia, respectivamente.
• "very low": < 1 mes experiencia media• "low": 4 meses de experiencia media• "nominal": 1 año de experiencia media• "high": > 3 años
39 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
M. MODP• Utilización de modernas prácticas de programación. • Varía de 'muy bajo' a 'muy alto'. • Estas prácticas incluyen, por ejemplo, programación
estructurada y desarrollo 'top-down'.• "very low": no se utilizan prácticas modernas de
programación -PMP-.• "low": uso experimental de algunas PMP• "nominal": experiencia razonable en el uso de
algunas PMP• "high": experiencia razonable en gran parte de PMP• "very high": uso habitual de PMP
40 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
N. TOOL
• El uso adecuado de herramientas software es un multiplicador de la productividad.
• La puntuación de TOOL varía desde 'muy bajo' cuando sólo se utilizan herramientas básicas, a 'muy alto' cuando se utilizan herramientas específicas.
41 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
O. SCED
• El tiempo nominal de desarrollo, tal como se define en el modo básico, es el plazo que requiere menor esfuerzo humano.
• Cualquier apresuramiento ('muy bajo') o retraso ('muy alto') demandarán más esfuerzo.
42 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Modelo Detallado• Este modelo puede procesar todas las características
del proyecto para construir una estimación. Introduce dos características principales:
1)Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven más afectadas que otras por los atributos. El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo. Esto ayuda a determinar la asignación del personal para cada fase del proyecto.
2)Jerarquía del producto a tres niveles. Se definen tres niveles de producto. Estos son módulo, subsistema y sistema. La cuantificación se realiza al nivel apropiado, esto es, al nivel al que es más susceptible la variación.
43 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Estimación del esfuerzo
A. Fases de desarrollo• El desarrollo del software se lleva a
cabo a través de cuatro fases consecutivas:
1.requerimientos/planes, 2.diseño del producto, 3.programación y 4.prueba/integración.
44 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
1) Requerimientos/planes
• Esta es la primera fase del ciclo de desarrollo.
• Se analiza el requerimiento, se muestra un Plan de Producto y se general una especificación completa del producto.
• Esta fase consume del 6% al 8% del esfuerzo nominal Kn, y dura del 10% al 40% del tiempo nominal de desarrollo td.
• Estos porcentajes dependen del modo y del tamaño (de 2000 LOC a 512000 LOC).
45 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
2) Diseño del producto
• La segunda fase del ciclo de desarrollo COCOMO se preocupa de la determinación de la arquitectura del producto y de las especificaciones de los subsistemas.
• Esta fase requiere del 16% al 18% del esfuerzo nominal Kn, y puede durar del 19% al 38% del tiempo nominal de desarrollo td.
46 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Programación
• La tercera fase del ciclo de desarrollo COCOMO se subdivide en dos subfases:
1.diseño detallado y 2.prueba del código. • Esta fase requiere del 48% al 68% del
esfuerzo nominal Kn, y dura del 24% al 64% del tiempo nominal de desarrollo.
47 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Prueba/Integración
• Esta última fase consiste principalmente en unir las diferentes unidades ya probadas.
• Se utiliza del 16% al 34% del coste nominal Kn y dura del 18% al 34% del td.
48 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
B. Principio de estimación del esfuerzoB.1. Tamaño equivalente. • Como parte del software puede haber
sido ya desarrollado, no se requiere entonces un desarrollo completo.
• En tales casos se estiman las partes de diseño (D%), código (C%) e integración (I%) a ser modificadas.
49 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
B.1. Tamaño equivalente (cont)
• Se calcula un factor de ajuste AA = 0.4 D + 0.3 C + 0.3 I
• El tamaño equivalente, Sequ es
Sequ = (S · A) / 100
50 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
B.2. Cálculo del esfuerzo• El tamaño equivalente se calcula para cada
módulo. • El esfuerzo asignado al desarrollo de cada
módulo se obtiene entonces a través de:1)seleccionar los valores apropiados de los
atributos de coste para cada fase.2)multiplicar los atributos de coste para cada
módulo y fase, obteniendo un conjunto de 4 multiplicadores globales.
3)multiplicar los atributos globales por el esfuerzo nominal en cada fase y sumarlos para obtener el esfuerzo total estimado.
51 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Conclusiones sobre COCOMO• Es uno de los modelos más documentados
en la actualidad y es muy fácil de utilizar. • Es correcto con referencia a los 63
proyectos utilizados, aunque de ello no se debe desprender que deba ser válido siempre.
• Una preocupación es la adaptación de las ecuaciones exponenciales a organizaciones específicas, cosa que no parece inmediatamente fácil.
52 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Valoración independiente
• Entrega otras fórmulas mejoradas respecto a las originales:
53 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Estimación con el método Cocomo
Ejemplo
54 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Introducción• Por un lado COCOMO define tres modos de desarrollo o
tipos de proyectos:1.Orgánico: proyectos relativamente sencillos, menores
de 50 KLOC líneas de código, en los cuales se tiene experiencia de proyectos similares y se encuentran en entornos estables.
2.Semi-acoplado: proyectos intermedios en complejidad y tamaño (menores de 300 KLOC), donde la experiencia en este tipo de proyectos es variable, y las restricciones intermedias.
3.Empotrado: proyectos bastante complejos, en los que apenas se tiene experiencia y se engloban en un entorno de gran innovación técnica. Además se trabaja con unos requisitos muy restrictivos y de gran volatilidad.
55 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Introducción (2)• Existen diferentes modelos que define
COCOMO:• Modelo básico: Se basa exclusivamente en
el tamaño expresado en LOC.• Modelo intermedio: Además del tamaño
del programa incluye un conjunto de medidas subjetivas llamadas conductores de costes.
• Modelo avanzado: Incluye todo lo del modelo intermedio además del impacto de cada conductor de coste en las distintas fases de desarrollo.
56 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Nuestro caso• Para este ejemplo se utilizará el
modelo intermedio, dado que realiza las estimaciones con bastante precisión.
• Así, las fórmulas serán:• E = Esfuerzo = a KLOC e * FAE
(persona x mes)• T = Tiempo de duración del
desarrollo = c Esfuerzo d (meses)• P= Personal = E/T (personas)
57 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Calculando el esfuerzo
• Para calcular el Esfuerzo, necesitaremos hallar la variable KLOC (Kilo-líneas de código), donde los PF son 261,36 (dato conocido) y las líneas por cada PF equivalen a 32 según vemos en la tabla que se ilustra a continuación:
58 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Tabla LDC / PF
LENGUAJE LOC/PF
Ensamblador 320
C 150
COBOL 105
Pascal 91
Prolog/LISP 64
C++ 64
Visual Basic 32
SQL 12
59 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Determinación de coeficientes
• Así pues tras saber que son 32 LOC por cada PF, por el hecho de ser Visual Basic el resultado de los KLOC será el siguiente:KLOC= (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000= 8,363 KLOC
• Así pues, en nuestro caso, el tipo orgánico será el más apropiado ya que el número de líneas de código no supera los 50 KLOC, y además el proyecto no es muy complejo, por consiguiente, los coeficientes que usaremos serán:
60 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Coeficientes según tipo
PROYECTO SOFTWARE a e c d
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32
61 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Personal necesario / mes
• Por otro lado, también hemos de hallar la variable que recoge la cantidad de personas por mes, FAE, la cual se obtiene mediante la multiplicación de los valores evaluados en los diferentes 15 conductores de coste que se observan en la tabla de la siguiente transparencia, lo que da como resultado:
• FAE=1,15*1,00*0,85*1,11*1,00*1,00*1,07*0,86*0,82*0,70*1,00*0,95*1,00*0,91*1,08
= 0,53508480
62 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Valoración de conductores
CONDUCTORES DE COSTE VALORACIÓN
Muy bajo Bajo Nominal Alto Muy alto Extr. alto
Fiabilidad requerida del software 0,75 0,88 1.00 1,15 1,40 -
Tamaño de la base de datos - 0,94 1.00 1,08 1,16 -
Complejidad del producto 0,70 0,85 1.00 1,15 1,30 1,65
Restricciones del tiempo de ejecución - - 1.00 1,11 1,30 1,66
Restricciones del almacenamiento principal - - 1.00 1,06 1,21 1,56
Volatilidad de la máquina virtual - 0,87 1.00 1,15 1,30 -
Tiempo de respuesta del ordenador - 0,87 1.00 1,07 1,15 -
Capacidad del analista 1,46 1,19 1.00 0,86 0,71 -
Experiencia en la aplicación 1,29 1,13 1.00 0,91 0,82 -
Capacidad de los programadores 1,42 1,17 1.00 0,86 0,70 -
Experiencia en S.O. utilizado 1,21 1,10 1.00 0,90 - -
Experiencia en el lenguaje de programación 1,14 1,07 1.00 0,95 - -
Prácticas de programación modernas 1,24 1,10 1.00 0,91 0,82 -
Utilización de herramientas software 1,24 1,10 1.00 0,91 0,83 -
Limitaciones de planificación del proyecto 1,23 1,08 1.00 1,04 1,10 -
63 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Justificación de los valores
• Para seleccionar los correspondientes valores mostrados de la tabla anterior, se tomaron en cuenta:
• Atributos de software• Atributos de hardware• Atributos del personal• Atributos del proyecto
64 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atributos de software
• Fiabilidad requerida del software: Si se produce un fallo por el pago de un pedido, o fallo en alguna reserva, etc...; puede ocasionar grandes pérdidas a la empresa (Valoración Alta).
• Tamaño de la base de datos: La base de datos de nuestro producto será de tipo estándar (Valoración Nominal).
• Complejidad del producto: La aplicación no va a realizar cálculos complejos (Valoración Baja).
65 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atributos de hardware• Restricciones del tiempo de ejecución:
En los requerimientos se exige alto rendimiento (Valoración Alta).
• Restricciones del almacenamiento principal: No hay restricciones al respecto (Valoración Nominal).
• Volatilidad de la máquina virtual: Se usarán sistemas de la “Familia Windows” (Valoración Nominal).
• Tiempo de respuesta del ordenador: Deberá ser interactivo con el usuario (Valoración Alta).
66 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atributos del personal• Capacidad del analista: Capacidad alta relativamente,
debido a la experiencia en análisis en proyecto similar (Valoración Alta)
• Experiencia en la aplicación: Se tiene cierta experiencia en aplicaciones de esta envergadura (Valoración muy alta).
• Capacidad de los programadores: Teóricamente deberá tenerse una capacidad muy alta por la experiencia en anteriores proyectos similares (Valoración muy alta).
• Experiencia en SO utilizado: Con Windows 2000 Professional la experiencia es a nivel usuario (Valoración Nominal).
• Experiencia en el lenguaje de programación: Es relativamente alta, dado que se controlan las nociones básicas y las propias del proyecto (Valoración Alta).
67 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Atributos del proyecto
• Prácticas de programación modernas: Se usarán prácticas de programación mayormente convencional (Valoración Nominal).
• Utilización de herramientas software: Se usarán herramientas estándar que no exigirán apenas formación, de las cuales se tiene cierta experiencia (Valoración Alta).
• Limitaciones de planificación del proyecto: Existen pocos límites de planificación. (Valoración Baja).
68 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
ResultadosCálculo del esfuerzo del desarrollo:E = a KLOC e * FAE = 3,2 * (8.363)^1,05 *
0,53508480 = 15,91 personas /mes
Cálculo tiempo de desarrollo:T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses Productividad:PR = LOC/Esfuerzo = 8363/15,91 = 525 ,64
LOC/personas mes
Personal promedio:P = E/T = 15,91/7,15 = 2,22 personas
69 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Resultados (2)
• Según estas cifras será necesario un equipo de 3 personas trabajando alrededor de 7 meses, pero puesto que el desarrollo del proyecto debe realizarse en un plazo 3 meses, incrementaremos a 6 personas el número de personas del equipo de proyecto (ya que 15,91/3 nos da alrededor de este resultado).
• Entonces, tendremos un equipo formado por:– 1 Jefe de proyecto, – 2 Analistas, – 2 programadores y 1 – Responsable de calidad.
70 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy
Fuentes de información
• Sommerville, I. “Ingeniería de Software” 7ma edición.
• Pressman, R. “Ingeniería de Software: Un enfoque práctico” 5ta edición:– cap 2 12p– cap 5 22p
• Kendall, K.E. y Kendall, J.E. “Análisis y diseño de sistemas” 6ta edición.
• http://en.wikipedia.org/wiki/Delphi_method• http://www.angelfire.com/scifi/jzavalar/apuntes/apu
ntes.html