Calidad del software y factores para su aseguramiento

Presentación del tema: "Calidad del software y factores para su aseguramiento"— Transcripción de la presentación:

1 Calidad del software y factores para su aseguramiento
Gabriel G. Barrios Martínez Ingeniero de Sistemas – Universidad del Magdalena Auditor Interno de Calidad – Universidad del Magdalena Gerencia de Proyectos Informáticos – SENA Regional Magdalena Fundamentos de la Calidad para la gestión pública Desarrollo y Administración de SIARE – Recursos Educativos

2 Definición de Calidad “Es la totalidad de las características o rendimiento, que puede ser usado para determinar si un producto cumple o no su aplicación prevista o intencionada” Japanese Industrial Standard JIS z “Conjunto de propiedades y características de un producto o servicio, que le confiere la aptitud para satisfacer necesidades explícitas o implícitas” ISO 8402 “El grado en que un producto, proceso o sistema cumple con sus requerimientos” IEEE

3 Definición de Calidad La calidad no es absoluta, puede tomar diferentes puntos de vistas dependiendo las diversas situaciones. Existen muchos factores que contribuyen a la calidad. Algunos aspectos pueden ser medidos y otros no. Funcionalidad Oportunidad Costo

4 ¿Cómo saber que obtuve calidad?
comparando entre unos requisitos preestablecidos y el producto realmente desarrollado. Requisitos preestablecidos: Definir las necesidades o requisitos que quiere el cliente o usuario, y planificar o especificar lo que se intenta conseguir. Producto desarrollado: Comparar lo que se ha conseguido y medir lo que el cliente valora.

5 Implicaciones Disposición Compromiso Lleva a: Inversión Conflictos
Realizar un producto de calidad, implica trabajo en equipos que trae consigo necesidad de inversión y solución de conflictos. Sí estos retos son sobrepasado en definitiva el resultado será una garantía de satisfacción. Trabajo en Equipo Conflictos

6 Aseguramiento de la calidad
Etapa de la calidad Calidad total Mejora de la calidad Aseguramiento de la calidad Mejora continua Control de la calidad Prevenir defectos No podemos decir que se tiene calidad en un producto o proceso, tan sólo con el hecho de iniciar controles y mejoras; es necesario finalizar o quemar etapas. Los primeros paso o la primera etapa serán controles muy rigurosos y en mayor cantidad en el cumplimientos de las normas, también se presentan desconfianza en el sistema y conflictos por el trabajo colaborativo. Después de superado la primera etapa existe más confianza del proceso por parte de la dirección del proyecto; los controles son menos rigurosos, debido al compromiso y integración del equipo de trabajo. Buscan mantener los niveles alcanzados. Por ultimo, una vez madurado el pensamiento orientado a procesos y que el control sea parte esencial del trabajo, nuestro tiempo esta básicamente dispuesto a las mejoras, a la optimización, a hacer más eficientes. Detectar defectos Tiempo

7 Calidad del software ¿Qué es la Ingeniería de Software?
“Estudio de los principios y metodologías para desarrollar y mantener el software”. Zelkowitz. “Es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computador y la documentación apropiada para desarrollarlos, operarlos y mantenerlos”. Boehm. Características del software: Se desarrolla no se fabrica. Se deteriora por la aparición de nuevas tecnologías. Se desarrolla a la medida. Posee un ciclo de vida.

8 Proceso de Gestión de Software
Un producto de software con calidad se desarrolla bajo un proceso de software. Proceso Software es: “Un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y mantener un producto software.” (Fuggetta, A. (2000): Software Process: A Roadmap. International Conference on Software Engineering)

9 Beneficio y Perjuicios
Beneficio de los procesos de software Los procesos permiten que los productos sean repetibles, sostenibles, continuos y finitos. También genera base de conocimientos, oportunidad de mejoras, organiza y evita redundancia de trabajo. Perjuicios de los procesos de software Sí no se lleva una adecuada gestión del proceso de software, se puede caer en ciclo infinitos para el desarrollo del producto, convirtiéndose en procesos complejos y difícil de administrar.

