Control y Calidad de SW Separata

Separata preparada para el desarrollo del curso de:

Control de Calidad de Software

Tercera Unidad Temática:

MODELO DE MADUREZ DE CAPACIDADES DEL PROCESO DE

SOFTWARE– GESTIÓNAR LA CALIDAD EN PROYECTOS DE

TIC CMMI

Prof. Dr. Ing. Edward J. Flores M.

NOVENO CICLO

Semestre: 2012-I

Universidad Privada TELESUP Página 2

INDICE

Semana 15: Estrategia Empresarial……………….……………..…. Página 03

Semana 11: La Calidad y los Modelos de Calidad..………………. Página 08

Semana 12: Técnicas de Aseguramiento de la Calidad………….. Página 12


DÉCIMA SEMANA–Estrategia Empresarial

CMMI

Nivel 2: Administrado

REQM

PP

PMC

SAM

MA

PPQA

CM

Administración de Requerimientos.

Planeamiento de Proyectos

Monitoreo y control de proyecto.

Administración de acuerdo cliente/servidor

Mediciones y Análisis

Proceso y aseguramiento de la calidad

Administración de la configuración

Todos los “Objetivos Específicos y Genéricos” de todas las “Áreas de Proceso del Nivel 2 han sido alcanzadas.

Los proyectos son planificados, realizados, medidos y controlados. Se normalizan las buenas prácticas en el desarrollo de proyectos (en

base a la experiencia y al método).

En este nivel consolidado, las buenas prácticas se mantienen en los momentos de estrés.

Se definen hitos para la revisión de los productos. El progreso del proyecto es visible por el Gerente en cada hito. Los resultados son revisados con los participantes y son controlados. Los resultados satisfacen los requerimientos especificados,

estándares y objetivos.


El proceso de Planeamiento Estratégico

Proceso de Mejoramiento y re-diseño continuo.


Determinación de Estrategias

Negociación Costos Recursos

Infraestructura

DESCRIPCION DE CRITERIOS

INDEPENDENCIA GEOGRAFICA.

La operación se llevaría a cabo en lugares distantes geográficamente, lo cual reduciría la probabilidad de que en caso de siniestro severo, la operación se

afecte en los dos lugares simultáneamente.

AUTONOMIA.

Cuando se es dueño de los recursos necesarios y tienen total control sobre

ellos; posee completa autonomía para realizar sus procesos y operaciones, sin depender de entidades externas.

DEPENDENCIA PROVEEDOR/”SERVICE”.

La alternativa esta sujeta a la permanencia en el mercado de la firma proveedora/”service” del recurso necesario.

DEPENDENCIA CON ENTIDAD EXTERNA.

Se tienen alternativa de procesamiento dependiendo de la disposición y de la disponibilidad de recurso que tenga la entidad escogida como soporte.

DEPENDENCIA CON TELECOM.

La alternativa depende totalmente del servicio que preste telecom en un momento determinado.

DEPENDENCIA RUTAS DE TRANSPORTE.

La alternativa depende de que haya transporte a las diferentes ciudades los días y horas claves para la entidad

TRANSPORTE DE DOCUMENTOS.

El transporte de documentos incrementa el riesgo de perdida de la información.

TRANSPORTE MEDIOS MAGNETICOS.

Al tenerse que transportar medios magnéticos y archivos, aumenta el riesgo de perdida de información y por lo tanto de la confidencialidad de la misma.

FACILIDAD DE TRASLADO DEL RECURSO.

En esta alternativa el recurso necesario puede ser trasladado fácilmente.

FACILIDAD DE OPERACION.

Con la alternativa, la operación se puede efectuar sin cambios drásticos, permitiendo llevar a cabo las labores diarias sin mucha dificultad.


AUMENTO DE CARGAS DE TRABAJO EN LA OFICINA “SOPORTE”.

Al presentarse una mayor afluencia de publico por el traslado de la operación de una oficina a otra, las cargas de trabajo del personal de la oficina de soporte

aumentan.

AUMENTA EL RIESGO DE ERRORES EN OPERACION.

Al presentarse congestión y sobrecargas de trabajo en la oficina

soporte”aumenta el riesgo de que los funcionarios de esta cometan errores.

CAPACIDAD DE PROCESOS.

Se tiene la capacidad de recurso suficiente para la operación y/o proceso.

CONOCIMIENTO FUNCIONARIOS.

Los funcionarios tienen el suficiente conocimiento de la operación y/o proceso,

sin requerirse una capacitación durante la contingencia.

SERVICIO AL CLIENTE.

Al utilizarse la alternativa, el servicio al cliente va a verse deteriorado en alguna

medida.

