Curso ISO IEC 90003.2004 Abril 2015.pdf

REQUISITOS NORMATIVOS

Y

AUDITOR INTERNO ISO 9001

CON APLICACIÓN DE LA GUÍA ISO/IEC

90003:2004

90003:2004

Directrices para la aplicación de la norma ISO 9001 al software

Nos presentamos:

Nombre y Apellido

Organización

PRESENTACIONES Y EXPECTATIVAS

ESTRUCTURA

•HORARIOS

Día 1: 14:00 – 18:00, 15:30 Coffee Break Día 2: 09:00 – 13:00, 11:00 Coffee Break •METODO DE APRENDIZAJE

Presentaciones – Debates - Ejercicios •OBJETIVO DEL APRENDIZAJE

Habilidad para gestionar un SGC en una organización basada en Tecnología de la Información con enfoque a las recomendaciones de ISO/IEC

ENFOQUE

¿Se podrá certificar un SGC en ISO 9001 y homologarlo en ISO/IEC 90003

cuyos procesos de diseño y desarrollo son ágiles, tipo SCRUM?

ISO: International Organization for Standarization

(Organización Internacional de Normalización).

IEC: International Electrotechnical Commission

(Comisión Electrotécnica Internacional).

ORGANIZACION ISO/IEC

ISO/IEC 90003 fue elaborada por un comité técnico

conjunto, JTC1, Subcomité SC 7 Ingeniería de sistemas y

de software.

La primer versión fue la 9000-3:1997. La guía vigente es

NORMAS Y ESTÁNDARES RELACIONADOS A TI

Estándares TI

Estándares TI

ISO/IEC 90003

ISO/IEC 90003

Guía aplicación

9001 en TI

ISO 9001

Requisitos

ISO 20000-1

ISO 27001

Seguridad de

ISO 20000-1

Gestión

servicios TI

la información

Seguridad de

la información

COBIT/PMBOK

Otros:

ITIL/CMMI/ COBIT/PMBOK

ITIL: Information Technology Infrastructure Library CMMI: Capability Maturity Model Integrated

COBIT: Control Objectives for Information and related Technology PMBOK: Project Management Body of Knowlegment

ACTIVIDADES

Controles:

Métricas Métricas, , Indicadores Indicadores

CONCEPTO Y ELEMENTOS DEL PROCESO

Las actividades pueden ser vistas como PROCESOSN

Entradas:

Requerimientos

Requerimientos //

Salidas:

C

L

I

Realimentación:

Errores,

Errores, performaceperformace, nuevos , nuevos rqrq..

El Proceso transforma entradas en

salidas agregando valor

LA CADENA DE PROCESOS

P R U P R O G D I A N

Errores, Nuevos requerimientos

Iteración de actividades en Tecnología de la Información

C

L

I M P L F A C

C

L

U E B A S G R A M A C I Ó N I S E Ñ O N Á L I S I S SISTEMAS BIANCHI

L

I

E

N

T

E

L A N T A C I Ó N Nuevas versiones C T I B I L I D A D

L

I

E

N

T

E

CICLO P-H-V-A

A

P

PLANEAR:

Plan de proyecto,

Plan de liberación de versiones, Plan de pruebas,

Plan de instalación/Migración

ACTUAR:

Ajustes metodología, estimaciones.

Inicio nuevo ciclo

V

H

VERIFICAR:

Indicadores de Rework, Calidad del software, fechas de entrega, esfuerzo laboral utilizado.

Reuniones de retrospectiva. Auditorias de proyectos.

HACER:

CICLO P-H-V-A ¿o SCRUM?

A

P

PLANEAR:

Planificación del producto o servicio.

ACTUAR:

Ajustes metodología, estimaciones.

Inicio nuevo ciclo

SPRINT PLANNING

RETRSOPECTIVE

V

H

VERIFICAR:

Indicadores de Rework, Calidad del software, fechas de entrega, Velocidad del equipo.

HACER:

Análisis, Diseño, Programación, Pruebas, Implementación, Soporte Post instalación.

ISO/IEC 90003:2004 -

3 Términos y Definiciones

Actividades de análisis de requerimientos, diseño, programación, integración, prueba, instalación y soporte.

Versión formalmente aprobada de un ítem de configuración, formalmente determinada y fijada en un momento específico durante el ciclo de vida Ciclo de vida

Desarrollo

Línea de Base

Marco de trabajo que contiene procesos, actividades y tareas involucradas en el desarrollo, operación y mantenimiento de un producto de sw desde los requerimientos hasta la terminación de su uso. Ejemplo: Cascada, SCRUM.

determinada y fijada en un momento específico durante el ciclo de vida del ítem de configuración. Ej.: cronogramas.

Conjunto de programas de computadora, procedimientos y documentación y datos posiblemente asociados.

Desempeño de actividades, trabajo u obligaciones relacionadas con un producto de software, tales como su desarrollo, mantenimiento y

operación. Línea de Base

Producto de Software

ISO/IEC 90003:2004 -

1.2 Exclusiones Permitidas

Ídem 9001,

pueden ser excluidos requisitos si no son

apropiados debido a naturaleza del producto/servicio o de la

organización.

Las exclusiones deben:

-

no afectar la capacidad para proveer producto/servicio

conforme y

-

estar limitadas a la cláusula 7

CONTROL DE DOCUMENTOS

4.2.3

4.0 - SISTEMA DE GESTION DE CALIDAD

REQUISITOS GENERALES 4.1 MANUAL 4.2.1 _4.0 SISTEMA DE Indicar Cumplimiento de ISO/IEC 90003 Descripción de:

-Ciclo de vida utilizado

-Herramientas

-Estándares

