Enero 2006 2
Contenido de la sesión
Calidad del software
Conceptos de Calidad
Calidad del producto
¿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
Enero 2006 4
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
Sridharan (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 del
software deben ser realizadas por personas que no estén directamente involucradas en el esfuerzo de desarrollo.
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
Pressman (2004) considera que el aseguramiento de la calidad del
software comprende una gran variedad de tareas asociadas:
Preparar u plan de aseguramiento de la calidad del software para
un 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 definido
Asegurar 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
Enero 2006 6
CONTROL DE LA CALIDAD DEL SOFTWARE
Segú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-rias
a cualquier falla encontrada durante el proceso de desarrollo.
Adicionalmente, el asegurar la calidad en las primeras fases del
proceso 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 sus bases.
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 esfuerzan por desviar los mecanismos de protección.
3) Descubrir cualquier uso de privilegios que pueden ocurrir cuando un usuario asume una funcionalidad con privilegios mayores que el suyo propio.
Enero 2006 8
CALIDAD DEL PRODUCTO DE SOFTWARE
Para 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.
CALIDAD DEL PRODUCTO DE SOFTWARE
La 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.
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.
Modelos de calidad de producto de software
El 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 9126
El modelo sistémico de la calidad del producto del LISI (Ortega,
Enero 2006 12
ISO 9126
ISO 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 respectivas
subcaracteristicas, para La calidad interna y externa.
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.
Descritas
Descritas
por
por
metricas
metricas
internas
internas
,
,
externas
externas
o en
o en
uso
uso
de l
de l
as
as
caracter
caracter
í
í
sticas de ISO 9126
sticas de ISO 9126
Enero 2006 16
ISO 9126 Calidad en el ciclo de vida
CALIDAD DEL PRODUCTO DE SOFTWARE
ISO/IEC 9126
Presentado en 1992, las características de calidad de los productos de 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
Enero 2006 18
CALIDAD DEL PRODUCTO DE SOFTWARE
ISO/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 PORTABILIDADCALIDAD DEL PRODUCTO DE SOFTWARE
MODELO 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 SOFTWARE
MODELO ORIENTADO AL PRODUCTO PROPUESTO POR LISI
MODELO DE CALIDAD DE SOFTWARE
Diseño •Usabilidad •Funcionalidad •Fiabilidad •Mantenibilidad •Eficiencia •Portabilidad Requerimientos Atributos externos Atributos Internos/ Propiedades del Producto
Implementación Efectividad del Producto Eficiencia del Proceso Eficiencia del Producto Efectividad del Proceso
Actividad Práctica
PIENSE – 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.
Enero 2006 22
Modelos de calidad de proceso de software
Personal Software Process
Capability Maturity Model
ISO/IEC serie 9000
ISO/IEC 15504
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
ISO 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
Enero 2006 24
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
ISO 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
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
CMM (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 Proceso disciplinado Proceso estándar y consistente Proceso predecible Proceso en continuo 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
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.
E n t r a d a E n t r a d a E n t r a d a E n t r a d a E n t r a d a S a l i d a S a l i d a S a l i d a S a l i d a S a l i d a 5 4 3 2 1
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 MADUREZ
NIVELES DE MADUREZ
ÁREAS CLAVES DEL PROCESO
ÁREAS CLAVES DEL PROCESO
RASGOS COMUNES RASGOS COMUNES PRÁCTICAS CLAVES PRÁCTICAS CLAVES Proceso de Capacidad Metas Implementación o Institucionalización Infraestructura o Actividades indican contienen
alcanzan organizadas por
contienen dirigen
describen
Enero 2006 28
NIVEL 1
no 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 Para producirResultados
Nivel1:
NIVEL 2
las políticas para la gerencia de un proyecto de software y los
procedimientos 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
funcionalidad
el 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
Actividad Para producir
Nivel 2:
Piense antes de actuar
y piense despues de actuar para
asegurase que hizo lo correcto Planifica Evalua Para mejorar Resultados
NIVEL 2
NIVEL 3
los procesos están documentados e éstos integrados en un
todo coherente
hay un equipo de personas que es responsable por el proceso
de software
un 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
funcionalidad
el 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 Para producir Resultados
Nivel 3 Use las lecciones aprendidas Planifica Evalua Para mejorar
NIVEL 3
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ón
Los 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
Enero 2006 34
Estandards Actividad Para producir Resultados
Nivel 4 Predices los resultados y generas las oportunidades para obtenerlos Planifica Evalúa Para mejorar Para difundirlos
NIVEL 4
NIVEL 5
la organización entera se enfoca en procesos de mejora
continua
tiene el propósito de identificar debilidades y fortalecer de
manera proactiva el proceso
Las innovaciones que aprovechan lo mejor de la práctica de
la ingeniena del software son identificadas y transferidas
El 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 Para producirResultados
Nivel 5 Usa las lecciones aprendidas para tener más lecciones aprendidas... Planifica Evalua Para mejorar Para difundirlos Para mejorar
NIVEL 5
Categorías Gerencia Organizacional Ingeniería Niveles 1 Inicial 2 Repetible 3 Definido 4 Gerenciado 5 Optimizado Proceso Ad Hoc Gerencia de software integrado Coordianción Intergrupal Gernecia de los Requerimientos
Gerencia del Proyecto de Software
Planficación del Proyecto de Software Gerencia de Contratistas Aseguramiento de la Calidad del Software Gerencia de Configuraciones Enfasis en la organzación por proceso Definición del Proceso Entrenamiento Ingenieria de Software de productos Inspecciones Gerencia de la Calidad del Software
Gerencia Cuantitativa del Software
Gerencia de Cambios Tecnológicos
Enero 2006 38
Areas Claves Nivel 2
Gerencia deRequerimientos
Planificacion Proyecto de
Software ConfiguracionesGerencia de Aseguramiento de la Calidad del Software
Gerencia de Subcontratistas Seguimiento Proyecto de Sw
1. Los requeirmientso del software identificados son controlados para orientar la ingeniería del software y su gerencia
2. Planes del proyecto, productos y actividades son consistentes con los requerimientos identificados. Propósito Establecer un entendimiento común entre el cliente y los requerimientos 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 software
El acuerdo es la base para las estimaciones, planificacion, desempeño y seguimiento de las actividades del proyecto
Enero 2006 40
1. Las estimaciones se usan para
planificar y hacerle seguimiento al proyecto.
2. Las actividades y los acuerdos se documentan.
Propósito
Alcance
Implica
Desarrollar estimaciones para la ejecución de los trabajos Establecer los acuerdos necesarios
Definir un plan de trabajo
El Plan provee las bases para iniciar el esfuerzo de trabajo y su gerencia. Metas Establecer un plan razonable para hacer la ingeniería del software y gerenciar el proyecto.
Area Clave: Seguimiento al Proyecto de Software
1.El desempeño y los resultados actuales tienen un seguimiento 2. Las acciones correctivas se toman
cuando hay desviaciones
3. Los cambios (en los planes) son resultado de un acuerdo entre los afectados.
Propósito
Alcance
Implica:
Comparar resultados versus acuerdos, y estimaciones
Ajustar los planes
Metas
Tener una visión clara del progreso del proyecto afin de gerenciarlo y tomar las acciones adecuadas ante las desviaciones.
Enero 2006 42
1.Se planifican actividades de ACS 2. 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 los gerentes.
Propósito
Tener una gerencia con vision apropiada del proceso a ser seguido y del
producto a obtenerse.
Alcance
Metas
Implica
Revisar los productos para garantizar que cumplen con los estandares propuestos
Tener a disposición del proytecto y otros gerentes los resultados de las revisiones
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 Metas Mantener la integridad de los productos de software a lo largo del ciclo de vida.
Involucra
Identificar unidades de configuración Conmtrolar los cambios sitemáticamente
Mantener la integridad a todo lo largo del cilo de vida
Enero 2006 44
1. Se seleccionan contratistas adecuados.
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 Metas Seleccionar contratistas de calidad idónea y gerenciarlos. Implica: Seleccionar contratistas Establecer acuerdos
Hacer seguimiento y revisiones a los resultados de los contratistas
Enero 2006 45
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
SPICE (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:
Arquitectura del modelo Categoría del proceso Categoría del proceso Proceso Proceso Práctica base Práctica base Nivel de capacidad Nivel de capacidad Características comunes Características comunes Práctica genérica Práctica gené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
Enero 2006 46
ENG.2 Mantenimiento del Sistema y el Software ENG.1 Desarrollo
Aná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 del
Sistema.
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ón Selección del proveedor Monitoreo del proveedor Aceptación del cliente
CUS.4 Operación
Uso operacional Soporte al cliente
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 proceso Valuación del proceso Mejoramiento 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
Enero 2006 48 NIVELES DE
CAPACIDAD DESCRIPCIÓN
0
NO REALIZADO
El proceso no tiene ninguna característica común. Hay fracaso general para realizar las prácticas bases en el proceso. No hay productos de trabajo o rendimientos del proceso fácilmente identificables.
1 REALIZADO INFORMALMENTE
Generalmente se realizan prácticas bases del proceso. La actuación de estas prácticas bases no puede planearse rigurosamente. La actuación depende del conocimiento individual y el esfuerzo. Los individuos dentro de la organización están de acuerdo que esta acción debe realizarse y desde cuando. Hay productos de trabajo identificables para el proceso.
2
PLANIFICADO Y SEGUIDO
En el proceso, las prácticas bases se planifican y se siguen. Se verifica la actuación según los procedimientos especificados. Los productos de trabajo conforman los estándares especificados y los requisitos.
3
BIEN DEFINIDO
Las prácticas base son realizadas según un proceso bien definido que usa
versiones aprobadas, ajustadas a los estándares y a los procesos documentados. 4
CUANTITATIVAMENTE CONTROLADO
Se recolectan y analizan medidas detalladas de ejecución. Esto lleva a una
comprensión cuantitativa de la capacidad del proceso y una habilidad mejoradas para predecir su actuación. La actuación se maneja objetivamente. La calidad de los productos de trabajo es cuantitativamente conocida.
5
CONTINUAMENTE MEJORADO
Se establece la efectividad del proceso cuantitativo y las metas de eficacia para la ejecución., basado en las metas comerciales de la organización. La mejora
continua del proceso contra estas metas es habilitada por “feedback” desde la ejecución de procesos definidos y manejando ideas y tecnologías innovadoras.
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
SPICE (Software Process Improvement and Capacitability dEtermination)
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
SPICE (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ÍA
DEL PROCESO DESCRIPCIÓN
CLIENTE-PROVEEDOR Procesos que directamente impactan al cliente, desarrollo, soporte ytransición del software al cliente. INGENIERÍA Procesos que directamente especifican, llevan a cabo, o mantienen, unsistema y la documentación del usuario.
PROYECTO Procesos que establecen el proyecto, coordinan y manejan los recursospara elaborar un producto o proporcionar servicios que satisfacen al cliente.
SOPORTE Procesos que habilitan y apoyan la actuación de los otrs procesos enun proyecto. ORGANIZACIÓN Procesos que establecen las metas comerciales de la organización ydesarrollan el proceso, el producto y los recursos determinador, que
Enero 2006 50
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
PSP (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:
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
Cubo 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 se puede 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 SOFTWARE
Cubo 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 DE
ANÁLISIS Y SÍNTESIS DE SISTEMAS DE INFORMACIÓN
(Callaos y Callaos, 1996) Eficiencia del proceso Efectividad del proceso Eficiencia del producto Efectividad del producto Cliente Usuario
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
MODELO 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.
Enero 2006 54
CALIDAD DEL PROCESO DE DESARROLLO DE
SOFTWARE
MODELO ORIENTADO AL PROCESO
PROPUESTO POR LISI
Ciclo de VidaPrimario Ciclo de Vida de Apoyo Ciclo de Vida Organizacional Nivel 0 Categoria Cliente_Proveedor Categoría Ingeniería Categoría de Gestión Categoría de Soporte Categoría Organizacional Nivel 1 Principio 1 Principio 3 Principio 4 Principio 2 Nivel 2 Nivel 3 Nivel 4 ENG.2 Categoría organizacional 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
Actividad Práctica
PIENSE – 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.
Enero 2006 56
