GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES

Transcripción

1 GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES

2 Tabla de contenido INTRODUCCIÓN AL MODELO... 4 OBJETO DE ESTA GUÍA Proceso de GESTIÓN DEL MODELO DE CICLO DE VIDA Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la PYME Proceso de SUMINISTRO Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la implantación del proceso en la PYME Proceso de DEFINICIÓN DE REQUISITOS DE LAS PARTES INTERESADAS Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la implantación del proceso en la PYME Proceso de ANÁLISIS DE LOS REQUISITOS DEL SISTEMA Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la implantación del proceso en la PYME Proceso de PLANIFICACIÓN DEL PROYECTO Objetivo Resultados esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME: Observaciones prácticas para la PYME Proceso de EVALUACIÓN Y CONTROL DE PROYECTOS Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME

3 6.4. Observaciones prácticas para la PYME Proceso de GESTIÓN DE LA CONFIGURACIÓN Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la PYME Proceso de GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones prácticas para la PYME Proceso de MEDICIÓN Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones Prácticas para la PYME Proceso de ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE Objetivo Resultados Esperados de una implantación exitosa del proceso Propuesta de aplicación en la PYME Observaciones Prácticas para la PYME ANEXOS ANEXO 1. AUTOMATIZACIÓN DE LOS PROCESOS ANEXO 2. ESTRUCTURA DOCUMENTAL ANEXO 3. BIBLIOGRAFÍA

4 INTRODUCCIÓN AL MODELO El Modelo de Mejora y Evaluación de la Calidad del Ciclo de Vida del Software elaborado por AENOR acorde a la ISO 15504, tiene como objetivo principal proporcionar a las pequeñas y medianas factorías de software un marco de referencia para la mejora de los procesos de calidad internos relacionados con el desarrollo de software, para su posterior certificación según el referencial conocido como SPICE, en su nivel 2. Los procesos han sido seleccionados de la norma internacional ISO/IEC 12207:2008 Ingeniería de Sistemas y Software. Procesos del ciclo de vida del software y están definidos por y para las empresas o departamentos que desarrollan software. Si por una parte tenemos el marco de los procesos por el otro debemos contar con una norma, también de rango internacional, que establezca los criterios de evaluación de la madurez de las compañías. La norma ISO/IEC SPICE, en su parte número 7 y publicada en noviembre de 2008, permite evaluar por niveles de madurez las organizaciones, a partir de la capacidad de los procesos evaluados (gestión de la configuración, análisis de los requisitos, etc.) y así obtener el certificado de AENOR. En el siguiente gráfico se muestran los procesos de la norma ISO/IEC 12207:2008 que componen el modelo de procesos de AENOR y que serán evaluados según los criterios definidos en la norma ISO/IEC SPICE. 4

5 Gráfico 1: Procesos de la norma ISO/IEC 12207:2008, correspondientes al nivel 2, y que serán evaluados según los criterios definidos en la norma ISO/IEC SPICE. Las normas de referencia mencionadas anteriormente permitirán a las factorías de software mejorar sus procesos internos de desarrollo con independencia del tipo de tecnología existente, el entorno de programación utilizado o la organización jerárquica definida. Llegados a este punto es fundamental establecer una definición única de lo que es un proceso. Un proceso es un conjunto de actividades repetitivas y sistemáticas mediante las cuales se convierten las entradas en salidas, que serán los productos o servicios que reciba el cliente, ya sea este interno o externo. En la práctica, si se pide a un grupo de empleados o técnicos que describan gráficamente las actividades de su empresa, la mayoría de ellos, ya pertenezcan a grandes organizaciones multinacionales o a pequeñas empresas, dibujarían algo similar a un organigrama, con más o menos casillas y niveles, pero tratando siempre de 5

6 mostrar las relaciones jerárquicas entre las diferentes unidades organizativas (zonas, áreas, departamentos, divisiones) de la empresa. Esta representación no permite identificar y mejorar los procesos, ya que no muestra a los clientes ni los productos o servicios que se le ofrecen, ni los flujos de trabajo mediante los que se obtienen dichos productos o servicios o los elementos de control aplicados. 6

7 OBJETO DE ESTA GUÍA En la práctica diaria de las organizaciones no siempre están claramente identificados los procesos de desarrollo del software puesto que, a menudo, se identifican más con las personas o departamentos que con el flujo de las propias actividades. Esta dificultad inicial para identificar los procesos de una organización, provoca conflictos de competencias que inciden poderosamente en la gestión de procesos, poniendo en riesgo el alcanzar los resultados esperados. La solución pasa por identificar los procesos de forma transversal a la organización, trazando la secuencia de las actividades correspondientes sin detenerse en los departamentos o áreas. Solo después se asignarán los responsables de realizar cada una de las actividades. Para ayudar a las organizaciones, esta Guía analizará cada uno de los procesos que componen el modelo, indicando aquellos aspectos que son requeridos por la normativa y aportando la experiencia real adquirida en numerosas PYMES que superaron con éxito la certificación de nivel 2. La Guía tiene un enfoque a procesos por lo que para cada uno de ellos se definirán solo aquellos parámetros que sirvan para su identificación, conteniendo la suficiente información para posibilitar su gestión: Nombre: Identificación del proceso. Objetivo: Propósito o finalidad del proceso. Responsable: Persona encargada de definir y mejorar el contenido del proceso. Actividades: Secuencia, interrelaciones y responsables de las tareas que componen el proceso. Entradas: Los elementos necesarios para poder iniciar el proceso. Salidas: Los resultados del proceso (producto obtenido y registros generados) Recursos: Elementos físicos, humanos o tecnológicos necesarios para poder ejecutar correctamente el proceso. Indicadores u otro mecanismo de control del proceso. 7

8 Gráfico 2: Descripción de los componentes de un proceso. A continuación se definen cada uno de los diez procesos que forman el nivel 2 del Modelo de Calidad de Desarrollo de Software y que se encuentran definidos en la norma de referencia ISO/IEC 12207:2008. Antes de iniciar cualquier definición y análisis de los procesos de desarrollo de software es fundamental recordar que: 1) la norma ISO/IEC 12207:2008 no establece una relación de las actividades o tareas que obligatoriamente hay que realizar, sino que se limita a definir qué se debe conseguir con el proceso correctamente implantado, es lo que se conoce como resultados del proceso o outcomes. Por ejemplo, en el proceso de Suministro, entre otros aspectos, se establece la obligatoriedad de identificar al comprador (cliente) pero deja a criterio de cada empresa cómo hacerlo. Algunas compañías optarán por llevar esta identificación con un fichero individual, otras usarán un ERP y otras aplicaciones de software libre para la gestión comercial. Estas opciones, y cualquier otra, son válidas siempre y cuando permitan la identificación del comprador. 8

9 2) para superar con éxito la auditoría de certificación de nivel 2 según el modelo de evaluación de AENOR, la norma con la que se realiza la evaluación. ISO/IEC 15504, conocida como SPICE requiere que cualquier organización pueda dar evidencia de la implantación efectiva de los procesos, esto es: a. Los procesos se lleven a cabo y se consigan todos sus objetivos determinados. b. Existencia de un compromiso efectivo de la Dirección en el desarrollo, implantación de los procesos, asegurando la asignación adecuada de recursos y velando por la consecución de los objetivos de los procesos. c. Esté definida la gestión de cómo se llevan a cabo los procesos, es decir, que esté documentado el funcionamiento de cada uno de los procesos del modelo en la PYME, sus actividades y tareas, responsables, registros generados d. Se evidencia la existencia de mecanismos sólidos y continuados de medición y seguimiento de los procesos y sus resultados, permitiendo evaluar el cumplimiento con los objetivos determinados. e. El personal de la organización que participa en el diseño o ejecución de los procesos es consciente de la pertinencia e importancia de sus actividades y cómo contribuyen al logro de los objetivos de los procesos. f. Existe una sistemática para la detección, registro y eliminación de las desviaciones en el desempeño de los procesos, previniendo que vuelvan a ocurrir. g. Los elementos de trabajo (plantillas, formatos, documentos, formularios ) están definidos, controlados, versionados y actualizados en caso de ser necesario. La PYME deberá analizar y entender los objetivos y resultados esperados que se detallan en cada uno de los diez procesos del modelo. Posteriormente comparará sus procesos actuales con la normativa, evaluando el grado de cumplimiento existente y definiendo las acciones de mejora necesarias para alcanzar el pleno cumplimiento de 9

