INTRODUCCIÓN Guía de Aplicación IRAM ISO/IEC 90003:2006 para Sistemas de Software

Transcripción

1 INTRODUCCIÓN Guía de Aplicación IRAM ISO/IEC 90003:2006 para Sistemas de Software Lic. Domingo Donadello Coordinador de Certificación de Sistemas de TI de IRAM 1

2 Programa Guía ISO 90003: Interpretaciones de las recomendaciones normativas Qué se audita? Objetivo del curso Conocer la Guía de aplicación ISO a los sistemas de software de computadoras 3

3 CRONOLOGIA 2004 => ISO/IEC => IRAM ISO/IEC 90003:2006 (Directrices para la aplicación de la Norma IRAM ISO 9001:2008 al Software) 4

4 ISO 9000:2000 Guía Fundamentos y vocabulario Origen y Motivación Surge debido a que la gestión de la calidad que propone ISO 9001:2008 que, aunque es un buen marco de partida, es excesivamente general y no alcanza para abordar proyectos de diseño e implantación de Sistemas de Gestión de la Calidad más especializados como es el caso de los proyectos de desarrollo de sistemas basados en software. Por ello, la ISO puede verse como una especialización de la ISO 9001:2008 para el desarrollo del software. 5

5 Enfoque basado en los procesos RED DE PROCESOS Entrada e GESTIÓN PROCESO E SOPORTE Salida E Entrada A GESTIÓN PROCESO A Salida A A C P D SOPORTE A C P D Entrada C GESTIÓN PROCESO C Salida C Entrada D GESTIÓN PROCESO D Salida D SOPORTE SOPORTE GESTIÓN A C P D A C P A Entrada B PROCESO B SOPORTE A C P D Salida B Cliente Interno Entrada F GESTIÓN PROCESO C SOPORTE Salida F Cliente Externo A P C D A C P D Retorno 6

6 Enfoque basado en los procesos Un enfoque de este tipo, cuando se utiliza dentro de un sistema de gestión de la calidad, enfatiza la importancia de: a) la comprensión y el cumplimiento de los requisitos b) la necesidad de considerar los procesos en términos que aporten valor c) la obtención de resultados del desempeño y eficacia del proceso, y d) la mejora continua de los procesos con base en mediciones objetivas 7

7 ISO Los sistemas de software se basan en la calidad y en la gestión por procesos El software es un tecnología por capas Ingeniería de Softw are Herramientas Métodos Modelo de proceso Foco en la calidad 8

8 Ejemplos para Organizaciones de Desarrollo de Software PROCESOS DE DIRECCION La Revisión por la Dirección Las Auditorias Internas La planificación y seguimiento de los objetivos de la calidad PROCESOS DE REALIZACION Construcción de software Diseño de una herramienta específica Atención de consultas de clientes Mantenimiento de adaptación de sistemas de software PROCESOS DE SOPORTE Gestión de configuración La capacitación del personal de desarrollo de sistemas La medición y evaluación de la satisfacción del cliente El archivo de historias de cambios a sistemas. 9

9 Ejemplos para Organizaciones con Áreas de Sistemas PROCESOS DE DIRECCION La Revisión por la Dirección Las Auditorias Internas La planificación y seguimiento de los objetivos de la calidad PROCESOS DE REALIZACION Planificación de desarrollo de sistemas El diseño de programas y bases de datos La planificación de las actividades de los proyectos El dictado de cursos de capacitación a usuarios PROCESOS DE SOPORTE La capacitación del personal de desarrollo El mantenimiento de sistemas y equipos El mantenimiento del software. Las compras de insumos La selección de proveedores de software y equipos 10

10 Ejemplos para la Administración Pública PROCESOS DE DIRECCION La Revisión por la Dirección Las Auditorias Internas La planificación y seguimiento de los objetivos de la calidad PROCESOS DE REALIZACION La concesión de espacios para su explotación La atención de consultas para la realización de un tramite La elaboración de pliegos de licitación La regulación de concesiones PROCESOS DE SOPORTE La atención de reclamos. La medición de la satisfacción del cliente. El mantenimiento del software. Las compras de insumos 11

