III CONGRESO NACIONAL DE SOFTWARE LIBRE

INGENIERÍA DE SISTEMAS

Ing. Andres Epifanía Huerta / ing_sist@hotmail.com

GUÍA DE CALIDAD PARA DESARROLLO DE

SOFTWARE

ISO/IEC 15504

Ing. Andres Epifanía Huerta

ing_sist@hotmail.com

Agenda:• Introducción• Antecedentes• ISO/IEC 15504• El proceso de certificación• Conclusión• Trabajos Futuros• Referencias

El sistema de información no cumple con los procesos que realiza la empresa

35%15% 50 %2009

Inadecuado Con limitaciones Adecuado

LAS EMPRESAS Y LOS SISTEMAS DE INFORMACIÓN

El sistema de información, se limita a operaciones establecidas en su inicio

El sistema de información, se adecua a los procesos y agrega nuevas funcionalidades

Este problema se identificó por primera vez en 1968, año en el que la organización NATO, de EE.UU desarrolló la primera conferencia sobre desarrollo de software, y en la que se acuñaron los términos “crisis del software”.

C. Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la eliminación de “GoTo” y la creación de la programación estructurada.

La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens.

El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb.

El primero sobre análisis de requisitos apareció en 1979

Crisis del Software Crisis del Software

¿Porqué existe fracaso?¿Porqué existe fracaso?

http://openpyme.osl.ull.es/

Conferencista: Ing. Andres Epifanía Huerta ing_sist@hotmail.com /

943786964

Software de Gestion Empresarial Abanq(es un software de tipo ERP orientado a la administración,

gestión comercial: Descargar)

Xendra(ERP localizado en el Peru, apatado a la realdiad peruana) http://www.xendra.org/

OpenBravo(es una aplicación de código abierto de gestión empresarial del tipo ERP destinada a empresas de pequeño y mediano

tamaño: Demo) OpenErp(Es un completo sistema de gestión empresarial (ERP) que

cubre las necesidades de las áreas de contabilidad, ventas, compras, y almacén e inventario, entre otras) http://openerp.com/

OpenCities(Administracion Publica-Descargar) http://www.open-cities.com/

Modalidad A Distancia

ReglamentosULADECH

Ley Universitaria

Ministerio De

Educación

Constitución Política

Modalidad A Distancia

ReglamentosULADECH

Ley Universitaria

Ministerio De

Educación

Constitución Política

SW Libre

Seguro

Económico

Fiable

Maduro

Podemos corregir en el acto• Los fallos en los sistemas de información, tanto de

funcionalidad como de seguridad, no son algo excepcional para los usuarios.

• Actualmente, más de la mitad de los errores pasan desapercibidos hasta la última fase del proceso de desarrollo del producto, e incluso hasta que llega a

manos de los usuarios.• Algunos desarrolladores se escudan en la complejidad

de los requerimientos. A mayor complejidad, mayor número de errores

Ing. Andres Epifanía Huerta / ing_sist@hotmail.com

Las excepciones son excepciones

• El 80 por ciento de los sistemas de información, una vez que son entregados, comienzan a identificar y corregir defectos.

• Algunos desarrolladores, opinan y fundamentan, que es parte del proceso de maduración del sistema.

• Los usuarios que detentan, los errores y defectos comienzan a cuestionar los sistemas.

Funcionalidad Seguridad Fiabilidad

Instituto nacional de estándares y tecnologías. • Según el NIST, el mercado de software está plagado de productos

deficientes debido a la utilización de herramientas de test estándares, datos de referencia, implementaciones y métricas que no han superado procesos

de certificación rigurosos. • Por su parte Raynald Korchia, director general de QA, empresa dedicada a

la calidad de software con la externalización de las pruebas, considera que no se utilizan lo suficiente las herramientas de testeo de software “y esto conduce problemas de mala calidad, retraso y aumento del coste. Estas

herramientas hacen que la comprobación sea más rápida y fiable”. Korchia destaca la importancia de la preparación de pruebas desde el principio,

“aunque esta parte no se ve fundamental y se está reduciendo, lo cual es un error porque los costes que genera el software de mala calidad pueden

ser mayores que los de las pruebas. • Una implementación inadecuada puede llegar a afectar a la imagen de la

