vvs tema6 aprf/teaching/vvs11/downloads/tema6/vvs_tema… · desarrollar planes de pruebas...

Topicos Avanzados en Pruebas de Software ‐‐ UNS 1

Gestión de TestingTemario VITemario VI


Gestión de TestingLectura

Sommerville I., 2000. Software Engineering, 7th Edition. Addison‐Wesley.Patton. Software Testing. SAMS. July 2005.Craig and Jaskiel. Systematic Software Testing. Artech House Publishers.March, 2005.Kaner, Kalk and Nguyen. Testing Computer Software. Wiley Computer Publishing.1999.Reportes Técnicos ISO/IEC JTC1/SC7: ISO 9126http://www.sei.cmu.eduReportes Técnicos: CMU/SEI‐93‐TR‐024, CMU/SEI‐93‐TR‐025Jenner – Software Quality Management and ISO 9001 – John Wiley & Sons, 1995


Planificación del Test (Test Planning) (1)

Determinar el alcance, enfoque, y programación de las actividades de testing

• Identificar las características a ser verificadas• Las tareas de testing que serán realizadas• El personal responsable para cada tarea • Los riesgos asociados con el plan


Planificación del Test (2)

• Debe iniciarse al comienzo y seguir en paralelo al desarrollo del software

Información delProyecto

Información delSoftware

Desarrollar Plande Pruebas Maestro

Desarrollar Planes dePruebas Detallados

• Plan Maestro• Recursos

• Planes Detallados• Recursos específicos



Codificación

Requerimientos

Diseño Preliminar

Diseño Detallado

Aceptación

Sistema

Integración

Unidad

DesarrolloDesarrollo TestingTesting

El test del sistema debe ser construido en base alDiseño Arquitectónico y Requerimientos



• El objetivo principal es comunicar al equipo encargado del testing:

• Sus intenciones

• Sus expectativas

• Su entendimiento del testing que será realizado

• El resultado final será un documento de alguna clase



Nada se puede dejar como asumido

• Aspectos a tener en cuenta para realizar el plan:

ExpectativasExpectativas de Alto Nivelde Alto Nivel

• Determinar el propósito del proceso de planificacióndel test y del plan del test

Programadores

Gerentes

Técnicos





•Qué producto se esta verificando?

•Debe haber un entendimiento de qué es el producto, su magnitud y su alcance

• Empezamos con la especificación





• Cuáles son las metas de calidad y confiabilidad del producto?

No debe tener ningún bug

Necesita la última tecnología

Debe ser lo más rápido posible




PersonasPersonas, Lugares y Cosas, Lugares y Cosas• Se debe incluir toda la información necesaria para cada miembro del equipo (nombre,Te, mail, dirección, título, responsabilidad)

• Dónde están almacenados los documentos, de dónde se puede bajar el software, dónde están las herramientas de test, etc.

• Qué hardware utiliza el sistema y de dónde lo puedo obtener. Si hay laboratorios para realizar testing de configuración, dónde están ?




DefinicionesDefiniciones

• ¿Qué es un bug?

El software no hace algo que la especificación del producto dice que debería

El software hace algo que laespecificación del producto dice

que no deberíaEl software hace algo que la especificación del producto no menciona

El software no hace algo que la especificación del producto no menciona pero debería




DefinicionesDefiniciones

• Todas las palabras y términos se deben definir

• Si existen diferentes definiciones, se debe llegar a un consenso

• Por ejemplo, se define bug, alpha release, beta release, etc

• Dependerá del tipo del proyecto, el modelo de desarrollo, el nivel de experiencia

• Deberán ser específico y precisas




ResponsabilidadesResponsabilidades InterInter‐‐GrupoGrupo

• Obviamente el programador programa, el testeador realiza las pruebas

• Se deben definir las actividades en forma detallada

• Indicar tarea y quiénes la realizarán

• Así las responsabilidades están bien separadas y cada sabe lo que debe hacer



XDefinir el programa beta

XDefinir version demo

XRevisar el material impreso

XRealizar el plan de test

XRealizar el testing de unidad

XDiseñar y codificar el producto

XPlanificación del Proyecto

XCrear una lista de componentes del producto

TareasTareas

Test

ers

Prog

ram

ador

es

Ger

ente

s

Esc.

Téc

nico

s

Mar

ketin

g

Sopo

rte d

ePr

od




