CICLO DE VIDA EN EL DESARROLLO SOFTWARE METODOLOGIAS APLICADAS A METRICAS

NSTOR MIGUEL RICO RICO OSCAR JAVIER VELANDIA FAJARDO

FUNDACIN UNIVERSITARIA PANAMERICANA FACULTAD DE INGENIERA TECNOLOGO EN ANALISIS Y DISEO DE SISTEMAS DE INFORMACION BOGOTA D.C.

CICLO DE VIDA EN EL DESARROLLO SOFTWARE METODOLOGIAS APLICADAS A METRICAS

NSTOR MIGUEL RICO RICO Cd. 80227556 OSCAR JAVIER VELANDIA FAJARDO Cd. 80239047

FUNDACIN UNIVERSITARIA PANAMERICANA FACULTAD DE INGENIERA INGENIERA DE SOFTWARE TECNOLOGO EN ANALISIS Y DISEO DE SISTEMAS DE INFORMACION BOGOTA D.C. MAYO DE 2013

CICLO DE VIDA EN EL DESARROLLO DEL SOFTWARE Es la forma mediante la cual se describen los diferentes pasos que se deben seguir para el desarrollo de un software, partiendo desde una necesidad hasta llegar a la puesta en marcha de una solucin y su apropiado mantenimiento. El ciclo de vida para un software comienza cuando se tiene la necesidad de resolver un problema, y termina cuando el programa que se desarroll para cumplir con los requerimientos, cubre dicha necesidad. La gestin de la calidad del software acta sobre 4 pilares que componen el proceso de desarrollo de software: Procesos de ciclo de vida tcnicas (cmo?) organizacin (quin?) - se basa en las personas, en su formacin o especializacin, y en cmo se organizan para desarrollar un proyecto. infraestructura (con qu?) - La infraestructura, por su parte, son las instalaciones, equipamiento, servidores, medios de comunicacin, de los que se dispone para el desarrollo de software. PROCESOS DEL CICLO DE VIDA SOFTWARE BASADOS EN ESTANDARES DE CALIDAD El ciclo de vida de un software es el perodo de tiempo que comienza con la concepcin de la idea de un software y que termina con la vida til del mismo. Durante este perodo de tiempo cooperan un conjunto de procesos interrelacionados, denominados procesos del ciclo de vida, con el objetivo de construir un producto de software de calidad.

Los modelos y estndares internacionales como ISO 12207, IEEE 1074 y CMMI identifican procesos que componen el ciclo de vida de un software. Tomando como base estos estndares, a continuacin se identifican las siguientes reas de procesos: PROCESOS PRINCIPALES Anlisis de requerimientos: Es el proceso de captura de requisitos, su especificacin en un formato, el uso de prcticas de comunicacin (prototipos, entrevistas) para identificar puntualmente lo que quiere el cliente, la revisin peridica de la consistencia entre requisitos y otros contenidos del desarrollo (diseo, cdigo, manual de usuarios), y la gestin de cambios en los requisitos durante todo el proyecto. Una gestin insuficiente de requisitos es una de las causas ms frecuentes de que los proyectos se retrasen, sobrepasen sus presupuestos o tengan menos funcionalidad de la esperada. El xito en la gestin de requisitos depende del conocimiento y la aplicacin apropiada de diferentes fundamentos, por ejemplo, metodologas de anlisis de requisitos, modelos de representacin, prcticas de comunicacin, metodologa de gestin de cambios en los requisitos, tcnicas de verificacin y validacin de la completitud y correccin de los requisitos y de su consistencia con otros productos del software. Una gestin

