Normas y modelos para la calidad de software

ACTIVIDAD 1.1

Evaluación de la Calidad de la Tecnología Educativa Presentado a la Docente: ASTRID VICTORIA

CARDENAS Estudiante: JOHNNATAN ANDRÉS FIGUEROA HIDALGO

Maestría en Gestión de la Informática

Educativa

Universidad de Santander

2015

1

INTRODUCCIÓN

Hoy en día hablar de calidad es un tema común, de moda y exigido en todos los

campos, pero resulta muy relevante cuando se habla del concepto a nivel se software,

en primer lugar se requieren programas responsables que se adapten a las necesidades

de los clientes y en segundo lugar que sean seguros tanto para su aplicación como para

conservación de la información.

Si hablamos del termino Calidad Del software debemos tener claro que su fin principal

es garantizar la calidad de las aplicaciones que se desarrollan y comercializan a nivel

mundial, estos se garantizan mediante el seguimiento de protocolos que lleven a cabo

en todas las empresas desarrolladoras cuyas principales características deben ser estar

escritos, personalizados, ser adaptados a los requerimientos de la organización además

de ser reconocidos por quienes laboran en su desarrollo.

Es un compromiso incorporarlos a nivel empresarial y establecer estándares y o

metodologías para definir criterios que se implementaran en el desarrollo del Software,

si carecemos de una metodología siempre habrá falta de calidad.

A nivel mundial se han establecido parámetros y normativas frente a la calidad del

software, a continuación se mencionan algunas de las identificadas:

Organización Características Forma de Trabajo establecida

Modelos de Calidad del Software a Nivel Producto

Capability Maturity Model Integration (CMMi)

Tiene el propósito de proporcionar una única guía unificada para la mejora de múltiples disciplinas tales como Ingeniería de Sistemas (SE – System Engineering), Ingeniería del Software y el Desarrollo Integrado del Producto y del Proceso (IPPD). El CMMi está caracterizado por áreas de proceso para las 4 disciplinas que cubre actualmente, es decir: Ingeniería de Sistemas (SE), Ingeniería del Software, Desarrollo Integrado del Producto y del Proceso (IPPD) y la Fuente proveedora (A). Aunque muchas de las áreas de proceso (Process Area - PA) definidas en el CMMi tengan los mismos nombres que las áreas clave de proceso (Key Process Area - KPA), definidas en su modelo 41 anterior el SW-CMM, existen una serie de cambios

Categoría 1: ‘PROCESS MANAGEMENT’ Esta categoría abarca las actividades relacionadas con la definición, planificación, asignación de recursos, implementación, monitoreo, medición y mejora de procesos.

Categoría 2: ‘PROJECT MANAGEMENT’ Esta categoría abarca las actividades relacionadas con planificación, monitoreo y control del proyecto

Categoría 3: ‘ENGINEERING’ Esta categoría abarca las actividades de desarrollo y mantenimiento de Ingeniería de Sistemas y Ingeniería de Software

Categoría 4:

2

significativos en cuanto al enfoque y al alcance de sus actividades y objetivos. Los enfoques de CMMi están diseñados para describir los niveles de mejoramiento del proceso.

‘SUPPORT’ Esta categoría abarca las actividades de soporte en el desarrollo y mantenimiento del 44 producto.

Overview de CMM (Capability Maturity Model)

CMM provee a las organizaciones de software una guía de cómo realizar un control de los procesos de desarrollo y mantenimiento de software. Permite seleccionar estrategias de mejoras de procesos determinando la madurez de los procesos existentes e identificando factores críticos respecto de la calidad del software y del mejoramiento de los procesos.

Nivel 2: Repetible o Administración de la Configuración del Software (Software Configuration Management) o Aseguramiento de la Calidad del Software o Planificación del Proyecto de Software (Software Project Planning) o Administración de Requerimientos (Requirements Management) o Administración de Subcontratos de Software Management)

Nivel 3: Definido o Revisiones (Peer Reviews) o Coordinación de los Grupos (Intergroup Coordination) o Ingeniería del Producto de Software (Software Product Engineering) o Administración del Software Integrado (Integrated Software Management) o Programa de Entrenamiento (Training Program) o Definición de los Procesos de la Organización (Organization Process Definition) o Enfoque de los Procesos de la Organización (Organization Process Focus)