10 los procesos en su organización. En la presente guía se propondrá un conjunto de actividades, entradas, salidas y recursos que servirán como punto de partida a una PYME cualquiera para construir cada uno de los diez procesos. Estos deberán aplicarse a los proyectos de desarrollo existentes en la PYME. Lógicamente se trata de una propuesta de mínimos que deberá ser enriquecida y ajustada en función de la realidad de cada PYME. En cualquier caso, todas las propuestas, sugerencias e indicaciones que contiene este documento están basadas en la experiencia real en la implantación en PYMEs españolas de los procesos de desarrollo de software. Es fundamental remarcar que el modelo establece la necesidad de contar con evidencias documentales de todos los procesos ligados a la empresa. Es fundamental entender que cuando se habla de documentar una evidencia las opciones son muchas y variadas y no solo el documento en papel. La organización puede dar evidencia por un conjunto de documentos tales como: manuales de usuario y registros de las aplicaciones informáticas usadas para el desempeño de los procesos, actas de reunión, correos electrónicos, informes, fichas de trabajo, etc. y todos ellos en diferentes soportes: papel, digital, imagen, software o una combinación de éstos. Lo habitual es contar con un documento principal en el que se presenten las actividades de cada proceso y referenciar a aquellos otros documentos, aplicaciones o herramientas que amplían y detallan las tareas concretas. Aunque inicialmente puede ser una carga de trabajo adicional para los responsables de la mejora de los procesos internos, el beneficio a corto plazo es evidente, dado que al establecer procedimientos documentados, estos deberán ser aprobados y verificados por todos los miembros implicados en cada proceso (la redacción de la documentación como tarea colectiva y colaborativa puede ser una labor interesante para depurar y mejorar los procesos). El primer paso para mejorar los procesos pasa, inevitablemente, por su formalización. 10

11 También es interesante tener en cuenta el hecho de que la documentación de los procesos y actividades es un pilar fundamental para la formación interna. Al tener acceso a la documentación, el personal de la empresa toma conciencia de los procesos que deben aplicarse en la producción del software, sirviendo también para que los implicados en otros procesos conozcan actividades que no tienen una relación directa con su trabajo diario, contribuyendo al despliegue del conocimiento a toda la empresa. Otro punto importante es que sirve de base para la capacitación de las nuevas incorporaciones a la plantilla, así como servir de referente y preceptor cuando hay desviaciones entre la práctica diaria y los procesos documentados. El conocimiento deja de residir en la experiencia de unas pocas personas a formar parte de toda la organización. 11

12 1. Proceso de GESTIÓN DEL MODELO DE CICLO DE VIDA Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Realización de Proyectos Organizacionales Objetivo El propósito de este proceso es definir, mantener y asegurar la disponibilidad de políticas, procesos y modelos del ciclo de vida para que sean usados por la organización Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Existen políticas y procedimientos para la gestión y el despliegue de los modelos de ciclo de vida y los procesos. RP2) Se definen las responsabilidades, compromisos y la autoridad necesarios para la gestión del ciclo de vida. RP3) Se definen, mantienen y mejoran los procesos de ciclo de vida, modelos y procedimientos para el uso por la organización. RP4) Se priorizan las mejoras en los procesos. 12

13 Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización. 1.3 Propuesta de aplicación en la PYME Este proceso es el más genérico de todos los que componen el modelo y no puede igualarse al resto, puesto que es el marco común en el que documenta la secuencia de tareas que deberán realizarse desde el inicio al cierre de los proyectos, los diferentes participantes, responsables, documentación aplicable, y los entregables que serán generados. Este proceso es de aplicación a todas las personas que de una u otra forma participen en alguna de las fases de un proyecto software en aspectos tales como producción de software o gestión del proyecto y tendrá como finalidad determinar, dar a conocer y aplicar la metodología adoptada para dicho proyecto. Este ciclo de vida no podrá responder a todas las casuísticas y tipología de proyectos que normalmente se realizan. Es por eso por lo que el ciclo de vida deberá ajustarse en función de las necesidades, indicando las exclusiones en el ciclo de vida general. No es lo mismo el ciclo de vida asociado a un proyecto que requiere dos meses de trabajo que otro que necesita 10 o más meses. Aunque en ambos proyectos exista una fase de codificación y pruebas, el número y detalle de la documentación generada, los diferentes perfiles intervinientes y herramientas utilizadas puede que no sean los mismos. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer una relación ordenada de las fases que son necesarias para producir el software: 13

14 Nombramiento de un responsable o responsables de documentar, mantener y mejorar el ciclo de vida de desarrollo del software en la PYME. Se requiere que la persona asignada tenga una visión global y de conjunto del funcionamiento productivo de la compañía. El responsable asignado procederá a la definición, coordinación y seguimiento de las diferentes etapas y recursos necesarios para el desarrollo del software en el contexto de los requisitos y limitaciones de cada tipología de proyecto. Como resultado de la puesta en práctica del modelo de ciclo de vida, las mejoras identificadas serán priorizadas en función del coste, facilidad de implantación, recursos necesarios, etc. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección/Operaciones: responsable de documentar, mantener y mejorar el ciclo de vida de desarrollo de la compañía Resto de la organización: aplicar las actividades definidas en el documento y notificar posibles mejoras al mismo. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Tipología de proyectos SALIDAS Documento de Ciclo de Vida Organigrama funcional Con relación a los recursos, las organizaciones debería contar, al menos, con los siguientes: 14

15 Plantilla de documento de ciclo de vida. Aplicación de gestión documental o estructura de directorios en la red. Un indicador asociado a este proceso, y sencillo de aplicar, es el número de desviaciones o incumplimientos del ciclo de vida comparado con el número de total de proyectos a los que aplica. 1.4 Observaciones prácticas para la PYME - Este proceso tiene una baja dificultad de implantación. - El proceso documentado de ciclo de vida permite indicar el resto de documentos o procesos que aplican en cada una de las etapas definidas. - La finalidad del Ciclo de Vida del Software es recoger formalmente la secuencia de las actividades o fases que deben de realizarse en un proyecto genérico de la compañía. En cada proyecto se realizará una adecuación del mismo de acuerdo a los requisitos y complejidad del proyecto. Esto es fundamental hacerlo para reducir el riesgo de elaborar un documento demasiado general o tan detallado que pocos proyectos puedan cumplirlo. A modo de ejemplo se muestra un ciclo de vida genérico. - Tanto las Actividades Principales como los Entregables deberán ajustarse a la realidad de la PYME a la tipología de proyectos que apliquen. Por ejemplo, en la etapa 5. Codificación, no todos los proyectos requerirán la realización de pruebas unitarias, de integración y de sistema, pero lo que sí es evidente que se ejecutarán un conjunto de pruebas al código generado. 15

16 Gráfico 3: Ejemplo del Ciclo de Vida de Desarrollo del Software para un proyecto genérico. 16

17 2. Proceso de SUMINISTRO Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Acuerdo Objetivo El propósito de este proceso es proporcionar al cliente un producto o servicio que cumpla con los requisitos acordados. Nota: Se requiere establecer un mecanismo para responder a las peticiones y exigencias de los clientes de la organización, preparar y emitir propuestas, y confirmar la entrega e instalación satisfactorias a través del establecimiento de un contrato/acuerdo relevante Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se identifica el comprador de un producto o servicio. RP2) Se genera una respuesta a la solicitud del comprador. RP3) Se establece un acuerdo entre el comprador y el proveedor para el desarrollo, mantenimiento, operación, embalaje, la entrega e instalación del producto y/o servicio. RP4) Se desarrolla por parte del proveedor un producto y/o servicio que satisfaga los requisitos acordados. 17

18 RP5) El producto y/o servicio es entregado al comprador, de conformidad con los requisitos acordados. RP6) El producto está instalado de conformidad con los requisitos acordados. Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización Propuesta de aplicación en la PYME Desde el punto de vista del ciclo de vida de desarrollo del software, este proceso se centra en los vínculos con el cliente durante el proceso de definición y aprobación de la oferta y al final del ciclo, con la aceptación y aprobación de la entrega del software por parte del cliente. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma una PYME debería hacer una relación ordenada de las principales actividades asociadas y que habitualmente se resumen en: Atender la solicitud del cliente, identificando los diversos canales y mecanismos que los clientes pueden utilizar. Registrar la oportunidad de negocio en el soporte existente (ficheros, aplicaciones informáticas de gestión comercial, ERPs, etc ) asegurando que permite mantener una identificación único, completa y suficiente de los clientes. Elaboración de la oferta sobre la base de plantillas corporativas. Elaborar la documentación asociada a la oferta en el caso de que fuese necesaria, como por ejemplo, prototipos, pantallazos, contratos 18