CONTROL DE DOCUMENTOS Y REGISTROS 4.2.4 DE CALIDAD DOCUMENTACION 4.2 SISTEMA DE GESTION DE CALIDAD

Explicar la metodología adoptada para cada recomendación 90003

Debe incluir como mínimo:

Indicar que el SGC cumple con ISO/IEC 90003:2004.

Al describir los procesos, evidenciar la relación de los requisitos con las

sugerencias en la guía ISO/IEC 90003.

4.2.2 – MANUAL DE CALIDAD

sugerencias en la guía ISO/IEC 90003.

¿Matriz de aplicabilidad / Mapa de requisitos?

Pensar en la

versión 2015 de ISO 9001

¿Cuántas páginas debe tener un MC?

4.2.4 - CONTROL DE REGISTROS

4.2.4.1 Evidencia de conformidad con los requisitos

Resultado documentados de pruebas, solicitudes de cambio Utilidad de las herramientas

4.2.4.2 Evidencia operación efectiva

Cambios a los recursos (personal, software de base, herramientas) y su justificación Cómo y porqué se seleccionaron herramientas, proveedores, metodologías.

1 2 3 4

5 6

Cómo y porqué se seleccionaron herramientas, proveedores, metodologías.

Acuerdos de licencias de software (el suministrado a los clientes y el de terceros para ayuda

al desarrollo y operación)

Liberación del software (relación al objetivo de calidad de software)

4.2.4.3 Retención y disposición

Tener en cuenta la degradación de los medios de almacenamiento y fecha de

vencimiento de los dispositivos que indica el fabricante..

¿Cuáles de los siguientes podrían ser registros

COMPROMISO DE LA DIRECCION

COMUNICAR IMPORTANCIA DE REQUERIMIENTOS

POLITICA - OBJETIVOS - REVISIONES - RECURSOS

5.1

5.0 - RESPONSABILIDAD DE LA DIRECCION

C

C

L

L

II

E

E

C

C

L

L

II

E

E

PLANIFICACION 5.4

ENFOQUE AL CLIENTE

NECESIDADES Y EXPECTATIVAS

5.2

POLITICA DE LA CALIDAD

5.3

REVISION POR LA DIRECCION

5.6

OBJETIVOS DE CALIDAD

PROCESOS - SISTEMA

5.4.1 5.4.2 MEDICION 8.0 C C A A L L II D D A A R R ISO/IEC 90003 Tiempo, Costo, Calidad

ALCANCE DEL SGC

E

E

N

N

T

T

E

E

E

E

N

N

T

T

E

E

5.5.1

RESPONS - AUTORIDAD

5.5.2

REPRES DE DIRECCION

5.5.3

COMUNICAC INTERNA

IMPLEMENTACION DEL SGC

5.5 MEDICION ANALISIS Y MEJORA A A D D P P E E R R C C II B B II D D A A R R E E Q Q U U E E R R II M M II E E T T O O S S PRODUCTO PRODUCTO

Debería incluir como mínimo

_{Fecha de entrega planificado vs. fecha de entrega real.} Cantidad de issues elegidos del backlog que

formaron parte del sprint

_{Costo estimado vs. costo real. Velocity}

_{Calidad cantidad de errores previstos vs. errores encontrados, cantidad de} issues re planificados.

5.4.1 - OBJETIVOS DE LA CALIDAD

Otros posibles objetivos

_{Rework: Cantidad de tareas que ingresan a desarrollo más de 1 vez.}

_{Regresiones: Cantidad de funciones existentes que se desajustan luego de una} versión nueva.

_{Cantidad de código en estándard / total del código. Líneas de código por método.}

_{Números de métodos por clase. Líneas de código reutilizadas.}

5.4.2 – PLANIFICACION SGC

Acciones C o P Oportunidades

de mejora

A

V

H

Tipos de modelo De ciclo de vida

P

P

Procesos de mejora Procesos de gestión POLITICA DE LA CALIDAD

ORGANIZACIONAL POR PROYECTO/

PRODUCTO (7.1) Oportunidades de mejora POLITICA DE LA CALIDAD

P

Medición y Análisis

- Satisfacción del Cliente - Productos ó servicios - Procesos

V

Gestión (implementación y seguimiento)

H

De ciclo de vida (Frameworks)

Activos por tipo De proyecto, Ambientes, herramientas Planes: proyectos, pruebas, configuración, capacitación

Ciclo aplicable al proy./producto

EJERCICIO 1 - DEBATE

¿Se puede excluir 7.3 si sólo se realiza mantenimiento ya que

el producto fue desarrollado antes del inicio del SGC?

¿Se puede excluir 7.5.2 con un call center/equipo de trabajo

funcionando para soporte?

¿Se puede excluir el deploy porque se terceriza la actividad o el

¿Se puede excluir el deploy porque se terceriza la actividad o el

alcance está enfocado al desarrollo, por ej.: “desarrollo de

software de misión crítica para entidades financieras”?

¿Qué pasa cuando se utilizan herramientas del cliente como

evidencia de nuestro SGC?

Cuando un procedimiento del SGC indica como “

optativo

” un

EJERCICIO 1 – DEBATE (cont.)

¿Lo que dice en los procedimientos es un problema del área de

calidad?

¿Voy a completar esta planilla para mostrarle al auditor?

6.0 - GESTION DE RECURSOS

6.0

GESTION DE

SUMINISTRO DE RECURSOS

AMBIENTE RECURSOS

e-learning,

_{auto capacitación,} Talleres internos.

_EFECTIVIDAD

GESTION DE RECURSOS

INFRAESTRUCTURA

AMBIENTE DE TRABAJO HUMANOS

_{Manejo de ambientes: Desarrollo,}

prueba, homologación, producción.