correcta y completa de requisitos debe permitir su uso como base para estimar, planificar, disear, implementar y verificar y validar el software Diseo: Es el proceso de definicin de la arquitectura del sistema, de las estructuras de datos y de los algoritmos a emplear, antes de realizar la construccin del software. Algunos fundamentos que garantizan diseos robustos son el conocimiento de estilos estructurados y conceptos bsicos de diseo, algoritmos y estructuras de datos primarias, esquemas tpicos de arquitecturas, herramientas de diseo, entre otros. Los ciclos de vida modernos de software prestan especial atencin al diseo de arquitectura, cuya solucin suele ser una tarea prioritaria. Organizaciones preocupadas por la calidad de su proceso de software documentan soluciones genricas de diseo en funcin del dominio de aplicacin a resolver, e incluyen experiencias previas de la aplicacin de estas soluciones. Implementacin: Cuando se llega a la implementacin dentro de un proceso correcto de software, la mayora del trabajo creativo ya ha sido realizado. En este sentido, la implementacin se considera una tarea de bajo nivel. Es decir, prcticas pobres de diseo pueden forzar la reescritura de gran parte del sistema, no siendo necesariamente as en el caso de usar prcticas pobres de codificacin. Sin embargo, estas malas prcticas pueden provocar errores sutiles cuya deteccin y correccin puede costar das o semanas. Por lo tanto, una organizacin que haga de la calidad una prioridad no debe desconocer ciertos fundamentos de construccin del software, por ejemplo, prcticas correctas y uniformes de codificacin, directrices para el uso de tipos de datos, reglas para empaquetar cdigo en mdulos, clases o ficheros, prcticas de testeo de unidad y de depuracin, estrategias de integracin, etc. La estandarizacin de las prcticas de implementacin de un software simplifican notablemente los esfuerzos de trabajo en grupo, en especial, aquellos orientados al mantenimiento del propio software o al "re uso" de cdigo en futuros proyectos por personas diferentes. Validacin y verificacin: Como proceso de validacin y de verificacin se entiende cualquier actividad orientada a determinar si los objetivos se han cumplido o no. Ms especficamente: Verificacin comprueba la consistencia del software con respecto a especificaciones y requisitos. Validacin comprueba si lo que se ha especificado e implementado es lo que el usuario realmente desea. Las tareas de validar y verificar no solo se aplican a productos de software, sino tambin a otros productos resultantes del proceso del desarrollo. Las primeras tareas para validar y verificar en el anlisis y la especificacin de requisitos, por ejemplo, pueden ser comprobar que el proyecto sea viable, que las especificaciones documentadas son completas, correctas, precisas, legibles, evaluables, y que, en general, responden a las expectativas del cliente. La validacin y verificacin del diseo debe garantizar que los requisitos no estn incompletos o incorrectamente diseados. En el caso de la implementacin y codificacin, la validacin y verificacin de software es comnmente conocida como testeo de software. Por lo tanto, se realiza test al software para detectar errores que, una vez corregidos, mejoran la calidad o fiabilidad del mismo. Existen distintos tipos de testeo en funcin de la unidad de software a la que se aplique y del objetivo que se persigue, por ejemplo, el testeo de unidad, de integracin, de sistema y de aceptacin. Finalmente, las actividades de validar y verificar son tambin necesarias durante la operacin y el mantenimiento del software, cuando se realiza un cambio en el software, se debe examinar el impacto del cambio sobre el sistema y considerar qu actividades son necesarias repetir para garantizar, al menos, la misma calidad en el software antes del cambio. Mantenimiento: De acuerdo a IEEE 1219, el mantenimiento de software es el conjunto de actividades de modificacin de un producto de software despus de entregado, para corregir fallos, mejorar su rendimiento u otros atributos, o adaptar el producto a un entorno modificado. Una vez comienzan a operar con el sistema, los usuarios pueden encontrar errores y aspectos que quieran mejorar, los mantenedores realizan los cambios, despus de lo cual los usuarios vuelven a usarlos y a proporcionar nueva informacin de mejora. Este ciclo de mantenimiento extiende la vida del producto de software. En muchos casos, el mantenimiento es el proceso ms largo del ciclo de vida. El mantenimiento de software es difcil de realizar y gestionar. Sin embargo, este proceso se simplifica notablemente si los procesos primarios previos de ingeniera han sido correctamente realizados y documentados.

PROCESOS GESTION Estimacin: El proceso de estimacin puede definirse a partir de tres pasos bsicos: Estimar el tamao del proyecto a partir de un anlisis preliminar de requisitos.

Estimar el esfuerzo total (en unidades de tiempo) que requiere el desarrollo de un proyecto de tal tamao. Estimar el tiempo de desarrollo del proyecto en funcin del esfuerzo estimado y del personal con el que se cuente para su realizacin. La diferencia entre un procedimiento de calidad y otro improvisado es que el primero define metodologas para hacer estimaciones objetivas y contrastadas dando lugar a estimaciones precisas, mientras que en el segundo las estimaciones son resultados de anlisis subjetivos y no contrastados conduciendo a resultados vagos, casi siempre, muy optimistas. Planificacin: La planificacin consta de dos partes: La divisin del proyecto en tareas La asignacin de recursos a tareas Es decir, ordenar las tareas en el tiempo, asignndoles recursos humanos y materiales para su realizacin. El tiempo asignado a una tarea depende de mltiples factores: tamao y complejidad de la tarea (productos de la estimacin), grado de conocimiento o de incertidumbre que tenemos sobre ella (anlisis de riesgos), y de la preparacin y experiencia del personal que debe realizarla. En proyectos con riesgos importantes, el tiempo de desarrollo no suele ser cerrado, sino en forma de rango dependiendo de los riesgos presentes. Su posible presentacin a clientes debe acompaarse de un documento que relacione incertidumbres con el rango. Estos proyectos deben ser peridicamente re-estimados y su planificacin refinada, tareas que deben ser tambin planificadas. Es recomendable dentro de un procedimiento de calidad la existencia de una metodologa con directrices para realizar planes de desarrollo, relacionada con las metodologas de elaboracin de estimaciones y de gestin de riesgos Medicin: Una de las claves del progreso a largo plazo de una organizacin de software es la medicin de datos para analizar la calidad del software y la productividad. Aparte de las tpicas mediciones sobre costos y tiempos en proyectos, recolectar datos histricos sobre cun largo es un programa (en lneas de cdigo) o un anlisis de requisitos (en nmero y complejidad de requisitos), nos crear bases objetivas para realizar futuras estimaciones en nuevos proyectos que suelen ser generalmente mejores que el instinto puro. Procesos ms sofisticados colectan mediciones sobre los cambios (errores, mejoras o nuevos requisitos) entre sucesivas versiones, por ejemplo, del documento de anlisis de requisitos o de cualquier producto de software. Estas mediciones sobre el nmero y naturaleza de los cambios permiten conocer ms objetivamente el nivel de estabilidad o madurez del producto objeto de medicin, el grado de flexibilidad ante cambios, entre otras caractersticas. El procedimiento de calidad de desarrollo de software de una organizacin, debe definir qu mediciones realizar, con qu objetivo y periodicidad, y cmo van a ser colectadas. Es usual disponer de un software que soporte la recoleccin automtica o semiautomtica de estas mediciones, y su uso de acuerdo a los fines para los que han sido definidas Control y seguimiento: Las actividades de control y seguimiento consisten en verificar que el progreso del proyecto se ajusta al plan y a los estndares, es decir, que se estn cumpliendo los plazos, costos, y los objetivos de calidad. En otras palabras, el control y seguimiento es un conjunto de actividades de validacin y verificacin del proceso de desarrollo. Idealmente, estas actividades deben aportar absoluta visibilidad del progreso del desarrollo. Algunas de estas actividades son revisiones y auditoras tcnicas, revisiones de hitos, reportes de estado, realizar mediciones (tiempo, presupuesto) y comparar con estimados, etc. Las tareas de control y seguimiento deben ser tambin planificadas. Sin ellas no es posible gestionar un proyecto ni sus riesgos, y no hay forma de saber si los planes se estn cumpliendo o no. Un control efectivo permite detectar anticipadamente problemas en el cronograma, cuando an hay tiempo suficiente para actuar sobre l. Gestin de riesgos: Usualmente, cuando realizamos el anlisis de un proyecto, aparecen incertidumbres sobre su comprensin, sobre el mtodo de solucin, sobre las herramientas de solucin, entre otras. De no atender prioritariamente estos aspectos inciertos, conocidos formalmente como riesgos, se convertirn en fuentes potenciales de errores en nuestro proceso. Una de las lneas esenciales de la gestin moderna de software es la gestin dinmica de riesgos. Este proceso peridico consiste en identificar y analizar cada riesgo, estimar su probabilidad de ocurrencia y su posible impacto en el cronograma, y definir un plan de gestin del mismo, el cual es un grupo de acciones orientadas a prevenir el riesgo o a corregir sus consecuencias, en funcin del proceso que resulte menos costoso. Una gestin global incluye adems el mantenimiento de listas actualizadas de riesgos ordenados por peligrosidad, de forma que nos sea posible centrarnos en aquellas incertidumbres potencialmente ms destructivas. Un procedimiento de calidad para el desarrollo de software debe incluir una metodologa de gestin de riesgos, as como un registro de riesgos y errores frecuentes en la organizacin que ayuden a evitar omisiones importantes.