19 Presentar y negociar con el cliente la oferta según el canal establecido (correo electrónico, correo ordinario o presencial. Cerrar la oportunidad de negocio, quedando a la espera de la aceptación o rechazo de la oferta por parte del cliente. Registrar modificaciones a la oferta inicial, creando nuevas versiones de la propuesta. Una vez que la producción del software ha finalizado y se han pasado las pruebas oportunas, el equipo de proyecto genera el paquete de entrega para el cliente identificándolo con un código único. Un posible método es asociando el código de proyecto, la fecha de generación del paquete y la versión (x.y.z) del producto a entregar. El equipo de proyecto deposita el paquete de entrega dentro de la carpeta de distribución de paquetes del proyecto. El jefe de proyecto genera el documento de entrega al cliente en el que relaciona todos los elementos que serán proporcionados. Este listado deberá ser coherente con los compromisos adquiridos en la última versión de la oferta aprobada por el cliente. tanto la firma del cliente como la del jefe de proyecto que procede a la entrega. Por último, el jefe de proyecto procede a la entrega formal del producto al cliente y la obtención de la conformidad. Esta entrega formal se suele hacer de forma presencial (en la cual se hace entrega del paquete elaborado y se firma el documento de registro de entrega) o de forma telemática, solicitándose posteriormente un correo electrónico al interlocutor del proyecto del cliente confirmando la aceptación de la entrega. 19

20 Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Desarrollo de negocio/área Comercial: responsable del logro de oportunidades comerciales. Operaciones: responsable de la elaboración de la propuesta y validación del contenido técnico de la misma, así como de recabar la aceptación de la entrega por el cliente. Dirección/Financiero: responsable de validar la forma y el periodo de pago de la propuesta antes y después de la negociación. En todo momento se tratan perfiles dentro de la empresa, no puestos de trabajo concretos, por lo que cuando la PYME no cuenta con una estructura de personal suficiente normalmente se fusionan en un solo perfil las responsabilidades anteriores. Por ejemplo para empresas muy pequeñas es habitual que la Dirección asuma la labor financiera y comercial. Por el contrario, si la PYME cuenta con más personal seguramente las responsabilidades se desplegarán a diferentes personas. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: Solicitud de oferta ENTRADAS Peticiones de modificación SALIDAS Registro de la solicitud de oferta Documentos de oferta almacenados Si procede, documentos de acuerdos de confidencialidad almacenados en repositorio del proyecto Registro de solicitudes de revisión de la 20

21 propuesta inicial mediante actas de reunión y/o correos electrónicos. Registro de las revisiones de la oferta mediante la creación de diferentes versiones del documento inicial. Registro de la aceptación de la oferta/propuesta mediante la firma del documento de oferta o correo electrónico indicando el código de oferta. Paquete de entrega al cliente (software, aplicaciones de instalación, documentación, manual de usuario, manual de administrador, manual de configuración ) Registro de entrega y aceptación Con relación a los recursos, es recomendable que las organizaciones cuenten con los siguientes: Plantilla de acta de reunión con cliente. Plantillas de hojas de cálculo con los sumarios ejecutivos que contemplan el análisis de los márgenes de beneficio y las valoraciones técnicas. Plantilla de documento de oferta. Plantilla de recepción y aceptación del producto. Aplicación o ficheros para la gestión comercial. En función de las necesidades la empresa puede fusionar las anteriores plantillas en una sola o, simplemente, no necesitarla. Los indicadores asociados a este proceso podrían ser 1) la tasa de peticiones de cambio de las ofertas, que permitiría identificar carencias en la descripción de los 21

22 servicios y detección de las necesidades de los clientes y 2) el número de entregas no aprobadas por el cliente respecto al número de entregas emitidas, con el fin de evaluar el grado de fiabilidad del desarrollo del software Observaciones prácticas para la implantación del proceso en la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene una baja dificultad de implantación. - Se debe documentar cómo realiza la empresa la gestión de las ofertas, la gestión de los contratos y la aceptación de la entrega por parte del cliente. - Este proceso tiene una baja dificultad de implantación, dado que las PYMEs en su gran mayoría disponen de una gestión del suministro más o menos evolucionada, contemplando al menos, la existencia de una oferta documentada, en el que se relacionan los elementos a desarrollar y los entregables mínimos esperados por parte del cliente. - Suelen presentarse dificultadas a la hora de documentar cuándo y cómo se generan las evidencias relativas a las peticiones de los clientes y más concretamente las relacionadas con cambios sobre los proyectos ya comenzados. - La entrega del software (con su correspondiente registro de entrega) no implica la aceptación formal por parte del cliente. Solo cuando el producto entregado sea el correcto y cumpla con los requisitos establecidos, se podrá requerir el registro formal de aceptación. En función del cliente y del proyecto que se 22

23 trate, en ocasiones el mismo registro de la entrega es, además, el registro de aceptación. - Para poder definir el proceso de suministro adecuadamente la PYME deberá recopilar las siguientes evidencias objetivas: solicitudes del cliente de nuevos proyectos y de cambios en los proyectos existentes, entregas de las ofertas, entregas del software, aceptación de fin de proyecto, etc. Estas evidencias suelen encontrarse en correos electrónicos, actas, documentos o contratos. - Como se verá en procesos siguientes, se deberá establecer un método formalizado de estimación del esfuerzo necesario para la realización del proyecto y que, aplicando variables económicas, establecerá el precio de los servicios incluidos en la oferta. 23

24 3. Proceso de DEFINICIÓN DE REQUISITOS DE LAS PARTES INTERESADAS Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos Técnicos Objetivo El propósito de este proceso es definir los requisitos necesarios para que el sistema pueda proporcionar los servicios necesarios a las partes interesadas (usuarios y otros afectados) en un entorno definido Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se especifican las características requeridas y el contexto de uso de los servicios. RP2) Se definen las restricciones del sistema. RP3) Existe trazabilidad de los requisitos, entre las partes interesadas y sus necesidades. RP4) Se describen las bases para la definición de los requerimientos del sistema. RP5) Se define la base para validar de la conformidad de los servicios. RP6) Existe una base para la negociación y el acuerdo de entrega de los productos o servicios. 24

25 3.3. Propuesta de aplicación en la PYME Desde el punto de vista del ciclo de vida de desarrollo del software, este proceso permitirá identificar, agrupar, procesar y monitorizar las necesidades de los usuarios y clientes a lo largo del ciclo de vida del software, permitiendo establecer las líneas base iniciales y sucesivas de los productos resultantes. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma una PYME debería hacer una relación ordenada de las principales actividades asociadas y que habitualmente se resumen en: Creación de un documento base que recoja el detalle de todos los requisitos funcionales y no funcionales (seguridad, capacidad, escalabilidad, etc.) que deberá incorporar el software. Este documento suele llamarse Catálogo de Requisitos. Normalmente se realiza la primera versión del Catálogo cuando se ha aprobado la oferta por parte del cliente y constituirá la línea base de requisitos sobre la que se irán incorporando las modificaciones que surjan a lo largo del proyecto. En el Catálogo se registrarán todos los requisitos contenidos en la oferta aprobada más aquellos otros que, aun no siendo solicitados expresamente por el cliente, son fundamentales para poder cumplir con sus expectativas. El Catálogo de Requisitos debe identificar cada requisito de manera independiente y única, de forma que pueda seguirse su traza, inequívocamente, a lo largo del proyecto y, además, se vincule a la prueba(s) correspondiente que permita su validación. Incorporación de requisitos partiendo de la versión inicial del catálogo. La incorporación de requisitos podrá ser de dos tipo: completando el listado, por medio de reuniones (presenciales o a distancia) con el cliente o por medio de peticiones de cambio. En ambos casos, la incorporación de los nuevos requisitos deberá estar documentada y aprobada tanto por la PYME como por el cliente. 25

26 Aceptación del Catálogo de requisitos. Es condición básica contar con la aprobación del documento por parte del cliente dado que en él se recogen los compromisos y expectativas del software que será desarrollado. Lo que no está incluido en el Catálogo de requisitos vigente no será desarrollado por la empresa ni será esperado por el cliente. Esta aceptación deberá estar documentada (correo electrónico, acta de reunión o similar) Elaboración del plan de pruebas. El Jefe de Proyecto y el responsable de Calidad elaborarán los casos de prueba que deberán aplicarse al software antes de su entrega al cliente. En este plan de pruebas se podrán validar requisitos individuales o agrupaciones de requisitos gracias a la trazabilidad entre este documento y el catálogo de requisitos. En algunos casos los clientes pueden solicitar la aprobación del plan de pruebas que utilizará la PYME. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Desarrollo de negocio/área Comercial: responsable del cierre del catálogo de requisitos con el cliente. Operaciones: responsable de definir con detalle el catálogo de todos los requisitos (funcionales y no funcionales) así como participar en el diseño del plan de pruebas. Calidad: responsable de elaborar el plan de pruebas. En todo momento se tratan perfiles dentro de la empresa, no puestos de trabajo concretos, por lo que cuando la PYME no cuenta con una estructura de personal suficiente normalmente se fusionan en un solo perfil las responsabilidades anteriores. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: 26

27 ENTRADAS Oferta aprobada Listado de requisitos funcionales y no funcionales SALIDAS Documento de Catálogo de requisitos Actas/correos electrónicos de las reuniones de toma de requisitos con el cliente Peticiones de modificación de requisitos Registro de la aceptación del catálogo de requisitos por parte del cliente (en ocasiones será la propia oferta aprobada) Documento de Plan de Pruebas Con relación a los recursos, las organizaciones debería contar, al menos, con los siguientes: Plantilla de acta de reunión con cliente. Plantilla de documento de catálogo de requisitos. Plantilla de documento de plan de pruebas. Es posible fusionar en una sola plantilla las correspondientes a catálogo de requisitos y plan de pruebas. En el caso de utilizar una aplicación informática para la gestión de los requisitos o plan de pruebas, no es necesario utilizar plantillas independientes. Un indicador asociado a este proceso podrían ser la tasa de peticiones de cambio de los requisitos respecto a la versión aprobada del Catálogo de requisitos, que permitiría identificar deficiencias en la identificación y definición de requisitos por parte del equipo de proyecto de desarrollo de software. 27