_{Herramientas de gestión de configuración}

y versionado.

_{Herramientas de administración del}

conocimiento.

_{Herramientas monitoreo de red, accesos,}

Enfoque en

_{Capacitaciones pendientes: Reprogramación de capacitaciones o}

justificación de porque no son más de interes de la organización.

_{Inducción a los empleados}

Criterio de confidencialidad mínimamente de acuerdo al cliente más

exigente en esta materia.

6.2 – RECURSOS HUMANOS

exigente en esta materia.

Descripción de las capacitaciones.

Requisitos legales: Comunicación “A” 4609 BCRA (Requisitos mínimos

de gestión, implementación y control de los riesgos relacionados con tecnología informática y sistemas de información), Ley de Habeas Data, Ley de delitos informáticos.

_{Autocapacitación, e-learning, talleres internos.}

Manejo de ambientes.

6.3 – INFRAESTRUCTURA

DESARROLLO _TESTING TEST INTEGRACION

TEST

ACEPTACIÓN PRODUCCIÓN

Ambiente de

Hardware/Software de base, comunicaciones y datos “similares” a producción.

Prueba circuitos end-to-end.

Pruebas performance, estres, conectividad.

Ambiente de desarrollo, datos de pruebas unitarias.

EJERCICIO 2 – Relacionar conceptos y requisitos

ISO 9001 e ISO/IEC 90003

1- Ciclo de vida

2- Desarrollo de software

3- Activos/ Artefactos

A- Actividades de análisis de requerimientos, diseño,

programación, integración, prueba, instalación y soporte. B- Conjunto de programas desarrollados para administrar los

recursos de un computador. Ej.: Windows, Linux, OS400. C- Java, C#, Cobol, C++, Visual Basic, Pascal, Delphi, Fortran,

Pl/I, .net.

D- Casos de uso, Diagramas de entidad relación, cronogramas, planes, código fuente, pruebas.

E- Marco de trabajo que contiene procesos, actividades y tareas Artefactos

4- Software de base

5- Lenguajes de programación

E- Marco de trabajo que contiene procesos, actividades y tareas involucradas en el desarrollo, operación y mantenimiento de un producto de sw desde los requerimientos hasta la

terminación de su uso. Ejemplo: Cascada. F- Ambientes de simulación de interfases.

G- Webservices. H- SCRUM.

PLANIFICACION DE LOS PROCESOS DE REALIZACION 7.1

C

C

L

L

II

E

E

7.0 - REALIZACION DEL PRODUCTO Y/O SERVICIO

C A L I D A D PRODUCTO

C

C

L

L

II

E

E

R E Q U E R I OPERACION PRODUCCION O 7.5 DISEÑO Y DESARROLLO 7.3 COMPRAS 7.4 IDENTIF. Y REVISION 7.2 VERIFICACION DE PRODUCTOS COMPRADOS 7.4.3 EVALUACION DE PROVEEDORES 7.4.1

P R O V E E D O R E S

P R O V E E D O R E S

DATOS DE COMPRAS 7.4.2

E

E

N

N

T

T

E

E

P E R C I B I D A A PRODUCTO SERVICIO

E

E

N

N

T

T

E

E

I M I E T O S PRESTACION (Incluye entrega y

Postventa)

DESARROLLO

PRODUCTO O SERVICIO

INSUMOS O SERVICIOS

REVISION

REQUISITOS DEL PRODUCTO

IDENTIFICACION Y TRAZABILIDAD

VALIDACION DE PROCESOS

PROPIEDAD DEL CLIENTE

PRESERVACION DEL PRODUCTO

CONTROL DE INSTRUMENTOS

7.5.2 7.5.3 7.5.4 7.5.5 7.6 RESULTADOS D&D

DATOS DE ENTRADA _7.3.2

REVISION D&D VERIFICACION D&D VALIDACION D&D 7.3.4 7.3.5 7.3.3 7.3.6

REVISION DE REQ

IDENTIF. DE REQ _7.2.1

COMUNICACIONES _7.2.3

ISO/IEC 90003:2004

Determinar necesidades y expectativas de los Clientes

Requerimientos

7.1.1 Ciclo de vida del software 7.1.2 Planificación de la calidad

7.2.1.1 Req. relacionados con el cliente

7.2.1.2 Req. adicionales determinados por la organización _{7.2.2.1 Intereses de la organización}

7.2.2.2 Riesgos

7.2.2.3 Representante del cliente Requerimientos

Realización del producto requerido

7.2.2.3 Representante del cliente

7.2.3.1 Comunicación con el cliente – Generalidades _{7.2.3.2 Comunicación con el cliente durante el desarrollo}

7.2.3.3 Comunicación con el cliente durante la operación / mantenimiento

_{7.3.1.1 Planificación del diseño y desarrollo}

7.3.1.2 Revisión, verificación y planificación 7.3.4 a 7.3.6 7.3.1.3 No hay directriz

7.3.1.4 Interfaces

7.3.2 / 7.3.3 / 7.3.4 / 7.3.5

7.3.6.1 Validación

7.3.6.2 Pruebas

ISO/IEC 90003:2004

7.1 Planificación de realización del producto

7.1.1 Ciclo de vida del software _{por PROYECTO}

Iterativo incremental, 3 versiones anuales.

7.1.2 Planificación de la calidad (Manual del proyecto) 7.1.2 Planificación de la calidad (Manual del proyecto)

Particularidades de la versión.

Excepciones al proceso definido en los procedimientos.

ISO/IEC 90003: 7.1 PLANIFICACIÓN DE REALIZACIÓN DEL PRODUCTO

Issue/Incidencia cabecera por proyecto con sus características.

7.2 Procesos relacionados con el Cliente