Relaciones con clientes: El conocimiento y aplicacin de buenas prcticas en las relaciones con clientes producen beneficios directos para el desarrollo de un software. Buenas relaciones con los clientes disminuyen el tiempo real y percibido de desarrollo, pues eliminan fuentes importantes de errores y riesgos para el proyecto, y propician una cooperacin ms activa y comprometida por parte de clientes y usuarios. Estas prcticas se extienden por mltiples reas de la ingeniera y la gestin, por ejemplo, definir y gestionar riesgos asociados con los clientes, emplear prcticas activas de comunicacin para ayudar a clientes a comprender lo que quieren, involucrar a clientes y usuarios en actividades de control del progreso del proyecto, emplear modelos incrementales de ciclos de vida que proporcionen al cliente seales peridicas y tangibles de progreso, entre otras. Como en los casos anteriores, la organizacin debe documentar la poltica de gestin de las relaciones con clientes

PROCESOS DE ASEGURAMIENTO DE LA CALIDAD Prevencin: Los estndares son uno de los medios ms efectivos para garantizar la calidad del software. Prcticamente para cada producto a elaborar (manual de usuario, interfaz, cdigo, anlisis de requisitos, etc.) o proceso a realizar (anlisis de riesgos, diseo, planificacin, etc.) deben existir estndares o normas organizacionales que definan directrices sobre cmo hacerlo. Los estndares tienen dos beneficios principales: Evitan improvisaciones, olvidos y errores al definir qu hacer y cmo hacerlo Proponen una manera uniforme de hacer que facilitan comparaciones entre proyectos y colaboraciones entre equipos de trabajo diferentes. Otro grupo de tcnicas orientado a prevenir errores y omisiones es el de mtodos formales, que hace referencia a una variedad de tcnicas de modelacin matemticas aplicables al diseo de sistemas informticos. Los mtodos formales pueden ser usados para especificar y modelar el comportamiento de un sistema y para verificar matemticamente que el diseo y la implementacin del sistema satisfacen sus especificaciones. Estas tcnicas pueden ser aplicadas prcticamente a todos los niveles del ciclo de vida del software, por ejemplo, un lenguaje de especificaciones formales para escribir requisitos (VDM, OCL), proceso de transformacin de requisitos en cdigo ejecutable que garantice que el cdigo satisface las propiedades especificadas, probar las propiedades de las especificaciones a travs de tcnicas automticas como verificacin de modelos y prueba de teoremas, formalismos para derivar casos de pruebas a partir de las especificaciones de software, entre otras. Los mtodos formales no son una estrategia de todo o nada. Aplicar mtodos formales solo a las partes ms crticas de un sistema es una estrategia til y muy efectiva. La verificacin formal completa debe aplicarse nicamente en sistemas crticos que requieran la mxima fiabilidad. Deteccin y correccin: La prctica ms conocida de deteccin de errores es el testeo de software. Aparte de ser un proceso primario de ingeniera (Verificacin y Validacin) para asegurar que las especificaciones y necesidades del usuario final se satisfacen, el testeo de software tambin pertenece a las actividades de deteccin de la gestin de la calidad pues ellas pueden detectar fallos de calidad. Las actividades de testeo pueden clasificarse en estticas o dinmicas. Las tcnicas de testeo esttico detectan errores sin ejecutar el programa, por ejemplo, inspecciones o recorridos de cdigo son tcnicas que consisten en detectar errores a travs de la lectura de cdigo. El testeo dinmico, por su parte, implica la ejecucin de programas. A su vez, las tcnicas dinmicas pueden subdividirse en dos estrategias generales: Testeo de comportamiento (caja negra, basado en datos, entrada/salida, basado en requisitos), en la que el tester es completamente ajeno al cdigo fuente del programa, y est nicamente interesado en casos en los que el programa no se comporta como se espera. Testeo estructurado (caja blanca, basado en lgica, basado en cdigo,) en la que el tester examina la estructura interna del programa con el objetivo de derivar casos de test. La derivacin de casos de test es, independiente de la estrategia de testeo utilizada, su parte ms importante y difcil. Existen mltiples tcnicas para este fi n que varan desde la aplicacin informal de heursticas simples (testeo segn la experiencia, testeo de ciclo de datos, testeo de combinacin de datos) hasta la derivacin formal utilizando modelos como grafos de flujo de datos o de control Evolucin y mejora: La mejora de procesos de software (SPI, de Software Process Improvement) se orienta a reducir costos y riesgos de los procesos, acortar el tiempo del proceso de desarrollo, y a incrementar la calidad del producto. Existen mltiples mtodos, y tcnicas que pueden ser usadas para determinar la efectividad de un proceso y para definir las correspondientes acciones de mejora. Estos modelos se dividen en dos estrategias principales: enfoque top-down, por ejemplo, CMMI, SPICE y BOOTSTRAP, que se basan fundamentalmente en evaluacin y en