10 Gestión Mejorar Definir y planificar Medir Controlar Ejecutar
Gestión de un proceso de software, tiene los principios básicos de la gestión de procesos; la diferencia lo que sucede dentro de cada etapa: Definir el proceso a utilizar, los factores y productos a evaluar. Establecer tiempos de entregas y realización de controles. Se debe tener en cuentas las mejoras planteadas en la realización de otros proyectos anteriores. Desarrollar el producto de software y realizar los controles establecidos; dentro de esta etapa se realiza documentación del producto y de los controles realizados. Comparar lo definido con los resultados de los controles y el producto terminado. Detectar fallas y presentar informe. Analizar las fallas y observar nuevas oportunidades de mejoras. Ejecutar

11 Características Característica Descripción Comprensión Visibilidad
Definición y especificación del proceso para garantizar el entendimiento por parte del equipo y la organización. Visibilidad Definición de resultados concretos de cada actividad para garantizar la visibilidad del progreso. Apoyo Posibilidad de soporte tecnológico para el desarrollo de actividades del proceso. Aceptación El proceso es aceptable (viable) y utilizable por parte de los equipos de desarrollo. Fiabilidad El proceso está diseñado para identificar y manejar los errores del proceso antes de que los errores se trasladen al producto. Robustez EL proceso puede continuar a pesar de los sucesos inesperados. Mantenibilidad El proceso puede evolucionar para reflejar los cambios en la organización o las mejoras a partir de los errores. Rapidez Cuán rápido se puede ejecutar el proceso para obtener un producto a partir de una especificación. Ing. Ernesto A. Galvis L. MSc. Prog. Ingenieria de Sistemas Universidad del Magdalena Diplomado en Gestión de la Calidad del Software Calidad del Proceso Juan Pavón Mestras - Facultad de Informática UCM, 2004 Proceso del software

12 Modelos Definen las actividades para la gestión de un proyecto de software. Capability Maturity Model Integration (CMMI) ISO/IEC 12207 eXtreme Programming (XP) Open Unified Process (OpenUP). Scrum. Rational Unified Process (RUP)

13 Capability Maturity Model Integration
CMMI (Capability Maturity Model Integration) es un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales de procesos efectivos. CMMI basado en la mejora del proceso incluye la identificación de las fortalezas de su organización, procesos y debilidades; además hacer cambios en el proceso, de convertir debilidades en fortalezas. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute). Software Engineering Institute - El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI.

14 CMMI Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser: Definidas en un procedimiento documentado Provistas (la organización) de los medios y formación necesarios Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas) Medidas Verificadas

15 Esquema de Madures CMMI
N5. Repetible Resultados cuantificados, con opción de mejora Medidas de Producto y Proceso. Registro de valores de Calidad N4. Gestionado Desarrollo y Mantenimiento documentado y Estandarizado N3. Definido N1. Las organizaciones no tienen un proceso estructurado. El desarrollo es caótico. Los Presupuestos y tiempos son a menudo superiores. La calidad del producto no se puede predecir. N2. En la organización que se encuentra en este nivel algunas áreas organizacionales y/o proyectos han alcanzado las metas genéricas y específicas establecidas en sus áreas de proceso, es decir planean sus procesos, los ejecutan, los miden y los controlan. N3. Tienen los procesos caracterizados, entendidos por los ejecutores, descritos mediante estándares, procedimientos, métodos y herramientas. N4. La organización selecciona y administra las actividades que contribuyen perceptiblemente al funcionamiento de proceso total. Estas actividades seleccionadas son controladas con técnicas estadísticas y otras técnicas cuantitativas. N5. El nivel 5 está centrado en mejorar continuamente el desempeño de los procesos con mejoras tecnológicas incrementales e innovadoras. Gestión del proceso seguimiento de: coste, planificación y funcionalidad N2. Repetible N1. Inicial El éxito del proceso depende del esfuerzo individual

16 ISO/IEC 12207 Tomo como base a la norma británica BS 5750 de 1987, y sufrió su mayor crecimiento a partir de la versión de La versión actual data de del 13 de Noviembre de Establece un marco común para los procesos de software de ciclo de vida, con una terminología bien definida, que puede hacer referencia a la industria del software. Contiene procesos, actividades y tareas que se van a aplicar durante la adquisición de un producto de software o servicio y durante el suministro, desarrollo, operación, mantenimiento y eliminación de productos de software. Las Normas ISO (La Organización Internacional para la Estandarización) 9000 Estaban principalmente dirigidas a organizaciones que realizaban procesos productivos en las Empresas de Servicio.

