Guia de calidad para desarrollo de software
Upcoming SlideShare
Loading in...5
×
 

Guia de calidad para desarrollo de software

on

  • 2,686 views

Ponencia presentada en el III Congreso Nacional de Software Libre

Ponencia presentada en el III Congreso Nacional de Software Libre

Statistics

Views

Total Views
2,686
Views on SlideShare
2,578
Embed Views
108

Actions

Likes
1
Downloads
69
Comments
0

3 Embeds 108

http://campus.uladech.edu.pe 46
url_unknown 40
http://formacionandres.blogspot.com 22

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Guia de calidad para desarrollo de software Guia de calidad para desarrollo de software Presentation Transcript

    • 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 [email_address]
    • 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 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 35% 15% 50 %
    • Crisis del Software
      • 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
    • ¿Porqué existe fracaso?
    • ¿El problema será el Software libre?
    • 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/
    •  
    • SW Libre Seguro Económico Fiable Maduro Modalidad A Distancia Reglamentos ULADECH Ley Universitaria Ministerio De Educación Constitución Política Modalidad A Distancia Reglamentos ULADECH Ley Universitaria Ministerio De Educación Constitución Política
    • 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 2: Realización de la evaluación Parte 5: Un ejemplo de modelo de evaluación de procesos Parte 6: Conceptos y Vocabulario Parte No Normativa 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 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 evaluados Nombre 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 evaluados Nombre 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ón Criterio 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 proceso PA 2.1 Gestión de la realización PA 2.2 Gestión del producto de trabajo CI AI ó CI AI ó CI Nivel 3: Proceso Establecido PA 1.1 Realización del proceso PA 2.1 Gestión de la realización PA 2.2 Gestión del producto de trabajo PA 3.1 Definición del proceso PA 3.2 Despliegue del Proceso CI CI CI AI ó CI AI ó 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 proceso PA 2.1 Gestión de la realización PA 2.2 Gestión del producto de trabajo PA 3.1 Definición del proceso PA 3.2 Despliegue del Proceso PA 4.1 Medición del proceso PA 4.2 Control del proceso CI CI CI CI CI AI ó CI AI ó CI Nivel 5: Proceso en Optimización PA 1.1 Realización del proceso PA 2.1 Gestión de la realización PA 2.2 Gestión del producto de trabajo PA 3.1 Definición del proceso PA 3.2 Despliegue del Proceso PA 4.1 Medición del proceso PA 4.2 Control del proceso PA 5.1 Innovación del proceso PA 5.2 Optimización continua CI CI CI CI CI CI CI AI ó CI AI ó CI
    • ¿Por qué aplicar la norma en una Organización? Motivación para aplicar un modelo de mejora de procesos
    •