QuQuéé deber verificarse y qudeber verificarse y quéé nono

• Aquellos componentes ya testeados en previas entregas (releases)

• Se deben identificar componentes a ser testeados y componentes no testeados

• Si el componente no será verificado, indicar razones por las cuales no se hará (no porque no lo entiendan)




FasesFases del del Test Test y Estrategias y Estrategias

• Según el modelo de desarrollo (code and fix, espiral)

• Indicar cada una de las fases junto con la estrategia a utilizar en cada una de ellas. Por ejemplo, caja negra, caja blanca, integración bottom‐up, etc.

• Se requieren testeadores experimentados




RequerimientosRequerimientos de Recursos de Recursos

• Personal: full‐time, part‐time, experiencia, cantidad

• Equipamiento: computadoras, hardware, etc.

• Espacio de oficinas y laboratorios

• Software: BD’s, procesadores de texto, qué debe comprarse?

• Accesorios: teléfonos, discos, libros, etc.




• PlanificaciPlanificacióón del n del TestTest

Testers

Meses



4 semanasReleaseFase de Test 3

6 semanasBeta ReleaseFase de Test 2

Código completo

Plan de test completo

7 días después de la especificación

Fecha de Comienzo

6 semanasFase de Test 1

12 semanasCasos de Test Completos

4 semanasPlan de Test Completo

DuraciónTarea de Testing


PlanificaciPlanificacióónn del del TestTest

• En vez de indicar fechas exactas...




• Casos de Test

• Reportar bugs

• Métricas y Estadísticas

• Total de fallas encontradas diariamente

• Lista de fallas que necesitan todavía ser arregladas

• Total de fallas encontradas por testador




RiesgosRiesgos

• Identificar los riesgos tempranamente

• Testeadores experimentados sabrán dimensionarlos mejor

• El impacto sobre el esfuerzo en el testingpuede ser muy grande




Estándares de Pruebas Software (1)

ISEB (Information Systems Examinations Board) & ISTQB (International Software Testing Qualification Board) para certificación internacional de profesionales de testing.

Adhiere a los Estándares de Pruebas:

BS7925‐1 Software Testing Vocabulary

BS7925‐2 Software Component Testing

IEEE Std 829‐1998 Standard for Software Test Documentation

IEEE Std 1028 Standard for Reviews & Inspections

IEEE Std 1044 & 1044.1 Standard Classification for Software Anomalies

ISO9126 Software Quality Standard


Documentación de Test (1)

• Todo lo que vimos hasta ahora debe DOCUMENTARSE

• Utilizando la IEEE Std. 829-1998 Standard for Software Test Documentation



Especificación del Diseño del Test

Especificación de Caso de Test

Especificación de losProcedimientos de Test

IEEE Std. 829-1998

Especificación del Plan de Test Maestro



Señalar el enfoque, los recursos y el esquema de actividades de test, así como los elementos a verificar, las características, las actividades de test, el personal

responsable y los riesgos asociados


IEEE Std. 829-1998



1. Identificador único del documento2. Introducción y resumen de elementos y características a verificar3. Elementos software a verificar

‐ Software (módulos, etc.)‐ Documentación (Especificación de Análisis y de Diseño)

4. Características a verificar• Deposito de efectivo usabilidad• Transferencia de fondos seguridad• Consultar el saldo de una cuenta performance


IEEE Std. 829-1998


5. Características que no se probarán• Errores relacionados con el tiempo.• Condiciones de error no detectadas.• Condiciones especiales de los datos.• Invalidez de la información mostrada por pantalla.• Interacción con tareas en background.• Fallos de configuración/compatibilidad con software• Incapacidad de soportar el volumen de carga o fallos hardware

6. Enfoque general del test (actividades, técnicas, herramientas, etc)• En todos los niveles (Test de Unidad, de Integración, etc.)

Unidad Integración Sistema Aceptación


IEEE Std. 829-1998



7. Criterios de éxito/fallo para cada elemento

Casos de Test que se han ejecutado con éxito/fallado:

• Número, tipo, severidad, y ubicación


IEEE Std. 829-1998



8. Criterios de suspensión y requisitos de reanudación9. Documentos a entregar

• Planes de test, especificación del diseño del test, casos de test, herramientas, reportes

10. Actividades de preparación y ejecución de test

Organización de EquiposJefe de equipo

• JUAN PEREZ• Preparación de casos de test• Ejecución de tests• Datos de los tests• Preparar informe