compañía.

¿Cómo medir la calidad?• La calidad del software, puede medirse a

través de las siguientes características: funcionalidad, fiabilidad, rendimiento, usabilidad, seguridad, soportabilidad, localizabilidad.

¿Qué es ISO 15504?

Norma que proporciona un marco de trabajo para la evaluación de procesos

Establece los requisitos mínimos para realizar una evaluación que asegure la consistencia de las valoraciones obtenidas

Objetivo de la evaluación del proceso: conocer la capacidad de los procesos de una organización.

Características Puede ser utilizado por una área de desarrollo

de Software. Actualmente tiene 10 partes (1-7 completas, 8-10 en

desarrollo) Comprende: evaluación de procesos, mejora de

procesos, determinación de capacidad. Equivalente y compatible con CMMI

Estructura – Partes de la Norma

Estructura del estándar ISO/IEC 15504

Parte Normativa

Parte 1: Conceptos y Vocabulario

Parte 1: Conceptos y Vocabulario

Parte 2: Realización de la evaluación

Parte 2: Realización de la evaluación

Parte 5: Un ejemplo de modelo de evaluación

de procesos

Parte 5: Un ejemplo de modelo de evaluación

de procesos

Parte 6: Conceptos y Vocabulario

Parte 6: Conceptos y Vocabulario

Parte No Normativa

Parte 3: Guía para la realización de la

evaluación

Parte 3: Guía para la realización de la

evaluación

Parte 4: Guía sobre el uso para la mejora y

determinación de calidad del proceso

Parte 4: Guía sobre el uso para la mejora y

determinación de calidad del proceso

Parte 7: Evaluación de la madurez de una

organización

Parte 7: Evaluación de la madurez de una

organización

Estructura - Niveles de Madurez

Niveles de madurez de la parte 7 del estándar ISO/IEC 15504

¿Qué ventajas aporta este modelo a las empresas de desarrollo y mantenimiento software?

• Pueden contar con una norma ISO, internacional y abierta. • Integración más fácil con otras normas ISO del sector TIC, como son: ISO

27000 de seguridad, ISO 20000 de servicios de IT e ISO 9000. • Pueden certificar sus sistemas. • Utiliza un modelo de buenas prácticas actualizado y específico de

desarrollo software (ISO 12207:2008). • Evalúa por niveles de madurez, la evaluación más extendida entre los

modelos de mejora. • Normalmente, tiene un menor coste de certificación que otros modelos

similares. • Su certificación puede ser revalidado por entidades certificadoras, más

prestigiosas.

1. Concepto de Vocabulario

2. Realización de la evaluación.

3. Guía para la realización de la evaluación

4. Mejoramiento y calidad de los procesos

5. Evaluación de los procesos

6. Conceptos y Vocabularios

7. Evaluación y madurez de la organización

Concepto de vocabulario es importante• El problema no solamente radica en la comunicación.  Muchas

metodologías pretenden dar herramientas eficaces para que la comunicación sea clara y concisa, pero cuando las ideas no se tienen claras, de nada sirve explicarlas.

• El Cliente no tiene clara las cosa porque no maneja aún los conceptos de nuevos proyectos. Esto es normal, se necesita tener en cuenta para mejorar la información y la etapa de rápido aprendizaje del cliente.

•MODELO DE EVALUACIÓN•PROCESOS EVALUADOS•CRITERIOS DE EVALUACIÓN•ATRIBUTOS DEL PROCESO Y SU CALIFICACIÓN•FASES DE CERTIFICACIÓN •PROCESOS DE AUDITORIA PARA LA CERTIFICACIÓN•ENTIDADES CERTIFICADORAS.•¿POR QUÉ APLICAR LA NORMA EN UNA

ORGANIZACIÓN?

El Proceso de Certificación

Procesos evaluadosNombre Objetivo

Proceso de Suministro (SUM)

Proporcionar al cliente un producto o servicio que cumpla con los requisitos acordados.

Proceso de Definición de los Requisitos de

Usuario (RQU)

Definir los requisitos del sistema para proporcionar los servicios necesarios a usuarios y otros afectados en un entorno definido.

