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