7.2.1 Determinación de los requisitos del producto

7.2.1.1 Requerimientos relacionados con el cliente

7.2.1.2 Requierimientos adicionales determinados por la organización

Scrum: Se actualiza el BACK LOG

7.2.2 Revisión de los requisitos del producto

7.2.2.1 Intereses de la organización

ISO/IEC 90003:2004

7.2.2.1 Intereses de la organización

7.2.2.2 Riesgos

7.2.2.3 Representante del cliente

Scrum: Se prioriza el BACK LOG

7.2.3 Comunicación con el cliente

7.2.3.1 Generalidades

7.2.3.2 Comunicación con el cliente durante el desarrollo

7.2.1.1 Requerimientos relacionados con el cliente

Metodología de aprobación/acuerdo de requerimientos, cambios, evaluación de prototipos. Trazabilidad del requerimiento con producto final.

Casos de uso, UML (unified modeling lenguage).

7.2.1 DETERMINACIÓN DE LOS REQUISITOS DEL PRODUCTO

7.2.1.2 Requerimientos adicionales determinados por la organización

7.2.2.1 Intereses de la organización

Características del producto arquitectura, escalabilidad, nicho de mercado, performance Plataformas hardware, sistemas operativos, conectividad con motores de base de datos. Acuerdos con interfaces externas: APIs, Conectores.

Requerimientos de instalación (hw, sw de base, comunicaciones), copias y distribución. Aspectos legales, de seguridad y confidencialidad

Protección de la información (habeas data), licencias, patentes, derecho de autor

7.2.2.2 Riesgos Acciones de ponderación y mitigación

7.2.2 REVISIÓN DE LOS REQUERIMIENTOS

RELACIONADOS CON EL PRODUCTO

7.2.2.2 Riesgos _{Acciones de ponderación y mitigación}

Confiabilidad de las estimaciones, equipo de trabajo junior. Alta rotación del personal.

Disperción geográfica, tema desconocido, novedad técnica. Interfaces con sistemas legacy o de terceras partes.

Usuario inexistente o no comprometido = cambios a los requerimientos al momento de la entrega.

7.2.2.3 Representante del cliente

Identificado su responsabilidad en el manual del proyecto.

7.2.2.2: RIESGOS - Definiciones

Riesgo: Evento o condición incierta que, en caso de ocurrir, tiene un efecto positivo o negativo sobre los objetivos de un proyecto.

Identificación de los riegos, ejemplos:

_{Tecnología nueva o poco probada Escaso involucramiento del cliente}

_{Personal con perfil inadecuado para la complejidad de la solución Deficiencias con interfaces a terminales/concesionarios}

_{Cambios a requerimientos ya definidos y estimados Demasiadas funciones dentro de una misma versión No se detectan riesgos}

_{No se detectan riesgos}

Análisis de riesgo

Análisis de la probabilidad ocurrencia del evento y el impacto que ese evento puede causar en costo, tiempo y/o calidad del producto.

Respuesta al riesgo

- Evitar el riesgo: Se deberá cambiar el requerimiento o especificación con el objeto de eliminar las causas que generan el riesgo.

- Transferirel riesgo: Se podrá realizar mediante la tercerización a un especialista en los casos donde el equipo de trabajo no tiene experiencia en el tema y es muy costoso o impracticable por los tiempos planificados.

- Mitigar el riesgo: Se aplicará alguna actividad o práctica que baje la probabilidad y/o el impacto hasta un riesgo aceptable. Esta actividad se registrará en Mantis.

7.2.3.1 Generalidades

El método de comunicación podría cambiar por proyecto

7.2.3.2 Comunicación con el cliente durante el desarrollo

Planes de comunicación que indique frecuencia del seguimiento a los planes y tareas. Procesos de prototipos.

Criterios de aceptación de pruebas y entregables.

7.2.2.3 Comunicación con el cliente durante la operación y el mantenimiento

7.2.3 COMUNICACIÓN CON EL CLIENTE

7.2.2.3 Comunicación con el cliente durante la operación y el mantenimiento

SLA: Service Level Agreenment sobre actividades de mantenimiento Tiempos de respuesta a inquietudes, solicitudes, incidentes

Tiempos de resolución de incidentes por tipificación (críticos, graves, medianos, bajos). Penalizaciones

Información sobre el producto: Ayuda en línea, manuales de usuario, sitios web.

EJERCICIO 3 – DEBATE req. 7.1 y 7.2

Revisar el requisito 7.2.1.1 c). Responder ¿es necesario

conseguir la aprobación del cliente para un requisito?

¿Cómo? ¿Y con SCRUM?

Si se estudia el riesgo al momento de la generación del

requisito, ¿Es necesario reconsiderar nuevos riesgos? ¿En

requisito, ¿Es necesario reconsiderar nuevos riesgos? ¿En

qué proyectos se debe analizar riesgo? ¿Cuándo generar

acciones?

7.3.1 Planificación del diseño y desarrollo

7.3.1.1 Planificación del diseño y desarrollo

7.3.1.2 Revisión, verificación y planificación _{7.3.4 a 7.3.6}

7.3.1.3 No hay directriz 7.3.1.4 Interfaces

7.3.2 Entradas del diseño y desarrollo

7.3.3 Resultados del diseño y desarrollo

ISO/IEC 90003:2004 – 7.3 Diseño y desarrollo

7.3.4 Revisión del diseño y desarrollo

7.3.5 Verificación del diseño y desarrollo

7.3.6 Validación del diseño y desarrollo

7.3.6.1 Validación 7.3.6.2 Pruebas

7.3.1.1 Planificación del diseño y desarrollo

Etapas: análisis, diseño, programación, pruebas e instalación. Hitos