28 2.4. Observaciones prácticas para la implantación del proceso en la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene una dificultad media de implantación. - Es práctica habitual en las PYMEs que el contenido de la oferta se utilice como un Catálogo de servicios. Eso no es correcto a menos que el nivel de detalle sea suficiente para el equipo de desarrollo, incluya tanto requisitos funcionales como no funcionales y además, incorpore un mecanismo de identificación único para cada requisito facilitando su trazabilidad a lo largo de todo el proyecto. - Se recomienda elaborar un Catálogo de requisitos único, formalizando las actividades necesarias para su redacción y aprobación por las partes interesadas con el objeto de que sirva como 1) un documento independiente, cuya línea base son los requisitos presentados en la oferta y 2) Base para las pruebas validación a la finalización del proyecto - Una vez que se asume la importancia de formalizar la gestión de los requisitos, las empresas son conscientes de los beneficios de mantener, a lo largo de la vida del proyecto, el catálogo de requisitos de forma independiente a la oferta y generando diferentes versiones a medida que el cliente modifica los requisitos. - En este proceso las empresas deben establecer la diferencia entre requisitos funcionales y no funcionales. Por requisitos funcionales se entiende a aquellos que especifican los criterios que se deben utilizar para juzgar el funcionamiento 28

29 de un sistema, en lugar de un comportamiento específico. En general, los requisitos funcionales definen lo que el sistema debería de hacer, mientras que los requisitos no funcionales verifican cómo un sistema debería de ser. Una buena definición de requerimientos no funcionales es tan importante como los requisitos funcionales. Deben de ser definidos, analizados y trazados. - Cuando el cliente proporcione un documento con los requisitos del proyecto, con formato distinto del Catálogo de Requisitos de la organización, no será preciso realizar la adaptación del mismo, considerándose dicho documento como el catálogo de requisitos base del proyecto. - La trazabilidad entre los requisitos de sistema y de usuario es crítica para una implantación exitosa del proceso. Como se ha expuesto anteriormente este objetivo del proceso exige que los requisitos estén catalogados, priorizados y analizados para conocer sus implicaciones sobre el sistema (librerías, objetos, software...). Este concepto va más allá y también afecta a las pruebas que serán realizadas para validar los requisitos. Dicho de otra forma, gracias a la asignación de una codificación unívoca tanto del requisito como de la prueba, si partimos del Catálogo de Requisitos llegamos al Plan de Pruebas asociado y viceversa. 29

30 4. Proceso de ANÁLISIS DE LOS REQUISITOS DEL SISTEMA Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos Técnicos Objetivo El propósito de este proceso es transformar los requisitos en un conjunto adecuado de requisitos técnicos del sistema que guiará el diseño del sistema Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se establece y define un conjunto de requisitos funcionales y no funcionales del sistema que describen el problema a resolver. RP2) Se aplican las técnicas apropiadas para optimizar la solución del proyecto seleccionado. RP3) Los requisitos del sistema son analizados para puedan ser corregidos y probados. RP4) Se comprende el impacto de los requisitos del sistema en el entorno de explotación. RP5) Los requisitos se priorizan, aprueban y actualizan cuando es necesario. RP6) Se establece la consistencia y trazabilidad entre los requisitos del sistema y la línea base de requisitos del cliente. 30

31 RP7) Los cambios en la línea base son evaluados frente al coste, planificación e impacto técnico. RP8) Los requisitos del sistema se comunican a todas las partes interesadas y se colocan en la línea base Propuesta de aplicación en la PYME Los objetivos de este proceso están íntimamente relacionados con los de definición de requisitos de las partes interesadas, por lo que las organizaciones podrán documentar ambos procesos de una forma única o por separado. Se elija uno u otro modelo, sí deberá asegurarse que todos los objetivos de ambos procesos han sido cubiertos. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma una PYME debería hacer una relación ordenada de las principales actividades asociadas y que habitualmente se resumen en: Identificar la solución más óptima. El jefe del proyecto o el analista estudiará los requisitos definidos en la versión vigente del Catálogo, con la finalidad de obtener un conjunto de soluciones adaptables a los requisitos del cliente. El equipo de proyecto evaluará las diferentes soluciones propuestas y elegirá la más óptima bajo los criterios de viabilidad técnica, rentabilidad económica y capacidad de la empresa. Una vez seleccionada la solución óptima se comprobará la precisión de los requisitos y su capacidad para ser probados. Elaborar el documento de análisis funcional de requisitos. Partiendo de una plantilla o de la aplicación informática utilizada para el diseño de desarrollo software y que se deberá mantener vivo el documento incorporando los cambios en los requisitos que vayan apareciendo a lo largo de la vida del proyecto. Este 31

32 documento de análisis será trasladado al equipo de desarrollo para el inicio de la codificación. Gestionar los cambios en los requisitos. Las peticiones de cambio deberán ser incluidas en el documento de análisis siempre y cuando hayan sido evaluados y aprobados por el equipo de proyecto. Toda petición del cliente se realizará a través de algún medio que permita ser registrado (correo electrónico, acta,...). Todo cambio aprobado será comunicado a las partes interesadas (cliente y equipo de proyecto) Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Operaciones: responsable de elaborar y mantener el documento de análisis de requisitos del proyecto. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Catálogo de requisitos SALIDAS Documento de Análisis Funcional de los requisitos Peticiones de modificación de requisitos Actas de reunión para la elaborar el análisis de los requisitos Registro de peticiones de cambio Documento actualizado del catálogo de requisitos (si se han producido cambios) Con relación a los recursos, las organizaciones podrán contar con los siguientes: Plantilla de documento de análisis de requisitos Plantilla de peticiones de cambio. 32

33 Técnicas de entrevistas y reuniones si fuese necesario Técnicas de para la representación de modelos de datos (diagramas Entidad- Relación) si fuese necesario Técnicas de descripción de estructuras de datos si fuese necesario Técnicas de Análisis Orientado a Objetos si fuese necesario Plantilla de actas de reunión Un indicador asociado a este proceso podría ser el número de peticiones de cambio aprobados y que han requerido de la modificación de la oferta o del plan de proyecto en cuanto a plazos de ejecución, recursos y/o presupuesto. Este método de control facilitará a la organización actualizar los riesgos asociados al proyecto de desarrollo de software y tomar las medidas oportunas, como por ejemplo, negociando una ampliación económica a la oferta Observaciones prácticas para la implantación del proceso en la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene una dificultad media de implantación. - El análisis de requisitos es realizado, en general, por analistas sin un método, procedimiento o técnica determinado. Este punto no deja de ser siempre un problema en gran parte de las PYMEs dado que normalmente un analista/jefe de proyecto/consultor es el que tiene la responsabilidad y la potestad para evaluar en el análisis si los requisitos impactan de una determinada manera y cómo afecta esto al resto de la empresa. Esta evaluación, aunque haya muchas técnicas en el mercado del software siempre es similar y se basa en la experiencia de dicho perfil, en el histórico de proyectos y en la analogía de cada 33

34 tarea con respecto a una evaluada con anterioridad. Por lo tanto es vital que en el proceso de Suministro se haga una evaluación adecuada de los requisitos, haciendo hincapié en que cuanto mejor esté definido y evaluado el requisito y se consiga la aprobación del cliente, mejor van a ser los resultados y mejor se podrá medir las desviaciones sobre la línea base del proyecto a lo largo de su ciclo de vida. - Para proyectos de pequeña envergadura es muy difícil justificar el coste de elaboración y mantenimiento de un documento completo de análisis, por lo que es habitual que la plantilla utilizada para el análisis funcional de los requisitos tenga campos opcionales. 34

35 5. Proceso de PLANIFICACIÓN DEL PROYECTO Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyectos Objetivo El propósito este proceso es identificar, coordinar y monitorizar las actividades, tareas y recursos necesarios para producir un producto y/o servicio, en el contexto de los requisitos y limitaciones del proyecto Resultados esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se ha definido el alcance de los trabajos del proyecto. RP2) Se ha evaluado la viabilidad de la consecución de los objetivos del proyecto con los recursos disponibles y las limitaciones existentes. RP3) Se han estimado y clasificado las tareas y los recursos necesarios para completar el trabajo. RP4) Se han identificado las interfaces entre los elementos en el proyecto, y con otro proyecto y las unidades de organización. RP5) Se han diseñado los planes para la ejecución del proyecto. RP6) Se llevan a la práctica los planes para la ejecución del proyecto. 35