17 ISO/IEC 12207 Se aplica a la adquisición de sistemas y productos de software y servicios, con el suministro, desarrollo, operación, mantenimiento y eliminación de productos de software y la parte de software de un sistema, ya sea de forma interna o externa a la organización. Aquellos aspectos de la definición del sistema necesario para proporcionar el contexto para los productos de software y servicios están incluidos. ISO / IEC 12207:2008 proporciona también un proceso que puede ser empleado para definir, controlar y mejorar los procesos de software de ciclo de vida.

18 eXtreme Programming (XP)
Es una de las llamadas Metodologías Agiles de desarrollo de software. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

19 eXtreme Programming (XP)
Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Simplicidad: Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento; Para mantener la simplicidad es necesaria la refactorización del código. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida. Comunicación: Para los programadores el código comunica mejor cuanto más simple sea. Debe comentarse sólo aquello que no va a variar. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. Retroalimentación (feedback): Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código. Coraje : Diseñar y programar para hoy y no para mañana necesita de valentía y coraje. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, solo si es persistente. Respeto: Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo. Simplicidad: La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo. Comunicación: La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que características tienen prioridad y siempre debe estar disponible para solucionar dudas. Retroalimentación (feedback): Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código. Coraje o valentía: Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar todo lo demás del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, solo si es persistente. Respeto: El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

20 Planificación/ Ciclos de Retroalimentación

21 SCRUM Es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Aunque estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas. Hoy en día es usado por empresas de todos los tamaños tales como Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, CapitalOne y la Reserva Federal de EE.UU.

22 SCRUM Esquema de trabajo SCRUM

23 Rational Unified Process
Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. No es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. El RUP está basado en 6 principios clave que son los siguientes: Adaptar el proceso : El proceso deberá adaptarse a las necesidades del cliente, las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen. Equilibrar prioridades: Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados. Colaboración entre equipos: El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc. Elevar el nivel de abstracción: Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Enfocarse en la calidad: El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

24 Ciclo de vida RUP El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

25 Calidad del Producto de Software
Análisis Diseño Codificación Integración Mantenimiento Ciclo de vida de 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 solución 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, deja de ser utilizado.

26 Definición del producto de software
Un producto de software es el conjunto de programas (fuentes y ejecutables), procedimientos, reglas y documentación posible asociada, así como los datos pertenecientes a la operación del sistema. Modulo 4 Calidad de Producto - Diplomado en Gestión de la Calidad del Software 2008 Ing. Johan Robles S. Universidad del Magdalena - Programa de Ingeniería de Sistemas

27 Calidad del Producto de Software
Luis Olsina en su metodología Web QEM plantea un modelo jerárquico de calidad de producto y desarrolla un marco conceptual de calidad. El marco conceptual define cuatro factores de calidad: Calidad de recurso Calidad de proceso Calidad de producto Calidad en uso

28 Calidad del Producto de Software
Marco conceptual de calidad propuesto por Olsina Fuente: GONZÁLEZ R. Julia. OLSINA, Luis. Hacia la medición de calidad en uso Web

29 Calidad del Producto de Software
Calidad Externa: no intenta evaluar las propiedades intrínsecas del producto, se refiere a la perspectiva del usuario con relación a la calidad del producto al ser utilizado en un ambiente y contexto específico. Calidad Interna: Es la totalidad de características del software producidas desde una perspectiva interna. Dichas características permanecen generalmente constantes a lo largo del ciclo de vida del software, aunque éste sea rediseñado y programado nuevamente. Calidad en Uso: se refiere a la perspectiva del usuario con relación a la calidad del producto al ser utilizado en un ambiente y contexto específico, es decir, si los usuarios pueden lograr sus metas usando el producto.

