Calidad del software Conceptos de Calidad Calidad … · El modelo presentado por Boehm en 1978 ... modelo de Calidad Sistémica, representados por las propiedades de los requerimientos,

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


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


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


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


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.


NIVELES DE CAPACIDAD. (ISO/IEC, 1997)

Enero 2006 49


Á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


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 2



MAN.3

MAN.1

MAN.4

MAN.2

Principio 1


Principio 2

ORG.5

ORG.2

ORG.6

ORG.3

ORG.7

ORG.4

ORG.1

ORG.8 ORG.9

Principio 1


Principio 2



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…

Documents

Calidad del software Conceptos de Calidad Calidad … · El modelo presentado por Boehm en 1978 ... modelo de Calidad Sistémica, representados por las propiedades de los requerimientos,