IEEE Std. 829-1998



11. Necesidades de entornoEn cuanto a:

• SOFTWARE y HADWARE: Sistema operativo, procesador, impresora

• DOCUMENTACION:Absoluta comodidad, tranquilidad

12. Responsabilidades en la organización y realización de los test• Pruebas de Documentación: Juan Perez• Pruebas de software: Josefa Martinez

13. Necesidades de personal y formación (training)14. Esquema de tiempos


IEEE Std. 829-1998



15. Riesgos asumidos por el plan y planes de contingencias• Riesgos

Fechas de entregas no realistasDisponibilidad del personalNecesidades de EntrenamientoFalta de requerimientos del productoDisponibilidad de los recursos

• Plan de contingenciasReducir el alcance de la aplicaciónRetrasar la implementaciónAgregar recursosPrever fallos críticosProcedimientos alternativos

16. Aprobaciones y firmas con nombre y puesto desempeñado


IEEE Std. 829-1998



Especificar los refinamientos necesarios sobre el enfoquegeneral reflejado en el plan e identificar las características

que se deben verificar con este diseño de test



IEEE Std. 829-1998


1. Identificador único para la especificación (y la referencia al plan de test asociado)

2. Característica(s) de los elementos software a verificar (y combinaciones de características)• Por ejemplo, depósito en una cuenta

3. Detalles sobre el plan de test del que surge este diseño, incluyendolas técnicas de test específicas y los métodos de análisis de resultados• Describe todos los test necesarios para testear una

característica• No se describe cómo son ejecutados los test• De cada test: identificador, casos que se van a utilizar

procedimientos que se van a seguir



IEEE Std. 829-1998


4. Criterios de éxito/fallo de la prueba (criterios para determinar si una característica o combinación de características ha pasado con éxito la prueba o no)

Definir uno de los casos de prueba identificandopor una especificación del diseño de las pruebas



IEEE Std. 829-1998



1. Identificador único de la especificación• fecha, número y versión del caso de test

2. Ítems a testear (por ejemplo, módulos) que se van a probar• Especificación de requerimientos, especificación de diseño, y

código3. Especificaciones de cada entrada requerida para ejecutar el caso

• incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronización de las mismas

4. Especificaciones de todas las salidas y las características requeridas• Cómo se debe ver el sistema luego de que se ejecutó el caso de

test • Se deben indicar características como, el tiempo respuesta para

los elementos que se van a probar



IEEE Std. 829-1998


5. Necesidades de entorno• hardware• Software (creación de stubs y drivers)• personal

6. Requisitos especiales de procedimiento • restricciones especiales en los procedimientos para ejecutar este

caso7. Dependencias entre casos

• por ejemplo, listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba

• Ejemplo:• Debemos tener un test que requiera el depósito en una

cuenta de $1000 que debe ejecutarse antes de ejecutar otro test que realiza el retiro (sino la cuenta no tendrá fondos)



IEEE Std. 829-1998


Especificación de los Procedimientos de Test

Especificar los pasos para la ejecución de un conjuntode casos de test o, más generalmente, los pasos

utilizados para analizar un elemento software con elpropósito de evaluar un conjunto de características

del mismo


IEEE Std. 829-1998



1. Identificador único de la especificación y referencia a la correspondiente especificación del diseño del test

2. Objetivo del procedimiento y lista de casos que se ejecutan con él3. Requisitos especiales para la ejecución (por ejemplo, entorno

especial o personal especial)4. Pasos en el procedimiento. Además de la manera de registrar los

resultados y los incidentes de la ejecución, se debe especificar:• La secuencia necesaria de acciones para preparar la ejecución• Acciones necesarias para empezar la ejecución• Acciones necesarias durante la ejecución• Cómo se realizarán las medidas ( por ejemplo, el tiempo de

respuesta)


IEEE Std. 829-1998


5. Pasos en el procedimiento. Además de la manera de registrar los resultados y los incidentes de la ejecución, se debe especificar:• Acciones necesarias para suspender la prueba (cuando los

acontecimientos no previstos lo obliguen)• Puntos para reinicio de la ejecución y acciones necesarias para el

reinicio en estos puntos• Acciones necesarias para detener ordenadamente la ejecución• Acciones necesarias para restaurar el entorno y dejarlo en la

situación existente antes de las pruebas• Acciones necesarias para tratar los acontecimientos anómalos