11 Ejemplos para Empresas de Manufactura MEJORA CONTINUA REVISION POR LA DIRECCION GESTION DE CALIDAD FORJA II VENTAS PROGRAMACIO N ACERIA LAMINACION TRATAMIENTO TERMICO ACONDICIONA DO Y DESPACHO FORJA I COMPRAS MANTENIMIENTO LABORATORIO AUDITORIAS DE CALIDAD FORMACION PROCESOS DE DIRECCION PROCESOS DE REALIZACION PROCESOS DE SOPORTE 12

12 ISO 9000:2000 Directrices de Fundamentos y vocabulario 1. Ámbito. Esta norma internacional proporciona una guía a las organizaciones para la aplicación de la ISO 9001:2008 para la adquisición, suministro, desarrollo, instalación y mantenimiento de SOFTWARE y servicios de soporte. General: esta norma especifica recomendaciones cuando una organización necesita demostrar su capacidad de proveer productos que cumplan los requerimientos del cliente y ayuda a brindar satisfacción al cliente a través de una efectiva aplicación del sistema incluyendo procesos de mejora continua y el aseguramiento de la conformidad del cliente. Esta no cambia ni agrega a los requisitos de la ISO 9001:2008. No está destinada pero puede ser utilizada como criterio de evaluación en el registro ni certificación del sistema de calidad. 13

13 2 - Términos y definiciones Para el propósito de esta norma se utilizan los términos y definiciones establecidos en la norma ISO 9000:2000 Sistemas de Gestión de Calidad - Fundamentos y vocabulario Proveedor Organización Cliente Terminología de la cadena de suministros 14

14 ISO 9001:2008 Guía ISO Palabras clave Cliente Producto de software Servicio Soporte Requisitos Satisfacción del cliente Mejora continua Aseguramiento de la conformidad Calidad Gestión de la calidad 15

15 Proceso Actividad o serie de actividades que le agregan valor a una entrada antes de transformarla en salida. La forma natural de realizar actividades en el desarrollo de software El modelo en cascada es el modelo natural de desarrollo de software 16

16 Proceso en software Elementos: Proveedor Entrada de datos Cliente Requisitos Salida Actividades o tareas que agregan valor Requisitos Recursos: Materiales Herramientas CASE Know-how Personas Lenguajes Utilitarios Hardware PROVEEDOR Entrada Agregado de Valor / Controles Salida CLIENTE Recursos INDICADORES 17

17 Indicadores basados en métricas Métricas Internas Deben aplicarse a producto no ejecutable como especificaciones o código fuente durante el diseño y codificación. Métricas externas Usa medidas de un producto de software derivadas del comportamiento del sistema del cual es parte por testeo, operación y observación del software ejecutable o sistema. Relación entre métricas internas y externas Las métricas internas y externas están fuertemente relacionadas ya que predicen el posible comportamiento del software. Criterios de medición Las métricas son seleccionadas de acuerdo al punto de vista del evaluador Las métricas pueden ser usadas para comparar productos de software 18

18 Diferencia entre Procedimiento y Proceso Procedimiento Se orientan por operaciones y/o por la norma. Se documentan en instrucciones de procedimiento Contenidos: Objeto/ Campo de aplicación Responsabilidades Ejecutores Instalaciones Desarrollo (Eventos, Flujograma) Documentación Registros Proceso Se orientan por la generación de valor Se documentan en descripciones de procesos Contenidos: Descripción del desarrollo Dueño del proceso Cliente del proceso Proveedor del proceso Objetivos del proceso Indicadores Cuantitativos /cualitativos Marco de condiciones Acciones de mejora 19

19 4.1 Requisitos generales 4.1.a) Identificar los procesos necesarios para el sistema de gestión de la calidad y su aplicación a través de la organización. En el caso de los procesos referidos al software, se deben considerar procesos de: Planificación y Gestión de Proyectos, Requerimientos, Análisis y Diseño, Producción y Testeo del Software, Mantenimiento y Soporte de Aplicaciones. 20

20 4.1 Requisitos generales Esta guía está condicionada por dos elementos: a) Identificación de procesos y su aplicación. b) Secuencia de procesos y su interacción. La organización debería también definir la secuencia e interacción de los procesos en: a) Los modelos del ciclo de vida para el desarrollo de software, por ejemplo, cascada, incremental o evolutivo, y b) La planificación de la calidad y desarrollo, la cual debería estar basada sobre un modelo el ciclo de vida adoptado. 21