modelos, y enfoque bottom-up, por ejemplo, GQM, QIP y AMI, los cuales aplican fundamentalmente mediciones como guas bsicas de mejora. Los modelos de madurez de proceso de desarrollo de software, como los antes mencionados, no han tratado adecuadamente el proceso de testeo. Qu es exactamente un proceso maduro de testeo? Cmo se debe organizar y poner en marcha la mejora de un proceso de testeo? Cmo se debe incorporar a la organizacin de una empresa? Para responder a estas preguntas existen modelos especializados para medir la madurez y mejorar el proceso de testeo, por ejemplo, TIM (Test Improvement Model), TOM (Test Organisation Maturity Model), TPI (Test Process Improvement Model) y TMM (Testing Maturity Model). ETAPAS DEL CICLO DE VIDA DEL SOFTWARE El ciclo de vida clsico del software siendo uno de los ms utilizados, est conformado en su versin ampliada por siete etapas que se pueden representar mediante un modelo en cascada

INGENIERA DE SISTEMAS: En esta etapa el analista luego de un minucioso y detallado estudio de los sistemas de una organizacin, detecta un problema o una necesidad que para su solucin y/o satisfaccin es necesario realizar un desarrollo de software. ANLISIS: En esta etapa se debe entender y comprender de forma detallada cual es la problemtica a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal manera que se obtenga la informacin necesaria y suficiente para afrontar su respectiva solucin. Esta etapa es conocida como la del QU se va a solucionar. DISEO: Una vez que se tiene la suficiente informacin del problema a solucionar, es importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es conocida bajo el CMO se va a solucionar. IMPLEMENTACIN: partiendo del anlisis y diseo de la solucin, en esta etapa se procede a desarrollar el correspondiente programa que solucione el problema mediante el uso de una herramienta computacional determinada. PRUEBAS: Los errores humanos dentro de la programacin de los computadores son muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor nmero de situaciones posibles a las que se pueda enfrentar. DOCUMENTACIN: Es la gua o comunicacin escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa. La importancia de la documentacin radica en que a menudo un programa escrito por una persona, es modificado por otra. Por ello la documentacin sirve para ayudar a comprender o usar un programa o para facilitar futuras modificaciones (mantenimiento). La documentacin se compone de tres partes:

Documentacin Interna: Son los comentarios o mensajes que se aaden al cdigo fuente para hacer ms claro el entendimiento de los procesos que lo conforman, incluyendo las precondiciones y las poscondiciones de cada funcin. Documentacin Externa: Se define en un documento escrito con los siguientes puntos: Descripcin del Problema Datos del Autor Algoritmo (diagrama de flujo o Pseudocdigo) Diccionario de Datos Cdigo Fuente (programa)

Manual de Usuario: Describe paso a paso la manera cmo funciona el programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.

MANTENIMIENTO: una vez instalado un programa y puesto en marcha para realizar la solucin del problema previamente planteado o satisfacer una determinada necesidad, es importante mantener una estructura de actualizacin, verificacin y validacin que permitan a dicho programa ser til y mantenerse actualizado segn las necesidades o requerimientos planteados durante su vida til. Para realizar un adecuado mantenimiento, es necesario contar con una buena documentacin del mismo.