IEEE Std. 829-1998


• Futuro de los Estándares de Testing:

• ISO/IEC 29119 Software Testing• Bajo desarrollo por ISO/IEC JTC1/SC7 Working Group 26.

• Reemplazará a algunos de los estándares IEEE y BSI para testing de software:

• IEEE 829 Test Documentation

• IEEE 1008 Unit Testing

• BS 7925-1 Vocabulary of Terms in Software Testing

• BS 7925-2 Software Component Testing Standard


IEEE Std. 29119


BS 7925-1

BS 7925-2 IEEE 829IEEE 1008

BS 7925-2

Documentation

Part 3

TestingTechniques

Part 4

Processes

Part 2

Concepts & VocabularyPart 1


IEEE Std. 29119


El objetivo no es necesariamente alcanzar una calidad perfecta, sino la necesaria y suficiente para cada contexto de uso a la hora de laentrega y del uso por parte de los usuarios.

ISO 9126 entrega la definición de las características y los procesos de evaluación de calidad asociados para usar cuando se especifican los requisitos y la evaluación de los productos de software a lo largo de su vida útil.

ISO 9126 define la Calidad del Software como: “La totalidad de características de un producto de software que se manifiesta en su habilidad para satisfacer necesidades establecidas o implícitas”.

ISO 9126 – Calidad de Producto Software (1)


Enfatiza tres puntos importantes:

Los requisitos del software constituyen el fundamento para medirla calidad. La carencia de conformidad con los requisitos es carencia de calidad.

Los estándares especificados definen un conjunto de criterios de desarrollo que guían la manera en que el software se somete al trabajo ingenieril. Si no se siguen los criterios, la carencia de calidad será un resultado casi seguro.

Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo, mantenibilidad). Si el software se conforma con los requisitos explícitos pero falla en atender los requisitos implícitos, la calidad del software es sospechosa.



Diferentes aspectos de la calidadInterna: medible a partir de las características intrínsecas, como el código fuente

Externa: medible en el comportamiento del producto, como en una prueba

En uso: durante la utilización efectiva por parte del usuario



ISO 9126 – Calidad Interna y Externa (1)

Las funciones requeridas están disponibles en el software?

Funcionalidad

ConfiabilidadQué tan

confiable es el software?

Mantenibilidad Qué tan fácil de modificar

es el software?

Usabilidad

Es fácil de usar el

software?Portabilidad

Qué tan fácil es transferir el software a otro

entorno?

Eficiencia

Qué tan eficiente es el

software?




Functionality: Capacidad del producto software de proveer funciones que alcancen las necesidades establecidas y derivadas cuando el software es usado bajo condiciones especificadas.

SuitabilitySuitability: La capacidad del producto software para proveer un conjunto apropiado de finciones para tareas y objetivos del usuario especificados.

AccuracyAccuracy: La capacidad del producto software de proveer resultados o efectos correctos y/o acordados.

InteroperabilityInteroperability: La capacidad del producto software de interactuar con uno o más sistemas especificados.

SecuritySecurity: La capacidad del producto software de proteger información y datos de manera que personas o sistemas no autorizados no puedanleerlos o modificarlos y no rechazar el acceso de personas autorizadas.

ComplianceCompliance: La capacidad del producto software de adherir a estándares, convenciones o regulaciones legales o prescripciones similares.



Reliability: Capacidad del producto software de mantener un nivel especificado de performance cuando se usa bajo condiciones especificadas.

MaturityMaturity: La capacidad del producto software para evitar fallas como resultado de defectos en el software.

Fault ToleranceFault Tolerance: La capacidad del producto software mantener un nivel especificado de performance en caso de existencia de defectos o de infringir la interface especificada.

RecoverabilityRecoverability: La capacidad del producto software de reestablecer un nivel especificado de performance y de recuperar los datos directamente afectados en el caso de una falla.

ComplianceCompliance: La capacidad del producto software de adherir a estándares, convenciones o regulaciones relacionadas a reliability.



Usability: Capacidad del producto software de ser entendido, aprendido, usado y atractivo al usuario, cuando se usa bajo condiciones especificadas.

UnderstandabilityUnderstandability: La capacidad del producto software de posibilitar que el usuario entienda si el software es adecuado, y cómo puede ser usado en tareas y condiciones de uso particulares.

LearnabilityLearnability: La capacidad del producto software de posibilitar que el usuario aprenda la aplicación.

