Guia de Implantacion Del Nivel 2 de Spice en Pymes

GUA DE IMPLANTACIN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE
EN LAS PYMES
GUA DE IMPLANTACIN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES
Tabla de contenido
INTRODUCCIN AL MODELO ........................................................................................................ 4 OBJETO DE ESTA GUA................................................................................................................... 7 1. Proceso de GESTIN DEL MODELO DE CICLO DE VIDA ........................................................... 12 1.1. Objetivo ................................................................................................................................ 12 1.2. Resultados esperados de una implantacin exitosa del proceso ........................................ 12 1.3 Propuesta de aplicacin en la PYME ..................................................................................... 13 1.4 Observaciones prcticas para la PYME ................................................................................. 15 2. Proceso de SUMINISTRO ......................................................................................................... 17 2.1. Objetivo ................................................................................................................................ 17 2.2. Resultados esperados de una implantacin exitosa del proceso ........................................ 17 2.3. Propuesta de aplicacin en la PYME .................................................................................... 18 2.4. Observaciones prcticas para la implantacin del proceso en la PYME .............................. 22 3. Proceso de DEFINICIN DE REQUISITOS DE LAS PARTES INTERESADAS ................................. 24 3.1. Objetivo ................................................................................................................................ 24 3.2. Resultados esperados de una implantacin exitosa del proceso ........................................ 24 3.3. Propuesta de aplicacin en la PYME .................................................................................... 25 2.4. Observaciones prcticas para la implantacin del proceso en la PYME .............................. 28 4. Proceso de ANLISIS DE LOS REQUISITOS DEL SISTEMA ........................................................ 30 4.1. Objetivo ................................................................................................................................ 30 4.2. Resultados esperados de una implantacin exitosa del proceso ........................................ 30 4.3. Propuesta de aplicacin en la PYME .................................................................................... 31 4.4. Observaciones prcticas para la implantacin del proceso en la PYME .............................. 33 5. Proceso de PLANIFICACIN DEL PROYECTO ........................................................................... 35 5.1. Objetivo ................................................................................................................................ 35 5.2. Resultados esperados de una implantacin exitosa del proceso ........................................ 35 5.3. Propuesta de aplicacin en la PYME: ................................................................................... 36 5.4. Observaciones prcticas para la PYME ................................................................................ 38 6. Proceso de EVALUACIN Y CONTROL DE PROYECTOS ............................................................ 40 6.1. Objetivo ................................................................................................................................ 40 6.2. Resultados Esperados de una implantacin exitosa del proceso ....................................... 40 6.3. Propuesta de aplicacin en la PYME .................................................................................... 41
Gua de implantacin orientativa para la mejora de la calidad del desarrollo de software de las PYMES espaolas conforme a los niveles de madurez nivel 1 y nivel 2 de la norma internacional ISO/IEC 15504 utilizando los procesos de la ISO 12207:2008. Proyecto con subvencin obtenida del Ministerio de Industria, Turismo y Comercio Plan Avanza - .
Pgina 2
6.4. Observaciones prcticas para la PYME ................................................................................ 43 7. Proceso de GESTIN DE LA CONFIGURACIN ........................................................................ 45 7.1. Objetivo ................................................................................................................................ 45 7.2. Resultados Esperados de una implantacin exitosa del proceso ....................................... 45 7.3. Propuesta de aplicacin en la PYME .................................................................................... 46 7.4. Observaciones prcticas para la PYME ................................................................................ 48 8. Proceso de GESTIN DE LA CONFIGURACIN DEL SOFTWARE .............................................. 50 8.1. Objetivo ................................................................................................................................ 50 8.2. Resultados Esperados de una implantacin exitosa del proceso ....................................... 50 8.3. Propuesta de aplicacin en la PYME .................................................................................... 51 8.4. Observaciones prcticas para la PYME ................................................................................ 53 9. Proceso de MEDICIN ............................................................................................................. 55 9.1. Objetivo ................................................................................................................................ 55 9.2. Resultados Esperados de una implantacin exitosa del proceso ....................................... 55 9.3. Propuesta de aplicacin en la PYME .................................................................................... 56 9.4. Observaciones Prcticas para la PYME................................................................................. 58 10. Proceso de ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE ........................................... 61 10.1. Objetivo .............................................................................................................................. 61 10.2. Resultados Esperados de una implantacin exitosa del proceso ..................................... 61 10.3. Propuesta de aplicacin en la PYME .................................................................................. 62 10.4. Observaciones Prcticas para la PYME .............................................................................. 65 ANEXOS ....................................................................................................................................... 68 ANEXO 1. AUTOMATIZACIN DE LOS PROCESOS ....................................................................... 68 ANEXO 2. ESTRUCTURA DOCUMENTAL ...................................................................................... 70 ANEXO 3. BIBLIOGRAFA.............................................................................................................. 72
Pgina 3
INTRODUCCIN AL MODELO
El Modelo de Mejora y Evaluacin de la Calidad del Ciclo de Vida del Software elaborado por AENOR acorde a la ISO 15504, tiene como objetivo principal proporcionar a las pequeas y medianas factoras de software un marco de referencia para la mejora de los procesos de calidad internos relacionados con el desarrollo de software, para su posterior certificacin segn el referencial conocido como SPICE, en su nivel 2.
Los procesos han sido seleccionados de la norma internacional ISO/IEC 12207:2008 Ingeniera de Sistemas y Software. Procesos del ciclo de vida del software y estn 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, tambin de rango internacional, que establezca los criterios de evaluacin de la madurez de las compaas.
La norma ISO/IEC 15504 SPICE, en su parte nmero 7 y publicada en noviembre de 2008, permite evaluar por niveles de madurez las organizaciones, a partir de la capacidad de los procesos evaluados (gestin de la configuracin, anlisis de los requisitos, etc.) y as obtener el certificado de AENOR.
En el siguiente grfico se muestran los procesos de la norma ISO/IEC 12207:2008 que componen el modelo de procesos de AENOR y que sern evaluados segn los criterios definidos en la norma ISO/IEC 15504 SPICE.
Pgina 4
Grfico 1: Procesos de la norma ISO/IEC 12207:2008, correspondientes al nivel 2, y que sern evaluados segn los criterios definidos en la norma ISO/IEC 15504 SPICE.
Las normas de referencia mencionadas anteriormente permitirn a las factoras de software mejorar sus procesos internos de desarrollo con independencia del tipo de tecnologa existente, el entorno de programacin utilizado o la organizacin jerrquica definida.
Llegados a este punto es fundamental establecer una definicin nica de lo que es un proceso.
Un proceso es un conjunto de actividades repetitivas y sistemticas mediante las cuales se convierten las entradas en salidas, que sern los productos o servicios que reciba el cliente, ya sea este interno o externo.
En la prctica, si se pide a un grupo de empleados o tcnicos que describan grficamente las actividades de su empresa, la mayora de ellos, ya pertenezcan a grandes organizaciones multinacionales o a pequeas empresas, dibujaran algo similar a un organigrama, con ms o menos casillas y niveles, pero tratando siempre de
Pgina 5
mostrar las relaciones jerrquicas entre las diferentes unidades organizativas (zonas, reas, departamentos, divisiones) de la empresa.
Esta representacin 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.
Pgina 6
OBJETO DE ESTA GUA
En la prctica diaria de las organizaciones no siempre estn claramente identificados los procesos de desarrollo del software puesto que, a menudo, se identifican ms con las personas o departamentos que con el flujo de las propias actividades.
Esta dificultad inicial para identificar los procesos de una organizacin, provoca conflictos de competencias que inciden poderosamente en la gestin de procesos, poniendo en riesgo el alcanzar los resultados esperados. La solucin pasa por identificar los procesos de forma transversal a la organizacin, trazando la secuencia de las actividades correspondientes sin detenerse en los departamentos o reas. Solo despus se asignarn los responsables de realizar cada una de las actividades.
Para ayudar a las organizaciones, esta Gua 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 certificacin de nivel 2. La Gua tiene un enfoque a procesos por lo que para cada uno de ellos se definirn solo aquellos parmetros que sirvan para su identificacin, conteniendo la suficiente informacin para posibilitar su gestin: Nombre: Identificacin del proceso. Objetivo: Propsito 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 fsicos, humanos o tecnolgicos necesarios para poder ejecutar correctamente el proceso. Indicadores u otro mecanismo de control del proceso.
Pgina 7
Grfico 2: Descripcin de los componentes de un proceso.
A continuacin 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 definicin y anlisis de los procesos de desarrollo de software es fundamental recordar que:
1) la norma ISO/IEC 12207:2008 no establece una relacin 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 cmo hacerlo. Algunas compaas optarn por llevar esta identificacin con un fichero individual, otras usarn un ERP y otras aplicaciones de software libre para la gestin comercial. Estas opciones, y cualquier otra, son vlidas siempre y cuando permitan la identificacin del comprador.
Pgina 8
2) para superar con xito la auditora de certificacin de nivel 2 segn el modelo de evaluacin de AENOR, la norma con la que se realiza la evaluacin. ISO/IEC 15504, conocida como SPICE requiere que cualquier organizacin pueda dar evidencia de la implantacin 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 Direccin en el desarrollo, implantacin de los procesos, asegurando la asignacin adecuada de recursos y velando por la consecucin de los objetivos de los procesos. c. Est definida la gestin de cmo 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 slidos y continuados de medicin y seguimiento de los procesos y sus resultados, permitiendo evaluar el cumplimiento con los objetivos determinados. e. El personal de la organizacin que participa en el diseo o ejecucin de los procesos es consciente de la pertinencia e importancia de sus actividades y cmo contribuyen al logro de los objetivos de los procesos. f. Existe una sistemtica para la deteccin, registro y eliminacin de las desviaciones en el desempeo de los procesos, previniendo que vuelvan a ocurrir. g. Los elementos de trabajo (plantillas, formatos, documentos,
formularios) estn 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
Pgina 9
los procesos en su organizacin. En la presente gua se propondr un conjunto de actividades, entradas, salidas y recursos que servirn como punto de partida a una PYME cualquiera para construir cada uno de los diez procesos. Estos debern aplicarse a los proyectos de desarrollo existentes en la PYME.
Lgicamente se trata de una propuesta de mnimos que deber ser enriquecida y ajustada en funcin de la realidad de cada PYME. En cualquier caso, todas las propuestas, sugerencias e indicaciones que contiene este documento estn basadas en la experiencia real en la implantacin en PYMEs espaolas 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 organizacin puede dar evidencia por un conjunto de documentos tales como: manuales de usuario y registros de las aplicaciones informticas usadas para el desempeo de los procesos, actas de reunin, correos electrnicos, informes, fichas de trabajo, etc. y todos ellos en diferentes soportes: papel, digital, imagen, software o una combinacin 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 amplan 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 debern ser aprobados y verificados por todos los miembros implicados en cada proceso (la redaccin de la documentacin 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 formalizacin.
Pgina 10
Tambin es interesante tener en cuenta el hecho de que la documentacin de los procesos y actividades es un pilar fundamental para la formacin interna. Al tener acceso a la documentacin, el personal de la empresa toma conciencia de los procesos que deben aplicarse en la produccin del software, sirviendo tambin para que los implicados en otros procesos conozcan actividades que no tienen una relacin directa con su trabajo diario, contribuyendo al despliegue del conocimiento a toda la empresa.
Otro punto importante es que sirve de base para la capacitacin de las nuevas incorporaciones a la plantilla, as como servir de referente y preceptor cuando hay desviaciones entre la prctica diaria y los procesos documentados. El conocimiento deja de residir en la experiencia de unas pocas personas a formar parte de toda la organizacin.
Pgina 11
1. Proceso de GESTIN DEL MODELO DE CICLO DE VIDA
Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Realizacin de Proyectos Organizacionales.
1.1. Objetivo
El propsito de este proceso es definir, mantener y asegurar la disponibilidad de polticas, procesos y modelos del ciclo de vida para que sean usados por la organizacin.
1.2. Resultados esperados de una implantacin exitosa del proceso
En un proceso de evaluacin, ya sea interno o externo, este proceso se considerar implantado correctamente siempre y cuando la organizacin muestre evidencias objetivas de los siguientes Resultados del Proceso (RP):
RP1) Existen polticas y procedimientos para la gestin 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 gestin del ciclo de vida. RP3) Se definen, mantienen y mejoran los procesos de ciclo de vida, modelos y procedimientos para el uso por la organizacin. RP4) Se priorizan las mejoras en los procesos.
Pgina 12
Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimiento de software acometido en la organizacin.
1.3 Propuesta de aplicacin en la PYME
Este proceso es el ms genrico de todos los que componen el modelo y no puede igualarse al resto, puesto que es el marco comn en el que documenta la secuencia de tareas que debern realizarse desde el inicio al cierre de los proyectos, los diferentes participantes, responsables, documentacin aplicable, y los entregables que sern generados.
Este proceso es de aplicacin a todas las personas que de una u otra forma participen en alguna de las fases de un proyecto software en aspectos tales como produccin de software o gestin del proyecto y tendr como finalidad determinar, dar a conocer y aplicar la metodologa adoptada para dicho proyecto.
Este ciclo de vida no podr responder a todas las casusticas y tipologa de proyectos que normalmente se realizan. Es por eso por lo que el ciclo de vida deber ajustarse en funcin 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 ms meses. Aunque en ambos proyectos exista una fase de codificacin y pruebas, el nmero y detalle de la documentacin generada, los diferentes perfiles intervinientes y herramientas utilizadas puede que no sean los mismos.
Actividades: Para la consecucin de los objetivos de este proceso definidos en la norma, la PYME deber hacer una relacin ordenada de las fases que son necesarias para producir el software:
Pgina 13
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 visin global y de conjunto del funcionamiento productivo de la compaa.
El responsable asignado proceder a la definicin, coordinacin y seguimiento de las diferentes etapas y recursos necesarios para el desarrollo del software en el contexto de los requisitos y limitaciones de cada tipologa de proyecto.
Como resultado de la puesta en prctica del modelo de ciclo de vida, las mejoras identificadas sern priorizadas en funcin del coste, facilidad de implantacin, recursos necesarios, etc.
Responsabilidades: El siguiente listado muestra los departamentos, reas o funciones ms habitualmente involucrados en este proceso:
- Direccin/Operaciones: responsable de documentar, mantener y mejorar el ciclo de vida de desarrollo de la compaa - Resto de la organizacin: aplicar las actividades definidas en el documento y notificar posibles mejoras al mismo.
Las entradas y las salidas mnimas de este proceso se resumen en la siguiente tabla:
ENTRADAS Tipologa de proyectos Organigrama funcional
SALIDAS Documento de Ciclo de Vida
Con relacin a los recursos, las organizaciones debera contar, al menos, con los siguientes:
Pgina 14
- Plantilla de documento de ciclo de vida. - Aplicacin de gestin documental o estructura de directorios en la red.
Un indicador asociado a este proceso, y sencillo de aplicar, es el nmero de desviaciones o incumplimientos del ciclo de vida comparado con el nmero de total de proyectos a los que aplica.
1.4 Observaciones prcticas para la PYME
Este proceso tiene una baja dificultad de implantacin.
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 genrico de la compaa. En cada proyecto se realizar una adecuacin 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 genrico.
Tanto las Actividades Principales como los Entregables debern ajustarse a la realidad de la PYME a la tipologa de proyectos que apliquen. Por ejemplo, en la etapa 5. Codificacin, no todos los proyectos requerirn la realizacin de pruebas unitarias, de integracin y de sistema, pero lo que s es evidente que se ejecutarn un conjunto de pruebas al cdigo generado.
Pgina 15
Grfico 3: Ejemplo del Ciclo de Vida de Desarrollo del Software para un proyecto genrico.
Pgina 16
2. Proceso de SUMINISTRO
Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Acuerdo.
2.1. Objetivo
El propsito 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 organizacin, preparar y emitir propuestas, y confirmar la entrega e instalacin satisfactorias a travs del establecimiento de un contrato/acuerdo relevante.
En un proceso de evaluacin, ya sea interno o externo, este proceso se considerar implantado correctamente siempre y cuando la organizacin 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, operacin, embalaje, la entrega e instalacin del producto y/o servicio. RP4) Se desarrolla por parte del proveedor un producto y/o servicio que satisfaga los requisitos acordados.
Pgina 17
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.
2.3. Propuesta de aplicacin en la PYME
Desde el punto de vista del ciclo de vida de desarrollo del software, este proceso se centra en los vnculos con el cliente durante el proceso de definicin y aprobacin de la oferta y al final del ciclo, con la aceptacin y aprobacin de la entrega del software por parte del cliente.
Actividades: Para la consecucin de los objetivos de este proceso definidos en la norma una PYME debera hacer una relacin 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 informticas de gestin comercial, ERPs, etc) asegurando que permite mantener una identificacin nico, completa y suficiente de los clientes.
Elaboracin de la oferta sobre la base de plantillas corporativas.
Elaborar la documentacin asociada a la oferta en el caso de que fuese necesaria, como por ejemplo, prototipos, pantallazos, contratos
Pgina 18
Presentar y negociar con el cliente la oferta segn el canal establecido (correo electrnico, correo ordinario o presencial.
Cerrar la oportunidad de negocio, quedando a la espera de la aceptacin 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 produccin del software ha finalizado y se han pasado las pruebas oportunas, el equipo de proyecto genera el paquete de entrega para el cliente identificndolo con un cdigo nico. Un posible mtodo es asociando el cdigo de proyecto, la fecha de generacin del paquete y la versin (x.y.z) del producto a entregar.
El equipo de proyecto deposita el paquete de entrega dentro de la carpeta de distribucin de paquetes del proyecto.
El jefe de proyecto genera el documento de entrega al cliente en el que relaciona todos los elementos que sern proporcionados. Este listado deber ser coherente con los compromisos adquiridos en la ltima versin 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 obtencin 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 telemtica, solicitndose posteriormente un correo electrnico al interlocutor del proyecto del cliente confirmando la aceptacin de la entrega.
Pgina 19
- Desarrollo de negocio/rea Comercial: responsable del logro de oportunidades comerciales.
- Operaciones: responsable de la elaboracin de la propuesta y validacin del contenido tcnico de la misma, as como de recabar la aceptacin de la entrega por el cliente.
- Direccin/Financiero: responsable de validar la forma y el periodo de pago de la propuesta antes y despus de la negociacin.
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 pequeas es habitual que la Direccin asuma la labor financiera y comercial. Por el contrario, si la PYME cuenta con ms personal seguramente las responsabilidades se desplegarn a diferentes personas.
ENTRADAS Solicitud de oferta Peticiones de modificacin
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 revisin de la
Pgina 20
propuesta inicial mediante actas de reunin y/o correos electrnicos. Registro de las revisiones de la oferta mediante la creacin de diferentes versiones del documento inicial. Registro de la aceptacin de la oferta/propuesta mediante la firma del documento de oferta o correo electrnico indicando el cdigo de oferta. Paquete de entrega al cliente (software, aplicaciones de instalacin, documentacin, manual de usuario, manual de administrador, manual de configuracin) Registro de entrega y aceptacin
Con relacin a los recursos, es recomendable que las organizaciones cuenten con los siguientes: - Plantilla de acta de reunin con cliente. - Plantillas de hojas de clculo con los sumarios ejecutivos que contemplan el anlisis de los mrgenes de beneficio y las valoraciones tcnicas. - Plantilla de documento de oferta. - Plantilla de recepcin y aceptacin del producto. - Aplicacin o ficheros para la gestin comercial. En funcin de las necesidades la empresa puede fusionar las anteriores plantillas en una sola o, simplemente, no necesitarla.
Los indicadores asociados a este proceso podran ser 1) la tasa de peticiones de cambio de las ofertas, que permitira identificar carencias en la descripcin de los
Pgina 21
servicios y deteccin de las necesidades de los clientes y 2) el nmero de entregas no aprobadas por el cliente respecto al nmero de entregas emitidas, con el fin de evaluar el grado de fiabilidad del desarrollo del software.
2.4. Observaciones prcticas para la implantacin del proceso en la PYME
Las apreciaciones recogidas en este apartado estn basadas en proyectos reales y estn encaminadas a reducir las principales dificultades detectadas durante la implantacin del modelo de procesos de desarrollo de software en las PYMEs:
Este proceso tiene una baja dificultad de implantacin.
Se debe documentar cmo realiza la empresa la gestin de las ofertas, la gestin de los contratos y la aceptacin de la entrega por parte del cliente.
Este proceso tiene una baja dificultad de implantacin, dado que las PYMEs en su gran mayora disponen de una gestin del suministro ms o menos evolucionada, contemplando al menos, la existencia de una oferta documentada, en el que se relacionan los elementos a desarrollar y los entregables mnimos esperados por parte del cliente.
Suelen presentarse dificultadas a la hora de documentar cundo y cmo se generan las evidencias relativas a las peticiones de los clientes y ms concretamente las relacionadas con cambios sobre los proyectos ya comenzados.
La entrega del software (con su correspondiente registro de entrega) no implica la aceptacin 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 aceptacin. En funcin del cliente y del proyecto que se
Pgina 22
trate, en ocasiones el mismo registro de la entrega es, adems, el registro de aceptacin.
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, aceptacin de fin de proyecto, etc. Estas evidencias suelen encontrarse en correos electrnicos, actas, documentos o contratos.
Como se ver en procesos siguientes, se deber establecer un mtodo formalizado de estimacin del esfuerzo necesario para la realizacin del proyecto y que, aplicando variables econmicas, establecer el precio de los servicios incluidos en la oferta.
Pgina 23
3. Proceso de DEFINICIN DE REQUISITOS DE LAS PARTES INTERESADAS
Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos Tcnicos.
3.1. Objetivo
El propsito 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.
RP1) Se especifican las caractersticas 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 definicin de los requerimientos del sistema. RP5) Se define la base para validar de la conformidad de los servicios. RP6) Existe una base para la negociacin y el acuerdo de entrega de los productos o servicios.
Pgina 24
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 lneas base iniciales y sucesivas de los productos resultantes.
Creacin 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 Catlogo de Requisitos. Normalmente se realiza la primera versin del Catlogo cuando se ha aprobado la oferta por parte del cliente y constituir la lnea base de requisitos sobre la que se irn incorporando las modificaciones que surjan a lo largo del proyecto. En el Catlogo se registrarn todos los requisitos contenidos en la oferta aprobada ms aquellos otros que, aun no siendo solicitados expresamente por el cliente, son fundamentales para poder cumplir con sus expectativas. El Catlogo de Requisitos debe identificar cada requisito de manera independiente y nica, de forma que pueda seguirse su traza, inequvocamente, a lo largo del proyecto y, adems, se vincule a la prueba(s) correspondiente que permita su validacin.
Incorporacin de requisitos partiendo de la versin inicial del catlogo. La incorporacin 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 incorporacin de los nuevos requisitos deber estar documentada y aprobada tanto por la PYME como por el cliente.
Pgina 25
Aceptacin del Catlogo de requisitos. Es condicin bsica contar con la aprobacin 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 Catlogo de requisitos vigente no ser desarrollado por la empresa ni ser esperado por el cliente. Esta aceptacin deber estar documentada (correo electrnico, acta de reunin o similar)
Elaboracin del plan de pruebas. El Jefe de Proyecto y el responsable de Calidad elaborarn los casos de prueba que debern aplicarse al software antes de su entrega al cliente. En este plan de pruebas se podrn validar requisitos individuales o agrupaciones de requisitos gracias a la trazabilidad entre este documento y el catlogo de requisitos. En algunos casos los clientes pueden solicitar la aprobacin del plan de pruebas que utilizar la PYME.
Responsabilidades: El siguiente listado muestra los departamentos, reas o funciones ms habitualmente involucrados en este proceso: - Desarrollo de negocio/rea Comercial: responsable del cierre del catlogo de requisitos con el cliente. - Operaciones: responsable de definir con detalle el catlogo de todos los requisitos (funcionales y no funcionales) as como participar en el diseo 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.
Pgina 26
ENTRADAS Oferta aprobada Listado de requisitos funcionales y no funcionales
SALIDAS Documento de Catlogo de requisitos Actas/correos electrnicos de las
reuniones de toma de requisitos con el cliente
Peticiones de modificacin de requisitos
Registro de la aceptacin del catlogo de requisitos por parte del cliente (en ocasiones ser la propia oferta aprobada) Documento de Plan de Pruebas
Con relacin a los recursos, las organizaciones debera contar, al menos, con los siguientes: - Plantilla de acta de reunin con cliente. - Plantilla de documento de catlogo de requisitos. - Plantilla de documento de plan de pruebas.
Es posible fusionar en una sola plantilla las correspondientes a catlogo de requisitos y plan de pruebas. En el caso de utilizar una aplicacin informtica para la gestin de los requisitos o plan de pruebas, no es necesario utilizar plantillas independientes.
Un indicador asociado a este proceso podran ser la tasa de peticiones de cambio de los requisitos respecto a la versin aprobada del Catlogo de requisitos, que permitira identificar deficiencias en la identificacin y definicin de requisitos por parte del equipo de proyecto de desarrollo de software.
Pgina 27
Este proceso tiene una dificultad media de implantacin.
Es prctica habitual en las PYMEs que el contenido de la oferta se utilice como un Catlogo 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 adems, incorpore un mecanismo de identificacin nico para cada requisito facilitando su trazabilidad a lo largo de todo el proyecto.
Se recomienda elaborar un Catlogo de requisitos nico, formalizando las actividades necesarias para su redaccin y aprobacin por las partes interesadas con el objeto de que sirva como 1) un documento independiente, cuya lnea base son los requisitos presentados en la oferta y 2) Base para las pruebas validacin a la finalizacin del proyecto
Una vez que se asume la importancia de formalizar la gestin de los requisitos, las empresas son conscientes de los beneficios de mantener, a lo largo de la vida del proyecto, el catlogo 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
Pgina 28
de un sistema, en lugar de un comportamiento especfico. En general, los requisitos funcionales definen lo que el sistema debera de hacer, mientras que los requisitos no funcionales verifican cmo un sistema debera de ser. Una buena definicin 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 Catlogo de Requisitos de la organizacin, no ser preciso realizar la adaptacin del mismo, considerndose dicho documento como el catlogo de requisitos base del proyecto.
La trazabilidad entre los requisitos de sistema y de usuario es crtica para una implantacin exitosa del proceso. Como se ha expuesto anteriormente este objetivo del proceso exige que los requisitos estn catalogados, priorizados y analizados para conocer sus implicaciones sobre el sistema (libreras, objetos, software...). Este concepto va ms all y tambin afecta a las pruebas que sern realizadas para validar los requisitos. Dicho de otra forma, gracias a la asignacin de una codificacin unvoca tanto del requisito como de la prueba, si partimos del Catlogo de Requisitos llegamos al Plan de Pruebas asociado y viceversa.
Pgina 29
4. Proceso de ANLISIS DE LOS REQUISITOS DEL SISTEMA
Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos Tcnicos.
4.1. Objetivo
El propsito de este proceso es transformar los requisitos en un conjunto adecuado de requisitos tcnicos del sistema que guiar el diseo del sistema.
4.2. Resultados esperados de una implantacin exitosa del proceso En un proceso de evaluacin, ya sea interno o externo, este proceso se considerar implantado correctamente siempre y cuando la organizacin 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 tcnicas apropiadas para optimizar la solucin 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 explotacin. 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 lnea base de requisitos del cliente.
Pgina 30
RP7) Los cambios en la lnea base son evaluados frente al coste, planificacin e impacto tcnico. RP8) Los requisitos del sistema se comunican a todas las partes interesadas y se colocan en la lnea base.
Los objetivos de este proceso estn ntimamente relacionados con los de definicin de requisitos de las partes interesadas, por lo que las organizaciones podrn 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.
Identificar la solucin ms ptima. El jefe del proyecto o el analista estudiar los requisitos definidos en la versin vigente del Catlogo, 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 ms ptima bajo los criterios de viabilidad tcnica, rentabilidad econmica y capacidad de la empresa. Una vez seleccionada la solucin ptima se comprobar la precisin de los requisitos y su capacidad para ser probados.
Elaborar el documento de anlisis funcional de requisitos. Partiendo de una plantilla o de la aplicacin informtica utilizada para el diseo 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
Pgina 31
documento de anlisis ser trasladado al equipo de desarrollo para el inicio de la codificacin.
Gestionar los cambios en los requisitos. Las peticiones de cambio debern ser incluidas en el documento de anlisis siempre y cuando hayan sido evaluados y aprobados por el equipo de proyecto. Toda peticin del cliente se realizar a travs de algn medio que permita ser registrado (correo electrnico, 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 ms habitualmente involucrados en este proceso: - Operaciones: responsable de elaborar y mantener el documento de anlisis de requisitos del proyecto.
ENTRADAS Catlogo de requisitos
SALIDAS Documento de Anlisis Funcional de los requisitos
Peticiones de modificacin de requisitos
Actas de reunin para la elaborar el anlisis de los requisitos Registro de peticiones de cambio Documento actualizado del catlogo de requisitos (si se han producido cambios)
Con relacin a los recursos, las organizaciones podrn contar con los siguientes: Plantilla de documento de anlisis de requisitos Plantilla de peticiones de cambio.
Pgina 32
Tcnicas de entrevistas y reuniones si fuese necesario Tcnicas de para la representacin de modelos de datos (diagramas EntidadRelacin) si fuese necesario Tcnicas de descripcin de estructuras de datos si fuese necesario Tcnicas de Anlisis Orientado a Objetos si fuese necesario Plantilla de actas de reunin
Un indicador asociado a este proceso podra ser el nmero de peticiones de cambio aprobados y que han requerido de la modificacin de la oferta o del plan de proyecto en cuanto a plazos de ejecucin, recursos y/o presupuesto. Este mtodo de control facilitar a la organizacin actualizar los riesgos asociados al proyecto de desarrollo de software y tomar las medidas oportunas, como por ejemplo, negociando una ampliacin econmica a la oferta.
El anlisis de requisitos es realizado, en general, por analistas sin un mtodo, procedimiento o tcnica 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 anlisis si los requisitos impactan de una determinada manera y cmo afecta esto al resto de la empresa. Esta evaluacin, aunque haya muchas tcnicas en el mercado del software siempre es similar y se basa en la experiencia de dicho perfil, en el histrico de proyectos y en la analoga de cada
Pgina 33
tarea con respecto a una evaluada con anterioridad. Por lo tanto es vital que en el proceso de Suministro se haga una evaluacin adecuada de los requisitos, haciendo hincapi en que cuanto mejor est definido y evaluado el requisito y se consiga la aprobacin del cliente, mejor van a ser los resultados y mejor se podr medir las desviaciones sobre la lnea base del proyecto a lo largo de su ciclo de vida.
Para proyectos de pequea envergadura es muy difcil justificar el coste de elaboracin y mantenimiento de un documento completo de anlisis, por lo que es habitual que la plantilla utilizada para el anlisis funcional de los requisitos tenga campos opcionales.
Pgina 34
5. Proceso de PLANIFICACIN DEL PROYECTO
Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyectos.
5.1. Objetivo
El propsito 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.
RP1) Se ha definido el alcance de los trabajos del proyecto. RP2) Se ha evaluado la viabilidad de la consecucin 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 organizacin. RP5) Se han diseado los planes para la ejecucin del proyecto. RP6) Se llevan a la prctica los planes para la ejecucin del proyecto.
Pgina 35
5.3. Propuesta de aplicacin en la PYME:
Actividades: Para la consecucin de los objetivos de este proceso definidos en la norma, la PYME deber hacer establecer la secuencia de actividades necesarias para una correcta planificacin de los proyectos de desarrollo. A continuacin se proponen las siguientes:
Definicin del mbito del trabajo y asignacin de los recursos ms adecuados. El responsable del departamento de produccin asigna los recursos que van a formar parte del proyecto. Se recomienda que de esta notificacin de responsabilidades se deje evidencia, ya sea a travs de correo electrnico, acta de reunin interna o similar. En funcin del tipo del proyecto del que se trate, la compaa asignar diferentes perfiles (Director de Proyecto, Jefe de Proyecto, Analista Senior)
Dar de alta el proyecto en los sistemas corporativos de gestin. De esta forma se da conformidad al alcance del proyecto y a la asignacin de los recursos necesarios. De esta forma los intervinientes podrn ir cargando las horas invertidas en el proyecto. Adems se generar en los sistemas de control documental (directorios de red o aplicaciones informticas) la estructura en la que residir toda la informacin del proyecto y que estar formada por documentacin, distribuciones, paquetes entregables, etc.
Elaboracin del Plan de Proyecto. El jefe de proyecto, a partir de una plantilla normalizada, genera la primera versin del documento de plan de proyecto en la que se tendrn en cuenta los recursos existentes, los plazos y compromisos adquiridos con el cliente, as como los condicionantes y riesgos del proyecto. Dado
Pgina 36
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, electrnico o ser aplicacin informtica para la gestin de proyectos. Dado que los planes de proyecto suelen actualizarse con frecuencia, se recomienda no usar el soporte papel.
Estimacin de esfuerzos. Para una correcta implantacin del proceso es fundamental formalizar por escrito las actividades que permiten obtener la estimacin del esfuerzo y dedicaciones requeridas para las diferentes tareas reflejadas en el Plan de Proyecto.
Lanzamiento del Proyecto. Una vez validada la planificacin se recomienda la comunicacin al resto de intervinientes, especialmente a los analistas, programadores y testers, de los aspectos crticos del proyecto (datos del cliente, riesgos del proyecto, equipo de trabajo, tareas e hitos principales)
- Direccin/Comercial: responsable de sincronizar las acciones de comunicacin con el cliente y de otras acciones comerciales y de marketing. - Operaciones: responsable de la gestin y desarrollo del proyecto. - Calidad/Testing: responsable de la generacin y ejecucin 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.
Pgina 37
ENTRADAS Oferta aprobada Listado de requisitos (funcionales y no funcionales) Listado de proyectos vivos y grado de ocupacin del personal
SALIDAS Documento de Plan de Proyecto Acta de reunin/correo electrnico asignacin responsables de proyecto Acta de reunin/correo electrnico de inicio de proyecto
Respecto a los recursos, las organizaciones debera 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 nmero de incumplimientos de los planes de proyecto vivos comparado con los contenidos y requerimientos establecidos en la plantilla.
5.4. Observaciones prcticas para la PYME
Habitualmente las PYMEs contemplan la definicin del alcance y la planificacin 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.
Pgina 38
Tampoco se procede a formalizar internamente los arranques de los proyectos con las personas que participarn en su desarrollo.
El objetivo que condiciona el xito de la implantacin de este proceso es contar con un mtodo documentado para la estimacin de esfuerzos (horas o jornadas de dedicacin) para cada tarea definida en el Plan de Proyecto. En la realidad el dimensionamiento y clculo 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 duracin y coste de los proyectos. Lo ideal sera contar con un histrico de estimaciones pasadas agrupadas por fases del desarrollo, por componente o mdulo. En caso contrario la PYME deber establecer un mtodo de trabajo que le permita, con el paso del tiempo, ir generando un histrico fiable de datos.
Este proceso est ntimamente relacionado con el de Evaluacin y Control del Proyecto (que se analizar en el siguiente apartado) y por esa razn se recomienda definir un nico proceso documentado que englobe ambos, ganando coherencia y eficiencia.
Pgina 39
6. Proceso de EVALUACIN 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 Planificacin de Proyectos suele fusionarse en uno. 6.1. Objetivo
El propsito 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 tcnicos.
6.2. Resultados Esperados de una implantacin exitosa del proceso
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 organizacin. 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.
Pgina 40
Actividades: Para la consecucin de los objetivos de este proceso definidos en la norma, la PYME deber hacer establecer la secuencia de actividades necesarias para un seguimiento y evaluacin de la planificacin de los proyectos de desarrollo. A continuacin se proponen las siguientes:
Segn las necesidades del proyecto y con la finalidad de controlar la evolucin de la planificacin, el jefe de proyecto elaborar y emitir informes o comunicados peridicos de su estado. Estos informes debern estar accesibles y contener la informacin ms importante (consecucin de hitos, grado de avance, desviaciones con relacin a las fechas) permitiendo a otras reas de la compaa (Direccin, Calidad) o a los clientes estar informados de la evolucin.
Como resultado del anlisis de los informes o comunicados de seguimiento por parte de las reas de control (Direccin o Calidad) se evaluar si los objetivos del proyecto se han alcanzado o no. En caso de ser necesario se realizarn reuniones de seguimiento tanto internas como con el cliente y se deber dejar constancia de las conclusiones que impacten en la planificacin del proyecto.
Si tras el anlisis 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 repeticin. Del anlisis de la informacin de seguimiento tambin se podrn identificar problemas a futuro, por lo que se debern realizar los ajustes necesarios con carcter preventivo. Por ejemplo, si el jefe de proyecto detecta por adelantado la imposibilidad de cumplir con un hito de la planificacin, deber analizar la situacin 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 versin de la planificacin y guardar la que ha quedado obsoleta en el histrico documental.
Pgina 41
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 mnimo los cambios aprobados por la jefatura del proyecto debern quedar por escrito y sern notificados a las partes interesadas (clientes, miembros del equipo de proyecto, comercial) En el caso de que los cambios introduzcan cambios en la planificacin del proyecto, se proceder a emitir y aprobar una nueva versin del mismo.
A la finalizacin del proyecto se debera recabar las impresiones, comentarios y sugerencias de todas las partes interesadas, de forma que se puedan extraer conclusiones de mejora para futuros proyectos.
- Operaciones: responsable de la gestin y desarrollo del proyecto.
ENTRADAS Plan de Proyecto Peticiones del cliente
SALIDAS Informes de Seguimiento y Control Planes de proyecto actualizados Registro de conclusiones de la reunin de seguimiento del proyecto Informe de cierre del proyecto
Pgina 42
Respecto a los recursos, las organizaciones debera 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 reunin 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 fcil aplicacin y que proporcionan una informacin fundamental para el buen xito de los proyectos. El primero es el nmero de desviaciones en los hitos del proyecto respecto a la planificacin 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 informacin tanto a la jefatura del proyecto como a la Direccin de la compaa, dado que se trata de una medicin de la eficiencia de los proyectos, o lo que es lo mismo, la rentabilidad econmica de la empresa.
Este proceso tiene un grado de implantacin alto.
En general las compaas 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 mtodo documentado de
Pgina 43
recopilacin y anlisis de la informacin de progreso del proyecto, ni de la toma de acciones para la correccin de las posibles desviaciones detectadas.
Tambin es una prctica muy habitual iniciar los proyectos sin haber contemplado todos los aspectos mnimos que son necesarios para asegurar su xito. Aunque pueda parecer burocrtico es importante definir cmo se lleva a cabo la aceptacin 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 ms o menos sofisticada todas las compaas realizan un seguimiento de sus proyectos. Con la implantacin 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.
Pgina 44
7. Proceso de GESTIN DE LA CONFIGURACIN
Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyecto.
7.1. Objetivo
El propsito es este proceso es establecer y mantener la integridad de todos los productos de trabajo identificados de un proyecto o proceso y ponerlos a disposicin de las partes interesadas.
RP1) Se define una estrategia de gestin de configuracin. RP2) Se definen los elementos que requieren la gestin de configuracin. RP3) Se establecen las lneas base de configuracin. RP4) Se controlan los cambios a los elementos bajo configuracin. RP5) Se controla la configuracin de los entregables. RP6) El estado de los elementos bajo gestin de la configuracin 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 organizacin.
Pgina 45
El propsito del proceso de Gestin de Configuracin es asegurar la disponibilidad de las versiones consolidadas de cualquier documento que forma parte del ciclo de vida del proyecto.
Actividades: Para la consecucin de los objetivos de este proceso definidos en la norma, la PYME deber hacer establecer la secuencia de actividades necesarias para la gestin de la configuracin en los proyectos de desarrollo. A continuacin se proponen las siguientes:
La definicin de una estrategia documentada para la gestin de la configuracin en la compaa permitir establecer qu recursos e infraestructura sern necesarios para realizar un adecuado tratamiento de los elementos que estarn bajo control de configuracin. Las opciones ms habituales se reducen a dos: generar un directorio de carpetas en la red con permisos de acceso o utilizar una aplicacin de gestin de la documentacin o de proyectos. En ambos casos se guardarn aquellos elementos que afecten al buen desarrollo del proyecto. Como elemento de seguridad se deber asegurar la existencia de un mtodo de generacin de copias de seguridad mantenimiento bsico del repositorio en caso de prdida o eliminacin de cualquiera de los documentos.
Identificacin de los elementos afectados (no software). En el proceso documentado se establecern qu elementos estarn bajo control de configuracin, como por ejemplo, procedimientos, procesos documentados, guas, manuales, planes, actas, cronogramas, informes, documentos tcnicos, etc. La primera versin de estos elementos constituir la lnea base en el proyecto. Cualquier modificacin posterior ser un cambio en esta lnea base.
Pgina 46
Gestin de los elementos. La organizacin establecer el flujo de trabajo para el control de estos elementos en sus diferentes estados: elaboracin, revisin, aprobacin, distribucin e histrico. El sistema utilizado (directorios de red o aplicacin de gestin documental) deben asegurar:
o que siempre ser de aplicacin la ltima versin de cada elemento. o que se podr generar una nueva versin 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 configuracin y los cambios realizados.
- Direccin: responsable aprobar la documentacin de los procesos. - Operaciones: responsable de aplicar las polticas de Gestin de configuracin, estableciendo las lneas base de la documentacin y gestionando los directorios de la red o las herramientas utilizadas para la gestin de la configuracin. - Calidad: responsable de establecer las polticas de Gestin de configuracin y velar por su cumplimiento.
ENTRADAS Elementos del proyecto que deben estar bajo control de configuracin
SALIDAS Repositorio de Lneas base de documentacin actualizadas Copias de seguridad del repositorio
Respecto a los recursos, las organizaciones debera contar, al menos, con:

Pgina 47
Red corporativa / aplicacin de gestin de la documentacin, de proyectos o similar.
Para controlar si este proceso se est ejecutando correctamente se puede aplicar el indicador que relaciona el nmero de elementos definidos por el proyecto que deben ser configurados respecto al nmero real de elementos que estn bajo control de configuracin.
Este proceso tiene un grado de implantacin medio.
Aunque todas las empresas disponen, al menos, de carpetas compartidas en red con permisos para almacenar documentacin de los proyectos, no ocurre lo mismo con la existencia de una estrategia documentada para la gestin de la configuracin
El concepto Lnea Base de la Configuracin es muy importante que quede bien fijado en la organizacin, dado que es el punto de partida, la versin inicial sobre la que se realizarn modificaciones o actualizaciones.
En la formalizacin del proceso hay que hacer un especial nfasis en la descripcin de la estructura de las carpetas compartidas o de la aplicacin informtica equivalente, la codificacin de los documentos y el criterio de nombrado de las diferentes versiones de los documentos
Pgina 48
Es necesario definir una funcin dentro de la organizacin que se responsabilice de la terea de definir, mantener y supervisar las polticas definidas en el proceso de gestin de la configuracin. Para alcanzar una slida madurez en el ciclo de vida de los proyectos es condicin obligatoria contar con una gestin estricta de la configuracin y que esta requiere asumir un coste de horas asignadas y contar con un registro de su actividad. Aunque este pueda ser el proceso ms extrao a la hora de implantarlo en la compaa, la mayora de los casos ya lo est llevan a cabo en mayor o menor medida por parte de las compaas y que solamente requiere de su documentacin, partiendo de los objetivos del proceso.
Pgina 49
8. Proceso de GESTIN DE LA CONFIGURACIN DEL SOFTWARE
Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Soporte del Software.
8.1. Objetivo
El propsito 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 disposicin de las partes interesadas.
RP1) Se desarrolla una estrategia para la gestin de la configuracin del software. RP2) Los elementos generados por los proyectos son definidos, identificados y colocados en la lnea base. RP3) Se controlan las modificaciones y las entregas de los productos. RP4) Las modificaciones y entregas estn 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 manipulacin y entrega de los productos.
Pgina 50
El propsito del proceso de Gestin de Configuracin 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 cdigo fuente del proyecto, as como para garantizar la correcta reproductibilidad y evolucin 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 gestin de la configuracin en el que se incluyan los elementos software y no software.
Actividades: Para la consecucin de los objetivos de este proceso definidos en la norma, la PYME deber hacer establecer la secuencia de actividades necesarias para la gestin de la configuracin del software de los proyectos. A continuacin se proponen las siguientes:
La definicin de la estrategia documentada para la gestin de la configuracin del software en la compaa permitir establecer qu recursos e infraestructura sern necesarios para realizar un adecuado tratamiento del cdigo fuente que estar bajo control de configuracin. La opcin ms habitual es el uso de una herramienta automatizada para la generacin de las versiones del cdigo fuente, ya sea licenciataria o de cdigo abierto. Al igual que ocurra en el proceso de gestin de la configuracin, como elemento de seguridad se deber asegurar la existencia de un mtodo de generacin de copias de seguridad mantenimiento bsico del repositorio en caso de prdida o eliminacin de cualquiera de los cdigos fuente.
Identificacin de los elementos afectados (software). En el proceso documentado se establecern qu elementos software estarn bajo control de configuracin, como por ejemplo, libreras, scripts, mdulos, objetos. La primera
Pgina 51
versin de estos elementos constituir la lnea base en el proyecto. Cualquier modificacin posterior ser un cambio en esta lnea base.
Gestin de los elementos software. La organizacin establecer el flujo de trabajo para el control de estos elementos en sus diferentes estados: codificacin, revisin, validacin, check-in / check-out, distribucin e histrico. La herramienta utilizada debe asegurar:
o que siempre ser de aplicacin la ltima versin de cada elemento. o que se podr generar una nueva versin 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 configuracin y los cambios realizados.
- Direccin: responsable aprobar la documentacin de los procesos. - Operaciones: responsable de aplicar las polticas de Gestin de configuracin, estableciendo las lneas base de la documentacin y gestionando los directorios de la red o las herramientas utilizadas para la gestin de la configuracin. - Calidad: responsable de establecer las polticas de Gestin de configuracin y velar por su cumplimiento.
Las entradas y las salidas mnimas de este proceso se resumen en la siguiente tabla: ENTRADAS Elementos software que deben estar bajo control de configuracin SALIDAS Repositorio de Lneas base de los elementos software actualizadas Copias de seguridad del repositorio
Pgina 52
Respecto a los recursos, las organizaciones es altamente recomendable contar los siguientes:
- Aplicaciones informticas de gestin de la configuracin del software (propias, comerciales o de cdigo abierto). En el caso de no contar con una aplicacin de gestin automtica de versiones del software consultar el Anexo I de la presente Gua.
Para controlar si este proceso se est ejecutando correctamente se puede aplicar el indicador que relaciona el nmero de elementos software con su historial de modificaciones respecto al nmero 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 gestin de la configuracin 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.
Este proceso tiene un grado de implantacin medio-alto.
Se debe documentar la estrategia de gestin de la configuracin, lneas base, estrategia de ramas, nombrado de versiones, ramas de estabilizacin, control de accesos, herramientas de gestin de la configuracin, disponibilidad, etc.
Pgina 53
Es necesario elaborar informes de gestin de la configuracin donde se comunique el estado de los elementos de configuracin y sus modificaciones.
Aunque pueda sorprender an existen PYMEs sin ningn tipo de formalizacin por escrito de la gestin de la configuracin del software.
Las compaas que implantan eficazmente este proceso han formalizado documentalmente la estrategia de gestin de la configuracin del software mediante la definicin de polticas de versiones del software y de seguimiento de errores.
Hay ciertas dificultades en implantar correctamente este proceso dado la incorporacin de una herramienta de control de versiones del software obliga a modificar la forma de trabajar de los equipos de produccin.
Por la misma razn suele haber resistencias internas en las organizaciones a la hora de implantar y utilizar alguna herramienta automatizada de seguimiento de errores de programacin en el cdigo fuente.
Pgina 54
9. Proceso de MEDICIN
Dentro de la norma ISO/IEC 12207:2008, este proceso forma parte de los Procesos de Proyecto.
9.1. Objetivo
El propsito es este proceso es recoger, analizar e informar sobre los datos relativos a los productos desarrollados y procesos implantados dentro de la organizacin, para apoyar una gestin efectiva de los procesos y demostrar objetivamente la calidad de los productos.
En un proceso de evaluacin, ya sea interno o externo, este proceso se considerar implantado correctamente siempre y cuando la organizacin muestre evidencias objetivas de los siguientes Resultados del Proceso (RP)
RP1) Se identifican las necesidades de informacin de los procesos tcnicos y de gestin. RP2) Se identifican y/o desarrollan un conjunto de medidas, motivadas por las necesidades de informacin. RP3) Se identifican y planifican las actividades de medicin. RP4) Los datos requeridos son recogidos, almacenados, analizados y los resultados se interpretan. RP5) La informacin de los productos se utiliza para apoyar la toma de decisiones y proporcionar una base objetiva para la comunicacin.
Pgina 55
RP6) Se evala el proceso de medicin y las medidas. RP7) Las mejoras se comunican al responsable del Proceso de Medicin
El propsito del proceso de Medicin es recolectar y analizar datos relacionados con los productos, procesos y proyectos implementados en la organizacin, con la intencin de soportar una gestin eficiente de los procesos, demostrar la calidad de los productos objetivamente y dotar a los responsables de informacin fiable y objetiva para la toma de decisiones.
Determinar las necesidades de informacin de los procesos y las medidas relacionadas. Al menos una vez al ao se deberan establecer los objetivos de negocio que condicionar el funcionamiento de la organizacin. Estos objetivos pueden estar orientados a mejorar la productividad o la rentabilidad de los proyectos, reducir las horas dedicadas a corregir errores de programacin, simplificar los mtodos de trabajo En funcin de los objetivos de negocio definidos, se identificarn las mtricas ms viables a obtener durante la operacin de los procesos del modelo.
La obtencin de las medidas se realizar segn los intervalos establecidos (anualmente, a la finalizacin del proyecto, mensualmente) La periodicidad de obtencin se establecer pensando en cada mtrica y se registran en alguna herramienta que facilite su posterior anlisis y tratamiento (hojas de clculo, herramientas de gestin de indicadores. Los diferentes responsables implicados
Pgina 56
obtendrn sus mtricas asignadas y las remitirn a un ltimo responsable que ser el encargado de consolidarlas.
El responsable de generar informe de medicin de los procesos y los proyectos se basar en las mtricas obtenidas, realizar una consolidacin coherente de las mismas y remitir sus conclusiones a los mximos responsables de la organizacin.
Por ltimo, la direccin y otros responsables implicados, realizan un anlisis de los resultados obtenidos en los proyectos y procesos y extraer conclusiones acerca de la informacin obtenida y se llevarn a cabo las acciones correctivas o preventivas que se consideren necesarias. Adems se evaluar la validez de las medidas utilizadas, con la finalidad de comprobar que son las adecuadas para la valoracin tanto estratgica como operativa de los procesos del ciclo de vida. Las conclusiones se registran en un acta de reunin o similar y se distribuye a las personas implicadas.
- Direccin: responsable de aprobar y revisar los objetivos y mtricas asociadas. - Operaciones: obtener, segn los plazos establecidos, las mtricas de los proyectos. - Calidad: responsable de consolidar las mtricas, realizar el anlisis de tendencias y proponer posibles mejora en las mtricas y procesos.
ENTRADAS Objetivos de negocio y necesidades de informacin
SALIDAS Valores de las mtricas
Pgina 57
Informe de interpretacin de los resultados de las mtricas Acta o similar de la revisin por la Direccin de los resultados Registro de notificacin de las mejoras Acciones correctoras o preventivas
Respecto a los recursos, las organizaciones debera contar, al menos, con el siguiente: Hola de clculo, plantilla o software con la informacin consolidada de las mtricas de los procesos y proyectos. Plantilla del Informe o Resumen de interpretacin de los resultados de las mtricas. Estas dos plantillas pueden fusionarse en una sola de modo que en una nica plantilla se realice la recogida de mtricas y se formalice las conclusiones que se deriven de su anlisis.
Para controlar si este proceso se est ejecutando correctamente se puede aplicar el indicador que relaciona el nmero mtricas que son modificadas o eliminadas despus de la revisin por la direccin de los resultados obtenidos. Este elemento de control permite al responsable de este proceso de medicin evaluar la calidad de las mtricas.
9.4. Observaciones Prcticas para la PYME
Pgina 58
La implantacin efectiva de este proceso se ha demostrado que tiene una dificultad alta.
Este es el apartado ms dbil 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 ningn tipo de informe para ayudar a la toma de decisiones.
En este proceso se deben establecer mtricas no solo para el ciclo de vida de los proyectos sino tambin para los diez procesos que componen el presente modelo de mejora.
Llevar a cabo una gestin de las mtricas alineadas y son coherentes con los objetivos de la organizacin. Este es el punto que nos asegura que la PYME ha definido una estrategia de medicin que le permitir evaluar el grado de cumplimiento de los procesos desde una perspectiva de negocio. Aqu reside la dificultad de la implantacin del proceso ya que:
o supone una automatizacin o manual de la recopilacin de datos, o requiere una sistemtica en anlisis de los resultados obtenidos, o necesita de la colaboracin y concienciacin de los empleados en las tareas de ingreso de mtricas.
Las PYMEs que han implantado este proceso han identificado, al menos, las siguientes mtricas. Medidas de rentabilidad de proyectos: o Nmero de horas ofertadas en los documentos de oferta. o Nmero de horas estimadas pendientes de ejecutar. o Nmero de horas dedicadas e imputadas semanalmente/mensualmente por todos los integrantes de los equipos asignados.
Pgina 59
Medidas de incidencias en los proyectos: o Nmero total de incidencias detectadas en los proyectos y anotadas en la herramienta/hoja de clculo de control de cambios. o Nmero de incidencias resueltas en los proyectos y anotadas en la herramienta/hoja de clculo de control de cambios.
Medidas de Calidad: o Nmero de elementos del catlogo de requisitos de los proyectos. o No conformidades internas en las pruebas de aceptacin de los proyectos. o Desviacin entre la fecha de entrega real y la fecha de entrega planificada. o No conformidades detectadas en las pruebas de aceptacin de los proyectos.
Medidas de la eficacia de los procesos: o No conformidades detectadas en las evaluaciones y auditora de los procesos. Se evala la conformidad de las actividades y productos con relacin los procesos, planes de proyecto y normas de referencia. o Peticiones o sugerencias de mejora a los procesos.
Y por ltimo, sin medicin y anlisis de los procesos, no es posible mejorar la organizacin.
Pgina 60
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.
10.1. Objetivo
El propsito 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 disposicin de las partes interesadas.
RP1) Se ha desarrollado una estrategia para la realizacin 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 estndares, procedimientos y requisitos aplicables.
Pgina 61
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 lnea jerrquica de la organizacin sobre los procesos seguidos para el desarrollo de los proyectos y los productos intermedios y finales obtenidos. El proceso define un modelo sistemtico y planificado que permite garantizar que las actividades y productos son conformes a los estndares, procedimientos, planes de proyecto y normas de referencia. Adems proporciona un mecanismo de obtencin de informacin para mejorar los procesos que estn siendo aplicados en los proyectos.
Determinar la estrategia para la realizacin del aseguramiento de la calidad. El proceso de Aseguramiento de la Calidad abarca las actividades de planificacin y ejecucin de controles, revisiones para garantizar el cumplimiento de la organizacin 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 debern ser resueltas por medio de la planificacin, anlisis y cierre de acciones correctivas), comunicando adems los resultados obtenidos, a los implicados dentro de la organizacin o a los clientes, que as lo soliciten. Adems de acciones correctivas se podrn crear acciones preventivas que permitirn eliminar la causa de una potencial no conformidad. La poltica es pblica y se pone en conocimiento de toda la organizacin.
Pgina 62
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 estndares establecidos. En esta actividad se contempla tanto los pasos para la realizacin de dichas revisiones, como la identificacin de las No Conformidades derivadas:
Establecimiento de la agenda de revisiones: las revisiones abarcan tanto a los proyectos (el calendario de las revisiones estarn definidas en el Plan de Proyecto correspondientes) como a los procesos (su planificacin estar definida anualmente). Realizacin de las revisiones de calidad, por medio de listas de verificacin u otra herramienta similar. Identificacin de problemas o no conformidades: se buscarn evidencias del correcto o incorrecto uso de los procesos de la organizacin en los proyectos. Las revisiones repasarn el ciclo de vida aplicable al proyecto. Se documentarn tanto las pruebas realizadas como los resultados obtenidos y en el caso de que se detecten no conformidades, se abrirn acciones correctivas. En la gestin de las acciones correctivas se procurar hacer partcipe a las personas ms adecuadas y con mayor conocimiento sobre la materia para su pronta resolucin.
- Direccin: responsable de generar y aprobar las polticas generales de aseguramiento de calidad y aplicar las acciones correctoras basadas en las tareas de auditora 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 versin de los procesos documentados que
Pgina 63
han sido elaborados por la compaa, velando por su correcta aplicacin y notificando al rea de calidad cualquier desviacin, incoherencia o incumplimiento que detecten. - Calidad: responsable del aseguramiento del cumplimiento de los procesos y requerimientos de calidad, as como de realizar las auditoras y controles para el aseguramiento de la calidad en cada proyecto, en funcin de las polticas y actividades implantadas en la organizacin.
Las entradas y las salidas mnimas de este proceso se resumen en la siguiente tabla: ENTRADAS Planes de Proyectos SALIDAS Listas de verificacin o similar completadas Calendario de revisiones de calidad Registro de No Conformidades y Acciones Correctoras Comunicacin de la resolucin de las No Conformidades Nuevas versiones de los documentos de los procesos (si fuese necesario realizar una actualizacin) Informe de resultados de las revisiones de calidad
Respecto a los recursos, las organizaciones debera 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 verificacin u otro similar para la comprobacin de los requisitos definidos por la organizacin para sus proyectos y procesos.
Pgina 64
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: Nmero de revisiones realizadas por el equipo de Calidad en los proyectos. Nmero de NC detectadas: Nmero 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 realizacin 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.
10.4. Observaciones Prcticas para la PYME
La implantacin efectiva de este proceso se ha demostrado que tiene una dificultad alta.
A pesar de que las compaas entienden la importancia que tiene un proceso estructurado y sistemtico orientado al aseguramiento de la calidad, carecen de una estrategia formal de aseguramiento de la Calidad del Software.
Pgina 65
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 revisin continua y planificada de procesos y proyectos. Dado que el proceso requiere de un perfil especializado, no todas las compaas cuentan en su organizacin 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, priorizacin de otras tareas, falta de visin global del ciclo de vida del desarrollo, etc.
Aunque las factoras de software tengan aspectos en comn no son, ni mucho menos iguales, por lo que el grado de automatizacin ser diferente y la cultura de gestin de los procesos internos diferir. En el siguiente grfico se muestra el grado de dificultad en la implantacin de cada uno de los procesos en base a la experiencia real en PYMEs.
Pgina 66
Grfico 4: Grado de dificultad en la implantacin de los procesos.
Pgina 67
ANEXOS
ANEXO 1. AUTOMATIZACIN DE LOS PROCESOS
Como se ha ido perfilando a lo largo de esta gua cuanto ms automatizado est el proceso de gestin y ms 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 leccin: las empresas deben orientar sus esfuerzos al uso de software para la gestin de sus procesos de desarrollo de software. La prioridad y los plazos debern siempre estar determinados por las necesidades de la organizacin.
Las herramientas ms prioritarias son aquellas que inciden en los procesos nucleares del modelo:
Herramienta de control de versiones Herramienta de control de acceso a la documentacin Herramienta de control de errores / requisitos Herramienta de control y agrupamiento de mtricas (partes de hora, etc.) Herramientas de seguimiento de incidencias (similar a la de errores, pero para la trazabilidad de requisitos y variaciones de la lnea base) Herramienta de log de actividades (principalmente para gestin de la configuracin)
Sin menoscabo de otras herramientas sujetas a licencia tan vlidas como cualquier otra, en la siguiente tabla se muestran soluciones de cdigo abierto. Se han utilizado los siguientes criterios: Funcionalidades, Facilidad de integracin con otras aplicaciones, facilidad de uso y puesta en produccin.
Pgina 68
Grfico 5: Listado de aplicaciones de soporte a los procesos.
Esta relacin de aplicaciones no es nica y puede ampliarse con otras existentes en el mercado.
Pgina 69
ANEXO 2. ESTRUCTURA DOCUMENTAL
El siguiente diagrama muestra la jerarqua documental habitual que se genera cuando se disean, documentan e implantan los diez procesos. Esta representacin es solo una propuesta y cada empresa puede establecer su estructura y tipologa de documentos como considere ms oportuno:
Grfico 6: Ejemplo de estructura documental.
Estos documentos son; Poltica de Calidad de Desarrollo de Software Documento estratgico de la compaa que define los principios bsicos que rigen la calidad de desarrollo de software Polticas Organizativas
Pgina 70
Documento descriptivo de la Organizacin interna, los procesos de calidad implantados en la organizacin y sus relaciones, responsabilidades y funciones implicadas. Definicin de los Procesos Documento recoge las polticas, responsabilidades y enfoque de los diferentes procesos de calidad que sern evaluados segn ISO/IEC 15504. Vinculados a este documento maestro se formalizan las actividades y tareas requeridas por cada uno de los diferentes procesos de calidad que sern evaluados segn ISO/IEC 15504. Se referencia a documentos ms tcnicos, herramientas informticas, plantillas y formatos de trabajo. Formatos, plantillas y herramientas Formularios, tablas y aplicaciones informticas en los que registran los datos y acciones establecidas en los documentos anteriores y que dan evidencia de la implantacin efectiva de los procesos de calidad de desarrollo software.
Para la elaboracin de estos documentos se ha considerado la Norma ISO/IEC 15504, que contiene todos los atributos de determinacin del nivel de capacidad, proceso a proceso, y de forma agrupada el nivel de madurez de la Organizacin y la Norma ISO/IEC 122007, que contiene todos los procesos agrupados.
Pgina 71
ANEXO 3. BIBLIOGRAFA
Publicaciones de normas: [1] ISO/IEC TR 15504-7:2008 Information technology -- Process assessment -- Part 7: Assessment of organizational maturity. 2008. [2] ISO/IEC 12207:2008. Systems and software engineering - Software life cycle processes. 2008. [3] ISO/IEC 15504-2:2003, Information technology Process assessment Part 2: Performing an assessment. 2004. Otras Publicaciones: [1] INTECO. Estudio sobre la certificacin de la calidad como medio para impulsar la industria de desarrollo del software en Espaa; 2008. [2] INTECO. Estudio sobre metodologas y herramientas empleadas en los proyectos de software en Espaa y su repercusin sobre la calidad de los productos y servicios finales. 2008. [3] INTECO. Estudio sobre el modelo de factoras de software con un enfoque nearshore. 2009. [4] Dintel. Epoca II n 5. Proyecto ISO 15504 SPICE: mejora de la calidad de los procesos software. Carlos Manuel Fernndez, gerente TIC AENOR. 122-123 Febrero 2010 (http://www.iso15504.es/attachments/fernandez.pdf) [6] Piattini M, Garzs J. Fbricas de software: Experiencias, tecnologas y organizacin. 2 edicin: Ra-ma; 2010. [7] UNE n 242. Calidad y madurez en el desarrollo del software. Octubre 2009 (http://www.iso15504.es/attachments/110_une242.pdf).
Pgina 72

Guia de Implantacion Del Nivel 2 de Spice en Pymes

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Guia de Implantacion Del Nivel 2 de Spice en Pymes

Transféré par

Droits d'auteur :

Formats disponibles

GUA DE IMPLANTACIN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE

OBJETO DE ESTA GUA

Grfico 2: Descripcin de los componentes de un proceso.

formularios) estn definidos, controlados, versionados y actualizados en caso de ser necesario.