METODOLOGIAS APLICADAS A METRICAS El objetivo primordial de la ingeniera del software es producir un sistema, aplicacin o producto de alta calidad. Para lograr este objetivo, los ingenieros de software deben emplear mtodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software. Al mismo tiempo, un buen ingeniero del software y buenos administradores de la ingeniera del software deben medir si la alta calidad se va a llevar a cabo. A continuacin se ver un conjunto de mtricas del software que pueden emplearse a la valoracin cuantitativa de la calidad de software Medida de la calidad Aunque hay muchas medidas de la calidad de software, la correccin, facilidad de mantenimiento, integridad y facilidad de uso suministran indicadores tiles para el equipo del proyecto. Gilb *Len O. Ejiogo 90+ sugiere definiciones y medidas para cada uno de ellos, tales como: Correccin: A un programa le corresponde operar correctamente o suministrar poco valor a sus usuarios. La correccin es el grado en el que el software lleva a cabo una funcin requerida. La medida ms comn de correccin son los defectos por KLDC, en donde un defecto se define como una falla verificada de conformidad con los requisitos. Facilidad de mantenimiento. El mantenimiento del software cuenta con ms esfuerzo que cualquier otra actividad de ingeniera del software. La facilidad de mantenimiento es la habilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar si su entorno cambia o optimizar si el cliente desea un cambio de requisitos. No hay forma de medir directamente la facilidad de mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una mtrica orientada al tiempo simple es el tiempo medio de cambio (TMC), es decir, el tiempo que se tarda en analizar la peticin de cambio, en disear una modificacin apropiada, en efectuar el cambio, en probarlo y en distribuir el cambio a todos los usuarios. En promedio, los programas que son ms fciles de mantener tendrn un TMC ms bajo (para tipos equivalentes de cambios) que los programas que son ms difciles de mantener. Integridad. En esta poca de intrusos informticos y de virus, la integridad del software ha llegado a tener mucha importancia. Este atributo mide la habilidad de un sistema para soportar ataques (tanto accidentales como intencionados) contra su seguridad. El ataque se puede ejecutar en cualquiera de los tres componentes del software, ya sea en los programas, datos o documentos. Para medir la integridad, se tienen que definir dos atributos adicionales: La amenaza es la probabilidad (que se logra evaluar o concluir de la evidencia emprica) de que un ataque de un tipo establecido ocurra en un tiempo establecido. La seguridad es la probabilidad (que se puede estimar o deducir de la evidencia emprica) de que se pueda repeler el ataque de un tipo establecido, en donde la integridad del sistema se puede especificar cmo y donde se suman la amenaza y la seguridad para cada tipo de ataque: integridad = [1- amenaza x (1- seguridad)]

Facilidad de uso. El calificativo amigable con el usuario se ha transformado universalmente en disputas sobre productos de software. Si un programa no es amigable con el usuario, prcticamente est prximo al fracaso, incluso aunque las funciones que realice sean valiosas. La facilidad de uso es un intento de cuantificar lo amigable que pude ser con el usuario y se consigue medir en funcin de cuatro caractersticas: 1. Destreza intelectual y/o fsica solicitada para aprender el sistema 2. El tiempo requerido para alcanzar a ser moderadamente eficiente en el uso del sistema 3. Aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida cuando alguien emplea el sistema moderadamente y eficientemente 4. Valoracin subjetiva (a veces obtenida mediante un cuestionario) de la disposicin de los usuarios hacia el sistema. Los cuatro factores anteriores son slo un ejemplo de todos los que se han propuesto como medidas de la calidad del software.

Medidas de fiabilidad y de disponibilidad Todos los fallos del software, se producen por problemas de diseo o de implementacin. Considerando un sistema basado en computadora, una medida sencilla de la fiabilidad es el tiempo medio entre fallos (TMEF) [Mayrhauser91], donde: TMEF = TMDF+TMDR (TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparacin)) Como cada error de un programa no tiene la misma tasa de fallo, la cuenta total de errores no es una buena indicacin de la fiabilidad de un sistema. Disponibilidad. La disponibilidad del software es la probabilidad de que un programa funcione de acuerdo con los requisitos en un momento dado, y se define como: Disponibilidad = TMDF/(TMDF + TMDR) x 100 %

Eficacia de la Eliminacin de Defectos Una mtrica de la calidad que proporciona beneficios tanto a nivel del proyecto como del proceso, es la eficacia de la eliminacin de defectos (EED) En particular la EED es una medida de la habilidad de filtrar las actividades de la garanta de calidad y de control al aplicarse a todas las actividades del marco de trabajo del proceso. Cuando se toma en consideracin globalmente para un proyecto, EED se define de la forma siguiente: EED = E / (E + D) E= es el nmero de errores encontrados antes de la entrega del software al usuario final D= es el nmero de defectos encontrados despus de la entrega.

El valor ideal de EED es 1, donde simbolizando que no se han encontrado defectos en el software. De forma realista, D ser mayor que cero, pero el valor de EED todava se puede aproximar a 1 cuando E aumenta. En consecuencia cuando E aumenta es probable que el valor final de D disminuya (los errores se filtran antes de que se conviertan en defectos) Si se utiliza como una mtrica que suministra un indicador de la destreza de filtrar las actividades de la garanta de la calidad y el control, el EED alienta a que el equipo del proyecto de software instituya tcnicas para encontrar los errores posibles antes de su entrega. Del mismo modo el EED se puede manipular dentro del proyecto, para evaluar la habilidad de un equipo en encontrar errores antes de que pasen a la siguiente actividad, estructura o tarea de ingeniera del software. Por ejemplo, la tarea de anlisis de requerimientos produce un modelo de anlisis qu se puede inspeccionar para encontrar y corregir errores. Esos errores que no se encuentren durante la revisin del modelo de anlisis se pasan a la tareas de diseo (en donde se puede encontrar o no) Cuando se utilizan en este contexto, el EED se vuelve a definir como: EED = Ei / ( Ei + Ei+1) Ei = es el nmero de errores encontrados durante la actividad iesima de: ingeniera del software i