OperabilityOperability: La capacidad del producto software de posibilitar que el usuario lo opere y controle.

AttractivenessAttractiveness: La capacidad del producto software de ser atractivo al usuario.

ComplianceCompliance: La capacidad del producto software de adherir a estándares, convenciones o guías de estilo o regulaciones relacionadas a usability.



Efficiency: Capacidad del producto software de proveer adecuada performance, relativa a la cantidad de recursos usados, bajo condiciones establecidas.

Time BehaviorTime Behavior: La capacidad del producto software de proveer apropiados tiempos de respuesta y procesamiento y tasas de intercambio cuando se realizan sus funciones, bajo condiciones especificadas.

Resource UtilizationResource Utilization: La capacidad del producto software de usar la cantidad y tipo de recursos apropiada cuando el software realiza sus funciones bajo condiciones establecidas.

ComplianceCompliance: La capacidad del producto software de adherir a estándares, convenciones relacionadas a efficiency.



Maintainability: Capacidad del producto software de ser modificado. Las modificaciones pueden incluir correcciones, mejoras y adaptaciones del software a cambios en el entorno, así como en los requerimientos y en las especificaciones funcionales.

AnalysabilityAnalysability: La capacidad del producto software de que se le diagnostiquen deficiencias o causas de fallas, o de que se identifiquen las partes que serán modificadas.

ChangeabilityChangeability: La capacidad del producto software de posibilitar que una modificación especificada sea implementada.

StabilityStability: La capacidad del producto software de evitar efectos no esperados ante cambios en el software.

TestabilityTestability: La capacidad del producto software de posibilitar que el software modificado sea validado.

ComplianceCompliance: La capacidad del producto software de adherir a estándares y convenciones relacionadas a maintainability.



Portability: Capacidad del producto software de ser transferido de un entorno a otro.

AdaptabilityAdaptability: La capacidad del producto software de ser adaptado para diferentes entornos sin aplicar otras acciones o medios que aquellas previstas para este propósito en el software especificado.

InstallabilityInstallability: La capacidad del producto software de ser instalado en un entorno especificado.

CoCo‐‐existenceexistence: La capacidad del producto software de coexistir con otros software independientes en un entorno común compartiendo recursos comunes.

ReplaceabilityReplaceability: La capacidad del producto software de ser usado en lugar de otro software especificado para el mismo propósito en el mismo entorno.

ComplianceCompliance: La capacidad del producto software de adherir a estándares y convenciones relacionadas a portability.



ISO 9126 – Calidad en Uso (1)


Effectiveness: La capacidad del producto software de posibilitar alos usuarios alcanzar objetivos especificados con certeza y completitud en un contexto de uso especificado.

Productivity: La capacidad del producto software de posibilitar a los usuarios usar la cantidad apropiada de recursos en relación con la efectividad alcanzada en un contexto de uso especificado.

Safety: La capacidad del producto software de alcanzar un nivel aceptable de riesgo de daño a personas, software, equipos o entornos en un contexto de uso especificado.

Satisfaction: La capacidad del producto software de satisfacer a los usuarios en en un determinado contexto de uso.

ISO 9126 – Calidad en Uso (2)


El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie‐Mellon para el SEI (Software Engineering Institute).

A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América, desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW‐CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.

Modelos CMM


SW‐CMM se organiza en cinco niveles que priorizan acciones para incrementar la madurez del proceso de software.

Nivel de madurez: cada nivel o capa suministra una basepara la mejora continua.

Software CMM


INICIAL: proceso ad hoc, y ocasionalmente caótico. Pocos procesos están definidos y el éxito depende de esfuerzos individuales.

REPETIBLE: procesos básicos de gestión de proyectos para controlar costos, tiempos y funcionalidad. La disciplina del proceso se basa en repetir éxitos anteriores sobre proyectos de aplicaciones similares.

DEFINIDO: el proceso de software es documentado, estandarizado e integrado en la organización. Se institucionaliza el proceso de software.

GESTIONADO: se recolectan medidas detalladas del proceso de software y de la calidad del producto. Ambos son entendidos y controlados cuantitativamente.

OPTIMIZADO: la mejora continua del proceso es posible por la retroalimentación cuantitativa desde el proceso y a partir de nuevas ideas y tecnologías.

Software CMM


Software CMM ‐‐ KPAs