Nivel 4: Administrado o Administración de la Calidad de Software (Software Quality Management) o Administración de los Procesos Cuantitativos (Quantitative Process Management) Nivel 5: Optimizado o Administración de los Cambios de Procesos (Process Change Management) o Administración de los Cambios Tecnológicos (Technology Change Management) o Prevención de Defectos (Defect Prevention)

TickIT

El objetivo del programa TickIT era ayudar a las organizaciones de software a crear sistemas de calidad que agregaran valor a sus empresas y que cumplieran con la norma ISO 9001:2000. Los objetivos principales de TickIT son, además de desarrollar un sistema de certificación aceptable en el mercado, estimular a los desarrolladores de software a implementar sistemas de calidad, dando la dirección y guías necesarias para tal efecto. El objetivo

PARTE A - Introducción al TickIT y al proceso de certificación Esta parte presenta información general acerca de la operación de TickIT y cómo se relaciona con otras iniciativas de calidad tales como el Mejoramiento del Proceso.

PARTE B - Guía para los Clientes Esta parte describe las cuestiones relacionadas a la certificación del sistema de gestión de la calidad (SGC) en el campo del software desde el punto de vista del cliente quien inicia 81 un proyecto de desarrollo, y explica cómo el cliente puede contribuir a la calidad de los productos y

3

de la certificación es demostrar que las prácticas necesarias para asegurar la calidad durante el desarrollo de software existen y son verificables. En general, el modelo permite certificar cualquier tipo de proyecto a través de una estructura más flexible.

servicios entregados.

PARTE C - Guía para los Distribuidores Esta parte presenta información y una guía para las organizaciones que proveen software y 82 servicios de software, incluyendo desarrolladores, en base a la construcción de los SGC usando los procedimientos de TickIT. Indica cómo las organizaciones pueden acceder y mejorar la eficacia de sus SGC.

PARTE D - Guía para los Auditores Esta parte permite que los auditores tengan una guía usando los procedimientos de TickIT.

Modelo Bootstrap

Mediante esta metodología se tratará la mejora de procesos de software. ISO/IEC TR 15504 define un proceso como un grupo de actividades interrelacionadas donde una entrada se transforma en una salida. Se podría decir que la mejora de procesos es en parte mejor que la reingeniería. Esta metodología mediante prácticas, herramientas y estándares de calidad internacional; mide, evalúa y propone mejoras al proceso de desarrollo de SW que siguen las Unidades de Producción de Software (UPS) de las empresasBootstrap surge como parte del programa estratégico Europeo para investigación en tecnología de información. Este proyecto al igual que otros, tiene como principio el reducir costos y mejorar la calidad previendo problemas. Su objetivo es desarrollar un método para la evaluación de procesos de desarrollo de software (SW). Inicialmente se basó en el modelo de madurez de CMM añadiendo conceptos de calidad de ISO 9000

1- Organización ORG.1 – Ingeniería del Negocio ORG.2 – Gestión de Recursos Humanos ORG.3 – Gestión de la Infraestructura

ORG.1 Business Engineering (Ingeniería de negocio), se corresponde con Organisational Alignment. Este proceso sirve para asegurar que todo en la organización tiene una visión común respecto a los objetivos de negocio de la misma. ORG.2 Human Resource Management (Gestión de los recursos humanos), se corresponde con el proceso del mismo nombre, y que debe permitir conseguir las habilidades individuales y definición de roles necesarios en la organización. ORG.3 Infraestructure Management (Gestión de la infraestructura), se corresponde con Infraestructure, que se usa para establecer y mantener una infraestructura estable y fiable que de soporte a los demás procesos. Esto puede incluir hardware, software, métodos, herramientas, técnicas, etc.

Personal Software Process (PSP)

El proceso de PSP consiste de un conjunto de métodos, formularios y scripts que muestran a los Ingenieros de Software cómo planificar, medir y administrar su trabajo. El PSP está diseñado para ser usado en algún

El diseño de PSP está basado en los siguientes principios de planificación y calidad: Todo Ingeniero es diferente y para ser más efectivo, los Ingenieros deben planificar su trabajo y deben basar sus planes en sus datos personales

4