21 4.1 Requisitos generales a) Se muestran las actividades del RUP como ejemplo de workflows a mapear: 22

22 El proceso de la Ingeniería de Software según RUP 23

23 Utilizar el diagrama de actividades de UML para modelar los procesos 24

24 4. Sistema de Gestión de la Calidad Requerimientos generales Identificación de procesos y aplicación: debe identificarse los procesos de desarrollo, operación y mantenimiento. Secuencia de procesos e interacción La organización debería también definir la secuencia e interacción de los procesos en: a) Los modelos del ciclo de vida para el desarrollo software, por ejemplo, cascada, incremental y evolutivo, y b) planificación de la calidad y desarrollo, la cuál debería estar basada sobre un modelo el ciclo de vida. 25

25 Modelos de proceso de Software en cascada Communicat ion project init iat ion requirement gat hering Planning estimating scheduling tracking Modeling analysis design Const ruct ion code t est Deployment delivery support f eedback 26

26 Modelos de proceso de Software Incremental increment # n C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analy s is des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k increment # 2 delivery of nt h increment C o m m u n i c a t i o n P l a n n i n g M o d e l i n g increment # 1 analy s is des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k delivery of 2nd increment C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analy s is des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k delivery of 1st increment project calendar t ime 27

27 Modelos de proceso de Software RAD Team # n M o d e lin g business m odeling dat a m odeling process m odeling Communicat ion Team # 2 Mo d eling business m odeling dat a m odeling process m odeling Co n st ru ct io n com ponent reuse automatic code generation testing Planning Team # 1 Mode ling business modeling dat a modeling process modeling Co nst ruct io n com ponent reuse aut om at ic code generat ion t est ing De ployme nt int egrat ion delivery feedback Const ruct ion component reuse aut omat ic code generat ion t est ing days 28

28 Modelos de proceso de Software por Prototipos Communicat ion Qu ick p lan Mo d e lin g Qu ick d e sig n Deploym ent De live ry & Fe e dback Const ruct ion of prot ot ype 29

29 Modelos de proceso de Software Espiral communication planning estimation scheduling risk analysis start modeling analysis design deployment delivery feedback construction code test 30

30 Modelos de proceso de Software RUP (INICIO) Incept ion Elaborat ion Release soft ware increment t ransit ion const ruct ion product ion 31

31 Modelos de proceso de Software RUP Wor kflows UP Phases Incept ion Elaborat ion Const ruct ion Transit ion Product ion Requirements Analysis Design Planeamiento del proyeto incluyendo gestión de riesgos Implementation Test Support Iterations #1 #2 #n-1 #n 32

32 Modelos de proceso de Software EXtreme Programming XP Otros modelos usados: SCRUM user st ories values accept ance t est crit eria it erat ion plan simple design CRC cards spike solut ions prot ot ypes ref act oring pair programming Release sof t ware increment project velocity computed unit t est cont inuous int egrat ion accept ance t est ing 33

33 Tipos de documentación para procesos de software Se permite que los documentos para una efectiva planificación, operación y control de procesos de software [IRAM-ISO , 4.2.1, ítem d] cubran lo siguiente: 1) Descripciones de los procesos, tales como aquellos identificados al implementar 4.1; 2) Descripciones de instrucciones procedurales y/o plantillas utilizadas; 3) Descripciones de los modelos del ciclo de vida utilizados, tales como cascada, incremental y evolutivo; 4) Descripciones de herramientas, técnicas, tecnologías y métodos tales como aquellos identificados al implementar 4.1; 5) Tópicos /asuntos/temas/aspectos técnicos tales como estándares o documentos de guía para la codificación (programación), el diseño y desarrollo, y la prueba. 6) Legislación aplicable y bibliografía metodológica utilizada 34

34 Preparación para la realización de actividades Formación de equipos Selección de tipo de organización Consultora integral Área de sistemas de una empresa de turismo Área de desarrollo de una empresa constructora de quinchos Servicio externo de una empresa de fabricación de envases farmacéuticos Gobierno 35