DEMORAS ENTREGA INFORMACIÓN.

La alternativa obliga a que la entidad, que va a utilizar el equipo de soporte,

tenga que esperar a que la entidad que le va a conceder el equipo, termine sus procesos, ocasionándole esta situación perdida de tiempo y demoras en la entrega de la información.

AUMENTA EL RIESGO DE ERRORES EN TRANSCRIPCION.

Al utilizarse la alternativa, el riesgo de aumento de errores en la transcripción de datos es muy grande.

TIEMPOS ALTOS DE TRANSCRIPCION,

Al utilizarse la alternativa, hay alto riesgo de que los tiempos de transmisión

aumenten.

RIESGO DE DOCUMENTACION CON TRATAMIENTO INCORRECTO.

Cuando se incrementan las cargas de trabajo en forma imprevista se aumenta

el riesgo de clasificación incorrecta de documentos.

CONFIDENCIALIDAD INFORMACIÓN.

Al procesar la información en un lugar diferente, existe el riesgo de que la

confidencialidad de la información se pierda por manipulación de terceros.

ALTO COSTO.

Los costos que pueda generar esta alternativa, son altos comparados con los

costos que puedan generar las otras alternativas planteadas (en el caso de las alternativas para procesamiento en ciudades diferentes a la sede habitual, se presentan algunos costos asociados).

ALTERNATIVA A MEDIANO /LARGO PLAZO.


Dadas las tareas y actividades que habría que realizar previamente como es la adecuación del recurso de soporte, este alternativa no se podría poner en

practica en forma inmediata.

SUBUTILIZACION DEL RECURSO.

En caso de no presentarse un siniestro, se corre el riesgo de no darle

utilización adecuada al recurso.

DISPONIBILIDAD DEL RECURSO.

La alternativa esta completamente disponible, ya que el recurso de soporte se

encuentra siempre al alcance de la entidad.

VERIFICACION DEL PLAN.

La alternativa da la posibilidad de llevar a cabo periódicamente procedimientos

operativos del plan, que permiten determinar la confiabilidad del mismo.

UTILIZACION EQUIPOS OTRAS AREAS.

La alternativa obliga la utilización de los equipos de otras áreas de la entidad, interrumpido en su trabajo y actividades diarias.

TIEMPOS ALTOS DE PROCESO.

Al utilizarse un equipo de menor capacidad, los tiempos de proceso aumentan.

PROCESOS EN VARIOS LUGARES.

La alternativa obliga a procesar en distintos lugares debido a la falta de

capacidad de los equipos de soporte.

BAJO COSTO.

Los costos que pueda generar la alternativa son relativamente bajos

comparados con los costos que puedan generar las otras alternativas de soporte planteadas dentro del mismo ambiente operativo.

NO HAY GARANTIAS DE DISPONIBILIDAD PERMANENTE DE

EQUIPOS.

El proveedor no garantiza la disponibilidad permanente de recursos ya que en un momento dado puede disponer de ellos.

EQUIPOS REDUNDANTES.

El recurso de soporte posee una capacidad de operación/procesamiento similar al de la entidad, lo cual le permitiría en caso de siniestro severo, seguir prestando los servicios sin mayor traumatismo.

ACCESO A OTROS CENTROS DE COMPUTO.

Al tenerse un convenio con otras entidades, le permite tener acceso a otros centros de computo y a equipos de similar configuración.


UNDÉCIMA SEMANA – La Calidad y los Modelos de Calidad

Introducción La implantación de sistemas de calidad aportan gran número de beneficios a las compañías que apuestan por esta estrategia. No sólo reducen sus costes de manera razonable, sino que además incrementan sus ingresos gracias al

mayor grado de satisfacción de sus clientes y en una mejora de la motivación de sus empleados Definición de Calidad La calidad se puede definir como "una característica o atributo de una

cosa". De esta forma se podría decir que la calidad de los productos puede medirse como una comparación de sus características y atributos. Así, este concepto puede aplicarse a cualquier producto. ¿Qué es un modelo de Calidad?

Los Modelos de Calidad son herramientas que guían a las Organizaciones a la Mejora Continua y la Competitividad dando les especificaciones de que tipo de requisitos deben de implementar para poder brindar productos y servicios de alto nivel. Calidad de Software De acuerdo a la definicion del Instituto de Ingenieros Electricos y

Electronicos (IEEE, Std. 610-1990) “La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificacados y las necesidades o expectativas del cliente o usuario”. Factores que determinan la Calidad el Software:

Corrección. ¿Hace lo que quiero? Fiabilidad. ¿Lo hace de forma fiable todo el tiempo?