Ei + 1 es el nmero de errores encontrados durante la actividad de ingeniera del software (i + 1) que se puede seguir para llegar a errores que no se detectaron en la actividad i.

Un objetivo de calidad de un equipo de ingeniera de software es alcanzar un EED que se aproxime a 1, esto es, los errores se deberan filtrar antes de pasarse a la actividad siguiente. Esto tambin puede ser utilizado dentro del proyecto para evaluar la habilidad de un equipo, esto con el objetivo de encontrar deficiencias que harn que se atrase el proyecto. Factores de Calidad de McCall Los factores que perturban la calidad del software se pueden categorizar en dos grandes grupos: factores que se pueden medir directamente (por ejemplo: defectos por puntos de funcin) y factores que se pueden medir slo indirectamente (por ejemplo: facilidad de uso o de mantenimiento). McCall y sus colegas plantearon una categorizacin de factores que afectan a la calidad de software, en donde se centralizan con tres aspectos importantes de un producto de software: Sus caractersticas operativas Su capacidad de cambio Su adaptabilidad a nuevos entornos.

Correccin: Hasta dnde satisface un programa su especificacin y consigue los objetivos de la misin del cliente. Fiabilidad: Hasta dnde puede quedarse un programa que lleve a cabo su funcin pretendida con la exactitud solicitada. Eficiencia: El conjunto de recursos informticos y de cdigo necesarios para que un programa realice su funcin. Integridad: Hasta dnde se puede controlar el acceso al software o a los datos por individuos no autorizados Usabilidad (facilidad de manejo): El esfuerzo necesario para aprender, operar, y preparar datos de entrada e interpretar las salida (resultados) de un programa. Facilidad de mantenimiento: El esfuerzo necesario para localizar y arreglar un error en un programa. Flexibilidad: El esfuerzo necesario para modificar un programa operativo. Facilidad de prueba: El esfuerzo necesario para aprobar un programa para asegurarse de que realiza su funcin pretendida. Portabilidad: El esfuerzo necesario para trasladar el programa de un entorno de sistema hardware y/o software a otro. Reusabilidad: (capacidad de reutilizacin): Hasta dnde se puede volver a utilizar un programa (o partes) en otras aplicaciones con relacin al empaquetamiento y alcance de las funciones que ejecuta el programa.

Interoperatividad: El esfuerzo necesario para acoplar un sistema con otro. Es difcil y en algunos casos improbable, desarrollar medidas directas de los factores de calidad anteriores. Es por eso, que se definen y emplean un conjunto de mtricas para desarrollar expresiones para todos los factores de acuerdo con la siguiente relacin: Fq = c1 * m1 + c2 * m2 + + cn * mn Fq es un factor de calidad del software cn son coeficientes de regresin mn son las mtricas que afectan al factor de calidad.

Lo malo es que las mtricas definidas por McCall slo pueden medirse de manera subjetiva. Mtricas basadas en la funcin La mtrica de punto de funcin (PF) se puede usar como medio para predecir el tamao de un sistema que se va a obtener de un modelo de anlisis. Para instruir el empleo de la mtrica PF, se considerar una sencilla representacin del modelo de anlisis mostrada por Pressman. En donde se representa un diagrama de flujo de datos, de una funcin de una aplicacin de software llamada Hogar Seguro. La funcin administra la interaccin con el usurario, aceptando una contrasea de usuario para activar/ desactivar el sistema y permitiendo consultas sobre el estado de las zonas de seguridad y varios censores de seguridad. La funcin muestra una serie de mensajes de peticin y enva seales apropiadas de control a varios componentes del sistema de seguridad. El diagrama de flujo de datos se evala para determinar las medidas clave necesarias para el clculo de la mtrica de PF.: nmero de entradas de usuario nmero de salidas de usuario nmero de consultas del usuario nmero de archivos nmero de interfaces externas

Hay tres entradas del usuario: contrasea, interruptor de emergencias y activar/desactivar aparecen en la figura con dos consultas: consulta de zona y consulta de sensor. Se muestra un archivo (archivo de configuracin del sistema) Tambin estn presentes dos salidas de usuarios(mensajes y estado del sensor) y cuatro interfaces externas (sensor de prueba, configuracin de zona, activar/desactivar y alerta de alarma).