35 Tipos de documentación Documentos que establecen requisitos Documentos que establecen recomendaciones o sugerencias Evidencia objetiva de actividades realizadas o resultados logrados Especificaciones Guías Registros En el caso del proceso de desarrollo de software los tipos de documentos serán los que surgen de utilizar alguna herramienta CASE y una metodología específica, por Ej. Rational XDE, UML y RUP como modelo de proceso de software Software de gestión de configuración como MANTIS Casos de uso DFD Requisitos manuales 36

36 Cantidad de documentación Esto depende de: Cada organización determina la amplitud de la documentación requerida y los medios a utilizar. Tamaño y tipo de la Organización Requisitos del cliente o reglamentarios Complejidad e interacción de los Productos y Procesos. Competencia del personal En el caso de la Guía ISO 90003, la documentación forma parte de los estándares que establezca la organización, que deberá incluir como mínimo: Documento visión del proyecto Documento de modelo de negocios Documento de planificación del proyecto Documento de Análisis y diseño del software Documento de Testeo y de implementación de la aplicación 37

37 Tener en cuenta! El análisis de los procesos debería ser la fuerza impulsora para definir la documentación necesaria para el SGC, teniendo en cuenta los requisitos de la ISO 9001:2008. La documentación no debería ser la que dirija los procesos Los procesos a documentar son los referidos a desarrollo, pruebas de componentes e integración, instalación y mantenimiento de sistemas. 38

38 Requisitos de documentación ISO 9001:2008 Guía Se permite que la evidencia de la conformidad con los requisitos incluya: a) Resultados documentados de las pruebas, b) Informes sobre problemas, incluyendo los problemas relacionados con las herramientas utilizadas, c) Solicitudes de cambios, d) Documentos marcados con comentarios, e) Auditorías e informes de evaluación, y f) Registros de la revisión e inspección, tales como aquellos de revisiones del diseño, inspecciones de código, y walk-throughs/ ensayos/ escenarios. 39

39 Artefactos principales de RUP y flujo de información entre ellos 40

40 Conjunto de artefactos de documentación en RUP Modelo de Negocios Requerimientos Análisis y Diseño Implementación Testeo de software Desarrollo Gestión de proyecto Gestión de configuración y manejo de cambios Ambiente 41

41 Requisitos de documentación ISO 9001:2008 Guía Documentación de requisitos (Control de Registros) Evidencias de operaciones efectivas: Ejemplos de evidencias de operaciones efectivas del Sistema de Gestión de Calidad pueden ser incluidos, pero no limitados a: Cambios (y sus razones) para recursos (personas, soporte lógico y equipamiento) Estimaciones, por ejemplo, tamaño y esfuerzo del proyecto (personas, costo, calendario), Como y porque las herramientas, metodologías y proveedores fueron seleccionados y cualificados, Acuerdos de licencias de software (tanto el software suministrado al cliente como el adquirido para el desarrollo), Minutas de búsqueda y, Soportes lógicos de publicación de registros. 42

42 Business Vision Business Architecture Business Use Case La visión del negocio define el conjunto de las metas y de los objetivos a los cuales está dirigido el esfuerzo de modelar el negocio El documento proporciona una descripción comprensiva del negocio, usando un número de diversas visiones arquitectónicas para representar diferentes aspectos del negocio. Un caso de uso del negocio es un conjunto de acciones (funcionalidad) del negocio que brinda un resultado observable de valor a un agente particular del negocio. 43

43 Formato de la documentación La documentación puede estar en forma de: Notas técnicas incorporadas en un plano Un manual de instrucciones de un equipo Fotos videos modelos - muestras, etc En particular para la ISO 90003, la documentación puede estar directamente soportada en una herramienta CASE como Rational RSA u otras como Enterprise Architect, que incluyen la posibilidad de generar documentación automática en HTML. También es posible construir o utilizar un portal de documentación que facilita el acceso a múltiples niveles de usuarios. 44

44 Configuration Management Plan El plan de gestión de la configuración (CM) describe todas las actividades de la gestión de la configuración y del control de cambios (CCM) que se realizará durante el curso del ciclo de vida del producto o del proyecto. Detalla el horario de actividades, las responsabilidades asignadas, y los recursos requeridos, incluyendo el personal, las herramientas, y las instalaciones informáticas. 45