30 Modelos de calidad del Software
Los modelos de calidad de software surgieron a mediados de los años 70’s. Los modelos permiten evaluar la calidad de un producto de software definiendo objetivos específicos de calidad. Uno de los enfoques más utilizados para modelos de calidad de software consiste en descomponer jerárquicamente la calidad en características, sub-características, atributos, ítems, entre otros, que pueden ser utilizados como puntos clave en la observación de los aspectos relevantes del producto a evaluar. Algunos de los modelos más utilizados son: · Modelo de Gilb · Modelo de McCall · Modelo de Boehm · Modelo FURPS (Hewlett Packard) · Modelo propuesto por la norma ISO/IEC 9126

31 Modelos de calidad del Software

32 Modelo de McCall Operación de producto Revisión de Transición de
Facilidad de uso Seguridad (integridad) Eficiencia Corrección (exactitud) Fiabilidad Facilidad de mantenimiento prueba Flexibilidad Capacidad de reutilización Transportabilidad Interoperabilidad Operabilidad Familiarización Comunicatividad Volumen y tasa de E/S Datos comunes Control y audit. de acceso Integridad de datos Eficiencia de almacenam. Eficiencia de ejecución Compleción Capacidad de ampliación Trazabilidad Concisión Precisión Tolerancia a errores Simplicidad Consistencia Modularidad Autodescriptividad Instrumentación Generalidad Indep. máquina Indep. soft. de sistema Comunicac. comunes Visión de usuario Visión de la dirección Visión del desarrollador

33 Modelo de Boehm Fuente: OLSINA, Luis. Métricas, Criterios y Estrategias para Evaluar Calidad Web Parte II - Requerimientos de Calidad para Diseño y Evaluación. Facultad de Ingeniería, UNL Pam, Argentina.

34 NORMA ISO/ IEC 9126 La norma internacional ISO/IEC 9126 proporciona las guías de un modelo de calidad para un producto de software. Esta norma sigue el esquema propuesto por los modelos anteriores (McCall, Boehm, etc), además, retoma algunas de las características planteadas por dichos modelos, pero puntualiza seis características que considera fundamentales en la evaluación de calidad de un producto de software (funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad). Debido a la variedad existente en cuanto a modelos de calidad para tecnologías de software, en la década del 70 surgió la necesidad de desarrollar un modelo estándar para la evaluación de la calidad de los productos de software. Así, el ISO/IEC JTC119 se lanzó al desarrollo de esta tarea. En el año de 1991, salió al mercado la primera versión de la Norma. En el año 2001 dicha norma se reemplazó por dos nuevas versiones: ISO/IEC 9126 (Software Product Quality) e ISO/IEC (Software Product Evaluation).

35 NORMA ISO/ IEC 9126 Características para la calidad interna y externa: Funcionalidad: El producto software debe implementar los requerimientos solicitados por el usuario, de tal forma que éste lo pueda utilizar para los fines esperados, de una forma segura y precisa. Confiabilidad: El producto software debe realizar sus funciones conservando los niveles de desempeño deseados, bajo condiciones específicas. Facilidad de uso / Usabilidad: Esta característica indica que se debe observar en el producto de software la capacidad para que su lógica sea entendida por el usuario, así como la facilidad en el aprendizaje de las operaciones de entrada y salida de datos. Eficiencia: La eficiencia del producto software se debe observar no sólo en el tiempo de CPU sino en la consideración de los recursos empleados , tanto materiales como humanos. Mantenimiento: Un producto de software, debe ser modificado con cierto grado de facilidad. Las modificaciones pueden incluir correcciones, mejoras o adaptaciones del software a cambios en el entorno, en los requisitos o en las especificaciones funcionales. Portabilidad: El producto software debe tener la capacidad de ser instalado en un amplio abanico de entornos, con la posibilidad de ser transferido de uno a otro.

36 NORMA ISO/ IEC 9126 Modelo de calidad interna y externa propuesto por la Norma ISO/IEC 9126 (2001) Fuente: Elaboración propia con base en la Norma ISO/IEC 9126