36 Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización Propuesta de aplicación en la PYME: Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para una correcta planificación de los proyectos de desarrollo. A continuación se proponen las siguientes: Definición del ámbito del trabajo y asignación de los recursos más adecuados. El responsable del departamento de producción asigna los recursos que van a formar parte del proyecto. Se recomienda que de esta notificación de responsabilidades se deje evidencia, ya sea a través de correo electrónico, acta de reunión interna o similar. En función del tipo del proyecto del que se trate, la compañía asignará diferentes perfiles (Director de Proyecto, Jefe de Proyecto, Analista Senior ) Dar de alta el proyecto en los sistemas corporativos de gestión. De esta forma se da conformidad al alcance del proyecto y a la asignación de los recursos necesarios. De esta forma los intervinientes podrán ir cargando las horas invertidas en el proyecto. Además se generará en los sistemas de control documental (directorios de red o aplicaciones informáticas) la estructura en la que residirá toda la información del proyecto y que estará formada por documentación, distribuciones, paquetes entregables, etc. Elaboración del Plan de Proyecto. El jefe de proyecto, a partir de una plantilla normalizada, genera la primera versión del documento de plan de proyecto en la que se tendrán en cuenta los recursos existentes, los plazos y compromisos adquiridos con el cliente, así como los condicionantes y riesgos del proyecto. Dado 36

37 que las organizaciones no ejecutan un solo proyecto y que los recursos suelen estar asignados a varios proyectos diferentes, el Jefe de Proyecto deberá tener en cuenta esta disponibilidad de recursos a la hora de planificar. La plantilla normalizada podrá estar en soporte papel, electrónico o ser aplicación informática para la gestión de proyectos. Dado que los planes de proyecto suelen actualizarse con frecuencia, se recomienda no usar el soporte papel. Estimación de esfuerzos. Para una correcta implantación del proceso es fundamental formalizar por escrito las actividades que permiten obtener la estimación del esfuerzo y dedicaciones requeridas para las diferentes tareas reflejadas en el Plan de Proyecto. Lanzamiento del Proyecto. Una vez validada la planificación se recomienda la comunicación al resto de intervinientes, especialmente a los analistas, programadores y testers, de los aspectos críticos del proyecto (datos del cliente, riesgos del proyecto, equipo de trabajo, tareas e hitos principales) Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección/Comercial: responsable de sincronizar las acciones de comunicación con el cliente y de otras acciones comerciales y de marketing. Operaciones: responsable de la gestión y desarrollo del proyecto. Calidad/Testing: responsable de la generación y ejecución del plan de pruebas a partir del listado de requisitos (funcionales y no funcionales) y responsable del aseguramiento del cumplimiento de los procesos de calidad. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: 37

38 ENTRADAS Oferta aprobada Listado de requisitos (funcionales y no funcionales) Listado de proyectos vivos y grado de ocupación del personal SALIDAS Documento de Plan de Proyecto Acta de reunión/correo electrónico asignación responsables de proyecto Acta de reunión/correo electrónico de inicio de proyecto Respecto a los recursos, las organizaciones debería contar, al menos, con el siguiente: Plantilla de documento de plan de proyecto. Un indicador asociado a este proceso y que permite evaluar la eficacia del mismo es el número de incumplimientos de los planes de proyecto vivos comparado con los contenidos y requerimientos establecidos en la plantilla Observaciones prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene una dificultad media de implantación. - Habitualmente las PYMEs contemplan la definición del alcance y la planificación de los hitos del proyecto como una parte correspondiente al proceso de Suministro, sin embargo, una vez aceptada la propuesta por el cliente no se genera el correspondiente Plan de Proyecto. 38

39 - Tampoco se procede a formalizar internamente los arranques de los proyectos con las personas que participarán en su desarrollo. - El objetivo que condiciona el éxito de la implantación de este proceso es contar con un método documentado para la estimación de esfuerzos (horas o jornadas de dedicación) para cada tarea definida en el Plan de Proyecto. En la realidad el dimensionamiento y cálculo de los proyectos es realizado por personas concretas y en base a su experiencia profesional en proyectos similares, lo que le confiere un alto grado de subjetividad a la duración y coste de los proyectos. Lo ideal sería contar con un histórico de estimaciones pasadas agrupadas por fases del desarrollo, por componente o módulo. En caso contrario la PYME deberá establecer un método de trabajo que le permita, con el paso del tiempo, ir generando un histórico fiable de datos. - Este proceso está íntimamente relacionado con el de Evaluación y Control del Proyecto (que se analizará en el siguiente apartado) y por esa razón se recomienda definir un único proceso documentado que englobe ambos, ganando coherencia y eficiencia. 39

40 6. Proceso de EVALUACIÓN Y CONTROL DE PROYECTOS Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyectos. Este proceso y el anterior Planificación de Proyectos suele fusionarse en uno Objetivo El propósito de este proceso es determinar el estado del proyecto y asegurar que se realiza de acuerdo con los planes y el calendario establecido, presupuestos planificados y cumpliendo con los objetivos técnicos Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) El seguimiento del proyecto es monitorizado y reportado. RP2) Hay seguimiento de las interfaces entre los elementos del proyecto, y con otro proyecto y las unidades de organización. RP3) Cuando los objetivos del proyecto no se consiguen, se toman las acciones necesarias para corregir las desviaciones del plan y para prevenir la recurrencia de los problemas identificados en el proyecto. RP4) Los objetivos del proyecto son alcanzados y registrados. Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización. 40

41 6.3. Propuesta de aplicación en la PYME Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para un seguimiento y evaluación de la planificación de los proyectos de desarrollo. A continuación se proponen las siguientes: Según las necesidades del proyecto y con la finalidad de controlar la evolución de la planificación, el jefe de proyecto elaborará y emitirá informes o comunicados periódicos de su estado. Estos informes deberán estar accesibles y contener la información más importante (consecución de hitos, grado de avance, desviaciones con relación a las fechas ) permitiendo a otras áreas de la compañía (Dirección, Calidad) o a los clientes estar informados de la evolución. Como resultado del análisis de los informes o comunicados de seguimiento por parte de las áreas de control (Dirección o Calidad) se evaluará si los objetivos del proyecto se han alcanzado o no. En caso de ser necesario se realizarán reuniones de seguimiento tanto internas como con el cliente y se deberá dejar constancia de las conclusiones que impacten en la planificación del proyecto. Si tras el análisis de los informes o comunicados de seguimiento fuese necesario realizar acciones correctivas, el jefe de proyecto tomará las medidas oportunas para eliminar las desviaciones y prevenir su repetición. Del análisis de la información de seguimiento también se podrán identificar problemas a futuro, por lo que se deberán realizar los ajustes necesarios con carácter preventivo. Por ejemplo, si el jefe de proyecto detecta por adelantado la imposibilidad de cumplir con un hito de la planificación, deberá analizar la situación y tomar acciones encaminadas a incorporar nuevos recursos, negociar con el cliente un nuevo calendario, etc. En cualquiera de los casos se deberá generar una nueva versión de la planificación y guardar la que ha quedado obsoleta en el histórico documental. 41

42 Es habitual que el cliente solicite cambios una vez que el proyecto se ha puesto en marcha. Tiendo presente el enorme impacto que pueden tener estas modificaciones el jefe de proyecto siempre deberá evaluar los riesgos que los cambios introducen en el proyecto y ser aprobados, rechazados o aplazados. Como mínimo los cambios aprobados por la jefatura del proyecto deberán quedar por escrito y serán notificados a las partes interesadas (clientes, miembros del equipo de proyecto, comercial ) En el caso de que los cambios introduzcan cambios en la planificación del proyecto, se procederá a emitir y aprobar una nueva versión del mismo. A la finalización del proyecto se debería recabar las impresiones, comentarios y sugerencias de todas las partes interesadas, de forma que se puedan extraer conclusiones de mejora para futuros proyectos. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Operaciones: responsable de la gestión y desarrollo del proyecto. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: Plan de Proyecto ENTRADAS Peticiones del cliente SALIDAS Informes de Seguimiento y Control Planes de proyecto actualizados Registro de conclusiones de la reunión de seguimiento del proyecto Informe de cierre del proyecto 42

43 Respecto a los recursos, las organizaciones debería contar, al menos, con los siguientes, tanto de forma individual como agrupada en uno solo: Plantilla de documento de informe de seguimiento y control del proyecto. Plantilla de reunión de seguimiento del proyecto. Plantilla de informe de cierre del proyecto. Existe gran cantidad de indicadores asociado al proceso de seguimiento y control de los proyectos. Se proponen dos que son de fácil aplicación y que proporcionan una información fundamental para el buen éxito de los proyectos. El primero es el número de desviaciones en los hitos del proyecto respecto a la planificación prevista. El segundo es el ratio de horas cargadas por los intervinientes en el proyecto respecto a las horas asignadas. Ambos indicadores proporcionan una valiosa información tanto a la jefatura del proyecto como a la Dirección de la compañía, dado que se trata de una medición de la eficiencia de los proyectos, o lo que es lo mismo, la rentabilidad económica de la empresa Observaciones prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene un grado de implantación alto. - En general las compañías llevan a cabo un seguimiento no formalizado ni estructurado de los proyectos. Por ejemplo es habitual que se realicen reuniones de seguimiento con el cliente y que en el mejor de los casos se elaboren actas, sin embargo, no se cuenta con método documentado de 43