45 Documentación requerida Registros Guía Retención y disposición Al determinar los periodos de la retención para los registros, se debieran considerar los requisitos reglamentarios y regulativos. Cuando los registros son almacenados en medios electrónicos, la consideración de los tiempos de la retención y la accesibilidad de los registros debiera tener en cuenta la tasa de degradación de los medios, la disponibilidad de los dispositivos, y el software necesario para tener acceso a los registros. Se permite que los registros incluyan información almacenada en sistemas de correo electrónico. Se debiera considerar la protección contra los virus de computadora y el acceso no permitido o ilegal. La naturaleza propietaria de la información almacenada en registros debiera ser evaluada, al determinar los métodos de eliminación/ borrado de los datos de los medios, al final de su período de retención requerido. 46

46 Documentos electrónicos Ventajas de la documentación en medio electrónico El personal adecuado tiene acceso todo el tiempo a la información actualizada Los cambios y el acceso se realizan fácilmente y de manera controlada Fácil y rápida distribución, con la posibilidad de obtener copias impresas Posibilidad de acceso a documentos desde ubicaciones remotas La supresión o cancelación de documentos es simple y eficaz Software de gestión documental: SHAREDPOINT (MS) SVN (Libre) 47

47 Ejemplo de workflow para modelo de negocio utilizando el diagrama de actividades de UML 48

48 Ejemplo de workflow para gestionar proyectos 49

49 5. Responsabilidad de la Dirección 5.4 Planificación Objetivos de la Calidad Compromiso de la Gerencia Foco en el cliente Política de calidad Planeamiento Objetivos de calidad (ISO/IEC atributos de los procesos) Planeamiento del sistema de gestión de calidad Planificación del sistema de gestión de calidad La planificación puede darse a nivel organizacional y a nivel de proyecto/producto. La planificación del sistema de gestión de la calidad a nivel organizacional debe incluir lo siguiente: a) definición apropiada de los modelos de ciclo vida software que van a ser usados por los tipos de proyectos que la organización emprende, incluyendo como la organización implementa normalmente los procesos del ciclo de vida software; 50

50 5. Responsabilidad de la Dirección 5.4 Planificación a) definición de los productos de trabajo del desarrollo software, tales como: documento de requisitos software, documentos del diseño arquitectónico, documentos del diseño detallado, código del programa, y el manual del usuario; c) definición del contenido de los planes de gestión del software, tales como: planes de gestión de proyectos software, planes de gestión de la configuración, planes de verificación y validación del software, planes de aseguramiento de la calidad y planes de formación; d) definición de como los métodos de ingeniería del software son adaptados a los procesos de la organización dentro del ciclo de vida (ver 1.2 Aplicación); e) identificación de herramientas y entornos para el desarrollo software, funcionamiento o mantenimiento; 51

51 e) especificación de convenios para el uso de lenguajes de programación, por ejemplo, reglas de codificación, librerías de software y marcos de trabajo f) identificación de cualquier reutilización de software (ver también 7.5.4). La dirección representativa de la organización debe considerar cualquier cambio en el modelo de ciclo de vida del software que pueda afectar al sistema de gestión de la calidad y debe asegurar que dichos cambios no comprometan alguno de los controles del sistema de gestión de la calidad. 5.5 Responsabilidad, autoridad y comunicación Representante de la gerencia: Para una organización productora de software, sería beneficioso que el representante de la dirección tuviese experiencia en el desarrollo de software. Comunicación interna: se debe establecer un adecuado proceso de comunicación del Sistema de gestión de calidad 52

52 6. Gestión de los Recursos 6.2 Recursos Humanos Competencia, toma de conciencia y formación La formación necesaria debe ser determinada considerando la notación de requisitos, métodos de diseño, lenguajes de programación específicos, herramientas, técnicas y recursos técnicos que van a ser usados en el desarrollo y gestión del producto/proyecto. La tecnología empleada en el desarrollo software, funcionamiento y mantenimiento debe ser continuamente supervisada y evaluada para poner al día la destreza del personal. 53

