Calidad del software Conceptos de Calidad Calidad … · El modelo presentado por Boehm en 1978 ......
Transcript of Calidad del software Conceptos de Calidad Calidad … · El modelo presentado por Boehm en 1978 ......
Enero 2006 2
Contenido de la sesión
Calidad del softwareConceptos de CalidadCalidad del productoCalidad del proceso
Enero 2006 3
¿QUÉ ES CALIDAD DEL SOFTWARE?
Pressman (Pressman, 1998) define la calidad del software como:“la concordancia con los requerimientos funcionales y de rendimiento
explícitamente establecidos, con los estánda-res de desarrollo explícitamente documentados y con las características implícitas que
se espera de todo software desarrollado profesionalmente”.
En la definición de la calidad del software pueden estar involucrados aspectos como la ausencia de defectos, aptitud para el uso, seguridad, confiabilidad y reunión de especificacio-nes. Sin embargo, hay algo importante que se debe tener presente: la calidad del software debe ser construida desde el comienzo, no es algo que puede ser añadido después.
Para que el producto final sea de calidad, el proceso por medio del cual éste es elaborado debe ser también de calidad.
Enero 2006 4
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARESridharan (Sridharan, 2000) indica que mientras el software que se está desarrollado reúne los requerimientos y su desempeño es el esperado, es preciso que se supervisen las actividades de desarrollo del software y su rendimiento, en distintas oportunidades durante cada fase del ciclo de vida. Este es el papel del aseguramiento de la calidad del software.
Hay tres (3) aspectos muy importantes con relación al aseguramiento de la calidad del software: (Wiegers, 1990)
La calidad no se puede probar, se construye.El aseguramiento de la calidad del software no es una tarea que se realiza en una fase particular del ciclo de vida de desarrollo.Las actividades asociadas con el aseguramiento de la calidad delsoftware deben ser realizadas por personas que no estén directamente involucradas en el esfuerzo de desarrollo.
Enero 2006 5
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWAREPressman (2004) considera que el aseguramiento de la calidad delsoftware comprende una gran variedad de tareas asociadas:
Preparar u plan de aseguramiento de la calidad del software paraun proyecto.Participar en el desarrollo del proceso de descripción del proyecto de software.Revisar las actividades de ingeniería del software para verificar su consistencia con el proceso de software definido.Auditar el producto de software para verificar el cumplimiento del proceso de software definidoAsegurar que las divergencias en el trabajo de software sean documentadas de acuerdo a los estándares definidos.Alamacenar cualquier inconformidad y reportarla a la gerencia media.
Enero 2006 6
CONTROL DE LA CALIDAD DEL SOFTWARESegún Monsalve (1998), el control de la calidad se relaciona con la vigilancia permanente de todo el proceso de desarrollo y el ciclo de vida del software. Se logra mediante la observación constante del cumplimiento de cada una de las fases y actividades involucradas en el proceso de desarrollo.Para realizar un control de calidad deben ejecutarse frecuentes inspecciones a las metodologías de trabajo y a el uso de las herramientas, revisiones de prototipos y de las pruebas formales de los productos finales.El control de la calidad permite realizar las rectificaciones necesa-riasa cualquier falla encontrada durante el proceso de desarrollo.Adicionalmente, el asegurar la calidad en las primeras fases delproceso de desarrollo del software implica que los costos del control en las etapas posteriores tiende a disminuir al tener menos aspectos que controlar, además de que la calidad estaría asegurada en susbases.
Enero 2006 7
AUDITORÍA DE LA CALIDAD DEL SOFTWARE
La auditoría de la calidad se utiliza para descubrir y detener los errores del software. Se lleva a cabo para monitorear eventos espe-cíficos, o bien para revisar todas las actividades de un sistema.Las auditorías permiten garantizar la calidad del software: luego de llevar a cabo una auditoría de calidad, es más fácil mantener un registro con las deficiencias presentadas.La auditoría de la calidad del software tiene tres (3) metas de seguridad importantes:
1) Revisar los modelos de acceso a los componentes, las historias de acceso a los procesos y el uso de los mecanismos de protección soportados por el sistema.
2) Descubrir los usuarios frecuentes y esporádicos que se esfuerzanpor desviar los mecanismos de protección.
3) Descubrir cualquier uso de privilegios que pueden ocurrir cuandoun usuario asume una funcionalidad con privilegios mayores que el suyo propio.
Enero 2006 8
CALIDAD DEL PRODUCTO DE SOFTWAREPara Monsalve (1998), la principal meta de un equipo desarrollador de software debe ser siempre producir software de calidad; para ello, se deben tener en cuenta dos (2) ideas muy importantes:
Los productos de software son realizados por personas y para personas.Muchas personas asocian la calidad a un atributo exclusivo del producto y que comienza a considerarse una vez que se escriben las primeras líneas de código.
La calidad que pueden alcanzar los productos de software, y en general cualquier tipo de producto, está sometida a la manera cómo se desarrolla cada una de las etapas de la vida del producto, iniciándose con la concepción de la idea del producto hasta la entrega final y mantenimiento del mismo.
Enero 2006 9
CALIDAD DEL PRODUCTO DE SOFTWARELa calidad del producto de software involucra actividades como:
Administración de la calidad.
Uso de tecnología de Ingeniería de Software eficiente.
Aplicación de técnicas formales a lo largo de todo el proceso de desarrollo.
Minimización de las variaciones entre productos.
Verificación y pruebas formales en las diferentes etapas del desarrollo.
Control de la documentación.
Correcto mantenimiento y servicios de post-venta.
Enero 2006 10
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
La calidad está presente en todas las etapas del proceso de desa-rrollo de los productos de software. A grandes rasgos:
CALIDAD EN EL DISEÑO. Se basa en definir un listado de especificaciones a seguir; involucra la descripción de los procesos de desarrollo, tareas y responsabilidades de los equipos de desarrollo; dichos procesos pueden estar estandarizados.CALIDAD EN LA IMPLEMENTACIÓN. Se enfoca al grado de cumplimiento de los requerimientos de diseño. Si los requerimientos está bien definidos y especificados, el cumplimiento de la calidad en esta fase no debe tornarse difícil.CALIDAD EN LA SATISFACCIÓN. Es la medida de calidad apreciada por los usuarios finales de los productos de software. No puede esperarse calidad en esta fase si no hubo preocupación por ella en las etapas anteriores.
Enero 2006 11
Modelos de calidad de producto de softwareEl modelo propuesto por Mc Call en 1977 (Gillies, 1997) y está orientado a los desarrolladores de Sistemas, para ser utilizado durante el proceso de desarrollo.El modelo presentado por Boehm en 1978 (Pfleeger, 1998).Hewlett-Packard lo presenta en 1987, desarrollando un conjunto de factores de cali-dad de software (funcio-nalidad, facilidad de empleo, fiabilidad, rendimiento y capacidad de soporte) y sus atributos.En 1996, Dromey (Pfleeger, 1998) sugiere una técnica genérica para construir un modelo de calidad. El mismo resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo documentos de requerimientos, guías de usuarios, diseños, y código), las propiedades tangibles de los componentes y las propiedades tangibles de la composición de los componentes.ISO/IEC 9126El modelo sistémico de la calidad del producto del LISI (Ortega,2000)
Enero 2006 12
ISO 9126ISO Technical Committee produce un estándar compuesto por un grupo de características, tomando en cuenta que debían:•Describir la calidad del producto con un mínimo de coincidencias.•Formar un conjunto no mas de 8 características por razones de claridad y manejo•Identificar, con mayor refinamiento, las áreas de los atributos del software.•Considerar todos los aspectos de la calidad del software.
Especifica 6 características, con sus respectivassubcaracteristicas, para La calidad interna y externa.
Incluye Calidad Interna, Calidad Externa y Calidad en uso.
Enero 2006 13
ISO 9126 - USO•Identificar los requerimientos del software
•Identificar los objetivos del diseño de software
•Identificar los objetivos de las pruebas del software.
•Identificar los criterios de aceptación de calidad.
•ISO 15504 :calidad del software en los procesos de cliente-suministro.
•ISO 12207 definición de los requerimientos de calidad del software el la primera fase de su ciclo de vida
Enero 2006 14
Calidad Interna es una reflexión de la filosofía del diseño y su estrategia.
Calidad Externa es la calidad del producto entregado. Es evaluado por pruebas en ambientes simulados.
Calidad en Uso es la calidad del software vista desde un ambiente en particular.
DescritasDescritas porpor metricasmetricas internasinternas, , externasexternas o en o en usouso de lde las as caractercaracteríísticas de ISO 9126sticas de ISO 9126
Definiciones
Enero 2006 15
ISO 9126
Enero 2006 16
ISO 9126 Calidad en el ciclo de vida
Enero 2006 17
CALIDAD DEL PRODUCTO DE SOFTWAREISO/IEC 9126
Presentado en 1992, las características de calidad de los productosde software que establece este estándar de calidad, son:
FUNCIONALIDAD. Existencia de un conjunto de funciones y propiedades específicas establecidas.CONFIABILIDAD. Capacidad del software para mantener su nivel de actuación bajo ciertas condiciones, en un período de tiempo.USABILIDAD. Esfuerzo necesario para el uso y el valor de uso, por un conjunto determinado de usuarios.EFICIENCIA. Relación entre el nivel de desempeño del software y la cantidad de recursos usados bajo ciertas condiciones.MANTENIMIENTO. Esfuerzo necesario para hacer modificaciones específicas.PORTABILIDAD. Habilidad del software para ser transferido de un ambiente a otro.
Enero 2006 18
CALIDAD DEL PRODUCTO DE SOFTWAREISO/IEC 9126
• Adaptabilidad• Exactitud• Interoperabilidad• Complacencia• Seguridad
FUNCIONALIDAD
• Madurez• Tolerancia a fallas
• Recuperabilidad
CONFIABILIDAD
• Comprensibi-lidad
• Aprendizaje• Operabilidad
USABILIDAD
• Comportamiento del tiempo
• Comportamiento de los recursos
EFICIENCIA
• Análisis• Cambio• Estabilidad• Prueba
MANTENIMIENTO
• Adaptabilidad• Instalación• Conformidad• Reemplazo
PORTABILIDAD
ATRIBUTOS QUE ABARCAN LAS CARACTERÍSTICAS DE LA NORMA ISO/IEC 9126
Enero 2006 19
CALIDAD DEL PRODUCTO DE SOFTWAREMODELO ORIENTADO AL PRODUCTO PROPUESTO POR LISI
El modelo presenta aspectos de Efectividad del Producto los cuales son representados por las características externas de alto nivel del modelo ISO 9126: Usabilidad, Funcionalidad, Fiabilidad, Mantenibilidad, Eficiencia y Portabilidad.
Además, incluye elementos de Eficiencia del Producto, según el modelo de Calidad Sistémica, representados por las propiedades de los requerimientos, diseño e implementación del producto, siguiendo el modelo de Dromey.
Por último contempla elementos de Eficiencia y Efectividad del Proceso, los cuales fueron identificados en el Estándar ISO 15504.
Enero 2006 20
CALIDAD DEL PRODUCTO DE SOFTWAREMODELO ORIENTADO AL PRODUCTO PROPUESTO POR LISI
MODELO DE CALIDAD DE SOFTWARE
Diseño
•Usabilidad
•Funcionalidad
•Fiabilidad
•Mantenibilidad
•Eficiencia
•Portabilidad
Requerimientos
Atributos externosAtributos Internos/
Propiedades del Producto
Implementación
Efectividaddel Producto
Eficienciadel Proceso
Eficienciadel Producto
Efectividaddel Proceso
Enero 2006 21
Actividad PrácticaPIENSE – ESCRIBA – COMPARTA
1. De manera individual y en 15 minutos, PIENSE y ESCRIBA la respuesta de lo siguiente:
Escoja un Sistema conocido por Ud. y proponga la instanciación del modelo ISO 9126.
2. A nivel grupal y en máximo 5 minutos, COMPARTA lo que escribió en el paso anterior.
Duración 20 minutos
Enero 2006 22
Modelos de calidad de proceso de software
Personal Software ProcessCapability Maturity ModelISO/IEC serie 9000ISO/IEC 15504
Enero 2006 23
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWAREISO 9000
La serie de normas ISO 9000 es un conjunto de documentos que pueden usarse para los propósitos de aseguramiento de la calidad de casi cualquier cosa.Esta norma especifica los requisitos de los sistemas de calidad para ser usados en un contrato entre dos partes que requieren la demostración de la capacidad de un proveedor para diseñar y suministrar un producto determinado.ISO 9000. Normas para la gerencia y el aseguramiento de la calidad. Guía para la selección y uso.ISO 9001. Sistemas de Calidad - Modelo para el asefuramiento de la calidad en el diseño, desarrollo, producción, instalación y servicio.ISO 9002. Sistema de Calidad - Modelo para el aseguramiento de la calidad en la producción e instalación.
Enero 2006 24
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWAREISO 9000
ISO 9003. Sistemas de Calidad - Modelo para el aseguramiento de la calidad en la inspección final y prueba.
ISO 9004. Gerencia de la calidad y elementos del sistema de calidad -Pautas.
ISO 9000-3. Guía para la aplicación de la ISO 9001 al desarrollo, suministro y mantenimiento del software.
Dentro de las ventajas que presenta, se puede mencionar que es bastante conocido por las organizaciones y sus clientes, y sirve de apoyo a los demás estándares.
La crítica más importante es que descuida la etapa de análisis, haciendo énfasis en el diseño y el desarrollo. No fue creado para el tratamiento del software especificamente, por cuanto es una adaptación de las ideas de los procesos de manufactura.
Enero 2006 25
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARECMM (Capability Maturity Model)
Para Le Manh (Le Mahn, 1998), el CMM -creado por el SEI-. Provee a las organizaciones de software de una guía sobre cómo controlar el desarrollo y mantenimiento de sus procesos de software, y cómo evolucionar hacia una cultura de ingeniería
Nivel 1:Inicial
Nivel 1:Inicial
Nivel 2:Repetitivo
Nivel 2:Repetitivo
Nivel 3:Definido
Nivel 3:Definido
Nivel 4:Gerenciado
Nivel 4:Gerenciado
Nivel 5:Optimizado
Nivel 5:Optimizado
Procesodisciplinado
Procesoestándar yconsistente
Procesopredecible
Proceso encontinuo
mejoramiento
de software y administración excelente.
Fue diseñado para guiar a las organizaciones en la selección de estrategias de mejoramien-to de los procesos, determi-nando la madurez del proceso actual e identificando los problemas más críticos para la calidad y el mejoramiento del proceso.
Enero 2006 26
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
El CMM está estructurado en cinco (5) niveles de madurez que propor-cionan las bases para el mejora-miento continuo del proceso. Estos niveles definen una escala ordinal para medir la madurez de un proceso y evaluar su capacidad.
La “madurez de un proceso de software” es el grado para el cual un proceso específico está definido, manejado, medido, controlado y es efectivo.
La “capacidad del proceso de software” describe el rango de resultados esperados que se pueden alcanzar siguiendo tal proceso.
Entrada
Entrada
Entrada
Entrada
Entrada
Salida
Salida
Salida
Salida
Salida
5
4
3
2
1
CMM (Capability Maturity Model)
Enero 2006 27
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
A excepción del nivel 1, cada nivel de madurez se descompo-ne en áreas claves del proceso (18 en total).Cada área clave está organiza-da en 5 secciones llamadas características comunes.Las características comunes especifican las práctivas claves (343 en total) que bien dirigi-das, permiten alcanzar los objetivos de las áreas claves.Las áreas claves del proceso indican las áreas en que la organización debería enfocar el mejoramiento de un proceso de desarrollo de software.
NIVELES DE MADUREZNIVELES DE MADUREZ
ÁREAS CLAVES DEL PROCESOÁREAS CLAVES DEL PROCESO
RASGOS COMUNESRASGOS COMUNES
PRÁCTICAS CLAVESPRÁCTICAS CLAVES
Proceso deCapacidad
Metas
Implementacióno
Institucionalización
Infraestructurao
Actividades
indican contienen
alcanzan organizadas por
contienendirigen
describen
CMM (Capability Maturity Model)
Enero 2006 28
NIVEL 1no provee un ambiente estable para desarrollar y mantener software. los proyectos usualmente abandonan los procedimientos planificados el éxito depende de contar con un gerente excepcional y un heróico equipo de software. Cronogramas, presupuestos, funcionalidad y calidad del producto son generalmente imprevisibles.
Actividad ResultadosPara producirNivel1:
Simplemente hace
Enero 2006 29
NIVEL 2
las políticas para la gerencia de un proyecto de software y losprocedimientos para llevar a cabo esas políticas están establecidas. la planificación y la gerencia de nuevos proyectos se basan en la experiencia han instalado controles básicos de gerencia de software. los compromisos reales del proyecto se basan en los resultados observados en proyectos previos los gerentes del software para un proyecto le hacen seguimiento a los costos del software, los cronogramas y la funcionalidadel proceso de capacidad de software de se resume como una disciplina porque la planificación y el rastreo de proyectos de software son estables
Enero 2006 30
ActividadPara producir
Nivel 2:Piense antes de actuary piense despues de actuar paraasegurase que hizolo correcto
Planifica
Evalua
Para mejorar
Resultados
NIVEL 2
Enero 2006 31
NIVEL 3
los procesos están documentados e éstos integrados en un todo coherentehay un equipo de personas que es responsable por el proceso de softwareun programa de instrucción a lo largo de la organización es implementado los compromisos reales del proyecto se basan en los resultados observados en proyectos previos los gerentes del software para un proyecto le hacen seguimiento a los costos del software, los cronogramas y la funcionalidadel proceso de capacidad de software de se resume como una disciplina porque la planificación y el rastreo de proyectos de software son estables
Enero 2006 32
Estandards Actividad ResultadosPara producir
Nivel 3
Use lasleccionesaprendidas
Planifica
Evalua
Para mejorar
NIVEL 3
Enero 2006 33
NIVEL 4
la organización establece metas cuantitativas de calidad la productividad y la calidad son medidas por actividades importantes se tiene una base de datos de todos los proyectos a lo largo de la organizaciónLos riesgos involucrados debido a la curva de aprendizaje del dominio de una nueva aplicación son conocidos y cuidadosamente manejados.El proceso de capacidad se resume como predecible porque el proceso es medido y opera dentro de márgenes medibles. Los productos del software son predecibles como de alta calidad .
Enero 2006 34
Estandards Actividad ResultadosPara producir
Nivel 4
Predices losresultados y generas lasoportunidadesparaobtenerlos Planifica
Evalúa
Para mejorar
Para difundirlos
NIVEL 4
Enero 2006 35
NIVEL 5
la organización entera se enfoca en procesos de mejora continuatiene el propósito de identificar debilidades y fortalecer de manera proactiva el procesoLas innovaciones que aprovechan lo mejor de la práctica de la ingeniena del software son identificadas y transferidasEl proceso de capacidad se resume como un mejoramiento continuo porque las organizaciones se esfuerzan continuamente para mejorar el rango de sus procesos de capacidad, trayendo como consecuencia mejoramiento de la ejecución de sus proyectos.
Enero 2006 36
Estandards Actividad ResultadosPara producir
Nivel 5
Usa lasleccionesaprendidaspara tenermás leccionesaprendidas...
Planifica
Evalua
Para mejorar
Para difundirlosPara mejorar
NIVEL 5
Enero 2006 37
Categorías Gerencia Organizacional Ingeniería
Niveles
1 Inicial
2 Repetible
3 Definido
4 Gerenciado
5 Optimizado
Proceso Ad Hoc
Gerencia de software integradoCoordianción Intergrupal
Gernecia de losRequerimientosGerencia del Proyectode Software Planficación del Proyecto de Software Gerencia de ContratistasAseguramiento de la Calidad del SoftwareGerencia de Configuraciones
Enfasis en la organzación porprocesoDefinición del ProcesoEntrenamiento
Ingenieria de Software de productosInspecciones
Gerencia de la Calidaddel Software
Gerencia Cuantitativa del Software
Gerencia de CambiosTecnológicosGerencia de Cambios Prevención de Defectos
Enero 2006 38
Areas Claves Nivel 2
Gerencia de Requerimientos
Planificacion Proyecto de Software
Gerencia de Configuraciones
Aseguramiento de la Calidad del Software
Gerencia de SubcontratistasSeguimiento Proyecto de Sw
Enero 2006 39
1. Los requeirmientso del software identificados son controlados paraorientar la ingeniería del software y su gerencia
2. Planes del proyecto, productos y actividades son consistentes con losrequerimientos identificados.
PropósitoEstablecer un entendimientocomún entre el cliente y losrequerimientos del proyecto de software que direccionarán el proyecto.
Alcance
Metas
Implica establecer y mantener un acuerdo con el cliente con relacion a los requerimientos del proyecto de softwareEl acuerdo es la base para las estimaciones, planificacion, desempeño y seguimiento de las actividades del proyecto
Area Clave: Gerencia de Requerimientos
Enero 2006 40
1. Las estimaciones se usan paraplanificar y hacerle seguimiento al proyecto.
2. Las actividades y los acuerdos se documentan.
Propósito
AlcanceImplicaDesarrollar estimaciones para la ejecución de los trabajosEstablecer los acuerdos necesariosDefinir un plan de trabajoEl Plan provee las bases para iniciar el esfuerzo de trabajo y sugerencia.
Metas
Establecer un plan razonable parahacer la ingenieríadel software y gerenciar el proyecto.
Area Clave: Planificación del Proyecto de Software
Enero 2006 41
Area Clave: Seguimiento al Proyecto de Software
1.El desempeño y los resultadosactuales tienen un seguimiento
2. Las acciones correctivas se tomancuando hay desviaciones
3. Los cambios (en los planes) son resultado de un acuerdo entre losafectados.
Propósito
Alcance
Implica:Comparar resultados versus acuerdos, y estimacionesAjustar los planes
MetasTener una visión clara del progreso del proyectoafin de gerenciarlo y tomar las accionesadecuadas ante lasdesviaciones.
Enero 2006 42
1.Se planifican actividades de ACS2. Se verifican objetivamente que los
productos y las actividades se ajustan a los estándares.
3. Los grupos y personas afectados son informados de los resultados..
4. Los no acuerdos se remiten a losgerentes.
PropósitoTener una gerenciacon vision apropiadadel proceso a ser seguido y del producto a obtenerse.
Alcance
Metas
ImplicaRevisar los productos para garantizar que cumplen con los estandarespropuestosTener a disposición del proytecto y otros gerentes los resultados de lasrevisiones
Area Clave: Aseguramiento de la Calidad del Software
Enero 2006 43
1. Las actividades de GCS se planifican
2. Los productos de software seleccionados, se identifican, controlan y custodian.
3.Se controlan los cambios.4. Se le informa a los afectados de los
cambios. .
Porpósito
Alcance
MetasMantener la integridadde los productos de software a lo largo del ciclo de vida.
InvolucraIdentificar unidades de configuraciónConmtrolar los cambios sitemáticamenteMantener la integridad a todo lo largo del cilo de vida
Area Clave :Gerencia de Configuración del Software
Enero 2006 44
1. Se seleccionan contratistasadecuados.
2.Se logran acuerdos entre ellos.3. Mantenemos excelentes
comunicaciones.4. Se hace seguimientos a los resultados
del contratistas versus los acuerdos.
Propósito
Alcance
MetasSeleccionar contratistasde calidad idónea y gerenciarlos.
Implica:Seleccionar contratistasEstablecer acuerdosHacer seguimiento y revisiones a los resultados de loscontratistas
Area Clave: Gerencia de Subcontratistas
Enero 2006 45
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARESPICE (Software Process Improvement and Capacitability dEtermination)
Según la ISO/IEC (ISO/IEC, 1997), SPICE es un modelo para la evaluación de procesos de software que se encuentra dentro de los documento de la ISO y ha ido evolucionando hacia un proyecto de estándar ISO 15504.La arquitectura del modelo contiene dos jerarquías:
Arquitecturadel modelo
Categoríadel proceso
Categoríadel proceso
ProcesoProceso
Prácticabase
Prácticabase
Nivel decapacidad
Nivel decapacidad
Característicascomunes
Característicascomunes
Prácticagenérica
Prácticagenérica
El lado izquierdo consiste en la categoría de procesos, compuestos por procesos y éstos están compues-tos por prácticas bases.Los procesos son evaluacos en términos del lado derecho. Los procesos pueden ser evaluados a un nivel de capacidad; los niveles de capacidad están compuestos por características comunes; las caracte-rísticas comunes, a su vez, están compuestas por prácticas genéricas.
Enero 2006 46
ENG.2 Mantenimiento del Sistema y el Software
ENG.1 DesarrolloAnálisis y diseño de los Construcción del Software.requerimientos del Sistema.
Integración del Software.Análisis de los requerimientos de Software. Pruebas al Software.
Diseño del Software. Integración y pruebas delSistema.
Ciclo de Vida Primario
SUP.1 Documentación
SUP.2 Gestión de configuración
SUP.3 Aseguramiento de calidad
SUP.7 Auditoria
SUP.6 Revisión conjunta
SUP.5 Validación
SUP.4 Verificación
SUP.8 Resolución de problemas
Ciclo de Vida de Apoyo
Modelos de Certificación-ISO/IEC 15504
CUS.3 Licitar requerimientos
CUS.1 Adquisición CUS.2 Proveedor
Preparación de la adquisiciónSelección del proveedorMonitoreo del proveedorAceptación del cliente
CUS.4 Operación
Uso operacional
Soporte al cliente
CUS.1 Adquisición
Enero 2006 47
ORG.1 Lineamientos organizacionales
ORG.3 Gestión de recursos humanos
ORG.4 Infraestructura
ORG.5 Medición
ORG.6 Reuso
ORG.2 Mejoramiento Establecimiento del procesoValuación del procesoMejoramiento del proceso
Ciclo de Vida Organizacional
MAN.2 Gestión del proyecto
MAN.3 Gestión de calidad
MAN.4 Gestión de riesgo
MAN.1 Gestión
Modelos de Certificación-ISO/IEC 15504
Enero 2006 48
NIVELES DECAPACIDAD DESCRIPCIÓN
0NO REALIZADO
El proceso no tiene ninguna característica común. Hay fracaso general pararealizar las prácticas bases en el proceso. No hay productos de trabajo orendimientos del proceso fácilmente identificables.
1REALIZADO
INFORMALMENTE
Generalmente se realizan prácticas bases del proceso. La actuación de estasprácticas bases no puede planearse rigurosamente. La actuación depende delconocimiento individual y el esfuerzo. Los individuos dentro de la organizaciónestán de acuerdo que esta acción debe realizarse y desde cuando. Hay productosde trabajo identificables para el proceso.
2PLANIFICADO Y
SEGUIDO
En el proceso, las prácticas bases se planifican y se siguen. Se verifica laactuación según los procedimientos especificados. Los productos de trabajoconforman los estándares especificados y los requisitos.
3BIEN DEFINIDO
Las prácticas base son realizadas según un proceso bien definido que usaversiones aprobadas, ajustadas a los estándares y a los procesos documentados.
4CUANTITATIVAMENTE
CONTROLADO
Se recolectan y analizan medidas detalladas de ejecución. Esto lleva a unacomprensión cuantitativa de la capacidad del proceso y una habilidad mejoradaspara predecir su actuación. La actuación se maneja objetivamente. La calidad delos productos de trabajo es cuantitativamente conocida.
5CONTINUAMENTE
MEJORADO
Se establece la efectividad del proceso cuantitativo y las metas de eficacia para laejecución., basado en las metas comerciales de la organización. La mejoracontinua del proceso contra estas metas es habilitada por “feedback” desde laejecución de procesos definidos y manejando ideas y tecnologías innovadoras.
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARESPICE (Software Process Improvement and Capacitability dEtermination)
NIVELES DE CAPACIDAD. (ISO/IEC, 1997)
Enero 2006 49
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARESPICE (Software Process Improvement and Capacitability dEtermination)
ÁREAS GENERALES DE ACTIVIDAD. CATEGORÍAS DE PROCESOS. (ISO/IEC, 1997)
El Modelo SPICE fue ideado pensando en las particularidades que implica el desarrollo de software, es decir, fue diseñado especialmente para software
CATEGORÍADEL PROCESO DESCRIPCIÓN
CLIENTE-PROVEEDOR
Procesos que directamente impactan al cliente, desarrollo, soporte ytransición del software al cliente.
INGENIERÍAProcesos que directamente especifican, llevan a cabo, o mantienen, unsistema y la documentación del usuario.
PROYECTOProcesos que establecen el proyecto, coordinan y manejan los recursospara elaborar un producto o proporcionar servicios que satisfacen alcliente.
SOPORTEProcesos que habilitan y apoyan la actuación de los otrs procesos enun proyecto.
ORGANIZACIÓNProcesos que establecen las metas comerciales de la organización ydesarrollan el proceso, el producto y los recursos determinador, queayudarán a que la organización logre sus metas comerciales.
Enero 2006 50
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWAREPSP (Personal Software Process)
Hayes (Hayes, 1997) define al PSP como una medida del proceso de software diseñado para ser usado individualmente por los ingenieros de software y, al igual que el CMM, el PSP está basado en los principios del mejoramiento de procesos.
Mientras CMM se enfoca en el mejoramiento de la capacidad organizacional, el PSP se enfoca en la ingeniería individual y extiende los procesos y el control gerencial a los ingenieros de software; ásí, estos pueden desarrollar utilizando un enfoque disciplinado y estructurado.
El PSP está estructurado en siete niveles. Cada nivel se construye sobre el anterior añadiendo algunos pasos; esto minimiza el impacto de los cambios de los procesos en los ingenieros, ya que adaptan las nuevas técnicas a las prácticas existentes.
Las medidas que se introducen en cada nivel, están basadas en: tiempo de desarrollo, defectos y tamaño de los programas.
Enero 2006 51
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARECubo de Calidad Sistémica
Callaos y Callaos (Callos y Callaos, 1996) plantean que la calidad del diseño debe ser sistémica, realmente calidad total.
El sistema diseñado (producto) es diferente a las actividades humanas (proceso) a través del cual el producto de sistema es desarrollado.
Tanto el producto como el proceso deben ser eficientes y efectivos en su diseño; de esta relación se desprenden cuatro (4) clases de calidad: eficiencia del producto, efectividad del producto, eficiencia del proceso y efectividad del proceso.
Cada una de las cuatro (4) clases de calidad dependen de las otras. En términos del paradigma de investigación de operaciones, no sepuede maximizar una de ellas independientemente de las otras; elóptimo global no necesariamente es el mismo óptimo local y por lo general, el óptimo global no coincide con el óptimo local.
Enero 2006 52
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARECubo de Calidad Sistémica
Callaos y Callaos (Callos y Callaos, 1996) diferencian entre las clases de calidad según quién la reciba (cliente) y quién la perciba (usuario). La calidad total en el diseño debe ser orientada a ambos: al usuario y al cliente.
CUBO DE CALIDAD SISTÉMICA DEANÁLISIS Y SÍNTESIS DE SISTEMAS DE INFORMACIÓN
(Callaos y Callaos, 1996)
Eficienciadel
proceso
Efectividaddel
proceso
Eficienciadel
producto
Efectividaddel
producto
Cliente
Usuario
Enero 2006 53
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWAREMODELO ORIENTADO AL PROCESO PROPUESTO POR LISI
La solución propuesta establece un modelo que integra el enfoque de Calidad Sistémica (base conceptual), con las características presentes en el modelo de procesos de SPICE.
El modelo propuesto presenta una estructura compleja que está definida por niveles, donde cada nivel superior esta conformado por elementos del nivel inferior. Los niveles son:
Nivel 0: Ciclos de Vida.
Nivel 1: Categorías.
Nivel 2: Procesos.
Nivel 3: Principios.
Nivel 4: Bases Prácticas.
Enero 2006 54
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
MODELO ORIENTADO AL PROCESO PROPUESTO POR LISICiclo de Vida
PrimarioCiclo de Vida de
ApoyoCiclo de Vida
OrganizacionalNivel 0
CategoriaCliente_Proveedor
CategoríaIngeniería
Categoríade Gestión
Categoríade Soporte
CategoríaOrganizacional
Nivel 1
Principio 1
Principio 3 Principio 4
Principio 2
Nivel 2
Nivel 3
Nivel 4
ENG.2
Categoríaorganizacional
ENG.1
CUS.3
CUS.1
CUS.4
CUS.2
SUP.5
SUP.2
SUP.6
SUP.3
SUP.7
SUP.4
SUP.1
SUP.8
Principio 1
Principio 2
Principio 1
Principio 3 Principio 4
Principio 2
Principio 7 Principio 8
Principio 5 Principio 6
MAN.3
MAN.1
MAN.4
MAN.2
Principio 1
Principio 3 Principio 4
Principio 2
ORG.5
ORG.2
ORG.6
ORG.3
ORG.7
ORG.4
ORG.1
ORG.8 ORG.9
Principio 1
Principio 3 Principio 4
Principio 2
Principio 7 Principio 8
Principio 5 Principio 6
Principio 9
Enero 2006 55
Actividad PrácticaPIENSE – ESCRIBA – COMPARTA
1. De manera individual y en 15 minutos, PIENSE y ESCRIBA la respuesta de lo siguiente:
Realice la Lectura 1 y comente con el grupo cómo esto se puede aplicar en su organización.
2. A nivel grupal y en máximo 5 minutos, COMPARTA lo que escribió en el paso anterior.
Duración 20 minutos
Enero 2006 56
Preguntas…