1. Proceso de GESTIN DEL MODELO DE CICLO DE VIDA

1.2. Resultados esperados de una implantacin exitosa del proceso

1.3 Propuesta de aplicacin en la PYME

ENTRADAS Tipologa de proyectos Organigrama funcional

SALIDAS Documento de Ciclo de Vida

1.4 Observaciones prcticas para la PYME

Este proceso tiene una baja dificultad de implantacin.

2.2. Resultados esperados de una implantacin exitosa del proceso

2.3. Propuesta de aplicacin en la PYME

Elaboracin de la oferta sobre la base de plantillas corporativas.

Registrar modificaciones a la oferta inicial, creando nuevas versiones de la propuesta.

- Desarrollo de negocio/rea Comercial: responsable del logro de oportunidades comerciales.

ENTRADAS Solicitud de oferta Peticiones de modificacin

2.4. Observaciones prcticas para la implantacin del proceso en la PYME

Este proceso tiene una baja dificultad de implantacin.

trate, en ocasiones el mismo registro de la entrega es, adems, el registro de aceptacin.

3. Proceso de DEFINICIN DE REQUISITOS DE LAS PARTES INTERESADAS

3.2. Resultados esperados de una implantacin exitosa del proceso

3.3. Propuesta de aplicacin en la PYME