Gestión de Requerimientos (Requirements Management): establecer una comprensión mutua entre el cliente y el proyecto en relación a los requerimientos que son la base para la planificación y el control.

Planificación del Proyecto (Software Project Planning): establecer planes razonables para efectuar y manejar el proyecto. Son la base del proceso de gestión.

Seguimiento del Proyecto (Software Project Tracking and Oversight): establecer una visibilidad adecuada del avance real del proyecto de manera que puedan tomarse acciones efectivas cuando existen desvíos.

SW‐CMM → NIVEL 2


Gestión de Contratos de Software (Software Subcontract Management): seleccionar contratistas de software calificados y gestionar de manera efectiva la relación con ellos.

Asegurar la Calidad del Software (Software Quality Assurance): suministrar la visibilidad adecuada en los procesos y productos.

Gestión de la Configuración de Software (Software Configuration Management): establecer y mantener la integridad de los productos del proyecto a través de todo el ciclo de vida.



Enfoque en el Proceso de la Organización (Organization Process Focus): establecer las responsabilidades organizacionales para las actividades del proceso.

Definición del Proceso de la Organización (Organization Process Definition): desarrollar y mantener elementos del proceso de software que mejoren el rendimiento en los proyectos.

Programa de Entrenamiento (Training Program): desarrollar las habilidades y conocimientos de los individuos de manera que puedan cumplir sus roles efectiva y eficientemente.

Revisión de Pares (Peer Reviews): remover defectos de los productos de manera eficiente y temprana.



Gestión Integrada del Software (Integrated Software Management): integrar la ingeniería de software y las actividades de gestión en un proceso coherente y definido que se constituya en un estándar para la organización.

Ingeniería del Producto Software (Software Product Engineering): realizar un proceso de ingeniería bien definido y consistente que integre todas las actividades, ej., análisis de requerimientos, diseño, codificación, etc.

Coordinación entre grupos (Intergroup Coordination): establecer un medio para que el grupo de ingeniería de software participe activamente con otros grupos de ingeniería.



Gestión Cuantitativa del Proceso (Quantitative Process Management): controlar el rendimiento del proceso de manera cuantitativa. Se agrega un programa de medición a prácticas de nivel 3.

Gestión de la Calidad del Software (Software Quality Management): desarrollar un entendimiento cuantitativo de la calidad de los productos de software y alcanzar objetivos de calidad específicos.



Prevención de Defectos (Defect Prevention): identificar las causas de defectos y prevenirlos. Los cambios en el proceso que sean de valor general se transmiten de acuerdo a la Gestión de Cambios del Proceso.

Gestión de Cambios en la Tecnología (Technology Change Management): identificar nuevas tecnologías beneficiosas y transferirlas a la organización de manera ordenada.

Gestión de Cambios del Proceso (Process Change Management): mejorar continuamente el proceso de software con la intención de aumentar la calidad, incrementar la productividad y reducir el tiempo de entrega del producto.



CMMI (1)CMMI (Capability Maturity Model Integrated)

Integración de modelos (CMM‐SW, SE‐CMM, IPD‐CMM)

SE‐CMM. El Modelo de Capacidad y Madurez en la Ingeniería de Sistemas fue publicado por el SEI en noviembre de 1995. Estádedicado a las actividades de ingeniería de sistemas.

No utiliza niveles de madurez generales sino que en cada área de proceso una organización puede alcanzar un determinado nivel de madurez.

IPD‐CMM. El Modelo de Capacidad y Madurez para el Desarrollo Integrado de Productos fue propuesto como un borrador por el SEI en 1997, pero quedó integrado en el CMMI al publicarse este en el año 2000.


- Innovación y Distribución Organizacional (OID) - Análisis Causal y Resolución (CAR)

Inicial (1)

Gestionado (2)

Definido (3)

Gestionado Cuantitativamente

(4)

Optimizante (5)

Mejora Continua del Proceso (2 Áreas de Proceso)

Gestión Cuantitativa (2 Áreas de Proceso)

Gestión Básica de Proyectos (7 Áreas de Proceso)

Estandarización del Proceso (11 Áreas de Proceso)

- Rendimiento del Proceso Organizacional (OPP) - Gestión Cuantitativa de Proyectos (QPM )