37 NORMA ISO/ IEC 9126 El modelo de calidad en uso propuesto por la Norma expone cuatro características: Efectividad: Esta característica se refiere a la capacidad del producto de software para brindar la posibilidad a los usuarios de alcanzar metas u objetivos especificados con exactitud y completitud en un contexto de uso particular. Productividad: Esta característica se refiere a la capacidad del producto de software para permitir a los usuarios demandar una cantidad apropiada de recursos (como tiempo, esfuerzo, materiales y costos , entre otros) en relación a la efectividad alcanzada en un contexto de uso específico. Seguridad: Esta característica se refiere a la capacidad del producto de software para alcanzar niveles aceptables de riesgo en un contexto especial. Satisfacción: Esta característica se refiere a la capacidad del producto de software para satisfacer a los usuarios en un marco de trabajo particular, entendiendo por satisfacción como una respuesta de los usuarios a la interacción con el producto, incluyendo las actitudes producidas frente a su uso.

38 Ejemplo ISO/ IEC 9126

39 Métrica Las métricas son un conjuntos de reglas que ayudan a entender y medir que tan bien o mal esta operando o diseñado un producto de software. Incluyen actividades, tales como: Estimación de costo y esfuerzos. Medición de la productividad. Acumulación de datos. Elaboración de modelos de seguridad. Evaluación y modelos de desempeño. Valoración de las capacidades y la madures. Administración de métricas. Evaluación de métodos y herramientas.

40 Métrica Métricas para determinar los factores de calidad:
Facilidad de auditoria Exactitud Normalización de las comunicaciones Completitud Concisión Consistencia Estandarización de los datos Tolerancia de errores Eficiencia de la ejecución Facilidad de expansión Generalidad Independencia del hardware Instrumentación Modularidad Facilidad de operación Seguridad Auto-documentación Simplicidad Independencia del sistema Facilidad de traza Formación

41 Proceso de Evaluación y Modelación
Se recomienda realizar los siguientes paso para un proceso de evaluación del producto de software: Determinación de las condiciones iniciales: Tomar en cuenta condiciones básico para el proceso de evaluación. (las entradas del sistema, sus restricciones, y los servicios que proporciona el sistema). Selección del atributo de calidad y de sus métricas de software: definir el atributo de calidad de software que pretendemos estudiar. En la selección del atributo influyen las necesidades prioritarias de cada organización en sus productos de software. Proceso de Medición: La medición del software se refiere a derivar un valor numérico para algún atributo de un producto de software. Evaluación de los resultados y selección del modelo: La evaluación del proceso de medición la realizamos mediante el estudio de su distribución estadística. Los resultados de esta evaluación permiten analizar el conjunto de datos obtenidos mediante gráficas conocidas como histogramas. Estimación de los parámetros del modelo: En ocasiones, es necesario aplicar varios métodos para llegar a resultados confiables, y dependiendo del parámetro a estimar algunos métodos son mas adecuados que otros. Sustitución de los parámetros obtenidos y graficación del modelo resultante: La gráfica obtenida representa el comportamiento del atributo de calidad. Validación del modelo escogido: Con los parámetros obtenidos debemos verificar que el modelo, tal y como fue construido está de acuerdo con la población de métricas estudiada. Por lo tanto en este proceso, se realiza una comparación de los valores que se obtienen con el histograma contra los resultados que se obtienen con el modelo. Realización de las predicciones del atributo de calidad: Las predicciones del atributo de calidad se realizan mediante la observación del modelo (o ley de probabilidad) obtenido.

42 Campo de acción En la actualidad, existe mayor conciencia de procesos de calidad. Cada día la demanda de producto de calidad es mayor, al igual es el crecimiento de organizaciones especializadas en certificar la calidad de tales producto. El Tester es uno de los oficios crecientes dentro de la ingeniería de software, debido a que es necesario profesionales especializados en planear, ejecutar y medir características de software. Otra de las profesiones es la Gerencia de Proyectos, la cual juega un papel importante para el alcance de metas y eficiencia del trabajo. También existe un gran campo de acción en el la Gerencia de la Calidad, donde el pensamiento orientado a procesos es fundamental. Acompañando a este tenemos los Auditores que permiten la observación independiente del desarrollador. Además de los oficios tenemos la construcción de herramientas de gestión y de evaluación que cada vez son mas necesaria para el desarrollo eficaz de estos oficios.

43 Campo de acción En la página Testingreferences han creado un diagrama con parte de la historia del testing para ver sus inicios y la evolución.

44 Gracias !!!