Recursos humanos, equipamiento de hardware, ambientes (software de base, metodología de pasaje entre

ambientes).

Estimación de tiempos de las actividades utilizando riesgos y lecciones aprendidas. Estimación de la programación

Ojo de experto: Un sólo experto estudia las especificaciones y realiza estimación.

Wideband Delphi: Conjunto de expertos, opiniones anónimas hasta convergencia de opiniones.

7.3.1 Planificación del diseño y desarrollo

Wideband Delphi: Conjunto de expertos, opiniones anónimas hasta convergencia de opiniones. Analogía: Comparación con proyectos similares, novedades tecnológicas.

Precio del mercado: Se estima de acuerdo a lo que paga el cliente. Sólo muy peligroso. Algorítmicos: Puntos de función, COCOMO, Putnam

Serie de Fibonacci para ponderación de requierimientos Convenciones, estándares de programación y nomenclaturas.

7.3.1.4 Interfaces

Aclarar responsabilidades cuando hay interfaces desde/hacia legacy u otros productos integrados en la

7.3.2 Elementos de entrada para el diseño y desarrollo

Análisis = ¿QUÉ?

Evitar ambigüedad y contradicción

Detectar faltantes, inconsistencias o req. impracticables Req. asumidos o no establecidos

ANALISIS ESTRUCTURADO/ORIENTADO A OBJETOS

ANALISIS ESTRUCTURADO = Descomposición funcional basada en procesos / sub-procesos

ANALISIS OO = Composición de clases basada en abstracción de datos

ANALISIS OO = Composición de clases basada en abstracción de datos

Herramientas de análisis.

Casos de Uso / Historias (con niveles de detalle, narrativos, en gráficos como UML)

DFD: Diagramas de flujo de datos (Análisis estructurado).

Diagramas de transición de estados.

Diagrama de flujos.

7.3.3 Resultados del diseño y desarrollo

Diseño = ¿CÓMO?

Modelado de la solución Descomposición de módulos

Compsición de clases

ESTRUCTURADO/ORIENTADO A OBJETOS

Herramientas de diseño. Herramientas de diseño.

Arquitectura de la aplicación Diagrama de módulos

Diagramas de clases (Objetos).

Interfaces de usuario (pantallas modelo).

Pseudo código.

Autoridad de revisión

de temas importantes de diseño.

Seguimiento al

proyecto de acuerdo con Manual del proyecto / Plan de comunicaciones.

Programación de a

7.3.4 Revisión del diseño y desarrollo

Programación de a

pares:

Dos programadores, una computadora.

Sprint review

Inspección del código.

Prototipos de funcionamiento.

Revisión por pares.

7.3.6.1 – Validación

Circunstancias de no prueba: Simulación, inspección de código,

herramientas utilizadas.

7.3.6.2 - Pruebas

Pruebas unitarias: Pruebas del programador. 7.3.6 Validación del diseño y desarrollo

Pruebas unitarias: Pruebas del programador.

Pruebas de integración: Pruebas del sistema completo con interfaces.

Pruebas de performance, estres y volúmen.

Pruebas de aceptación: Pruebas de usuario / criterios de aceptación en

Descripción del impacto en:

Fechas/Hitos del proyecto

Costos

Diseño, manuales y productos entregados.

EJERCICIO 4 – DEBATE req. 7.3

¿En un proyecto de integración de soluciones, el integrador

debe realizar revisión / validación o no? ¿Seguimiento al

proyecto? Buscar requisitos.

¿Como aseguran las metodologías ágiles la planificación y

seguimiento a los proyectos indicadas en los requisitos 7.3.1

y 7.3.4?

y 7.3.4?

¿Cómo se manejaría un paso de arquitectura con SCRUM?

¿Cómo se verifica el diseño de un producto cuando no hay

documentos o activos más allá del código fuente (ayuda

patrones de diseño)?

¿Es aceptable no generar ninguna definición del cliente?

EJERCICIO 4 – DEBATE req. 7.3

¿Cómo se gestionan los cambios con SCRUM?

EJERCICIO 5 – Repaso 7.1, 7.2 y 7.3 y

relacionar con requisitos ISO 9001 e ISO/IEC 90003

1- Activo de diseño OO

2- Caso de uso

3- Patrón de diseño

4- Requisito NO

A- Documento o diagrama utilizado para describir un requisito funcional o no funcional.

B- Ejecución de conjuntos de casos de prueba funcionales y no funcionales con el objetivo de validación de software

(encontrar bugs).

C- Diagrama de clases (jerarquía de clases).

D- Diagrama de Entidad Relación (Descripción del agrupamiento y relación de los datos).

E- Portabilidad. 4- Requisito NO

funcional

5- Ciclos de pruebas.

6 - Interfaces

7- Estimación

E- Portabilidad.

F- Solución de diseño para problemas comunes y repetitivos. Ej.: Abstract Factory, Builder, Object Pool, Singleton.

G- Cantidad de transacciones por unidad de tiempo. H- Juicio de experto, Puntos de función, COCON. I – Diagrama de bloques.

7.4.1 Proceso de compras

7.4.1.1 Productos comprados

7.4.1.2 Control de los productos comprados

7.4.2 Información de las compras

ISO/IEC 90003:2004 – 7.4 Compras

7.4.1 Proceso de compras

7.4.1.1 Productos comprados

El software libre debe considerarse como producto comprado.

Desarrollos subcontratados (Ej.: Contratación de personal, tercerización de desarrollo de

módulos o productos completos).

Servicios subcontratados (Ej.: Instalación).

Herramientas utilizadas en el desarrollo: Diseño como EA, Ambientes (Ides) como Eclipse,

compiladores, robot de pruebas como Selenium.