Proceso de Análisis de los Requisitos del Sistema (RQSIS)

Transformar los requisitos de los stakeholders en un conjunto deseado de requisitos técnicos del sistema que guiarán el diseño del sistema.

Proceso de Gestión del Modelo del Ciclo de

Vida (MCV)

Definir, mantener y asegurar la disponibilidad de políticas, procesos y modelos del ciclo de vida, para que sean utilizados por la organización.

Proceso de Planificación del

Proyecto (PP)

Elaborar y comunicar los planes de proyecto, de forma efectiva y viable.

Procesos evaluadosNombre Objetivo

Proceso de Evaluación y Control del Proyecto

(ECP)

Determinar el estado del proyecto y asegurar que se realiza de acuerdo con los planes y el calendario establecido, presupuestos planificados y satisfaciendo los objetivos técnicos.

Proceso de Gestión de la Configuración del

Software (GCS)

Establecer y mantener la integridad de los elementos que forman el producto software de un proceso o proyecto y ponerlos a disposición de las partes interesadas.

Proceso de Gestión de la Configuración (GC)

Establecer y mantener la integridad de todos los productos de trabajo identificados de un proyecto o proceso y ponerlos a disposición de las partes interesadas.

Proceso de Medición (MED)

Recoger, analizar e informar sobre los datos relativos a los productos desarrollados y procesos implementados dentro de la unidad organizacional, para apoyar una gestión efectiva de los procesos y demostrar objetivamente la calidad de los productos.

Proceso de Aseguramiento de la

Calidad Software (ACS)

Asegurar que los productos de trabajo y los procesos cumplen con las disposiciones y planes predefinidos.

Criterios de evaluaciónCriterio Evaluador Entre Descripción

CI (Completamente Implementado)

86% a 100%

Hay evidencias de una completa y sistemática aproximación, y logro total, al cumplimiento del atributo en el proceso evaluado.

AI (Ampliamente Implementado)

51% a 85% Hay evidencias de una aproximación sistemática y logro significativo, al cumplimento del atributo en el proceso evaluado. Sin embargo pueden presentarse inconsistencias en algunas áreas de trabajo.

PI (Parcialmente Implementado)

16% a 50% Hay evidencia de alguna aproximación y algún logro, al cumplimiento del atributo en el proceso evaluado, pero algunos aspectos del proceso no se han implementado completamente.

NI (No implementado)0% a 15% Hay muy poco o incluso ninguna evidencia de

cumplimiento del atributo definido en el proceso evaluado.

Atributos del proceso y su Calificación

Nivel de Capacidad

Atributo de proceso (PA) Calificación

Nivel 1: Proceso Realizado

PA 1.1 Realización del proceso AI ó CI

Nivel 2: Proceso Gestionado

PA 1.1 Realización del procesoPA 2.1 Gestión de la realizaciónPA 2.2 Gestión del producto de trabajo

CIAI ó CIAI ó CI

Nivel 3: Proceso Establecido

PA 1.1 Realización del procesoPA 2.1 Gestión de la realizaciónPA 2.2 Gestión del producto de trabajoPA 3.1 Definición del procesoPA 3.2 Despliegue del Proceso

CICICIAI ó CIAI ó CI

Atributos del proceso y su Calificación

Nivel de Capacidad Atributo de proceso (PA) Calificación

Nivel 4: Proceso Predecible

PA 1.1 Realización del procesoPA 2.1 Gestión de la realizaciónPA 2.2 Gestión del producto de trabajoPA 3.1 Definición del procesoPA 3.2 Despliegue del ProcesoPA 4.1 Medición del procesoPA 4.2 Control del proceso

CICICICICIAI ó CIAI ó CI

Nivel 5: Proceso en Optimización

PA 1.1 Realización del procesoPA 2.1 Gestión de la realizaciónPA 2.2 Gestión del producto de trabajoPA 3.1 Definición del procesoPA 3.2 Despliegue del ProcesoPA 4.1 Medición del procesoPA 4.2 Control del procesoPA 5.1 Innovación del procesoPA 5.2 Optimización continua

CICICICICICICIAI ó CIAI ó CI

¿Por qué aplicar la norma en una Organización?

Motivación para aplicar un modelo de mejora de procesos