Post on 09-Jul-2020
MODULO IVMODULO IV
Ingeniería de SoftwareINF - 163
4.1 CONCEPTOS DE GESTION
Resumen preparado por Miguel Cotaña1
14/05/09
Gestión de ProyectosGestión de Proyectos
Cuando se planifica un proyecto setiene que obtener estimaciones delcosto y esfuerzo humano requeridopor medio de las mediciones depor 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, deconseguir 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 temporalcomprometido a crear un producto oservicio único.Entre sus características principales:
Temporalidad;
Qué es un Proyecto?Qué es un Proyecto?
Temporalidad;Unicidad;Progresividad;Ejecutado por personas;Limitado a ciertos recursos;Planificado, ejecutado ycontrolado.
4
Tareas críticas en la gestión de proyectosTareas críticas en la gestión de proyectos
El número de tareas identificables sonmuchas. Sin embargo, 3 son críticas yque deben ser desarrolladascorrectamente:
Estimación de duración, coste yesfuerzo necesarios para construirel producto;Planificación de tareas a realizar,asignación de personas, tiempos.Seguimiento
5
Estimación de proyectosEstimación de proyectos
Se define como la predicción depersonal, del esfuerzo, de los costes yde la planificación que se requerirá pararealizar todas las actividades yrealizar todas las actividades yconstruir todos los productos asociadoscon el proyecto.Uno de los parámetros críticos de laestimación es determinar su exactitud.
6
Estimar
Horas
hombre
Estimar
El
costo
Estimación enfoque tradicionalEstimación enfoque tradicional
7
Determinar
Plazos de
entrega
Determinar
Personal
involucrado
Estimar
Horas
hombre
Estimar
Tiempo
total
Determinar
Lineas de
codigo
Establecer
Estimación: método COCOMOEstimación: método COCOMO
8
Determinar
Personal
involucrado
Estimar
El
costo
Establecer
Plazo de
entrega
Puntos de
Función sin
ajustar
Puntos de
Funcion
ajustados
Estimación: método Punto FunciónEstimación: método Punto Función
9
Líneas
De código
Del software
Ratio
Líneas de
Código PF
Larry Putnam, ha apuntado que lagestión del desarrollo de softwareconsidera la estimación como unaactividad que permite obtener,actividad que permite obtener,prinicipalmente, respuestas a lassiguientes preguntas:
¿Cuánto Costará?¿Cuánto tiempo llevará hacerlo?
10
Razones de difícil estimaciónRazones de difícil estimación
No existe un modelo universal;Hay muchas personas implicadas enlos proyectos que precisan deestimaciones;estimaciones;La utilidad de una estimacióndependerá de la etapa de desarrolloen la que nos encontremos;La estimación, a menudo se realizasuperficialmente;
11
Las estimaciones claras, completas yprecisas son difíciles de formular;Las características del Sw y de sudesarrollo hacen difícil la estimación;
12
desarrollo hacen difícil la estimación;Existe tendencia aparente hacia lasubestimación;Existen malas interpretaciones;El estimador tiende a reducir enalgún grado, para hacer másaceptable la oferta.
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- Herramientas Organiza- experiencia
13
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 estimadorRequisitos de un buen estimador
No tiene ningún interés, directo niindirecto en los resultados del procesode estimación:Formación y experiencia profesional;Formación y experiencia profesional;Juicio independiente;Basarse en metodos que pueda serexplicado, cuestionado, discutido yauditado por otros expertos;Usa herramientas de estimación;Documentar la estimación.
14
Salidas del proceso de estimaciónSalidas del proceso de estimación
¿cuánta gente se necesita?;¿De qué perfiles?;¿Cuáles son los riesgos?;¿Cómo afectan las restricciones¿Cómo afectan las restriccionesimpuestas a las estimaciones?;¿Cuánto esfuerzo se necesita pararealizar cada fase del ciclo de vida?;¿Cómo impacta este proceso en elresto de proyectos de la empresa?;
15
¿Cuál será el esfuerzo paramantener este proyecto?;¿Cuál será el tamaño del sistema(lineas de código)?;
16
(lineas de código)?;¿Cuántos defectos tendrá elproducto?;¿Cuánta documentación serágenerada?;¿Cuál será el esfuerzo para generardicha documentación?.
El espectro de la gestiónEl espectro de la gestión
La gestión eficaz de la gestión deproyectos software se enfoca sobrelas cuatro P:las cuatro P:
Personal;Producto;Proceso;Proyecto.
17
El SEI ha desarrollado un modelo demadurez de la capacidad de gestiónde personal (MMCGP), que define:
Reclutamiento;Selección;
PersonalPersonal
Selección;Gestión del desempeño;Entrenamiento;Retribución;Desarrollo de la carrera;Desarrollo de la cultura deequipo.
18
Se clasifican en 5 categorías:Gestores ejecutivos, que definen losaspectos del negocio;Gestores (técnicos) del proyecto,
Los participantesLos participantes
Gestores (técnicos) del proyecto,quienes planifican, motivan, organizany controlan a los profesionales querealizan el trabajo de software;Profesionales, proporcionan lashabilidades técnicas necesarias;
19
Clientes, quienes especifican losrequisitos para la ingeniería desoftware y otros elementos que tienensoftware y otros elementos que tienenun interés mínimo en el resultado;Usuarios finales, quienesinteractúan con el software una vezque se libera su uso productivo.
20
Weinberg, sugiere un modelo deliderazgo:Motivación, la habilidad para alentar(mediante el “empuje o jalón”) alpersonal técnico;
Líderes de equipoLíderes de equipo
personal técnico;Organización, la habilidad paraadecuar los procesos existentes;Ideas o innovación, la habilidadpara alentar a la gente para crear ysentir creativamente.
21
Otra visión, define los rasgos:Resolución de problemas, ungestor puede diagnosticar losconflictos técnicos y organizativos;Dotes de gestión, encabezar y dirigirDotes de gestión, encabezar y dirigirIncentivos, un gestor deberecompensar la iniciativa y los logros;Influencia y fomento de la culturaen equipo, mantener el control ensituaciones de tensión emocional.
22
La mejor estructura de equipodepende del estilo de gestión de cadaorganización, del número de personasque integran el equipo y de susgrados de habilidad. Los factores:
El equipo de softwareEl equipo de software
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.
23
Constantine, sugiere 4 paradigmasorganizacionales para los equipos:Un paradigma cerrado, jerarquíatradicional de autoridad;Un paradigma aleatorio, estructuraUn paradigma aleatorio, estructuraun equipo libremente y depende de lainiciativa individual de los miembrosdel equipo. Cuando se requiereinnovación o adelantos tecnológicos,serán excelentes. Pero no sonordenados;
24
Un paradigma abierto, intentaestructurar un equipo en una formaque logre algunos de los controlesasociados con el paradigma cerrado.El trabajo se desarrolla enEl trabajo se desarrolla encolaboración. La sólida comunicación yla toma de decisiones basadas en elconsenso, son sus características;Un paradigma sincrónico, se apoyaen partes del problema con pocacomunicación activa entre ellos.
25
La filosofía ágil alienta la satisfaccióndel cliente y la temprana entregaincremental del software; pequeñosequipos de trabajo enormemente
Equipos ágilesEquipos ágiles
equipos de trabajo enormementemotivados; métodos informales;mínimos productos de trabajo de IS; ysimplicidad global de desarrollo.Estos equipos (ágiles) sonautoorganizados
26
Muchos modelos de proceso ágil (porejemplo, Scrum) brindan al equipoágil una autonomía significativa pararealizar la gestión del proyecto ytomar las decisiones técnicastomar las decisiones técnicasrequeridas para cumplir el trabajo.La planificación se mantiene en elmínimo, y al equipo se le permiteseleccionar su propio enfoque, sólorestringido por los requisitos delnegocio y estándares organizacionales
27
El gestor de un proyecto de softwarese enfrenta con un dilema desde elprincipio de un proyecto de IS. Serequieren estimaciones cuantitativas yun plan organizado, pero no dispone
El productoEl producto
un plan organizado, pero no disponede información sólida.En consecuencia, se deben examinarel producto y el problema que seintenta resolver al inicio del proyecto.Se debe establecer y acotar el ámbitodel producto.
28
La primera actividad de gestión :Contexto. ¿cómo encaja el softwareque se desarrollará en el negocio y quérestricciones se imponen?;Objetivos de información. ¿qué
Ámbito del softwareÁmbito del software
Objetivos de información. ¿quéobjetos de datos se requieren deentrada?;Función y desempeño. ¿quéfunciones realiza el software paratransformar los datos en salida?.
29
A veces llamada partición o elaboracióndel problema, es una actividad de la IR.Durante la actividad de fijación delámbito no se intenta en descomponercompletamente el problema
Descomposición del problemaDescomposición del problema
completamente el problemaUn problema complejo se divide enproblemas menores que resultan másmanejables. Ésta es la estrategia quese aplica cuando comienza laplanificación del proyecto
30
Las actividades del marco de trabajoque caracterizan al proceso desoftware son aplicables a todos losproyectos de software.El gestor del proyecto debe decidir
El procesoEl proceso
El gestor del proyecto debe decidircuál modelo de proceso es másadecuado para:
1) Los clientes que solicitaron ypersonas que realizarán el trabajo;
2) Las características del producto;3) El ambiente del proyecto.
31
La planeación del proyecto comienzacon la combinación del producto y elproceso. Cada función que el equipo desoftware someterá a ingeniería debe
Combinación del producto y el procesoCombinación del producto y el proceso
software someterá a ingeniería debepasar a través del conjunto deactividades del marco de trabajo:Comunicación, planificación, modelado,construcción y despliegue.
32
La descomposición del proceso comienzacuando el gerente de proyecto pregunta:¿cómo logramos esta actividad del marcode trabajo?Para un proyecto complejo se puede
Descomposición del procesoDescomposición del proceso
Para un proyecto complejo se puederequerir las siguientes tareas de trabajopara la actividad de comunicación:
1. Revisar la petición del cliente;2. Planificar reunión formal;3. Llevar a cabo investigaciones;
33
4) Preparar documento de trabajo;5) Celebrar reunión;6) Desarrollar y revisar miniprospectos
o caso de uso para valorar sucorrección;corrección;
7) Ensamblar miniprospectos en undocumento más amplio;
8) Revisar el documento conimplicados;
9)Modificar el documento.34
La gestión de un proyecto de softwareexitoso requiere entender qué puedesalir mal. J. Reel, define 10 señales:1.El personal de software noentiende las necesidades de sus
El proyectoEl proyecto
entiende las necesidades de susclientes;
2.El ámbito del producto está maldefinido;
3.Los cambios se gestionan mal;4.La tecnología elegida cambia;
35
5. Las necesidades comercialescambian (o están mal definidas);
6. Los plazos de entrega no sonrealistas;
7. Los usuarios se resisten;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 laslecciones aprendidas.
36
Se necesita un principio organizadorque escale hacia abajo paraproporcionar planes simples paraproyectos simples. Boehm, realiza unaserie de preguntas.
El principio W5 HHEl principio W5 HH
serie de preguntas.¿Por qué se desarrolla el sistema?¿Por qué se desarrolla el sistema?
¿Qué se hará?¿Qué se hará?¿Cuándo se hará?¿Cuándo se hará?
¿Quién es el responsable de una ¿Quién es el responsable de una función?función?
37
¿Dónde están ubicados en la ¿Dónde están ubicados en la organización?organización?
¿Cómo se hará el trabajo desde los ¿Cómo se hará el trabajo desde los puntos de vista técnico y de gestión?puntos de vista técnico y de gestión?
¿Cuánto de cada recurso se necesita?¿Cuánto de cada recurso se necesita?
38
MODULO IVMODULO IV
Ingeniería de SoftwareINF - 163
4.2 METRICAS DE PROCESO Y PROYECTO
Resumen preparado por Miguel Cotaña39
14/05/09
La medición permite obtener una visióndel proceso y el proyecto puesproporciona un mecanismo para lograruna evaluación objetiva.La medición se aplica al proceso deLa medición se aplica al proceso desoftware con la finalidad de mejorarlo demanera continua. La medición se utilizaa lo largo de un proyecto de softwarecomo apoyo en la estimación, el controlde calidad, la valoración de laproductividad y el control del proyecto.
40
El proceso de software y las métricasdel proyecto son medidascuantitativas que permiten a los ISobtener una visión de la eficacia delobtener una visión de la eficacia delproceso de software y los proyectosque llevan a cabo utilizando el procesocomo marco de trabajo.Se recopilan datos básicos de calidady productividad.
41
Luego, dichos datos se analizan,comparan con promedios pasados yvaloran para determinar si hanocurrido mejoras en la calidad y laocurrido mejoras en la calidad y laproductividad.Las métricas también se emplean paramarcar las áreas problema de modoque se puedan desarrollar remedios ymejorar el proceso de software.
42
Clasificación 1:�Métricas de producto.�Métricas de proceso.Clasificación 2:
�Métricas basadas en �Métricas basadas en
ClasificaciónClasificación
43
�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.
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:
44
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 maneraProporcionan 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 de calidad de McCallFactores de calidad de McCall
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
Facilidad de mantenimiento
Flexibilidad
Facilidad de prueba
Portabilidad Reusabilidad Interoperatividad
48
Revisión del Producto
Transición del producto
Operacióndel producto
Corrección Fiabilidad Usabilidad Integridad Eficiencia
• Corrección ¿ HACE LO QUE QUIERO?
Hasta donde satisface un programauna especificación y logra losobjetivos del cliente.
49
objetivos 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
• Eficiencia ¿ Se ejecutará en mi HW lo mejor
que se pueda?La cantidad de recursos informáticos y código necesaria para que un
50
y código necesaria 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.
• Usabilidad¿ Es fácil de manejar?
El esfuerzo necesario para aprender, operar , preparar datos de entrada e interpretar salidas (resultados) de un
51
interpretar salidas (resultados) de un programa.
• Facilidad de mantenimiento¿Puedo corregirlo?
El esfuerzo necesario para localizar y arreglar un error en un programa.
• Flexibilidad¿Puedo cambiarlo?
El esfuerzo necesario para modificar un programa operativo.
52
• Facilidad de prueba¿Puedo probarlo?
El esfuerzo necesario para probar unprograma y asegurarse de que realizala función pretendida.
• 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
53
• 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:expresiones 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
Factores de calidad de BoehmFactores de calidad de Boehm
57
Métricas en los dominios del proceso y el proyectoMétricas en los dominios del proceso y el proyecto
Las métricas del proceso serecopilan en el curso de todos losproyectos y durante largos periodos.proyectos y durante largos periodos.Su objetivo es proporcionar unconjunto de indicadores de procesoque conduzcan a la mejora de losprocesos de software a largo plazo
58
Las métricas del proyecto permitenque un gestor de proyecto desoftware:
1) Valore el estado de un proyecto encurso;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 mejorarcualquier proceso es medir susatributos específicos, desarrollar unconjunto de métricas significativas con
Métricas del proceso y mejora del proceso SwMétricas del proceso y mejora del proceso Sw
conjunto de métricas significativas conbase en dichos atributos y luegoemplear las métricas para ofrecerindicadores que conducirán a unaestrategia de mejora.
60
Características
del cliente
Condiciones
del negocio
Producto
proceso
del cliente del negocio
Entorno
de desarrollo
Personal Tecnología
61
Algunas métricas de proceso sonprivadas para el equipo del proyectode software, pero públicas para todoslos miembros del equipo.los miembros del equipo.Las métricas públicas por lo generalasimilan información queoriginalmente era privada para losindividuos y equipo
62
La métricas de proceso de softwareofrecen beneficios significativosconforme una organización trabaja enmejor grado global de madurez delmejor grado global de madurez delproceso. Sin embargo, como todas lasmétricas, éstas pueden emplearse maly crear más problemas de los quesolucionan
63
Grady, sugiere las siguientes reglas:Aplique sentido común ysensibilidad organizativa cuandointerprete datos métricos;Ofrezca retroalimentaciónOfrezca retroalimentaciónregular a los individuos yequipos que recopilan medidas ymétricas;No utilice las métricas paraevaluar a los individuos;
64
Trabaje con los profesionales yequipos para establecer metasclaras y las métricas que seemplearán para conseguirlas;Nunca use métricas para amenazarNunca use métricas para amenazara los individuos o equipos;Los datos métricos que indican unárea problema no debenconsiderarse negativos;No obsesionarse con una solamétrica.
65
A diferencia de las métricas delproceso de software que se utilizancon propósitos estratégicos, lasmétricas del proyecto de software sontácticas. Es decir, un gerente de
Métricas del proyectoMétricas del proyecto
tácticas. Es decir, un gerente deproyecto y un equipo de softwareemplean las métricas del proyecto ylos indicadores que se deducen deellas para adaptar el flujo de trabajodel proyecto y las actividades técnicas
66
La primera aplicación de las métricasdel proyecto ocurre durante laestimación. Las métricas recopiladasde los proyectos previos seaprovechan como base desde la cualaprovechan como base desde la cualse realizan estimaciones de esfuerzo ytiempo.Conforme el proyecto avanza, lasmedidas de esfuerzo y tiempoutilizados se comparan con originales
67
Mientras comienza el trabajo técnico,las otras métricas comienzan a tenersignificado. Se miden los índices deproducción representados en términosde modelos creados, hora de revisión,de modelos creados, hora de revisión,puntos de función y líneas fuenteentregadas.Además, se les da seguimiento a loserrores descubiertos durante cadatarea de IS.
68
Conforme el software evolucionadesde los requisitos hasta el diseño,se recopilan métricas técnicas paravalorar la calidad del diseño y mejorarvalorar la calidad del diseño y mejorarlos indicadores que influirán en elenfoque que se adopte para lageneración y prueba del código.
69
Medición del softwareMedició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 defectosrapidez de ejecución y defectosreportados);
2. Medidas indirectas del producto queinfluyen funcionalidad, calidad,complejidad, eficiencia,confiabilidad, facilidad demantenimiento, etc.
70
Las métricas del software orientadasal tamaño preceden de lanormalización de las medidas decalidad o productividad considerandoel tamaño de software que se ha
Métricas orientadas al tamañoMétricas orientadas al tamaño
el tamaño de software que se haproducido.Si una organización de softwaremantiene registros simples es factiblecrear una tabla de medidas orientadasal 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 seasimilen con métricas similaresprocedentes de otros proyectosrequiere elegir líneas de código convalor de normalización
72
A partir de los datos rudimentarios dela tabla se desarrolla un conjunto demétricas simples orientadas al tamañopara cada proyecto.La métricas orientadas al tamaño noLa métricas orientadas al tamaño nose aceptan universalmente como laforma de medir el proceso delsoftware
73
Las métricas del software orientadas ala función emplean como un valor denormalización una medida de lafuncionalidad que entrega laaplicación.
Métricas orientadas a la funciónMétricas orientadas a la función
aplicación.La métrica orientada a la funciónutilizada con mayor amplitud es elpunto de función (PF). El cálculo delPF se basa en características deldominio de información y lacomplejidad del software
74
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 se
75
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:
Número de entradas delusuario;Número de salidas delusuario;
76
usuario;Número de consultas delusuario;Número de archivos;Número de interfacesexternas.
La cuenta total debe ajustarseutilizando la siguiente ecuación:
PF = c-total x (0,65 + 0,01 x ∑Fi)
77
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".
Factor de ponderación
Parámetro de medición Cuenta Simple Media Compl.
Número de entradas delusuario
3 X 3 4 6 = 9
Se asume que la ∑Fi es 46 (un productomoderadamente complejo), por consiguiente:
PF = 50 x (0,65 + 0,01 x 46) = 56
78
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
Las métricas de proyectos de softwareconvencionales (LDC o PF) se aplicanen la estimación de proyectos desoftware OO. Sin embargo, estasmétricas no proporcionan suficiente
Métricas orientadas a objetosMétricas orientadas a objetos
métricas no proporcionan suficientegranularidad para la planificación y losajustes de esfuerzo que se requierenconforme se itera a lo largo de unproceso evolutivo o incremental.
79
Lorenz y Kidd, sugieren el siguienteconjunto de métricas OO:Número de guiones de escenario.Es una secuencia detallada de pasosque describen la interacción entre elque describen la interacción entre elusuario y la aplicación;Número de clases clave. Son loscomponentes enormementeindependientes definidos conantelación en análisis OO;
80
Número de clases de apoyo. Es unindicio de la cantidad de esfuerzoindispensable para desarrollar elsoftware, así como un indicio de lacantidad de reutilización;cantidad de reutilización;Número promedio de clases deapoyo por clase clave. Las clasesclave se conocen en etapas iníciales.Las clases de apoyo se definen a lolargo del curso de éste;Número de subsistemas.
81
Los casos de uso se define en etapastempranas del proceso de software, loque permite emplearlo en laestimación antes de iniciar lasactividades significativas de modelado
Métricas orientadas a casos de usoMétricas orientadas a casos de uso
actividades significativas de modeladoy construcción.Los casos de uso describen (al menosindirectamente) funciones ycaracterísticas visibles al usuario queson requisitos básicos para un sistema
82
El caso de uso es independiente dellenguaje de programación. Además, elnúmero de casos de uso esdirectamente proporcional al tamañodirectamente proporcional al tamañode la aplicación en LDC, así como alnúmero de casos de prueba quetendrán que diseñarse para ejercitarcompletamente la aplicación.
83
Entre las medidas que se puedenrecopilar son:
Número de páginas webestáticas;Número de páginas web
Métricas de proyectos de IWebMétricas de proyectos de IWeb
Número de páginas webdinámicas;Número de vínculos internos depágina;Número de objetos de datospersistentes;
84
Número de sistemas externos eninterfaz;Número de objetos de contenidoestático;estático;Número de objetos de contenidodinámico;Número de funcionesejecutables.
85
Métricas para calidad del softwareMétricas para calidad del software
La meta primordial de la IS esproducir un sistema, aplicación oproducto de alta calidad dentro de unmarco temporal que satisfaga unanecesidad del mercado.necesidad del mercado.El logro de esta meta requiere que losIS apliquen métodos eficacesacoplados con herramientasmodernas. Además se debe medir sise logrará la alta calidad.
86
Se pueden utilizar muchas medidas decalidad, el impulso primario, es medirlos errores y defectos. Las métricasderivadas de estas medidasproporcionan un indicio de laefectividad de la garantía de la calidaddel software y de las actividades decontrol tanto de los individuos comodel grupo.
87
Las métricas como los errores en elproducto de trabajo por punto defunción, errores descubiertos por horade revisión de la eficacia de cada unade las actividades implicadas en lamétrica. Los datos de error tambiénse pueden emplear en el cálculo de laeficacia en la eliminación de defectos(EED)
88
Los indicadores útiles para el equipo deproyecto son:Corrección. La medida más común parala corrección es defectos por KLDC,
Medición de la calidadMedición de la calidad
donde un defecto se define como unafalta comprobada de concordancia conlos requisitos. Cuando se considera lacalidad global de un producto, losdefectos son los problemas que reportael usuario después que se liberó.
89
Facilidad de mantenimiento. Es lasencillez con la que un programa puedecorregirse si se encuentra un error,adaptarse si su entorno cambia, omejorar si el cliente desea un cambio enlos requisitos. No existe forma de medirdirectamente, por lo que se empleanmedidas indirectas. Una simple medidaorientada al tiempo es el tiempo mediode cambio (TMC)
90
Integridad. Mide la habilidad de unsistema para resistir ataques a suseguridad.La medición de la integridad requieredefinir: amenaza y seguridad.definir: amenaza y seguridad.La integridad de un sistema se define:Integridad = 1Integridad = 1-- (amenaza x (1(amenaza x (1--seguridad))seguridad))
Si la probabilidad de amenaza es 0.50 yla posibilidad de repeler un ataque essólo 0.25, la integridad es 0.63(inaceptablemente baja).
91
Facilidad de uso. Con frecuencia, unprograma que no es fácil de usar estácondenado al fracaso, incluso si lasfunciones que realiza son valiosas.funciones que realiza son valiosas.
Es un intento por cuantificar la sencillezde la aplicación al utilizarla y se puedemedir en términos de características
92
Una métrica de calidad que ofrecebeneficios tanto en ámbito del proyectocomo en el proceso es la eficacia en laeliminación de defectos (EED). En
Eficacia en la eliminación de defectosEficacia en la eliminación de defectos
esencia, la EED es la medida de lahabilidad de filtrar las actividades de lagarantía de cualidad y de controlconforme se aplica a través de lasactividades del marco de trabajo.
93
Cuando se considera un proyecto comoun todo, la EED se define:
EED = E/(E+D)E es el número de errores encontradosE 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
94
La EED también se puede aplicar en elproyecto para valorar la habilidad de unequipo de encontrar errores antes deque pasen a la siguiente actividad.que pasen a la siguiente actividad.Por ejemplo, la tarea de análisis derequisitos produce un modelo de análisisque se revisa para encontrar y corregirerrores. Si no se encuentran errorespasan al diseño.
95
Cuando se aplica en este contexto laEED se redefine como:
EEDi = Ei/(Ei+Di+1)
Ei es el número de errores encontradosEi 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
96
Integración de las métricas dentro del proceso de SwIntegración de las métricas dentro del proceso de Sw
La mayoría de los desarrolladores desoftware todavía no miden y,lamentablemente, muchos tienenpoco deseo de comenzar.poco deseo de comenzar.
El problema es cultural !!!El problema es cultural !!!
97
Si no se mide, no existe una forma realde determinar si se está mejorando. Y sino se mejora, se está perdido.Si se emplea la medición para establecer
Argumentos para las métricas del softwareArgumentos para las métricas del software
Si se emplea la medición para estableceruna línea base del proyecto, cada uno delos temas: desarrollar estimaciones deproyecto significativas, producirsistemas de calidad, tener el producto atiempo, se vuelven más manejables.
98
Los datos de la línea base deben tenerlos siguientes atributos:
Los datos deben ser razonablementeprecisos;
Establecimiento de una línea baseEstablecimiento de una línea base
precisos;Los datos deben recopilarse paratantos proyectos como sea posible;Las medidas deben ser consistentes;Las aplicaciones deben ser similaresal trabajo que se estimará.
99
La recopilación de datos requiere unainvestigación histórica de los proyectosprevios para reconstruir los datosrequeridos
Recopilación, cálculo y evaluación de métricasRecopilació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
indicadores100