53 6. Gestión de los Recursos 6.2 Recursos Humanos La metodología de formación no tiene porque ser necesariamente los cursos de entrenamiento tradicionales, pudiendo ser talleres, autoformación, tutorías, formación en el trabajo o formación basada en Web. La evaluación de la eficacia de la formación puede realizarse usando medidas de los productos y procesos, identificando áreas de mejora en el rendimiento del personal (entre otras áreas de mejora). 54

54 6. Gestión de los Recursos 6.3 Infraestructura La infraestructura debe incluir hardware, software, herramientas y medios de desarrollo, funcionamiento o mantenimiento del software. La infraestructura puede incluir herramientas software que den soporte al diseño y desarrollo de procesos incluyendo: a) herramientas para el análisis, diseño y desarrollo, gestión de la configuración, pruebas, gestión del proyecto, documentación, creación o generación de código; b) aplicaciones del desarrollo y entornos de soporte; c) gestión del conocimiento, Intranet, herramientas extranet; d) herramientas de redes, incluyendo seguridad, copias de seguridad, protección de virus, cortafuegos; e) puntos de atención al cliente y herramientas de mantenimiento; f) control de accesos; g) librerías de software; 55

55 6. Gestión de los Recursos 6.3 Infraestructura h) herramientas para las operaciones de control tales como supervisión de redes, gestión de sistemas y gestión de almacenamiento Tanto si estas herramientas y técnicas se desarrollan internamente o son adquiridas, la organización debe evaluar si son o no adecuadas para su propósito. Las herramientas utilizadas en implementación del producto, tales como, herramientas de análisis, diseño y desarrollo, compiladores y ensambladores deben ser evaluadas, aprobadas y colocadas bajo una adecuado nivel de control de gestión de configuración antes de su uso. El ámbito de uso de tales herramientas y técnicas puede ser documentado con una guía apropiada, y su uso revisado, adecuadamente, para determinar si hay una necesidad de mejorar y/o actualizar. 56

56 7. Realización de Producto Planificación de la realización del producto Ciclo de vida del software Planeamiento de la calidad Ciclo de vida del Software Los procesos, actividades y tareas se han de planificar y desarrollar mediante modelos de ciclo de vida adecuados al proyecto software (tamaño, complejidad, seguridad, riesgos e integridad). La ISO 9001:2008 es adecuada para aplicarse sin considerar el ciclo de vida. El diseño y desarrollo pueden ser evolutivos => cambios/actualizaciones en procedimientos En productos críticos (posibles daños a personas, perdidas económicas importantes, etc) se deberá prestar una especial atención al diseño y desarrollo garantizando la inmunidad en condiciones potenciales de fallo. La planificación de la gestión del desarrollo software debería ser el resultado de la definición de que productos pueden se producidos, quién los produce y cuando son producidos (ver 7.3.1). La planificación de la calidad del software para el nivel de producto / proyecto debería ser el resultado de la descripción de que productos pueden ser desarrollados, evaluados o mantenidos. 57

57 Procesos del RUP 58

58 Scrum

59 Un Rol en RUP es una definición abstracta de un conjunto de Actividades realizadas y los artefactos manejados. Conjunto de Roles en RUP: Analistas, Desarrolladores, Testers, Managers Otros Roles 60

60 Monitoreo y control de proyecto 61

61 7.1.2 Planificación de la calidad La planificación de la calidad facilita el modo para adaptar la planificación del sistema de gestión de la calidad para un proyecto específico, producto o contrato. La planificación de la calidad debería ser de nuevo revisada junto con el progreso del diseño y desarrollo, y los elementos concernientes a cada fase deberían estar completamente definidos al comienzo de dicha fase. NOTA: Un documento que describe la planificación de la calidad puede ser un documento independiente (titulado plan de calidad), una parte de otros documentos o estar compuesto de varios documentos, incluyendo un plan de diseño y desarrollo. La planificación de la calidad del software a nivel de proyectos debería dirigirse a: a) La inclusión o referencia a, los planes de desarrollo (ver 7.3.1); b) los requisitos de calidad relativos a los productos y/o procesos; 62