44 recopilación y análisis de la información de progreso del proyecto, ni de la toma de acciones para la corrección de las posibles desviaciones detectadas. - También es una práctica muy habitual iniciar los proyectos sin haber contemplado todos los aspectos mínimos que son necesarios para asegurar su éxito. Aunque pueda parecer burocrático es importante definir cómo se lleva a cabo la aceptación del plan de proyecto entre los miembros del equipo y con el cliente. De esta forma todas las partes asumen las mismas reglas de juego y conocen los canales establecidos para solicitar y realizar ajustes al proyecto. - De una forma más o menos sofisticada todas las compañías realizan un seguimiento de sus proyectos. Con la implantación de este proceso, aseguramos que el documento del plan de proyecto es la base para monitorizar las actividades, comunicar el estado y tomar decisiones correctivas. El progreso se determina comparando los actuales elementos de trabajo: tareas, horas realizadas, coste y calendario actual, con los estimados en el plan de proyecto. 44

45 7. Proceso de GESTIÓN DE LA CONFIGURACIÓN Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyecto Objetivo El propósito es este proceso es establecer y mantener la integridad de todos los productos de trabajo identificados de un proyecto o proceso y ponerlos a disposición de las partes interesadas Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se define una estrategia de gestión de configuración. RP2) Se definen los elementos que requieren la gestión de configuración. RP3) Se establecen las líneas base de configuración. RP4) Se controlan los cambios a los elementos bajo configuración. RP5) Se controla la configuración de los entregables. RP6) El estado de los elementos bajo gestión de la configuración está disponible a lo largo de todo el ciclo de vida. RP7) Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organización. 45

46 7.3. Propuesta de aplicación en la PYME El propósito del proceso de Gestión de Configuración es asegurar la disponibilidad de las versiones consolidadas de cualquier documento que forma parte del ciclo de vida del proyecto. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para la gestión de la configuración en los proyectos de desarrollo. A continuación se proponen las siguientes: La definición de una estrategia documentada para la gestión de la configuración en la compañía permitirá establecer qué recursos e infraestructura serán necesarios para realizar un adecuado tratamiento de los elementos que estarán bajo control de configuración. Las opciones más habituales se reducen a dos: generar un directorio de carpetas en la red con permisos de acceso o utilizar una aplicación de gestión de la documentación o de proyectos. En ambos casos se guardarán aquellos elementos que afecten al buen desarrollo del proyecto. Como elemento de seguridad se deberá asegurar la existencia de un método de generación de copias de seguridad mantenimiento básico del repositorio en caso de pérdida o eliminación de cualquiera de los documentos. Identificación de los elementos afectados (no software). En el proceso documentado se establecerán qué elementos estarán bajo control de configuración, como por ejemplo, procedimientos, procesos documentados, guías, manuales, planes, actas, cronogramas, informes, documentos técnicos, etc. La primera versión de estos elementos constituirá la línea base en el proyecto. Cualquier modificación posterior será un cambio en esta línea base. 46

47 Gestión de los elementos. La organización establecerá el flujo de trabajo para el control de estos elementos en sus diferentes estados: elaboración, revisión, aprobación, distribución e histórico. El sistema utilizado (directorios de red o aplicación de gestión documental) deben asegurar: o que siempre será de aplicación la última versión de cada elemento. o que se podrá generar una nueva versión de los documentos, registrando los cambios realizados, los responsables de los cambios y fechas de cambio. o que se puede obtener el estado de los elementos de configuración y los cambios realizados. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección: responsable aprobar la documentación de los procesos. Operaciones: responsable de aplicar las políticas de Gestión de configuración, estableciendo las líneas base de la documentación y gestionando los directorios de la red o las herramientas utilizadas para la gestión de la configuración. Calidad: responsable de establecer las políticas de Gestión de configuración y velar por su cumplimiento. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Elementos del proyecto que deben estar bajo control de configuración SALIDAS Repositorio de Líneas base de documentación actualizadas Copias de seguridad del repositorio Respecto a los recursos, las organizaciones debería contar, al menos, con: 47

48 Red corporativa / aplicación de gestión de la documentación, de proyectos o similar. Para controlar si este proceso se está ejecutando correctamente se puede aplicar el indicador que relaciona el número de elementos definidos por el proyecto que deben ser configurados respecto al número real de elementos que están bajo control de configuración Observaciones prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: Este proceso tiene un grado de implantación medio. - Aunque todas las empresas disponen, al menos, de carpetas compartidas en red con permisos para almacenar documentación de los proyectos, no ocurre lo mismo con la existencia de una estrategia documentada para la gestión de la configuración - El concepto Línea Base de la Configuración es muy importante que quede bien fijado en la organización, dado que es el punto de partida, la versión inicial sobre la que se realizarán modificaciones o actualizaciones. - En la formalización del proceso hay que hacer un especial énfasis en la descripción de la estructura de las carpetas compartidas o de la aplicación informática equivalente, la codificación de los documentos y el criterio de nombrado de las diferentes versiones de los documentos 48

49 - Es necesario definir una función dentro de la organización que se responsabilice de la terea de definir, mantener y supervisar las políticas definidas en el proceso de gestión de la configuración. Para alcanzar una sólida madurez en el ciclo de vida de los proyectos es condición obligatoria contar con una gestión estricta de la configuración y que esta requiere asumir un coste de horas asignadas y contar con un registro de su actividad. Aunque este pueda ser el proceso más extraño a la hora de implantarlo en la compañía, la mayoría de los casos ya lo está llevan a cabo en mayor o menor medida por parte de las compañías y que solamente requiere de su documentación, partiendo de los objetivos del proceso. 49

50 8. Proceso de GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Soporte del Software Objetivo El propósito es este proceso es establecer y mantener la integridad de los elementos que forman el producto software de un proceso o proyecto y ponerlos a disposición de las partes interesadas Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se desarrolla una estrategia para la gestión de la configuración del software. RP2) Los elementos generados por los proyectos son definidos, identificados y colocados en la línea base. RP3) Se controlan las modificaciones y las entregas de los productos. RP4) Las modificaciones y entregas están disponibles para las partes interesadas. RP5) Se registra e informa del estado de los productos y sus modificaciones. RP6) Se asegura la integridad y consistencia de los productos. RP7) Se controla el almacenamiento, la manipulación y entrega de los productos. 50

51 8.3. Propuesta de aplicación en la PYME El propósito del proceso de Gestión de Configuración del Software es asegurar la disponibilidad de las versiones consolidadas del software que forma parte del ciclo de vida del proyecto. Está enfocado a garantizar la integridad del código fuente del proyecto, así como para garantizar la correcta reproductibilidad y evolución de las aplicaciones software, tanto durante el desarrollo como en el mantenimiento. La finalidad es la misma que el anterior proceso por lo que es posible establecer un único proceso de gestión de la configuración en el que se incluyan los elementos software y no software. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para la gestión de la configuración del software de los proyectos. A continuación se proponen las siguientes: La definición de la estrategia documentada para la gestión de la configuración del software en la compañía permitirá establecer qué recursos e infraestructura serán necesarios para realizar un adecuado tratamiento del código fuente que estará bajo control de configuración. La opción más habitual es el uso de una herramienta automatizada para la generación de las versiones del código fuente, ya sea licenciataria o de código abierto. Al igual que ocurría en el proceso de gestión de la configuración, como elemento de seguridad se deberá asegurar la existencia de un método de generación de copias de seguridad mantenimiento básico del repositorio en caso de pérdida o eliminación de cualquiera de los códigos fuente. Identificación de los elementos afectados (software). En el proceso documentado se establecerán qué elementos software estarán bajo control de configuración, como por ejemplo, librerías, scripts, módulos, objetos. La primera 51

52 versión de estos elementos constituirá la línea base en el proyecto. Cualquier modificación posterior será un cambio en esta línea base. Gestión de los elementos software. La organización establecerá el flujo de trabajo para el control de estos elementos en sus diferentes estados: codificación, revisión, validación, check-in / check-out, distribución e histórico. La herramienta utilizada debe asegurar: o que siempre será de aplicación la última versión de cada elemento. o que se podrá generar una nueva versión de los elementos software, registrando los cambios realizados, los responsables de los cambios y fechas de cambio. o que se puede obtener el estado de los elementos de configuración y los cambios realizados. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección: responsable aprobar la documentación de los procesos. Operaciones: responsable de aplicar las políticas de Gestión de configuración, estableciendo las líneas base de la documentación y gestionando los directorios de la red o las herramientas utilizadas para la gestión de la configuración. Calidad: responsable de establecer las políticas de Gestión de configuración y velar por su cumplimiento. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Elementos software que deben estar bajo control de configuración SALIDAS Repositorio de Líneas base de los elementos software actualizadas Copias de seguridad del repositorio 52