- Desarrollo de Requisitos (RD) - Solución Técnica (TS) - Integración del Producto (PI) - Verificación (VER) - Validación (VAL) - Enfoque Proceso Organizacional (OPF) - Definición del Proceso Organizacional (OPD) - Formación de la Organización (OT) - Gestión Integrada de Proyectos (IPM) - Gestión de Riesgos (RSKM) - Análisis de Decisión y Resolución (DAR)

- Gestión de Requisitos (REQM) - Planificación del Proyecto (PP) - Monitorización y Control del Proyecto (PMC) - Gestión del Acuerdo con el Suministrador (SAM) - Medición y Análisis (M & A) - Aseguramiento de la Calidad del Proceso y Producto (PPQA) - Gestión de la Configuración (CM)

- Procesos Caóticos (Ad Hoc)

- Gestión Cuantitativa del Suministrador (QSM)

- Gestión Integrada del Suministrador (ISM)

- Entorno Organizacional para la Integración (OEI) - Equipo Integrado (OIT)

- Selección y Monitorización del Suministrador (SSM)

CMMI (2)


CMMI

Gestión del Proceso

Gestión de Proyectos Ingeniería Soporte

- Enfoque Proceso Organizacional - Definición Proceso Organizacional - Formación Organizacional - Rendimiento - Innovación y Distribución Organizacional

- Planificación del Proyecto - Monitorización y Control de Proyectos - Gestión del Acuerdo con el Suministrador - Gestión Integrada de Proyectos - Gestión de Riesgos - Gestión Cuantitativa de Proyectos

- Gestión de Requisitos - Desarrollo de Requisitos - Solución Técnica - Integración del Producto - Verificación - Validación

- Gestión de Configuración - Aseguramiento de la Calidad del Proceso y Producto - Medición y Análisis - Análisis de Decisiones y Resolución - Análisis Causal y Resolución

IPPD Adquisición

- Entorno Organizacional para la Integración - Equipo Integrado

- Selección y Monitorización del Suministrador - Gestión Integrada del Suministrador - Gestión Cuantitativa del Suministrador

CMMI (3)


ISO 9000: Estándares para Gestión (1)

ISO (International Organization for Standarization) define calidad como:

“La totalidad de características y aspectos de un producto o servicio que definen su capacidad para satisfacer necesidades implícitas o explícitas.”

Calidad significa “satisfacer al cliente”.



ISO 9001: Quality Systems – Model for quality assurance in design/development, production, installation, and servicing”.

ISO 9002: Quality Systems – Model for quality assurance in production, installation, and servicing.

ISO 9003: Quality Systems – Model for quality assurance in final inspection and test.

ISO 9000.3: Quality management and quality system elements.

Guidelines for development, supply and maintenance of software.



ISO 9004.2: Quality management and quality systemelements.

Guidelines for services (ej., hospitales, comunicaciones, finanzas, administración,etc.)

ISO 9004.4: Guidelines for quality improvement.

Otras normas ISO:

ISO 10011: Guidelines for auditing quality systems.

ISO 10013: Guidelines for developing quality manuals.

ISO 9126: Information technology – Software product evaluation – Quality characteristics and guidelines for their use (base para establecer métricas de calidad)


ISO 9001: Sistema de Gestión de Calidad (1)



Sección 4.1: Management Responsibility.

Política de calidad acordada. Identifica los medios para implementar el sistema de gestión y la política de documentación (Quality Manual). Identifica productos y servicios. Define la organización (roles y responsabilidades) y los procedimientos de revisión.

Sección 4.2: Quality System.

Documentación de los procesos usados para desarrollar y entregar productos y servicios. Describe el manual de calidad, procedimientos de calidad, métodos y estándares. El plan de calidad describe cómo se alcanzarán los objetivos de calidad.



Sección 4.5: Document and Data Control.

Control de todos los documentos y datos que constituyen el sistema de gestión así como los productos del proceso de desarrollo. Todas las copias deben ser autorizadas, tener una lista de distribución y estar sujetas a un control de cambios formal.

Sección 4.17: Internal Quality Audits.

Procedimientos para revisar periódicamente y sistemáticamente todas las operaciones. Implica correcciones.

Sección 4.14: Corrective and Preventive Action.

Acciones que ratifican las causas de problemas. Los procesos, procedimientos, entornos, métodos, estándares y guías deberían ser revisados periódicamente en busca de mejoras.



Sección 4.16: Quality System Records.