Cursos y materiales de capacitación. Cursos y materiales de capacitación.

Los procesos fuera de la organización pueden impactar en el riesgo. (Ej.: Nuevos proveedores)

7.4.1.2 Control de productos comprados

Personal habilidades específicas y competencia requeridos.

Incrementar controles y medir su eficiencia ante productos/servicios comprados que serán

ISO/IEC 90003:2004 – 7.4.2 / 7.4.3

7.4.2 Información de compras

La información de compras para sw puede incluir:

•

Trazabilidad producto comprado: versión, manuales de instalación, configuración y uso.

•

Procedimiento y/o normas que el proveedor debe seguir.

•

Entorno homologado, Ej.: sistema operativo, hardware, motor de BD.

El requisito 7.2.2 puede aplicar a subcontratistas.

7.4.3 Verificación de los productos comprados

Identificar e implementar actividades necesarias para verificar el producto comprado.

•

Pruebas de aceptación / Criterios de aceptación del producto comprado.

•

Método de verificación – validación – aceptación del trabajo subcontratado.

•

Inspección y auditorías a la empresa contratada.

•

Contratación de personal: Educación, entrenamiento, habilidades, experiencia en áreas de negocio similares.

EJERCICIO 6 – DEBATE requisito 7.4

¿Es razonable excluir 7.4 Compras en una empresa

dedicada al desarrollo de software?

¿Es posible controlar a un programador free lance

sólo con una evaluación de proveedores?

7.5.1 Control de la producción y la prestación del servicio

7.5.1.1 Producción y prestación de servicios de software 7.5.1.2 Construcción y Liberación

7.5.1.3 Réplica (copia) 7.5.1.4 Entrega

7.5.1.5 Instalación 7.5.1.6 Operaciones 7.5.1.7 Mantenimiento

7.5.2 Validación de los procesos

ISO/IEC 90003:2004 – 7.5 Producción y

prestación del servicio

7.5.2 Validación de los procesos

7.5.3 Identificación y trazabilidad

7.5.3.1 Generalidades

7.5.3.2 Proceso de administración de la configuración 7.5.3.3 Trazabilidad

7.5.4 Propiedad del Cliente

7.5.1 Control de la producción y de la prestación del servicio

7.5.1.2 Construcción y liberación

7.5.1.2 Construcción y liberación

7.5.1.3 Réplica (copia) 7.5.1.3 Réplica (copia)

7.5.1.4 Entrega 7.5.1.4 Entrega

7.5.1.1 Producción y

Prestación servicios de sw 7.5.1.1 Producción y

Prestación servicios de sw Actividades de liberación, entrega y post producción._{Licencias entregadas}

_{Liberación del sw: publicaciones, instrucciones de instalación. Migración de datos.}

_{Bugs arreglados / funcionalidades nuevas Instaladores, prueba de los instaladores.}

_{Copias: pruebas de funcionamiento, rótulo con versión, notas de liberación y}

manuales de nuevas configuraciones y funciones / mejoras.

_{Mediofísico 7.5.5 Preservación del producto}

_{Publicación / Transmisión / VPN en ambientes del cliente}

Instrucciones de instalación

_{Roles y responsabilidades compartidas con el cliente.}

7.5.1.5 Instalación 7.5.1.5 Instalación 7.5.1.7 Mantenimiento 7.5.1.7 Mantenimiento 7.5.1.6 Operaciones 7.5.1.6 Operaciones

_{Roles y responsabilidades compartidas con el cliente.}

_Validaciones

_{Configuración.}

_{Planes de instalación y puesta en marcha.}

Criterios de aceptación

_{Capacitación nueva versión / producto.}

_{Esquema de back up por posible vuelta atrás.}

_{Mesa de ayudas / Comunicación con el cliente}

_{Soporte cuando corresponda (back up, seguridad, alta disponibilidad)}

_{Continuidad del negocio Continuidad del negocio / DRP}

SLA

SLA (Service Level Agreenment)

Alcance (7x24, horario comercial)

_{Definición/respuesta/atención de incidentes y consultas / Tipo de incidentes}

_{Seguimiento del servicio}

7.5.2 Validación de los procesos de producción y prestación

del servicio

Soporte post-producción

Personal de mesa de ayudas/soporte: Conocimiento técnico y del producto.

Instrucción al personal de soporte antes de liberar versiones.

Seguimiento al personal nuevo de soporte con personal con experiencia.

Métricas de resolución de primer nivel o segundo nivel (personal de

programación). programación).

7.5.3 Identificación y Trazabilidad

7.5.3.1 Generalidades

Gestión de la configuración: Versionado, trazabilidad de activos desde rq. A la liberación.

7.5.3.2 Proceso de administración de la configuración

Herramientas y responsabilidades (Subversion, CVS, SourceSafe, Change Manager for

Mainframe, Endevor)

Activos bajo control de la configuración (Análisis, diseño, programación, pruebas).

Identificación de todos los componentes de software que constituyen una versión (liberada o

no), incluyendo sw comprado o suministrado por el cliente.

Control de actualizaciones simultáneas del equipo de trabajo con los items de software.

7.5.3.3 Trazabilidad

Relación entre los activos que componen una versión.

7.5.4 Propiedad del cliente

Incorporar o adquirir productos del cliente. Herramientas de desarrollo

Ambientes de desarrollo y redes.

Hardware

Datos de prueba

Datos reales DESENCIBILIZACIÓN, CONTROL DE CLAVES ACCESO VPN Especificaciones, manuales, información confidencial.

RECOMENDACIONES:

7.5.5 Preservación del producto

Entrega de fuentes o de objetos/ejecutables. En el primer caso, ¿como se garantiza que no