Eficiencia. ¿Se ejecutará en mi hardware lo mejor que pueda? Seguridad (Integridad). ¿Es seguro? Facilidad de uso. ¿Está diseñado para ser usado?


Características de las empresas de desarrollo de Software inmaduras En una organización inmadura se presentan las siguientes caracteristicas:

Procesos software normalmente improvisados Si se han especificado, no se siguen rigurosamente Organización reactiva (resolver crisis inmediatas) Planes y presupuestos excedidos sistemáticamente, al no estar

basados en estimaciones realistas Para desarrollar software de calidad se deben corregir estoas practicas erroneas.

Medición de la Calidad de Software Existe necesidad de obtener datos objetivos que ayuden a mejorar la calidad del software. Algunos modelos incluyen métricas para evaluar diferentes atributos de

calidad del producto casi siempre en el nivel del diseño o del código Los modelos de calidad más recientes están orientados a la mejora de procesos Modelo de Gestión de Calidad de Software Un modelo de calidad del software es un conjunto de buenas practicas para el ciclo de vida del software, enfocado en los procesos de gestión y

desarrollo de proyectos. Construir un modelo de calidad es bastante complejo y es usual que estos modelos descompongan la calidad del producto software jerárquicamente en una serie de características y subcaracterísticas que pueden usarse como una lista de comprobación de aspectos relacionados con la calidad. Modelo de Calidad no es una Metodología

Se debe entender que un modelo de calidad no es una metodologia que nos resuelva la vida de forma sencilla y clara, los modelos de calidad nos dicen QUE hacer, no COMO hacerlo Modelos de Calidad de Software Existentes

Existen una variedad de modelos para la gestion de la calidad del software a continuación se presentan algunos de ellos: -CMMI -NORMA ISO/IEC 12007 -Metrica3 -ISO 15504


NORMA ISO/IEC 12007 Esta norma esta orientada a los procesos de ciclo de vida del software de la organización ISO. Establece un proceso de ciclo de vida para el software que incluye procesos

y actividades que se aplican desde la definición de requisitos, pasando por la adquisición y configuración de los servicios del sistema, hasta la finalización de su uso. Los procesos de la norma ISO 12207 se clasifican en tres grandes grupos: Procesos Principales

Adquisición. Suministro. Desarrollo. Explotación. Mantenimiento.

Procesos de Apoyo

Documentación Gestión de la configuración. Aseguramiento de calidad. Verificación. Validación. Revisión conjunta. Auditoría. Resolución de problemas.

Procesos de Gestión Gestión. Infraestructura. Mejora. Formación

Metodología Metrica3 ha sido desarrollada por el Ministerio de Administración Publica de España, es una metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de información para sistemizar las actividades del ciclo de vida de los proyectos software dentro de las Administraciones Públicas. Esta metodología propia está basada en el Modelo de Procesos del Ciclo de

vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination). Esta metodologia esta orientada a procesos.

Aseguramiento de Calidad Metrica3

Las actividades propias de la interfaz de Calidad en MÉTRICA Versión 3

están orientadas a verificar la calidad de los productos.


Objetivos: Reducir, eliminar y lo más importante, prevenir las deficiencias de

calidad de los productos a obtener. Alcanzar una razonable confianza en que las prestaciones y

servicios esperados por el cliente o el usuario queden satisfechas.

NORMA ISO 15504

Es un modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Características - Establece un marco para métodos de evaluación, no es un método o modelo en sí. - Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad.

- Está alineado con el estándar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de los sistemas de software. - Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de ésta última con 15504.


DUODÉCIMA SEMANA – Técnicas de Aseguramiento de la

Calidad

Introducción Desde su definición, la palabra "asegurar" implica afianzar algo, garantizar el cumplimiento de una obligación, transmitir confianza a alguien, afirmar, prometer, comprobar la certeza de algo, cerciorar; de acuerdo con esto, a través del aseguramiento, la organización intenta transmitir la confianza,

afirma su compromiso con la calidad a fin de dar el respaldo necesario a sus productos y/o servicios.

El aseguramiento de la calidad aborda principalmente tres áreas o técnicas:

Métricas del software: para el control del proyecto Verificación y validación: a lo largo del ciclo de vida del

software, incluyendo pruebas y procesos de revisión. Gestión de la configuración del software

Las técnicas de revisión de los productos software y las pruebas

están fundamentalmente orientadas a la detección de defectos en el SW que a la evaluación de aspectos orientados a la calidad.

Esto último es vital para asegurar la calidad, pero como ya hemos visto, la calidad es un concepto complejo y, que depende mucho del

punto de vista con el que se observe.

Este aseguramiento de la calidad se realiza a través de modelos. Los más conocidos son los siguientes:

Modelo de Boehm: modelo de descomposición de características de calidad del software en tres niveles antes de aplicar las métricas: usos principales, componentes intermedios y componentes primitivos.

Modelo factores/criterios/métricas: similar a Boehm, en el que se ha introducido mayor grado de descomposición en cada

nivel. Marco ISO 9126: denominado Evaluación de Productos

Software: Características de calidad y guías para su uso, la calidad se descompone en seis factores.

Paradigma GQM (Goal-Question-Metric): enfoque de medición para evaluar la calidad del software basado en la identificación de objetivos a lograr.

Modelo de Gilb: creación de una especificación de requisitos de calidad para cada proyecto que deben escribir conjuntamente el usuario y el analista.

Modelo CMM (Capability Maturity Model): modelo de capacidad de madurez del SEI (Software Engineering Institute).


Modelo SPICE: (Software Process Improvement and Capability Determination): modelo de valoración de la arquitectura que define los procesos y prácticas aconsejables.

Modelo de Boehm Los componentes o constructores del modelo se centran en el producto final. Se identifican características de calidad desde el punto de vista del usuario.

Modelo factores/criterios/métricas (McCall) ○ Descompone el concepto de calidad en tres usos o capacidades

importantes para un producto de software: ○ Operación ○ Revisión ○ Transición

○ Cada capacidad se descompone en una serie de factores que determinan la calidad en cada una de ellas:

Operación

Facilidad de Uso

Integridad

Eficiencia

Correción o exactitud

Fiabilidad

Revisión

Facilidad de prueba

Facilidad de Mantenimiento

Flexibilidad

Transición

Reusabilidad

Portabilidad

Interoperabilidad


○ Cada factor determinante de la calidad se descompone, a su vez, en una serie de criterios o propiedades que determinan su calidad.

○ Los criterios pueden ser evaluados mediante un conjunto de métricas. Para cada criterio deben fijarse unos valores máximo y mínimo aceptables para cada criterio.

Paradigma GQM (Goals-Question-Metrics) ○ Se basa en la mejora en la definición clara de procesos y productos.

Proporciona la estructura para obtener los objetivos cruciales del proyecto.

○ Consta de tres etapas: ○ Lista de objetivos principales en el desarrollo y mantenimiento del

proyecto.

○ Para cada objetivo obtener las preguntas que deben contestarse para saber si se están cumpliendo los objetivos.

○ Decidir qué medir para poder contestar las preguntas de forma adecuada.

○ Las medidas individuales obtenidas se relacionan para poder ser utilizadas en el contexto del proyecto completo


Modelo de Glib ○ Determinar una lista de características que definen la calidad de la

aplicación. Se distinguen dos tipos: ○ Originales ○ De los modelos tradicionales

○ Las características se pueden medir mediante varias subcaracterísticas o

métricas detalladas. Para cada una de ellas se debe especificar los siguientes conceptos:

○ Nombre y definición de la característica ○ Escala o unidades de medición ○ Recogida de datos o prueba ○ El valor previsto ○ El valor óptimo

○ El valor en el sistema actual ○ Comentarios

Modelo de CMM ○ Describe los principios y prácticas que conducen a mejores productos de

software. Se agrupan en cinco niveles que proporcionan el camino para mejorar la visibilidad y el control:

○ Nivel 1 (Inicial): se definen pocos procesos. ○ Nivel 2 ( Repetible): se establecen los procesos de gestión del

proyecto para hacer un seguimiento del coste, de la planificación y de la funcionalidad.

○ Nivel 3 (Definido): El proceso del software de las actividades de gestión y de ingeniería se documenta, se estandariza y se integra

dentro de un proceso de SW de toda una organización. ○ Nivel 4 (Gestionado): Se recopilan medidas detalladas del

proceso de software y de la calidad del producto. ○ Nivel 5 (Optimización): Mediante un resultado cuantitativo del

proceso y de las ideas y tecnologías innovadoras se posibilita una mejora del proceso.


Modelo SPICE ○ Modelo similar a CMM que también se utiliza para la mejora de procesos

y determinación de la capacidad.

○ Usa dos tipos de practicas: ○ Prácticas base ○ Prácticas genéricas

○ La parte izquierda del diagrama es la Vista funcional:

Suministro al cliente: procesos que afectan al cliente directamente.

Ingeniería: Procesos que especifican, implementan o mantienen el sistema y su documentación.

Proyecto: Procesos que establece el proyecto.

Soporte: procesos de apoyo a la realización de los otros procesos. Organización: procesos relacionados con los objetivos de negocio.

Documents

Control y Calidad de SW Separata