53 Respecto a los recursos, las organizaciones es altamente recomendable contar los siguientes: Aplicaciones informáticas de gestión de la configuración del software (propias, comerciales o de código abierto). En el caso de no contar con una aplicación de gestión automática de versiones del software consultar el Anexo I de la presente Guía. Para controlar si este proceso se está ejecutando correctamente se puede aplicar el indicador que relaciona el número de elementos software con su historial de modificaciones respecto al número total de elementos software configurado. Este control tiene mucho valor tanto para el responsable de validar el correcto estado de los elementos en la herramienta de gestión de la configuración como para el jefe de proyecto que le permite contar con una traza de todos los elementos que han sido modificados, antes de proceder a su entrega al cliente Observaciones prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - Este proceso tiene un grado de implantación medio-alto. - Se debe documentar la estrategia de gestión de la configuración, líneas base, estrategia de ramas, nombrado de versiones, ramas de estabilización, control de accesos, herramientas de gestión de la configuración, disponibilidad, etc. 53

54 - Es necesario elaborar informes de gestión de la configuración donde se comunique el estado de los elementos de configuración y sus modificaciones. - Aunque pueda sorprender aún existen PYMEs sin ningún tipo de formalización por escrito de la gestión de la configuración del software. - Las compañías que implantan eficazmente este proceso han formalizado documentalmente la estrategia de gestión de la configuración del software mediante la definición de políticas de versiones del software y de seguimiento de errores. - Hay ciertas dificultades en implantar correctamente este proceso dado la incorporación de una herramienta de control de versiones del software obliga a modificar la forma de trabajar de los equipos de producción. - Por la misma razón suele haber resistencias internas en las organizaciones a la hora de implantar y utilizar alguna herramienta automatizada de seguimiento de errores de programación en el código fuente. 54

55 9. Proceso de MEDICIÓN Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyecto Objetivo El propósito es este proceso es recoger, analizar e informar sobre los datos relativos a los productos desarrollados y procesos implantados dentro de la organización, para apoyar una gestión efectiva de los procesos y demostrar objetivamente la calidad de los productos Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP) RP1) Se identifican las necesidades de información de los procesos técnicos y de gestión. RP2) Se identifican y/o desarrollan un conjunto de medidas, motivadas por las necesidades de información. RP3) Se identifican y planifican las actividades de medición. RP4) Los datos requeridos son recogidos, almacenados, analizados y los resultados se interpretan. RP5) La información de los productos se utiliza para apoyar la toma de decisiones y proporcionar una base objetiva para la comunicación. 55

56 RP6) Se evalúa el proceso de medición y las medidas. RP7) Las mejoras se comunican al responsable del Proceso de Medición 9.3. Propuesta de aplicación en la PYME El propósito del proceso de Medición es recolectar y analizar datos relacionados con los productos, procesos y proyectos implementados en la organización, con la intención de soportar una gestión eficiente de los procesos, demostrar la calidad de los productos objetivamente y dotar a los responsables de información fiable y objetiva para la toma de decisiones. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para la gestión de la configuración del software de los proyectos. A continuación se proponen las siguientes: Determinar las necesidades de información de los procesos y las medidas relacionadas. Al menos una vez al año se deberían establecer los objetivos de negocio que condicionará el funcionamiento de la organización. Estos objetivos pueden estar orientados a mejorar la productividad o la rentabilidad de los proyectos, reducir las horas dedicadas a corregir errores de programación, simplificar los métodos de trabajo En función de los objetivos de negocio definidos, se identificarán las métricas más viables a obtener durante la operación de los procesos del modelo. La obtención de las medidas se realizará según los intervalos establecidos (anualmente, a la finalización del proyecto, mensualmente ) La periodicidad de obtención se establecerá pensando en cada métrica y se registran en alguna herramienta que facilite su posterior análisis y tratamiento (hojas de cálculo, herramientas de gestión de indicadores. Los diferentes responsables implicados 56

57 obtendrán sus métricas asignadas y las remitirán a un último responsable que será el encargado de consolidarlas. El responsable de generar informe de medición de los procesos y los proyectos se basará en las métricas obtenidas, realizará una consolidación coherente de las mismas y remitirá sus conclusiones a los máximos responsables de la organización. Por último, la dirección y otros responsables implicados, realizan un análisis de los resultados obtenidos en los proyectos y procesos y extraerá conclusiones acerca de la información obtenida y se llevarán a cabo las acciones correctivas o preventivas que se consideren necesarias. Además se evaluará la validez de las medidas utilizadas, con la finalidad de comprobar que son las adecuadas para la valoración tanto estratégica como operativa de los procesos del ciclo de vida. Las conclusiones se registran en un acta de reunión o similar y se distribuye a las personas implicadas. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección: responsable de aprobar y revisar los objetivos y métricas asociadas. Operaciones: obtener, según los plazos establecidos, las métricas de los proyectos. Calidad: responsable de consolidar las métricas, realizar el análisis de tendencias y proponer posibles mejora en las métricas y procesos. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: ENTRADAS Objetivos de negocio y necesidades de SALIDAS Valores de las métricas información 57

58 Informe de interpretación de los resultados de las métricas Acta o similar de la revisión por la Dirección de los resultados Registro de notificación de las mejoras Acciones correctoras o preventivas Respecto a los recursos, las organizaciones debería contar, al menos, con el siguiente: Hola de cálculo, plantilla o software con la información consolidada de las métricas de los procesos y proyectos. Plantilla del Informe o Resumen de interpretación de los resultados de las métricas. Estas dos plantillas pueden fusionarse en una sola de modo que en una única plantilla se realice la recogida de métricas y se formalice las conclusiones que se deriven de su análisis. Para controlar si este proceso se está ejecutando correctamente se puede aplicar el indicador que relaciona el número métricas que son modificadas o eliminadas después de la revisión por la dirección de los resultados obtenidos. Este elemento de control permite al responsable de este proceso de medición evaluar la calidad de las métricas Observaciones Prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: 58

59 - La implantación efectiva de este proceso se ha demostrado que tiene una dificultad alta. - Este es el apartado más débil de todas las PYME que, aunque suele recoger algunos datos mediante herramientas como el parte de horas o el seguimiento de incidencias y errores, estos datos no se analizan formalmente ni se genera ningún tipo de informe para ayudar a la toma de decisiones. - En este proceso se deben establecer métricas no solo para el ciclo de vida de los proyectos sino también para los diez procesos que componen el presente modelo de mejora. - Llevar a cabo una gestión de las métricas alineadas y son coherentes con los objetivos de la organización. Este es el punto que nos asegura que la PYME ha definido una estrategia de medición que le permitirá evaluar el grado de cumplimiento de los procesos desde una perspectiva de negocio. Aquí reside la dificultad de la implantación del proceso ya que: o supone una automatización o manual de la recopilación de datos, o requiere una sistemática en análisis de los resultados obtenidos, o necesita de la colaboración y concienciación de los empleados en las tareas de ingreso de métricas. - Las PYMEs que han implantado este proceso han identificado, al menos, las siguientes métricas. Medidas de rentabilidad de proyectos: o Número de horas ofertadas en los documentos de oferta. o Número de horas estimadas pendientes de ejecutar. o Número de horas dedicadas e imputadas semanalmente/mensualmente por todos los integrantes de los equipos asignados. 59

60 Medidas de incidencias en los proyectos: o Número total de incidencias detectadas en los proyectos y anotadas en la herramienta/hoja de cálculo de control de cambios. o Número de incidencias resueltas en los proyectos y anotadas en la herramienta/hoja de cálculo de control de cambios. Medidas de Calidad: o Número de elementos del catálogo de requisitos de los proyectos. o No conformidades internas en las pruebas de aceptación de los proyectos. o Desviación entre la fecha de entrega real y la fecha de entrega planificada. o No conformidades detectadas en las pruebas de aceptación de los proyectos. Medidas de la eficacia de los procesos: o No conformidades detectadas en las evaluaciones y auditoría de los procesos. Se evalúa la conformidad de las actividades y productos con relación los procesos, planes de proyecto y normas de referencia. o Peticiones o sugerencias de mejora a los procesos. - Y por último, sin medición y análisis de los procesos, no es posible mejorar la organización. 60

61 10. Proceso de ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Soporte del Software Objetivo El propósito es este proceso es establecer y mantener la integridad de los elementos que forman el producto software de un proceso o proyecto y ponerlos a disposición de las partes interesadas Resultados Esperados de una implantación exitosa del proceso En un proceso de evaluación, ya sea interno o externo, este proceso se considerará implantado correctamente siempre y cuando la organización muestre evidencias objetivas de los siguientes Resultados del Proceso (RP): RP1) Se ha desarrollado una estrategia para la realización del aseguramiento de la calidad. RP2) Se generan y se guardan las evidencias del aseguramiento de la calidad del software. RP3) Se identifican y registran los problemas y/o no conformidades con los requisitos. RP4) Se verifica la coherencia entre los productos, procesos y actividades con los estándares, procedimientos y requisitos aplicables. 61