han sido alterados desde el último test de aceptación?.

Almacenar los activos manteniendo versiones relacionadas con líneas de base. Plan de back-up.

Pruebas de buen funcionamiento del back-up al azar = Restore. Copias de resguardo fuera de la organización.

Vencimiento de los dispositivos de almacenamiento por resgurardos Protección contra virus

7.6 Control de los dispositivos de seguimiento y medición

Robot de pruebas (casos de pruebas programados) Ej.: Selenium.

Integración continua (pruebas unitarias al momento que el programador integra una

versión que ha trabajado localmente). Ej.: Hudson, Team Foundation. Eclipse.

Scripts/jobs para control de migraciones. Ambientes de simulación, Ej.:

facturación electrónica. RECOMENDACIONES:

RECOMENDACIONES:

Control de la configuración de los productos verificar que el software no haya

cambiado, nuevas librerías.

Control del porcentaje del producto que se prueba automáticamente.

Documentar bajo que condiciones, eventos, cambios al software debe revisarse las

EJERCICIO 7: Siglas. Relacionar con

requisitos ISO 9001 e ISO/IEC 90003

1- DRP

2- SLA

3-OO

A- Nivel del acuerdo del servicio.

B- Alta Disponibilidad.

C- Parte de la continuidad del negocio.

4- IDE

5-HA

D- Ambiente de programación.

E- Pruebas de estrés y volumen.

F- Herencia, Abstracción, Polimorfismo y Encapsulamiento.

EJERCICIO 8 – DEBATE requisitos 7.5 y 7.6

Opinión sobre las siguientes FRASES:

“La instalación no está incluida en nuestro SGC”

“La instalación la realiza un proveedor”

“La producción es atendida por una nueva persona, que incluso ingresa en el

ambiente del cliente y modifica datosN”

¿Se puede excluir 7.6 con el uso de un robot de pruebas/integración continua/script ¿Se puede excluir 7.6 con el uso de un robot de pruebas/integración continua/script

o jobs automáticos?

¿Cómo se relaciona SCRUM con errores detectados en producción o testing?

¿Cómo asegurar sprint fijos cuando se pueden incorporar errores que por definición no se puede prever? ¿o si?

PLANIFICACION DE MEDICIONES

8.1

8.0 - MEDICION, ANALISIS Y MEJORA

MEDICION DE PERCEPCION Y RECLAMOS 8.2.1 ANALISIS DE DATOS 8.4 CONTROL DE PNC 8.3

P R O V E E D O R E S

P R O V E E D O R E S

ACCIONES CORRECTIVAS Y PREVENTIVAS 8.5.2 8.5.3 DIRECCION PLANIFICACION CONTROL AUDITORIAS INTERNAS AUDITORIAS INTERNAS 8.2.2

C

C

L

L

II

E

E

C A L I D A D

C

C

L

L

II

E

E

R E Q PLANIFICACION

PROCESOS - SGC OBJETIVOS MEJORA CONTINUA 8.5 SEGUIMIENTO Y MEDICION DE PRODUCTOS 8.2.4 SEGUIMIENTO Y MEDICION DE PROCESOS 8.2.3

E

E

N

N

T

T

E

E

P E R C I B I D A A

E

E

N

N

T

T

E

E

Q U E R I M I E T O S OPERACION PRODUCCION O PRESTACION DISEÑO Y DESARROLLO

PRODUCTO O SERVICIO

COMPRAS

INSUMOS O SERVICIOS

IDENTIF. Y

REVISION

REQUISITOS DEL PRODUCTO

PROCESOS DE REALIZACION

8.2.1-SATISFACCION DEL CLIENTE

Análisis de los llamados a la mesa de ayudas

¿ Qué técnicas podemos utilizar ?

Cantidad de liberaciones posteriores a una nueva versión

Encuestas de Satisfacción por proyecto

Cantidad de liberaciones posteriores a una nueva versión

Cantidad de consultas de nuevas funciones

Realizar auditorías internas periódicas para determinar la calidad del SGC y del producto:

- Auditar diferentes tipos de proyectos (framework). - En distintas etapas del ciclo de vida.

- Seleccionar diferentes tecnologías.

- Auditar al personal técnico y código.

8.2.2-AUDITORIAS INTERNAS

- Auditar al personal técnico y código.

- Definir capacidades del auditor interno en ISO/IEC 90003.

- Auditores idóneos en TI.

- Según directrices de ISO 19011 para sistemas de

Definiciones ISO 9000:2005 acerca de la auditoría:

3.9.1 auditoría: proceso sistemático, independiente y

documentado para obtener evidencias de la auditoría (3.9.4) y evaluarlas de manera objetiva con el fin de determinar el grado en que se cumplen los criterios de auditoría (3.9.3)”

3.9.4 evidencia de la auditoría: registros (3.7.6), declaraciones de hechos o cualquier otra información (3.7.1) que son pertinentes para los criterios de

TÉCNICAS DE AUDITORIAS INTERNAS

cualquier otra información (3.7.1) que son pertinentes para los criterios de auditoría (3.9.3) y que son verificables

3.9.3 criterios de auditoría: conjunto de políticas, procedimientos (3.4.5) o requisitos (3.1.2)

Propósito de una AUDITORÍA

Determinar si el SGC conforma los requisitos de la norma, leyes y regulaciones y procedimientos definidos (escritos o no),

Auditor líder

Responsable de la conducción y realización de la auditoría.

Auditores

Realizan la auditoría siguiendo las instrucciones del auditor líder.

Requisitos del auditor

EQUIPO AUDITOR

Requisitos del auditor

• Independiente del área auditada,

• Libre de conflicto de intereses,

• Experiencia y capacitación.