62 c) los sistemas de gestión de la calidad adaptando y/o identificando los procesos e instrucciones específicos, apropiados para el ámbito del manual de calidad y algunas exclusiones expuestas (ISO 9001:2008, 1.2); d) los procedimientos e instrucciones específicos del proyecto, tales como, especificación de pruebas del software detallando los planes, diseños, casos de pruebas y procesos para la unidad, integración, sistemas y pruebas de aceptación (ver 8.2.4); e) los métodos, modelo(s) del ciclo de vida, herramientas, convenios de lenguajes de programación, bibliotecas, marcos de trabajo y otros componentes reutilizables para ser usados en los proyectos; f) los criterios para el comienzo y el final de cada fase o etapa del proyecto; g) los tipos de análisis y otras verificaciones y actividades de validación para ser llevadas a cabo (ver 7.3.4, y 7.3.6); h) los procesos de gestión de la configuración para ser llevados a cabo (ver 7.5.3); 63

63 i) las actividades de seguimiento y las medidas para ser llevadas a cabo; j) las persona(s) responsables de aprobar las salidas de los procesos para su uso posterior; k) la formación necesaria para el uso de herramientas y técnicas, y la organización de la formación previa a la habilidad necesaria; l) los registros para ser mantenidos (ver 4.2.4); m) la gestión de cambios, como por ejemplo, para recursos, escalas de tiempo y cambios de contrato. Una planificación de la calidad abreviada es útil aplicada a software diseñado para un propósito limitado. Ejemplos de software de propósito limitado: Prototipos de demostración de prueba-de-concepto. Una solución interna carente de algunas características (seguridad,funcionamiento operacional completo, etc.) El software de propósitos-limitados ha de probarse de forma consistente con su uso para reducir en lo posible omisiones y errores. 64

64 Procesos relacionados con el cliente Determinación de requerimientos relacionados con el producto, incluyendo actividades de lanzamiento y post lanzamiento Requerimientos relacionados con el cliente. Las acciones a realizar deben incluir métodos para acordar, autorizar y modificar requerimientos, métodos para evaluar prototipos o demostraciones y métodos para registrar y revisar resultados de revisiones. Se debe incluir la aprobación de requerimientos por el cliente y métodos para la trazabilidad de los requerimientos en el producto final. Requerimientos adicionales determinados por la organización 65

65 Revisión de requerimientos relacionados con el producto Intereses de la organización: Algunas cuestiones que puedan ser relevantes durante el análisis de la organización de las ofertas de software, contratos u oórdenes incluyen : a) la validación de los requisitos y las características del producto, incluyendo la identificación de las características requeridas del software (p.e. funcionalidad, usabilidad, mantenibilidad, portabilidad y eficiencia); b) el diseño del software y el desarrollo de los estándares y procedimientos para ser usados; c) la identificación de los servicios, herramientas, elementos de software y datos, serán suministrados por el cliente, la definición y documentación de los métodos para evaluar su ideoneidad para el uso; 66

66 d) El sistema operativo o plataforma de hardware; e) la concordancia entre el control de las interfaces externas con el producto software; f) los requisitos de reproducción y distribución g) los asuntos relacionados con el cliente; 1. los procesos del ciclo de vida impuestos por el cliente; 2. el periodo de obligación de la organización para suministrar copias y la capacidad de lectura de las copias originales; 67

67 h) los asuntos de gestión: 1. la gestión del riesgo será dirigida (ver también ); 2. la responsabilidad de la organización con respecto al trabajo subcontratado; 3. la planificación del progreso, los revisiones técnicas y salidas; 4. la instalación, mantenimiento y requisitos de apoyo; 5. la disponibilidad oportuna de los recursos técnicos, humanos y financieros; 68

68 i) los asuntos legales, de seguridad y confidencialidad : 1. la información manejada según el contrato pueda estar sujeta a asuntos relacionados con los derechos de la propiedad intelectual, contratos de licencias, requisitos estatutarios y reglamentarios, y la protección de la información incluyendo las patentes y los copyright; 2. la salvaguarda de la copia original del producto y los derechos del cliente a acceder o verificar ese original; 3. el nivel de revelación de la información al cliente, necesita ser mutuamente acordada por las partes; 4. la definición de los términos de garantía; 5. las obligaciones asociadas con el contrato. 69