62 10.3. Propuesta de aplicación en la PYME El proceso de Aseguramiento de Calidad tiene como objetivo asegurar a los clientes (tanto internos, como externos), la entrega de productos de la calidad acordada, proporcionando visibilidad a la línea jerárquica de la organización sobre los procesos seguidos para el desarrollo de los proyectos y los productos intermedios y finales obtenidos. El proceso define un modelo sistemático y planificado que permite garantizar que las actividades y productos son conformes a los estándares, procedimientos, planes de proyecto y normas de referencia. Además proporciona un mecanismo de obtención de información para mejorar los procesos que están siendo aplicados en los proyectos. Actividades: Para la consecución de los objetivos de este proceso definidos en la norma, la PYME deberá hacer establecer la secuencia de actividades necesarias para la gestión de la configuración del software de los proyectos. A continuación se proponen las siguientes: Determinar la estrategia para la realización del aseguramiento de la calidad. El proceso de Aseguramiento de la Calidad abarca las actividades de planificación y ejecución de controles, revisiones para garantizar el cumplimiento de la organización con los procesos definidos, así como la calidad final de los productos realizados. De esta actividad se podrá derivar un conjunto de No Conformidades (incumplimientos) que deberán ser resueltas por medio de la planificación, análisis y cierre de acciones correctivas), comunicando además los resultados obtenidos, a los implicados dentro de la organización o a los clientes, que así lo soliciten. Además de acciones correctivas se podrán crear acciones preventivas que permitirán eliminar la causa de una potencial no conformidad. La política es pública y se pone en conocimiento de toda la organización. 62

63 Revisiones de calidad de los proyectos, herramientas y plantillas de trabajo. Las revisiones de Calidad tienen el objetivo de asegurar que los productos (entendiendo producto como herramientas y plantillas de trabajo) y procesos planificados para los proyectos son implementados conforme a los estándares establecidos. En esta actividad se contempla tanto los pasos para la realización de dichas revisiones, como la identificación de las No Conformidades derivadas: Establecimiento de la agenda de revisiones: las revisiones abarcan tanto a los proyectos (el calendario de las revisiones estarán definidas en el Plan de Proyecto correspondientes) como a los procesos (su planificación estará definida anualmente). Realización de las revisiones de calidad, por medio de listas de verificación u otra herramienta similar. Identificación de problemas o no conformidades: se buscarán evidencias del correcto o incorrecto uso de los procesos de la organización en los proyectos. Las revisiones repasarán el ciclo de vida aplicable al proyecto. Se documentarán tanto las pruebas realizadas como los resultados obtenidos y en el caso de que se detecten no conformidades, se abrirán acciones correctivas. En la gestión de las acciones correctivas se procurará hacer partícipe a las personas más adecuadas y con mayor conocimiento sobre la materia para su pronta resolución. Responsabilidades: El siguiente listado muestra los departamentos, áreas o funciones más habitualmente involucrados en este proceso: Dirección: responsable de generar y aprobar las políticas generales de aseguramiento de calidad y aplicar las acciones correctoras basadas en las tareas de auditoría llevadas a cabo por el Responsable de Calidad.. Operaciones: los Jefes de Proyecto y resto de miembros del equipo son responsables de aplicar la última versión de los procesos documentados que 63

64 han sido elaborados por la compañía, velando por su correcta aplicación y notificando al área de calidad cualquier desviación, incoherencia o incumplimiento que detecten. Calidad: responsable del aseguramiento del cumplimiento de los procesos y requerimientos de calidad, así como de realizar las auditorías y controles para el aseguramiento de la calidad en cada proyecto, en función de las políticas y actividades implantadas en la organización. Las entradas y las salidas mínimas de este proceso se resumen en la siguiente tabla: Planes de Proyectos ENTRADAS SALIDAS Listas de verificación o similar completadas Calendario de revisiones de calidad Registro de No Conformidades y Acciones Correctoras Comunicación de la resolución de las No Conformidades Nuevas versiones de los documentos de los procesos (si fuese necesario realizar una actualización) Informe de resultados de las revisiones de calidad Respecto a los recursos, las organizaciones debería contar, al menos, con el siguiente: Plantilla registro de no conformidades y acciones correctivas. Plantilla de informe de los resultados de las revisiones de calidad. Listas de verificación u otro similar para la comprobación de los requisitos definidos por la organización para sus proyectos y procesos. 64

65 Para controlar si este proceso se está ejecutando correctamente se puede aplicar el siguiente conjunto de indicadores que permiten evaluar la eficacia del proceso de aseguramiento de la calidad: Revisiones de Calidad realizadas: Número de revisiones realizadas por el equipo de Calidad en los proyectos. Número de NC detectadas: Número de No Conformidades detectadas en un proyecto. % Acciones correctoras fuera de plazo: Porcentaje de Acciones Correctoras realizadas fuera de plazo. Esfuerzo en Actividades de Calidad: Esfuerzo total incurrido en la realización de las actividades de calidad del proyecto. % Esfuerzo Calidad vs. Esfuerzo total del Proyecto: Esfuerzo dedicado a las actividades de calidad, respecto del esfuerzo global del proyecto Observaciones Prácticas para la PYME Las apreciaciones recogidas en este apartado están basadas en proyectos reales y están encaminadas a reducir las principales dificultades detectadas durante la implantación del modelo de procesos de desarrollo de software en las PYMEs: - La implantación efectiva de este proceso se ha demostrado que tiene una dificultad alta. - A pesar de que las compañías entienden la importancia que tiene un proceso estructurado y sistemático orientado al aseguramiento de la calidad, carecen de una estrategia formal de aseguramiento de la Calidad del Software. 65

66 - Tener un proceso de aseguramiento de calidad conlleva, inevitablemente, la existencia de un perfil de responsable de calidad (a tiempo completo o parcial) y una revisión continua y planificada de procesos y proyectos. Dado que el proceso requiere de un perfil especializado, no todas las compañías cuentan en su organización y lo que se hace es asignar esta tarea a otro perfil (jefe de proyecto, programador, analista ) con lo que se pierde eficiencia a medio a largo plazo dado que se manifiestan diversos problemas como injerencia de tareas, priorización de otras tareas, falta de visión global del ciclo de vida del desarrollo, etc. Aunque las factorías de software tengan aspectos en común no son, ni mucho menos iguales, por lo que el grado de automatización será diferente y la cultura de gestión de los procesos internos diferirá. En el siguiente gráfico se muestra el grado de dificultad en la implantación de cada uno de los procesos en base a la experiencia real en PYMEs. 66

67 Gráfico 4: Grado de dificultad en la implantación de los procesos. 67

68 ANEXOS ANEXO 1. AUTOMATIZACIÓN DE LOS PROCESOS Como se ha ido perfilando a lo largo de esta guía cuanto más automatizado está el proceso de gestión y más herramientas de software se utilizan, mejor se adaptan los procedimientos internos a los procesos necesarios para poder alcanzar el nivel de madurez necesario. Por lo tanto, primera lección: las empresas deben orientar sus esfuerzos al uso de software para la gestión de sus procesos de desarrollo de software. La prioridad y los plazos deberán siempre estar determinados por las necesidades de la organización. Las herramientas más prioritarias son aquellas que inciden en los procesos nucleares del modelo: Herramienta de control de versiones Herramienta de control de acceso a la documentación Herramienta de control de errores / requisitos Herramienta de control y agrupamiento de métricas (partes de hora, etc.) Herramientas de seguimiento de incidencias (similar a la de errores, pero para la trazabilidad de requisitos y variaciones de la línea base) Herramienta de log de actividades (principalmente para gestión de la configuración) Sin menoscabo de otras herramientas sujetas a licencia tan válidas como cualquier otra, en la siguiente tabla se muestran soluciones de código abierto. Se han utilizado los siguientes criterios: Funcionalidades, Facilidad de integración con otras aplicaciones, facilidad de uso y puesta en producción. 68

69 Gráfico 5: Listado de aplicaciones de soporte a los procesos. Esta relación de aplicaciones no es única y puede ampliarse con otras existentes en el mercado. 69

70 ANEXO 2. ESTRUCTURA DOCUMENTAL El siguiente diagrama muestra la jerarquía documental habitual que se genera cuando se diseñan, documentan e implantan los diez procesos. Esta representación es solo una propuesta y cada empresa puede establecer su estructura y tipología de documentos como considere más oportuno: Gráfico 6: Ejemplo de estructura documental. Estos documentos son; - Política de Calidad de Desarrollo de Software Documento estratégico de la compañía que define los principios básicos que rigen la calidad de desarrollo de software - Políticas Organizativas 70