La cuenta total mostrada en la figura debe ajustarse usando la ecuacin: PF = cuenta-total * (0.65 + 0.01 * Fi) Donde cuenta - total es la suma de todas las entradas PF obtenidas y Fi( i=1 a 14) son valores de ajuste de complejidad. Para el propsito de este ejemplo, asumimos que Fi es 46 (un producto moderadamente complejo) Por lo tanto: PF = 50* [0.65+(0.01*46)]=56 Basndose en el valor previsto de PF obtenido del modelo de anlisis, el equipo del proyecto puede estimar el tamao global de implementacin de las funciones de Hogar Seguro. Asuma que los datos de los que se disponen indican que un PF supone 60 lneas de cdigo (si se usa un lenguaje orientado a objetos) y que en un esfuerzo de un mes- persona se producen 12 PF. Estos datos histricos proporciona al administrador del proyecto una importante informacin de planificacin basada en el modelo de anlisis en lugar de en estimaciones preliminares. La mtrica Bang Puede emplearse para desarrollar una indicacin del tamao del software a implementar como consecuencia del modelo de anlisis. Desarrollada por Tom DeMarco *Ejiogo 91+, la mtrica bang es una indicacin, independiente de la implementacin, del tamao del sistema *Ejiogo 91+. Para calcular la mtrica bang, el desarrollador de software debe evaluar primero un conjunto de primitivas (elementos del modelo de anlisis que no se subdividen ms en el nivel de anlisis) Las primitivas se determinan evaluando el modelo de anlisis y desarrollando cuentas para los siguientes elementos: Primitivas funcionales (Pfu) Transformaciones (burbujas) que aparecen en el nivel inferior de un diagrama de flujo de datos. Elementos de datos (ED) Los atributos de un objeto de datos, los elementos de datos no compuestos y aparecen en el diccionario de datos. Objetos (OB) Objetos de datos. Relaciones (RE) Las conexiones entre objetos de datos. Transiciones (TR) El nmero de transacciones de estado en el diagrama de transicin de estado. Adems de las seis primitivas nombradas arriba, se determinan medidas adicionales para: Primitivas modificadas de funcin manual (PMFu) Funciones que caen fuera del lmite del sistema y que deben modificarse para acomodarse al nuevo sistema. Elementos de datos de entrada (EDE) Aquellos elementos de datos que se introducen en el sistema. Elementos de datos de salida (EDS) Aquellos elementos de datos que se sacan en el sistema. Elementos de datos retenidos (EDR) Aquellos elementos de datos que son retenidos (almacenados) por el sistema.

Muestras (tokens) de datos (TCi) Las muestras de datos (elementos de datos que no se subdividen dentro de una primitiva funcional) que existen en el limite de la i-sima primitiva funcional (evaluada para cada primitiva). Conexiones de relacin (Rei) Las relaciones que conectan el i-simo objeto en el modelo de datos con otros objetos. DeMarco *Ejiogo 91+ sugiere que la mayora del software se pu ede asignar a uno de los dos dominios siguientes, dominio de funcin o dominio de datos, dependiendo de la relacin RE/PFu. Las aplicaciones de dominio de funcin (encontrados comnmente en aplicaciones de ingeniera y cientficas) hacen hincapi en la transformacin de datos y no poseen generalmente estructuras de datos complejas. Las aplicaciones de dominio de datos (encontradas comnmente en aplicaciones de sistemas de informacin) tienden a tener modelos de datos complejos *Ejiogo 91+. Si RE / Pfu < 0,7 implica una aplicacin de dominio de funcin Si 0,8 < RE / Pfu < 1,4 implica una aplicacin hbrida Si RE / Pfu > 1,5 implica una aplicacin de dominio de datos. Como diferentes modelos de anlisis harn una participacin del modelo con mayor o menor grado de refinamiento, DeMarco sugiere que se emplee una cuenta medida de muestras (token) por primitiva para controlar la uniformidad de la participacin a travs de muchos diferentes modelos dentro del dominio de una aplicacin *Ejiogo 91+. TCavg = TCi/Pfu Una vez que se ha calculado la mtrica bang , se puede emplear el historial anterior para asociarla con el esfuerzo y el tamao. DeMarco sugiere que las organizaciones se construyan sus propias versiones de tablas IPFuC y IOBC para calibrar la informacin de proyectos completos de software. MODELOS SISTEMATICOS DE CALIDAD La definicin de calidad sistmica en el desarrollo de los sistemas de informacin consta de cuatro tipos de cualidades, considerando las dimensiones del cliente y del usuario: Eficiencia del producto Efectividad del producto Eficiencia del proceso Efectividad del proceso

Esta divisin se justifica en un sentido, porque un proyecto incluye tanto la eficiencia como la efectividad y en el otro, porque el sistema concebido (el producto) es diferente al sistema de las actividades humanas (el proceso) mediante el cual el sistema - producto es diseado. La calidad global no es la suma de las calidades parciales, sino el compromiso entre todo el conjunto de calidades que conlleve a un ptimo global con cierto sacrificio de los ptimos parciales. MODELO SISTMICO DE CALIDAD (MOSCA) Es un modelo que integra modelos de calidad de producto y proceso. Fundamentalmente, la calidad del proceso garantiza la calidad del producto y consecuentemente no se pueden desligar estas dos calidades; tener modelos separados capaces de medir individualmente la calidad de un producto o de un proceso de software no garantiza la relacin sistmica que debe estar presente entre ellos. Esto se debe a que la naturaleza de los sistemas no puede ser divida en partes, sino que debe existir una interdependencia y colaboracin entre las partes (proceso y producto) para que el mismo sea visto como un todo. La estructura de MOSCA consta de 4 niveles los cuales son explicados brevemente a continuacin:

Nivel 0: Dimensiones. las cuatro dimensiones propuestas en el prototipo de modelo, slo un balance y una buena interrelacin entre ellas garantizan la calidad Sistmica global de una organizacin Eficiencia del proceso Efectividad del proceso Eficiencia del producto Efectividad del producto

Nivel 1: Categoras. Se contemplan 11 categoras: Del Producto: Funcionalidad (FUN): Capacidad del producto del software para proveer funciones que cumplan con necesidades especficas o implcitas, cuando el software es utilizado bajo ciertas condiciones Fiabilidad (FIA): Capacidad del producto de software para mantener un nivel especificado de rendimiento cuando es utilizado bajo condiciones especificadas Usabilidad (USA): Capacidad del producto de software para ser atractivo, entendido, aprendido y utilizado por el usuario bajo condiciones especficas Eficiencia (EFI): Capacidad del producto de software para proveer un rendimiento apropiado, relativo a la cantidad de recursos utilizados, bajo condiciones especficas Mantenibilidad (MAB): Capacidad del producto para ser modificado. Portabilidad (POR): Capacidad del producto de software para ser transferido de un ambiente a otro Del Proceso: Cliente-Proveedor (CUS): Est conformada por procesos que impactan directamente al cliente, apoya el desarrollo y la transicin del Software hasta el cliente, y provee la correcta operacin y uso del producto o servicio de software. Ingeniera (ENG): Consiste en procesos que directamente especifican, implementan o mantienen el producto de software, su relacin con el Sistema y su documentacin Soporte (SUP): Consta de procesos que pueden ser empleados por cualquiera de los procesos (incluyendo a los de soporte) en varios niveles del ciclo de vida de adquisicin. Gestin (MAN): Abarca los procesos que contienen prcticas genricas, que pueden ser utilizadas por cualquier personal que dirija algn tipo de proyecto o proceso Organizacional (ORG): Agrupa los procesos que establecen las metas con (valores) de proceso, producto y recurso, que ayudarn a la organizacin a alcanzar sus metas en los proyectos

Esta divisin no implica un desligamiento entre ellas, simplemente se realiza para identificar a que sector o sub modelo pertenecen. Nivel 2: Caractersticas. Cada categora tiene asociado un conjunto de caractersticas (56 asociadas al producto y 27 al proceso de desarrollo), las cuales definen las reas claves a satisfacer para lograr, asegurar y controlar la calidad tanto en el producto como en el proceso. Entre las caractersticas asociadas a cada categora del producto, se proponen en el modelo MOSCA, una serie de caractersticas del proceso. Esto se debe, a que algunas caractersticas de la calidad del proceso, impactan directamente en las categoras del producto al igual que ciertas caractersticas de la calidad del producto definen categoras del proceso. Esto ayuda a precisar que si una vez medidas las caractersticas asociadas a una categora en particular del producto, arroja resultados no deseados, se pueden analizar las caractersticas de la calidad del proceso asociadas a esa categora del producto para encontrar las posibles causas. Nivel 3: Mtricas. Para cada caracterstica se propone una serie de mtricas utilizadas para medir la calidad sistmica. A cada una de las caractersticas que conforman MOSCA (679 en total). Nmero de componentes de acceso a la base de datos (Producto) 7-5 4-3 2-1 4 3 2

METRICA Rango Valor

>8 5

0 1

METRICA Rango Valor

Generacin de documentacin en concordancia con los estndares y polticas establecidos (Proceso) SI NO N/A N/S

En resumen, MOSCA consta de un total de 11 categoras (6 pertenecientes al producto y 5 al proceso de desarrollo), 83 caractersticas (56 asociadas al producto y 27 al proceso de desarrollo) y un total de 679 mtricas. En este sentido, la aplicacin de un modelo como MOSCA puede llegar a ser complejo sino se cuenta con una gua que permita conducir este proceso; es decir, aplicar MOSCA para evaluar la calidad sistmica de un producto de software y de la organizacin que lo desarroll. Distribucin de las caractersticas y mtricas para medir la calidad sistemtica del producto software:

Distribucin de las Caractersticas y mtricas para medir la calidad Sistmica del Proceso de Desarrollo

Caractersticas del proceso que influyen en la Funcionalidad del producto de software:

Caractersticas del proceso que influyen en la Fiabilidad del producto de software:

Caractersticas del proceso que influyen en la Usabilidad del producto de software:

Caractersticas del proceso que influyen en la Eficiencia del producto de software

Caractersticas del proceso que influyen en la Mantenibilidad del producto de software

Caractersticas del pro o que influyen en la Portabilidad del producto de software

Caracteristicas del proceso que influyen en todas las categorias del producto software

BIBLIOGRAFIA http://www.iti.es/media/about/docs/tic/01/2003-07-calidad.pdf http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/Capitulo%20I/problemas.htm http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo4.pdf http://javierreyesb.blogspot.com/2010/10/metricas-del-software.html http://www.slideshare.net/FernandoHernandez34/mtrica-de-puntos-de-funcin http://es.wikipedia.org/wiki/M%C3%A9trica_de_punto_funci%C3%B3n http://www.monografias.com/trabajos55/proceso-de-desarrollo-software/proceso-de-desarrollo-software2.shtml http://www.scielo.org.mx/pdf/cys/v8n3/v8n3a5.pdf http://www.lisi.usb.ve/publicaciones/02%20calidad%20sistemica/calidad_21.pdf