Requiere que se identifiquen, cataloguen, archiven y mantengan todos los registros relacionados con el sistema de gestión de la calidad, incluyendo actividades de desarrollo, mantenimiento y soporte. Deben poderser recuperados rápidamente (auditorias, evaluaciones externas, requerimientos satisfactorios, etc.)

Sección 4.18: Training.

Requiere que se identifiquen las necesidades de entrenamiento detodo personal afectado a calidad y también personal afectado al desarrollo. Incluye entrenamiento en herramientas, técnicas, lenguajes, así como en el sistema de gestión de calidad.


ISO 9001: Sistema de Gestión de Producto (1)



Sección 4.8: Product Management.

Todos los aspectos y versiones de documentos y programas deberían ser identificados y manejados de manera de poder ser correctamente ubicados y/o cambiados (gestión de la configuración). Los cambios se refieren a documentos y a componentes de software. Todos los productos deben ser identificados incluyendo su versión.

Sección 4.7: Control of Customer‐Supplied Product.

Toda la información y el material suministrado por el cliente debe estar disponible bajo la responsabilidad del cliente.



Sección 4.6: Purchasing.

Evaluación de compras y de proveedores para asegurar que los bienes y servicios satisfacen lo especificado en un contrato. Incluye desarrollos por subcontratos.

Sección 4.15: Handling, Storage, Packaging, Preservation and Delivery.

Requiere que aseguremos que el software y los documentos son manejados, almacenados y entregados en forma adecuada.

Sección 4.13: Control of Nonconforming Products.

Si un producto es defectuoso después de haber sido entregado para su identificación, se requiere un control para verificar que el defecto es rectificado.


ISO 9001: Sistema de Gestión de Desarrollo (1)



Secciones 4.2, 4.4 y 4.9 –IEEE 1298: Process Control (and Project Planning).

El plan de calidad debe incluir información sobre entregas y puntos de revisión. El proceso de producir software es cubierto por la definición ISO de “proceso especial” (un proceso donde los defectos pueden no detectarse hasta que el producto este en uso).

El desarrollo de software debe asegurar que todos los procesos, procedimientos, métodos y estándares adhieren al plan de calidad. El control del entorno (soporte del software, sistemas operativos, etc.) debe estar sujeto a control de la configuración.

Los estándares deben cubrir todas las prácticas (programación, diseño, prueba y preparación de documentos). El control del proceso debe incluir entrenamiento como servicio (ej., uso del nuevo sistema).



Sección 4.3: Contracts Reviews.Los contratos y las ordenes deben ser revisados para asegurar que existen las capacidades y recursos para satisfacer las necesidades del cliente.

Sección 4.4: Design and Development Control.Refuerza la revisión formal del diseño, de la programación y de los documentos del usuario. Es esencial que se aseguren las entradas al proceso de diseño, se definan metologías y técnicas y se sigan procedimientos. El producto del diseño debe ser seguro, confiable y fácil de mantener.

Sección 4.10: Inspection and Testing.Refuerza la inspección formal y la prueba del producto. Debe incluir la revisión y preparación de planes de test, datos de test y resultados del test.



Sección 4.12: Inspection and Test Status.

Enfoca el medio para identificar el estado del producto bajo desarrollo. Corresponde al estado del test y a la inspección sobre el producto.

Sección 4.11: Control of Inspection, Measuring, and Test Equipment.

Cuando se requieren herramientas o equipamiento especial, se exige que existan las políticas y procedimientos para asegurar que es posible verificarlo. En software, los programas de test deben demostrar ser capaces de probar el sistema. Con instrumentos, esta verificación de capacidad de medir es llamada “calibración”.

Sección 4.20: Statistical Techniques.

Rara vez usadas para software.



Sección 4.19: Servicing and Software Maintenance.

Se requieren políticas y procedimientos para asegurar que el mantenimiento se hace correctamente. Incluye todos los tipos de mantenimiento. Debe hacerse con los mismos controles de calidad que el software original.

Gestión de Requerimientos.

ISO 9001 NO se refiere explícitamente a la necesidad de preparar una especificación de requerimientos y asume que se define en un contrato. Los requerimientos son vistos a través de revisiones de contratos (asegurar que se definan en forma adecuada en el documento) y encontrol del diseño (resolver requerimientos ambiguos). IEEE 1298 requiere que haya una aceptación formal de los requerimientos.

vvs tema6 aprf/teaching/vvs11/downloads/tema6/vvs_tema… · desarrollar planes de pruebas...

Documents