ENTRADAS Oferta aprobada Listado de requisitos funcionales y no funcionales

SALIDAS Documento de Catlogo de requisitos Actas/correos electrnicos de las

reuniones de toma de requisitos con el cliente

Peticiones de modificacin de requisitos

2.4. Observaciones prcticas para la implantacin del proceso en la PYME

Este proceso tiene una dificultad media de implantacin.

4. Proceso de ANLISIS DE LOS REQUISITOS DEL SISTEMA

4.3. Propuesta de aplicacin en la PYME

documento de anlisis ser trasladado al equipo de desarrollo para el inicio de la codificacin.

ENTRADAS Catlogo de requisitos

SALIDAS Documento de Anlisis Funcional de los requisitos

Peticiones de modificacin de requisitos

4.4. Observaciones prcticas para la implantacin del proceso en la PYME

Este proceso tiene una dificultad media de implantacin.

5. Proceso de PLANIFICACIN DEL PROYECTO

5.2. Resultados esperados de una implantacin exitosa del proceso

5.3. Propuesta de aplicacin en la PYME:

5.4. Observaciones prcticas para la PYME

Este proceso tiene una dificultad media de implantacin.

6. Proceso de EVALUACIN Y CONTROL DE PROYECTOS

6.2. Resultados Esperados de una implantacin exitosa del proceso

6.3. Propuesta de aplicacin en la PYME

- Operaciones: responsable de la gestin y desarrollo del proyecto.

ENTRADAS Plan de Proyecto Peticiones del cliente

6.4. Observaciones prcticas para la PYME

Este proceso tiene un grado de implantacin alto.

7. Proceso de GESTIN DE LA CONFIGURACIN

7.2. Resultados Esperados de una implantacin exitosa del proceso

7.3. Propuesta de aplicacin en la PYME

Respecto a los recursos, las organizaciones debera contar, al menos, con:

Red corporativa / aplicacin de gestin de la documentacin, de proyectos o similar.

7.4. Observaciones prcticas para la PYME

Este proceso tiene un grado de implantacin medio.

8. Proceso de GESTIN DE LA CONFIGURACIN DEL SOFTWARE

8.2. Resultados Esperados de una implantacin exitosa del proceso

8.3. Propuesta de aplicacin en la PYME

8.4. Observaciones prcticas para la PYME

Este proceso tiene un grado de implantacin medio-alto.

9.2. Resultados Esperados de una implantacin exitosa del proceso

9.3. Propuesta de aplicacin en la PYME

ENTRADAS Objetivos de negocio y necesidades de informacin