Atributos del auditor Objetividad

Analítico

Amabilidad

Saber

Actitud +

Observador

Organizado

Curioso

Perseverante

Programa de auditoría, considerar:

- Importancia de la actividad

- Resultado de la auditoría previa

- Minimizar alteraciones en la empresa

- Disponibilidad de auditados y auditores

PROGRAMA DE AUDITORÍA

Pautas para el programa

- Alcanzar todos los sectores y procesos del SGC.

- Cubrir todos los requisitos aplicables.

- Definir y justificar frecuencia según importancia de la actividad, resultados de los procesos y auditorías previas.

1- PREPARACIÓN – 40%

- Las auditorias no deben se realizadas “por sorpresa” sino acorde al plan de

auditoría.

- Revisión de informes previos, procedimientos, nuevas legislaciones,

reclamos, necesidades de negocio.

- Listas de verificación

- Plan de auditoría

ETAPAS DE AUDITORIAS: PREPARACIÓN

- Plan de auditoría

2- EJECUCIÓN – 40%

- Reunión inicial

_{Exponer el propósito de la auditoría Revisión del plan}

_{Identificación de los responsables de procesos}

_{Aclarar que se toman decisiones de acuerdo a una muestra}

- Entrevistas y recopilación de evidencias

_{Crear un buen clima de comunicación (contacto visual, lenguaje corporal, trato}

ETAPAS DE AUDITORIAS: EJECUCIÓN

_{Crear un buen clima de comunicación (contacto visual, lenguaje corporal, trato}

respetuoso).

_{Evidencias objetivas (examen de registros, documentos). Evitar preguntas cerradas o dirigidas.}

_{Prestar atención, hacer sentir cómo al auditado.}

- Reunión final

3- INFORME – 10%

- Área auditada.

- Lugar y fecha

- Equipo auditor

- Participantes

- Documentos aplicables

- Objetivo y alcance

ETAPAS DE AUDITORIAS: INFORME y SEGUIMIENTO

- Objetivo y alcance

- Resumen de las actividades desarrolladas

- Comentarios sobre los hallazgos

- Conclusiones

4-SEGUIMIENTO – 10%

- Verificar efectividad acciones correctivas

- Verificar estudio de costo/beneficio en oportunidades de mejoras.

EJERCICIO 9 – Auditando un SGC

homologado en ISO/IEC 90003

-

Realizar una lista de verificación de auditoría interna para la

empresa “Byte a byte”, que se dedica al desarrollo,

implementación y soporte de su sistema ERP.

Un módulo del ERP

lo desarrolla la empresa del primo del dueño.

Enfocar al capítulo

7.2 y 7.3.

- Realizar una lista de verificación de auditoría interna para la

8.2.3 – Seguimiento y control de los procesos

Debe incluir como mínimo

_{Fecha de entrega planificado vs. fecha de entrega real.}

_{Costo estimado vs. costo real.}

Calidad: cantidad de errores previstos vs. errores encontrados.

8.2.4 – Seguimiento y control del producto

Rework: Cantidad de tareas que ingresan a desarrollo más de 1 vez.

_{Regresiones: Cantidad de funciones existentes que se desajustan luego}

de una versión nueva.

_{Cantidad de código en estándard / total del código.}

_{Líneas de código por método.}

Números de métodos por clase.

_{Líneas de código reutilizadas.}

_{Tiempo transcurrido desde que se modificó una clase.}

_{Portabilidad.}

_{Escalabilidad.}

Confiabilidad.

Controlar el producto no conforme, para prevenir su uso o liberación no intencional

Definir autoridad para liberar aplicación con errores conocidos

Nuevo testing después de la corrección

Definir PNC y su tratamiento

8.3- CONTROL PRODUCTO NO CONFORME

Recolectar y analizar datos para determinar la efectividad del SGC / producto y para identificar mejoras que pueden realizarse:

Analizar datos para proveer información de :

8.4 – ANALISIS DE DATOS

- Análisis exhaustivos en los distintos niveles de pruebas

- Conformidad con los requisitos del producto

Las acciones que impliquen cambios en la

metodología realizar con casos piloto para medir su

efectividad antes de su generalización.

TRATAMIENTO DE NO CONFORMIDADES

Cliente

Reclamos o Quejas por Producto o

Servicio NC Proveedores Insumo o servicio NC Areas/Sectores Producto, proceso o sistema NC

Revisión por la Dirección Sistema NC Auditorías Internas Sistema NC Detección, comunicación y registros Determinación

Identificar causa raíz, definir la AC,

verificar implement. y eficacia Determinación del Alcance Disposición y Acc. inmediatas

AC MANDATORIA

ANALISIS DE CAUSA

Por qué?

Síntomas

Por qué?

Causas aparentes Evidencias objetivas

del problema

NC

Por qué?

ALCANCE

Implicancias ocultas

Por qué?

?

Causa Raíz

Por qué?

TIPOS DE ACCIONES

Evidencias objetivas del problema

Síntomas Causas La ACCION INMEDIATA

ataca al problema

NC

ALCANCE Implicancias ocultas

Causa Raíz Causas aparentes

Su propósito es limitar sus efectos y ponerlo bajo control

La ACCION CORRECTIVA ataca a la causa

EJERCICIO 10 – DEBATE capítulo 8

OPINIÓN acerca de PNC:

¿Un error en desarrollo es una N/C?,

¿Un error en testing?,

¿Un error en producción?,

¿Cuándo un error es un PNC?

¿Todos los PNC son N/C? ¿Todos los PNC son N/C?

¿Cómo se deben controlar las características del producto?

¿Las AC y AP provienen solamente de auditorías internas?

¿Las reuniones de retrospectiva o similares, son input al SGC?