lenguaje de programación o metodología de diseño, y puede ser usado en varios aspectos del trabajo de software. Consiste en un proceso de nivel 5 de CMM diseñado para calcular el costo individual. Se aplica en la mayoría de las tareas de desarrollo de software como ser: *definición de requerimientos, * diseño de la 97 arquitectura, * desarrollo del módulo, * producción de la documentación, * pruebas del sistema, * mantenimiento del sistema y * desarrollo de pequeños programas. Es un prerrequisito del planeamiento de la organización para producir el TSP (Team Software Process)

Para mejorar el performance, los Ingenieros deben usar los procesos bien definidos y medidos

Para producir productos de calidad, los Ingenieros deben ser responsables de la calidad de sus productos. Los productos superiores no son producidos por medio de errores, los Ingenieros deben hacer lo posible por realizar un trabajo de calidad

Menor costo en encontrar y arreglar los defectos de un proceso

Es más eficiente prevenir defectos que encontrar y arreglarlos

Team Software Process (TSP)

El objetivo era suministrar un proceso operacional que ayude a los Ingenieros hacer trabajos de calidad. El principal motivador para el desarrollo de TSP fue la convicción que los equipos de Ingenieros puedan hacer el trabajo de manera extraordinaria, pero solo si ellos son formados y entrenados. El objetivo del TSP es construir y guiar a los equipos. Los equipos son requeridos para la mayoría de los proyectos de Ingeniería. El desarrollo de sistemas es una actividad en equipo, y la efectividad del equipo determina la calidad de la Ingeniería. En Ingeniería, los equipos de desarrollo tienen múltiples especialidades y todos los miembros trabajan en vista de un objetivo en común.

Los miembros del equipo establecen objetivos en común y roles definidos,

el equipo desarrolla una estrategia,

los miembros del equipo definen un proceso en común para su trabajo, todos los miembros del equipo participan en la producción del planeamiento, y cada miembro conoce su rol en ese planeamiento, el equipo negocia el plan con la dirección,

La dirección revisa y acepta el plan negociado y los miembros del equipo se comunican de manera frecuente.

Six Sigma For Software

Six Sigma es una propuesta que permite mejorar procesos y productos que ha tenido una gran aceptación. Es una filosofía, una métrica y una estructura de mejoramiento. Esta filosofía pretende ser aplicada en los dominios relacionados a la tecnología y al software; y es utilizada para lograr la satisfacción del cliente con productos novedosos a un precio competitivo.

En la primera fase, denominada Define (Definición), se identifican los posibles proyectos Six Sigma, que deben ser evaluados por la dirección en función de los factores críticos de éxito para la empresa para evitar la infrautilización de recursos

La segunda fase, Measure (Medición) consiste en la caracterización del proceso o procesos afectados, analizando su funcionamiento actual y determinando los requisitos clave de los clientes de dicho proceso o procesos, así como las características de calidad 21 Felhmann,

5

Thomas M, ”Six Sigma for Software”, Zurich, Switzerland, 2003. 124 del producto o servicio críticas para el cliente.

En la tercera fase, Analyze (Análisis), el equipo analiza los datos obtenidos sobre el funcionamiento del proceso. En algunos casos se trata de datos históricos, procedentes de los registros habituales de la organización y, en otros, es necesaria una recopilación de datos específica, que la organización no utiliza normalmente

En la siguiente fase, de Improve (Mejora), el equipo trata de buscar la solución estadística al problema, determinando las relaciones causa-efecto (relación matemática entre las variables de funcionamiento y las de respuesta) para identificar la combinación o situación 125 de aquellas, más adecuada para conseguir los valores objetivo de éstas.

La quinta y última fase, Control (Control), consiste en diseñar y documentar los controles, basados en el autocontrol, en mecanismos a prueba de error (mistake proofing) y en el control estadístico de los procesos, necesarios para asegurar que lo conseguido mediante el proyecto Six Sigma se mantenga una vez que se hayan implantado los cambios y el equipo deje de prestar al proceso la atención que ha prestado durante el proyecto.

Modelos de Calidad del Software a Nivel ProductoModelo de Gilb El modelo de Gilb plantea la creación

