Compendio de Ingeniería del Softwarecotana.informatica.edu.bo/downloads/gestion de proyectos y...
113
4.1 CONCEPTOS DE GESTION MODULO IV Ingeniería de Software INF - 163 Resumen preparado por Miguel Cotaña 1 23/11/09
Transcript of Compendio de Ingeniería del Softwarecotana.informatica.edu.bo/downloads/gestion de proyectos y...
4.1 CONCEPTOS DE GESTION
MODULO IV
Ingeniería de SoftwareINF - 163
Resumen preparado por Miguel Cotaña1
23/11/09
Gestión de Proyectos
Cuando se planifica un proyecto setiene que obtener estimaciones delcosto y esfuerzo humano requeridopor medio de las mediciones desoftware que se utilizan pararecolectar los datos cualitativos acercadel software y sus procesos paraaumentar su calidad.
2
La gestión del proyecto consiste en lautilización de las técnicas yactividades de gestión requeridas paraconseguir un producto de calidad, deacuerdo con las necesidades de losusuarios, dentro de un presupuesto ycon una planificación de tiemposestablecidos previamente.
3
Es un esfuerzo temporal
comprometido a crear un producto o
servicio único.
Entre sus características principales:
Temporalidad;
Unicidad;
Progresividad;
Ejecutado por personas;
Limitado a ciertos recursos;
Planificado, ejecutado y
controlado.
Qué es un Proyecto?
4
Tareas críticas en la gestión de proyectos
El número de tareas identificables son
muchas. Sin embargo, 3 son críticas y
que deben ser desarrolladas
correctamente:
Estimación de duración, coste y
esfuerzo necesarios para construir
el producto;
Planificación de tareas a realizar,
asignación de personas, tiempos.
Seguimiento5
Estimación de proyectos
Se define como la predicción de
personal, del esfuerzo, de los costes y
de la planificación que se requerirá para
realizar todas las actividades y
construir todos los productos asociados
con el proyecto.
Uno de los parámetros críticos de la
estimación es determinar su exactitud.
6
7
Estimar
Horas
hombre
Estimar
El
costo
Determinar
Plazos de
entrega
Determinar
Personal
involucrado
Estimación enfoque tradicional
8
Estimar
Horas
hombre
Estimar
Tiempo
total
Determinar
Personal
involucrado
Estimar
El
costo
Determinar
Lineas de
codigo
Establecer
Plazo de
entrega
Estimación: método COCOMO
9
Puntos de
Función sin
ajustar
Puntos de
Función
ajustados
Líneas
De código
Del software
Ratio
Líneas de
Código PF
Estimación: método Punto Función
Larry Putnam, ha apuntado que la
gestión del desarrollo de software
considera la estimación como una
actividad que permite obtener,
prinicipalmente, respuestas a las
siguientes preguntas:
¿Cuánto Costará?
¿Cuánto tiempo llevará hacerlo?10
Razones de difícil estimación
No existe un modelo universal;
Hay muchas personas implicadas en
los proyectos que precisan de
estimaciones;
La utilidad de una estimación
dependerá de la etapa de desarrollo
en la que nos encontremos;
La estimación, a menudo se realiza
superficialmente;
11
12
Las estimaciones claras, completas y
precisas son difíciles de formular;
Las características del Sw y de su
desarrollo hacen difícil la estimación;
Existe tendencia aparente hacia la
subestimación;
Existen malas interpretaciones;
El estimador tiende a reducir en
algún grado, para hacer más
aceptable la oferta.
13
QUÉproducto
CON QUÉsiginificado
QUIÉNPersonal
CÓMOProyecto
PARA QUIÉNusuario
Tamaño sw RestriccionesOrdenador
Calidad personal
Req. durac. Proyecto
participación
Calidadrequerida
Tiempo ejec. Resp. Mem.
Experiencia Dilatación comprensi.
estabilidad
Compleji-dad del Sw
Herramientas Organiza-ción
experiencia
Nivel de utilización
Técnicas Prototipado conocimientos
Documen-tación
Programación Modeladoágil
Equipos
Tipo aplicación
Equipo de programación
Matriz de organizació
procedimiento
Requisitos de un buen estimador
No tiene ningún interés, directo ni
indirecto en los resultados del proceso
de estimación:
Formación y experiencia profesional;
Juicio independiente;
Basarse en metodos que pueda ser
explicado, cuestionado, discutido y
auditado por otros expertos;
Usa herramientas de estimación;
Documentar la estimación.14
Salidas del proceso de estimación
¿cuánta gente se necesita?;
¿De qué perfiles?;
¿Cuáles son los riesgos?;
¿Cómo afectan las restricciones
impuestas a las estimaciones?;
¿Cuánto esfuerzo se necesita para
realizar cada fase del ciclo de vida?;
¿Cómo impacta este proceso en el
resto de proyectos de la empresa?;
15
16
¿Cuál será el esfuerzo para
mantener este proyecto?;
¿Cuál será el tamaño del sistema
(lineas de código)?;
¿Cuántos defectos tendrá el
producto?;
¿Cuánta documentación será
generada?;
¿Cuál será el esfuerzo para generar
dicha documentación?.
El espectro de la gestión
La gestión eficaz de la gestión de
proyectos software se enfoca sobre
las cuatro P:
Personal;
Producto;
Proceso;
Proyecto.
17
El SEI ha desarrollado un modelo de
madurez de la capacidad de gestión
de personal (MMCGP), que define:
Reclutamiento;
Selección;
Gestión del desempeño;
Entrenamiento;
Retribución;
Desarrollo de la carrera;
Desarrollo de la cultura de
equipo.
Personal
18
Se clasifican en 5 categorías:
Gestores ejecutivos, que definen los
aspectos del negocio;
Gestores (técnicos) del proyecto,
quienes planifican, motivan, organizan
y controlan a los profesionales que
realizan el trabajo de software;
Profesionales, proporcionan las
habilidades técnicas necesarias;
Los participantes
19
Clientes, quienes especifican los
requisitos para la ingeniería de
software y otros elementos que tienen
un interés mínimo en el resultado;
Usuarios finales, quienes
interactúan con el software una vez
que se libera su uso productivo.
20
Weinberg, sugiere un modelo de
liderazgo:
Motivación, la habilidad para alentar
(mediante el “empuje o jalón”) al
personal técnico;
Organización, la habilidad para
adecuar los procesos existentes;
Ideas o innovación, la habilidad
para alentar a la gente para crear y
sentir creativamente.
Líderes de equipo
21
Otra visión, define los rasgos:
Resolución de problemas, un
gestor puede diagnosticar los
conflictos técnicos y organizativos;
Dotes de gestión, encabezar y dirigir
Incentivos, un gestor debe
recompensar la iniciativa y los logros;
Influencia y fomento de la cultura
en equipo, mantener el control en
situaciones de tensión emocional.22
La mejor estructura de equipo
depende del estilo de gestión de cada
organización, del número de personas
que integran el equipo y de sus
grados de habilidad. Los factores:
La dificultad del problema;
El tamaño del programa;
El tiempo que el equipo;
El grado de modularidad;
La calidad y confiabilidad;
La rigidez en fechas de entrega.
El equipo de software
23
Constantine, sugiere 4 paradigmas
organizacionales para los equipos:
Un paradigma cerrado, jerarquía
tradicional de autoridad;
Un paradigma aleatorio, estructura
un equipo libremente y depende de la
iniciativa individual de los miembros
del equipo. Cuando se requiere
innovación o adelantos tecnológicos,
serán excelentes. Pero no son
ordenados;24
Un paradigma abierto, intenta
estructurar un equipo en una forma
que logre algunos de los controles
asociados con el paradigma cerrado.
El trabajo se desarrolla en
colaboración. La sólida comunicación y
la toma de decisiones basadas en el
consenso, son sus características;
Un paradigma sincrónico, se apoya
en partes del problema con poca
comunicación activa entre ellos.25
La filosofía ágil alienta la satisfacción
del cliente y la temprana entrega
incremental del software; pequeños
equipos de trabajo enormemente
motivados; métodos informales;
mínimos productos de trabajo de IS; y
simplicidad global de desarrollo.
Estos equipos (ágiles) son
autoorganizados
Equipos ágiles
26
Muchos modelos de proceso ágil (por
ejemplo, Scrum) brindan al equipo
ágil una autonomía significativa para
realizar la gestión del proyecto y
tomar las decisiones técnicas
requeridas para cumplir el trabajo.
La planificación se mantiene en el
mínimo, y al equipo se le permite
seleccionar su propio enfoque, sólo
restringido por los requisitos del
negocio y estándares organizacionales27
El gestor de un proyecto de software
se enfrenta con un dilema desde el
principio de un proyecto de IS. Se
requieren estimaciones cuantitativas y
un plan organizado, pero no dispone
de información sólida.
En consecuencia, se deben examinar
el producto y el problema que se
intenta resolver al inicio del proyecto.
Se debe establecer y acotar el ámbito
del producto.
El producto
28
La primera actividad de gestión :
Contexto. ¿cómo encaja el software
que se desarrollará en el negocio y qué
restricciones se imponen?;
Objetivos de información. ¿qué
objetos de datos se requieren de
entrada?;
Función y desempeño. ¿qué
funciones realiza el software para
transformar los datos en salida?.
Ámbito del software
29
A veces llamada partición o elaboración
del problema, es una actividad de la IR.
Durante la actividad de fijación del
ámbito no se intenta en descomponer
completamente el problema
Un problema complejo se divide en
problemas menores que resultan más
manejables. Ésta es la estrategia que
se aplica cuando comienza la
planificación del proyecto
Descomposición del problema
30
Las actividades del marco de trabajo
que caracterizan al proceso de
software son aplicables a todos los
proyectos de software.
El gestor del proyecto debe decidir
cuál modelo de proceso es más
adecuado para:
1) Los clientes que solicitaron y
personas que realizarán el trabajo;
2) Las características del producto;
3) El ambiente del proyecto.
El proceso
31
La planeación del proyecto comienza
con la combinación del producto y el
proceso. Cada función que el equipo de
software someterá a ingeniería debe
pasar a través del conjunto de
actividades del marco de trabajo:
Comunicación, planificación, modelado,
construcción y despliegue.
Combinación del producto y el proceso
32
La descomposición del proceso comienza
cuando el gerente de proyecto pregunta:
¿cómo logramos esta actividad del marco
de trabajo?
Para un proyecto complejo se puede
requerir las siguientes tareas de trabajo
para la actividad de comunicación:
1. Revisar la petición del cliente;
2. Planificar reunión formal;
3. Llevar a cabo investigaciones;
Descomposición del proceso
33
4) Preparar documento de trabajo;
5) Celebrar reunión;
6) Desarrollar y revisar miniprospectos
o caso de uso para valorar su
corrección;
7) Ensamblar miniprospectos en un
documento más amplio;
8) Revisar el documento con
implicados;
9) Modificar el documento.
34
La gestión de un proyecto de software
exitoso requiere entender qué puede
salir mal. J. Reel, define 10 señales:
1.El personal de software no
entiende las necesidades de sus
clientes;
2.El ámbito del producto está mal
definido;
3.Los cambios se gestionan mal;
4.La tecnología elegida cambia;
El proyecto
35
5. Las necesidades comerciales
cambian (o están mal definidas);
6. Los plazos de entrega no son
realistas;
7. Los usuarios se resisten;
8. Se pierde el patrocinio;
9. El equipo carece de personal con
las habilidades apropiadas;
10.Los gestores (y profesionales)
evitan las mejores prácticas y las
lecciones aprendidas.36
Se necesita un principio organizador
que escale hacia abajo para
proporcionar planes simples para
proyectos simples. Boehm, realiza una
serie de preguntas.
¿Por qué se desarrolla el sistema?
¿Qué se hará?
¿Cuándo se hará?
¿Quién es el responsable de una
función?
El principio W5 HH
37
¿Dónde están ubicados en la
organización?
¿Cómo se hará el trabajo desde los
puntos de vista técnico y de gestión?
¿Cuánto de cada recurso se necesita?
38
4.2 METRICAS DE PROCESO Y PROYECTO
MODULO IV
Ingeniería de SoftwareINF - 163
Resumen preparado por Miguel Cotaña39
23/11/09
La medición permite obtener una visión
del proceso y el proyecto pues
proporciona un mecanismo para lograr
una evaluación objetiva.
La medición se aplica al proceso de
software con la finalidad de mejorarlo de
manera continua. La medición se utiliza
a lo largo de un proyecto de software
como apoyo en la estimación, el control
de calidad, la valoración de la
productividad y el control del proyecto.40
El proceso de software y las métricas
del proyecto son medidas
cuantitativas que permiten a los IS
obtener una visión de la eficacia del
proceso de software y los proyectos
que llevan a cabo utilizando el proceso
como marco de trabajo.
Se recopilan datos básicos de calidad
y productividad.
41
Luego, dichos datos se analizan,
comparan con promedios pasados y
valoran para determinar si han
ocurrido mejoras en la calidad y la
productividad.
Las métricas también se emplean para
marcar las áreas problema de modo
que se puedan desarrollar remedios y
mejorar el proceso de software.
42
43
Clasificación 1:Métricas de producto.Métricas de proceso.Clasificación 2:
Métricas basadas en atributos internos del producto:–Medidas de estructuración de unprograma.
–Métricas de complejidad.–Métricas de cobertura depruebas.
–Métricas de calidad deldiseño.
Métricas basadas en atributos externos del producto:–Métricas de portabilidad.–Métricas de defectos.–Métricas de usabilidad.–Métricas de mantenibilidad.
–Métricas de fiabilidad.
Clasificación
44
Métricas basadas en código fuente:Nº de líneas de código.Nº de líneas de comentario.Nº de instrucciones.Densidad de documentación.Métricas basadas en estructura de diseño:Relacionadas con el control intramodular.Relacionadas con el acoplamiento entre clases.
Métricas para sistemas orientados a objetos:Acoplamiento.Herencia.Cohesión.
Se aplica las métricas paravalorar la calidad de losproductos.
Proporcionan una manerasistemática de valorar la calidadbasándose en un conjunto dereglas. Se aplican a todo el ciclode vida permitiendo descubrir ycorregir problemas potenciales.
45
Los requisitos del Software son labase de las medidas de calidad. Lafalta de concordancia con losrequisitos es una falta de calidad.
Unos estándares específicos definenun conjunto de criterios de desarrolloque guían la manera en que se hacela ingeniería del Software. Si no sesiguen los criterios, habráseguramente poca calidad.
46
Los factores que afectan la calidad se puedencategorizar en:
Factores que se pueden medirdirectamente, como por ejemplo los defectospor punto de función.
Factores que se pueden medir sóloindirectamente, como por ejemplo lafacilidad de uso o mantenimiento.
En todos los casos debe aparecer la medición.Debe ser posible comparar el software(documentos, programas, datos) con unareferencia y llegar a una conclusión sobre lacalidad.
47
Factores de calidad de McCall
48
Revisión del
Producto
Transición del
producto
Operación
del producto
Corrección Fiabilidad Usabilidad Integridad Eficiencia
Facilidad de mantenimiento
Flexibilidad
Facilidad de prueba
Portabilidad
Reusabilidad
Interoperatividad
49
• Corrección ¿ HACE LO QUE QUIERO?
Hasta donde satisface un programauna especificación y logra losobjetivos del cliente.
• Fiabilidad ¿ Lo hace de forma fiable todo el
tiempo?Hasta donde se puede esperar que un programa lleve a cabo su función pretendida con la exactitud requerida
50
• Eficiencia ¿ Se ejecutará en mi HW lo mejor
que se pueda?La cantidad de recursos informáticos y código necesario para que un programa realice su función.
• Seguridad¿ Es seguro?
Hasta donde se puede controlar el acceso al software o a los datos por personas no autorizadas.
51
• Usabilidad¿ Es fácil de manejar?
El esfuerzo necesario para aprender, operar , preparar datos de entrada e interpretar salidas (resultados) de un programa.
• Facilidad de mantenimiento¿Puedo corregirlo?
El esfuerzo necesario para localizar y arreglar un error en un programa.
52
• Flexibilidad¿Puedo cambiarlo?
El esfuerzo necesario para modificar un programa operativo.
• Facilidad de prueba¿Puedo probarlo?
El esfuerzo necesario para probar unprograma y asegurarse de que realizala función pretendida.
53
• Portabilidad¿Podré usarlo en otra máquina?
El esfuerzo necesario para transferir el programa de un entorno de sistema de HW y/o SW a otro;
• Reusabilidad¿Podré reutilizar alguna parte del SW?Hasta donde se puede volver a emplear un programa (o partes de un programa) en otras aplicaciones;
• Interoperabilidad¿Podré hacerlo interactuar con otro sistema?El esfuerzo necesario para acoplar un sistema con otro.
54
Es difícil desarrollar medidas directasde los factores de calidad señaladosanteriormente, se definen un conjuntode métricas para desarrollarexpresiones que utilicen los factores:
Fq = c1 x m1 + c2 x m2 +….+cn x mn
Fq es factor de calidad
Cn son coeficientes de regresión
Mn son las métricas que afectan al factor calidad.
55
Lamentablemente muchas de lasmétricas definidas por McCallsolamente pueden medirse demanera subjetiva.
Las métricas se acomodan en unalista de comprobación que se empleapara puntuar atributos específicos delsoftware. El esquema de puntuaciónque se propone es una escala del 0(bajo) al 10 (alto)
56
57
Factores de calidad de Boehm
Métricas en los dominios del proceso y el proyecto
Las métricas del proceso se
recopilan en el curso de todos los
proyectos y durante largos periodos.
Su objetivo es proporcionar un
conjunto de indicadores de proceso
que conduzcan a la mejora de los
procesos de software a largo plazo
58
Las métricas del proyecto permiten
que un gestor de proyecto de
software:
1) Valore el estado de un proyecto en
curso;
2) Rastree los riesgos potenciales;
3) Descubra las áreas problema antes
de que se vuelvan “críticas”;
4) Ajuste el flujo de trabajo o las
tareas;
5) Evalué la habilidad del equipo.59
La única forma de racional de mejorar
cualquier proceso es medir sus
atributos específicos, desarrollar un
conjunto de métricas significativas con
base en dichos atributos y luego
emplear las métricas para ofrecer
indicadores que conducirán a una
estrategia de mejora.
Métricas del proceso y mejora del proceso Sw
60
proceso
Características
del cliente
Condiciones
del negocio
Entorno
de desarrollo
Personal Tecnología
Producto
61
Algunas métricas de proceso son
privadas para el equipo del proyecto
de software, pero públicas para todos
los miembros del equipo.
Las métricas públicas por lo general
asimilan información que
originalmente era privada para los
individuos y equipo
62
La métricas de proceso de software
ofrecen beneficios significativos
conforme una organización trabaja en
mejor grado global de madurez del
proceso. Sin embargo, como todas las
métricas, éstas pueden emplearse mal
y crear más problemas de los que
solucionan
63
Grady, sugiere las siguientes reglas:
Aplique sentido común y
sensibilidad organizativa cuando
interprete datos métricos;
Ofrezca retroalimentación
regular a los individuos y
equipos que recopilan medidas y
métricas;
No utilice las métricas para
evaluar a los individuos;64
Trabaje con los profesionales y
equipos para establecer metas
claras y las métricas que se
emplearán para conseguirlas;
Nunca use métricas para amenazar
a los individuos o equipos;
Los datos métricos que indican un
área problema no deben
considerarse negativos;
No obsesionarse con una sola
métrica.65
A diferencia de las métricas del
proceso de software que se utilizan
con propósitos estratégicos, las
métricas del proyecto de software son
tácticas. Es decir, un gerente de
proyecto y un equipo de software
emplean las métricas del proyecto y
los indicadores que se deducen de
ellas para adaptar el flujo de trabajo
del proyecto y las actividades técnicas
Métricas del proyecto
66
La primera aplicación de las métricas
del proyecto ocurre durante la
estimación. Las métricas recopiladas
de los proyectos previos se
aprovechan como base desde la cual
se realizan estimaciones de esfuerzo y
tiempo.
Conforme el proyecto avanza, las
medidas de esfuerzo y tiempo
utilizados se comparan con originales67
Mientras comienza el trabajo técnico,
las otras métricas comienzan a tener
significado. Se miden los índices de
producción representados en términos
de modelos creados, hora de revisión,
puntos de función y líneas fuente
entregadas.
Además, se les da seguimiento a los
errores descubiertos durante cada
tarea de IS.68
Conforme el software evoluciona
desde los requisitos hasta el diseño,
se recopilan métricas técnicas para
valorar la calidad del diseño y mejorar
los indicadores que influirán en el
enfoque que se adopte para la
generación y prueba del código.
69
Medición del software
Se clasifican en 2 categorías:
1. Medidas directas del proceso de
software (costo, esfuerzo aplicados)
y del producto (líneas de código,
rapidez de ejecución y defectos
reportados);
2. Medidas indirectas del producto que
influyen funcionalidad, calidad,
complejidad, eficiencia,
confiabilidad, facilidad de
mantenimiento, etc.70
Las métricas del software orientadas
al tamaño preceden de la
normalización de las medidas de
calidad o productividad considerando
el tamaño de software que se ha
producido.
Si una organización de software
mantiene registros simples es factible
crear una tabla de medidas orientadas
al tamaño.
Métricas orientadas al tamaño
71
Proyecto LDC esfuerzo $ Pag.doc errores defectos personal
BetaAlfa
Gamma.....
121002720020200
.
.
.
.
.
.
145233......
150240314
.
.
.
.
.
50014801000
.
.
.
.
.
.
139350200
.
.
.
.
.
.
197654......
356......
El desarrollo de métricas que se
asimilen con métricas similares
procedentes de otros proyectos
requiere elegir líneas de código con
valor de normalización72
A partir de los datos rudimentarios de
la tabla se desarrolla un conjunto de
métricas simples orientadas al tamaño
para cada proyecto.
La métricas orientadas al tamaño no
se aceptan universalmente como la
forma de medir el proceso del
software
73
Las métricas del software orientadas a
la función emplean como un valor de
normalización una medida de la
funcionalidad que entrega la
aplicación.
La métrica orientada a la función
utilizada con mayor amplitud es el
punto de función (PF). El cálculo del
PF se basa en características del
dominio de información y la
complejidad del software
Métricas orientadas a la función
74
75
La métrica del punto de función(PF) se puede utilizar como mediopara predecir el tamaño de unsistema obtenido a partir de unmodelo de análisis.Para visualizar esta métrica seutiliza un diagrama de flujo dedatos, el cual se evalua paradeterminar las siguientes medidasclave que son necesarias para elcálculo de la métrica de punto defunción:
76
Número de entradas delusuario;Número de salidas delusuario;Número de consultas delusuario;Número de archivos;Número de interfacesexternas.
77
Entradas: Pantallas o formularios através de los cuales usuarioshumanos de una aplicación u otrosprogramas agregan nuevos datos oactualizan datos existentes. Si unapantalla de entrada es muy grandepara ser desplegada de una vez(asumiendo 80 columnas y 25líneas) y requiere de una segundapantalla, el conjunto cuenta comouna (1) sola entrada. Se debenconsiderar entradas que requierenprocesamiento único.
78
Salidas: Pantallas o informes que laaplicación produce para uso humanoo para otros programas. Las salidasque requieren procesamientoseparado deben ser contabilizadas:en una aplicación de remuneracionesuna función de salida que genere100 cheques contaría como una solasalida.
Ej: pantallas, informes impresos,archivos en disco, sets de cheques,facturas impresas.
79
Las consultas se dividen en dospartes: la porción de entrada y laporción de salida. Ejemplos deconsultas: consulta de un usuario sinactualizar un archivo, mensajes deayuda, mensajes de selección. Unaconsulta típica sería una relacionadacon una reservación aérea.
Pantallas que le permiten a losusuarios interrogar una aplicación ysolicitar asistencia o información, talcomo pantallas de ayuda (HELP).
80
Archivos internos lógicos:Colección lógica de registro que laaplicación modifica o actualiza unatabla de una base de datos.
Archivos externos de interfaz:bases de datos compartidas,archivos lógicos direccionables desdeo hacia otra aplicación. Es unconjunto de datos definidos por elusuario, que están relacionadoslógicamente y que sólo son usadospara propósitos de referencia.
FI.1 comunicación de datos
FI.2 funciones distribuidas
FI.3 objetivos de performance
FI.4 configuración usada fuertemente
FI.5 tasa de transacciones
FI.6 entrada de datos en línea
FI.7 eficiencia del usuario final
FI.8 actualización en línea
FI.9 procesamiento complejo
FI.10 reusabilidad
FI.11 facilidad de instalación
FI.12 facilidad operacional
FI.13 sitios múltiples
FI.14 facilitamiento del cambio
CGS… Factores de influencia
81
0 factor no presente o sin influencia
1 influencia insignificante
2 influencia moderada
3 influencia promedio
4 influencia significativa
5 influencia fuerte
Escala de evaluación
82
83
Comunicación de datos: implicaque datos y/o información de controlson enviadas o recibidas. Laevaluación es un 0 para aplicacionesbatch, y un 5 para aplicaciones enque predomina el teleproceso;
Funciones distribuidas: analiza siuna aplicación es monolítica y operaen un solo procesador o si esdistribuida. 0 para aplicacionesmonolíticas y un 5 para aplicacionesque se ejecutan dinámicamente envarios procesadores;
84
Objetivos de performance: laevaluación sería un 0 si no hayestablecido ningún criterio especialde performance, y un 5 si losusuarios insisten en objetivos deperformance muy rigurosos querequieren un esfuerzo;
Configuración usadafuertemente: la evaluación sería un0 si la aplicación no tienerestricciones especiales de uso, y un5 si el uso anticipado requiereespecial esfuerzo para ser logrado;
85
Tasa de transacciones: laevaluación sería un 0 si el volumende transacciones no es significativo,y un 5 si el volumen es losuficientemente significativo comopara producir stress en la aplicacióny requerir un esfuerzo especial paraalcanzar throughputs deseados;
Entrada de datos en línea: laevaluación sería un 0 si menos del15% de las transacciones soninteractivas, y un 5 si más del 50%de las transacciones son interactivas
86
Eficiencia del usuario final: laevaluación sería un 0 si no hayusuarios finales o no hayrequerimientos especiales para losusuarios finales, y un 5 si losrequerimientos de eficiencia deusuarios finales son losuficientemente rígidos como pararequerir un esfuerzo;
Actualización en línea: laevaluación sería 0 si no hay, y un 5si las actualizaciones son obligatoriasy especialmente difíciles;
87
Procesamiento complejo: laevaluación sería 0 si no hay, y un 5en casos que requieren decisioneslógicas extensas, matemáticacompleja, procesamiento deexcepciones;
Reusabilidad: la evaluación seríaun 0 si la funcionalidad se planifica,y un 5 si mucha de la funcionalidady los artefactos del proyecto sepretende que sean usadosampliamente por otras aplicaciones;
88
Facilidad de instalación: laevaluación sería un 0 si este factores insignificante, y un 5 si lainstalación es importante y tanrestrictiva que requiere un esfuerzoespecial para cumplirlasatisfactoriamente;
Facilidad operacional: laevaluación sería un 0 si este factores insignificante, y un 5 si lafacilidad operacional es tanrestrictiva que requiere un esfuerzoespecial para alcanzarla;
89
Sitios múltiples: la evaluación seríaun 0 si hay solo un sitio planificadode uso, y un 5 si el proyecto y susartefactos se pretenden sean usadosen muchos lugares;
Facilitamiento del cambio: laevaluación sería un 0 si el cambio noocurre, y un 5 si la aplicación sedesarrolla específicamente parapermitir a los usuarios finales elhacer cambios rápidos para controlardatos o tablas que ellos mantienencon la ayuda de la aplicación.
90
La cuenta total debe ajustarseutilizando la siguiente ecuación:
PF = c-total x (0,65 + 0,01 x Fi)
Donde c-total es la suma de todaslas entradas PF obtenidas y Fi (i=1a 14) son los "valores de ajuste decomplejidad".
91
Factor de ponderación
Parámetro de medición Cuenta Simple Media Compl.
Número de entradas delusuario
3 X 3 4 6 = 9
Número de salidas del usuario 2 X 4 5 7 = 8
Número de consultas delusuario
2 X 3 4 6 = 6
Número de archivos 1 X 7 10 15 = 7
Número de interfaces externas 4 X 5 7 10 = 20
Cuenta total 50
Cálculo de puntos de función
Se asume que la Fi es 46 (un productomoderadamente complejo), por consiguiente:
PF = 50 x (0,65 + 0,01 x 46) = 56
Las métricas de proyectos de software
convencionales (LDC o PF) se aplican
en la estimación de proyectos de
software OO. Sin embargo, estas
métricas no proporcionan suficiente
granularidad para la planificación y los
ajustes de esfuerzo que se requieren
conforme se itera a lo largo de un
proceso evolutivo o incremental.
Métricas orientadas a objetos
92
Lorenz y Kidd, sugieren el siguiente
conjunto de métricas OO:
Número de guiones de escenario.
Es una secuencia detallada de pasos
que describen la interacción entre el
usuario y la aplicación;
Número de clases clave. Son los
componentes enormemente
independientes definidos con
antelación en análisis OO;93
Número de clases de apoyo. Es un
indicio de la cantidad de esfuerzo
indispensable para desarrollar el
software, así como un indicio de la
cantidad de reutilización;
Número promedio de clases de
apoyo por clase clave. Las clases
clave se conocen en etapas iníciales.
Las clases de apoyo se definen a lo
largo del curso de éste;
Número de subsistemas.94
Los casos de uso se define en etapas
tempranas del proceso de software, lo
que permite emplearlo en la
estimación antes de iniciar las
actividades significativas de modelado
y construcción.
Los casos de uso describen (al menos
indirectamente) funciones y
características visibles al usuario que
son requisitos básicos para un sistema
Métricas orientadas a casos de uso
95
El caso de uso es independiente del
lenguaje de programación. Además, el
número de casos de uso es
directamente proporcional al tamaño
de la aplicación en LDC, así como al
número de casos de prueba que
tendrán que diseñarse para ejercitar
completamente la aplicación.
96
Entre las medidas que se pueden
recopilar son:
Número de páginas web
estáticas;
Número de páginas web
dinámicas;
Número de vínculos internos de
página;
Número de objetos de datos
persistentes;
Métricas de proyectos de IWeb
97
Número de sistemas externos en
interfaz;
Número de objetos de contenido
estático;
Número de objetos de contenido
dinámico;
Número de funciones
ejecutables.
98
Métricas para calidad del software
La meta primordial de la IS es
producir un sistema, aplicación o
producto de alta calidad dentro de un
marco temporal que satisfaga una
necesidad del mercado.
El logro de esta meta requiere que los
IS apliquen métodos eficaces
acoplados con herramientas
modernas. Además se debe medir si
se logrará la alta calidad.
99
Se pueden utilizar muchas medidas de
calidad, el impulso primario, es medir
los errores y defectos. Las métricas
derivadas de estas medidas
proporcionan un indicio de la
efectividad de la garantía de la calidad
del software y de las actividades de
control tanto de los individuos como
del grupo.
100
Las métricas como los errores en el
producto de trabajo por punto de
función, errores descubiertos por hora
de revisión de la eficacia de cada una
de las actividades implicadas en la
métrica. Los datos de error también
se pueden emplear en el cálculo de la
eficacia en la eliminación de defectos
(EED)
101
Los indicadores útiles para el equipo de
proyecto son:
Corrección. La medida más común para
la corrección es defectos por KLDC,
donde un defecto se define como una
falta comprobada de concordancia con
los requisitos. Cuando se considera la
calidad global de un producto, los
defectos son los problemas que reporta
el usuario después que se liberó.
Medición de la calidad
102
Facilidad de mantenimiento. Es la
sencillez con la que un programa puede
corregirse si se encuentra un error,
adaptarse si su entorno cambia, o
mejorar si el cliente desea un cambio en
los requisitos. No existe forma de medir
directamente, por lo que se emplean
medidas indirectas. Una simple medida
orientada al tiempo es el tiempo medio
de cambio (TMC)103
Integridad. Mide la habilidad de un
sistema para resistir ataques a su
seguridad.
La medición de la integridad requiere
definir: amenaza y seguridad.
La integridad de un sistema se define:
Integridad = 1- (amenaza x (1-seguridad))
Si la probabilidad de amenaza es 0.50 y
la posibilidad de repeler un ataque es
sólo 0.25, la integridad es 0.63
(inaceptablemente baja).104
Facilidad de uso. Con frecuencia, un
programa que no es fácil de usar está
condenado al fracaso, incluso si las
funciones que realiza son valiosas.
Es un intento por cuantificar la sencillez
de la aplicación al utilizarla y se puede
medir en términos de características
105
Una métrica de calidad que ofrece
beneficios tanto en ámbito del proyecto
como en el proceso es la eficacia en la
eliminación de defectos (EED). En
esencia, la EED es la medida de la
habilidad de filtrar las actividades de la
garantía de cualidad y de control
conforme se aplica a través de las
actividades del marco de trabajo.
Eficacia en la eliminación de defectos
106
Cuando se considera un proyecto como
un todo, la EED se define:
EED = E/(E+D)
E es el número de errores encontrados
antes de entregar el software.
D es el número de defectos encontrados
después de la carga.
El valor ideal de la EED es 1
107
La EED también se puede aplicar en el
proyecto para valorar la habilidad de un
equipo de encontrar errores antes de
que pasen a la siguiente actividad.
Por ejemplo, la tarea de análisis de
requisitos produce un modelo de análisis
que se revisa para encontrar y corregir
errores. Si no se encuentran errores
pasan al diseño.
108
Cuando se aplica en este contexto la
EED se redefine como:
EEDi = Ei/(Ei+Di+1)
Ei es el número de errores encontradosdurante la actividad i de la IS.
Ei+1 es el número de errores encontradosdurante la actividad i+1 de IS que sepuede seguir para llegar a erroresque no fueron descubiertos en laactividad i de IS
109
Integración de las métricas dentro del proceso de Sw
La mayoría de los desarrolladores de
software todavía no miden y,
lamentablemente, muchos tienen
poco deseo de comenzar.
El problema es cultural !!!
110
Si no se mide, no existe una forma real
de determinar si se está mejorando. Y si
no se mejora, se está perdido.
Si se emplea la medición para establecer
una línea base del proyecto, cada uno de
los temas: desarrollar estimaciones de
proyecto significativas, producir
sistemas de calidad, tener el producto a
tiempo, se vuelven más manejables.
Argumentos para las métricas del software
111
Los datos de la línea base deben tener
los siguientes atributos:
Los datos deben ser razonablemente
precisos;
Los datos deben recopilarse para
tantos proyectos como sea posible;
Las medidas deben ser consistentes;
Las aplicaciones deben ser similares
al trabajo que se estimará.
Establecimiento de una línea base
112
La recopilación de datos requiere una
investigación histórica de los proyectos
previos para reconstruir los datos
requeridos
Recopilación, cálculo y evaluación de métricas
Proceso
de IS
Proyecto
de SW
Producto
de SW
Recopilacion
de datosCálculo de
métricas Evaluación
Métricas
medidas
métricas
indicadores113