de una especificación de requisitos de calidad para cada proyecto que deben escribir conjuntamente el usuario y el analista. Es un modelo que permite determinar una lista de características que definen la calidad de la aplicación. Puede ser de 2 tipos: (1) Originales y (2) de modelos tradicionales. Las características se pueden medir mediante varias subcaracterísticas o métricas detalladas. Para cada una de ellas, se deben especificar los siguientes conceptos: Nombre y definición de la característica,Escala o unidades de medición

6

Recopilación de datos o prueba, Valor previsto, Valor óptimo, Valor en el sistema actual y comentarios.

Modelo GQM (Goal –

Question - Metric)

El modelo GQM (objetivo-pregunta-métrica /goal – question - metric) de Basili y Rombach (1998) es una propuesta de objetivos / metas orientado a la definición de modelos de calidad. Se propone el paradigma GQM para evaluar la calidad de cada proyecto. Este modelo utiliza una propuesta para definir un modelo de calidad hasta obtener las métricas respectivas con el análisis e interpretación de los datos de las 130 mediciones respectivas. Plantea el enfoque de medición para evaluar la calidad del software basado en la identificación de objetivos a lograr.

Consta de 3 etapas 1- Listar los objetivos principales del

desarrollo y mantenimiento del proyecto

2- 2- Para cada objetivo, se deben obtener las preguntas que deben contestarse para saber si se están cumpliendo los objetivos

3- 3- Decidir qué medir para poder contestar las preguntas de manera adecuada, es decir, desarrollar un conjunto de métricas que ayuden a responder la pregunta.

Modelo de McCall

La calidad de un sistema, aplicación o producto es tan buena como los requisitos que describen el problema, el diseño que modela la solución, el código que conduce a un programa ejecutable y las pruebas que ejercitan el software para detectar errores. Un buen Ingeniero del Software utiliza mediciones que evalúan la calidad del análisis y los modelos de diseño, el código fuente y los casos de prueba que se han creado al aplicar la Ingeniería de Software.

El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto

Operación del producto,

Revisión del producto y

Transición del producto (Figura 21).

Modelo de BOEHM

El modelo de Boehm (1978) agrega algunas características a las existentes en el modelo de McCall y representa una estructura jerárquica de características, cada una de las cuales contribuye a la calidad total. Consiste en un modelo de descomposición de características de calidad del software en 3 niveles (usos principales, componentes intermedios y componentes primitivos) previos a la aplicación de métricas.

El modelo de Boehm tiene como finalidad que a través de la calidad del software, el software: (1) realice lo que desea el usuario, (2) utilice recursos informáticos de manera correcta y eficiente, (3) sea fácil de utilizar y aprender; (4) sea bien diseñado, codificado, probado y mantenido. Este modelo es similar al de McCall ya que presenta una jerarquía de características, está basado en un amplio rango de características e incorpora 19 criterios que incluyen características de performance del hardware.

Modelo de Dromey

El modelo de Dromey tiene el propósito de trabajar con una estructura que permite construir y utilizar un modelo de calidad práctico

Las características de calidad planteadas en este modelo son: Eficiencia, Confiabilidad, Facilidad de mantenimiento, Portabilidad, Facilidad de uso y

7

para evaluar las etapas de Determinación de los requerimientos, Diseño e Implementación. Esta información puede ser usada para elaborar, comparar y evaluar la calidad de los productos de software.

Funcionalidad. Estas características pueden ser agrupadas de acuerdo a diversos aspectos a tener en cuenta en la implementación: (1) corrección,(2) aspectos internos,(3) aspectos del contexto (4) aspectos descriptivos.

Bibliografía

Escalone Fernanda, 2006, estudio comparativo de los modelos y estándares de calidad del software Recuperado de URL: http://laboratorios.fi.uba.ar/lsi/scalone-tesis-maestria-ingenieria-en-calidad.pdf

Rojas S Saulo, Revista escuela administración de negocios No 38, 1999, Calidad del

software camino a una verdadera industria del software, recuperado de URL: file:///C:/Users/MONICA/Downloads/133-349-1-PB.pdf

Troya Oscar, Carvajal Carlos, 2012, métricas para la calidad del Software, Recuperado de Url: http://es.slideshare.net/oskrtroy/metrica-calidad-desoftware

Alderete Verónica, Colombo Adriana, de cómo martillos y pinzas se tornas en tecnología de punta, Recuperado Url: http://200.16.86.50/digital/33/revistas/cse/sixsigma-six.pdf