Guia de Implantacion Del Nivel 2 de Spice en Pymes

7/31/2019 Guia de Implantacion Del Nivel 2 de Spice en Pymes

1/72

GUA DE IMPLANTACIN DEL MODELO DEPROCESOS DE CALIDAD DEL DESARROLLO DE

SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICEEN LAS PYMES


2/72

GUA DE IMPLANTACIN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DESOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES

Pgina 2

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 - .

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.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




4. Proceso de ANLISIS DE LOS REQUISITOS DEL SISTEMA ........................................................ 30

4.1. Objetivo ................................................................................................................................ 30




5. Proceso de PLANIFICACIN DEL PROYECTO ........................................................................... 355.1. Objetivo ................................................................................................................................ 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



3/72


Pgina 3




7. Proceso de GESTIN DE LA CONFIGURACIN ........................................................................ 45

7.1. Objetivo ................................................................................................................................ 45




8. Proceso de GESTIN DE LA CONFIGURACIN DEL SOFTWARE .............................................. 50

8.1. Objetivo ................................................................................................................................ 50



8.4. Observaciones prcticas para la PYME ................................................................................ 539. Proceso de MEDICIN ............................................................................................................. 55

9.1. Objetivo ................................................................................................................................ 55



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


4/72


Pgina 4



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.


5/72


Pgina 5



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


6/72


Pgina 6



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.


7/72


Pgina 7



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 lanormativa 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.


8/72


Pgina 8



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 otareas 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.


9/72


Pgina 9



2) para superar con xito la auditora de certificacin de nivel 2 segn el modelode evaluacin de AENOR, la norma con la que se realiza la evaluacin. ISO/IEC

15504, conocida como SPICE requiere que cualquier organizacin pueda darevidencia de la implantacin efectiva de los procesos, esto es:

a. Los procesos se lleven a cabo y se consigan todos sus objetivosdeterminados.

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 demedicin 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 delos 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 lasdesviaciones 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


10/72


Pgina10



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 aplicarsea 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.


11/72


Pgina11



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 procesosque 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.


12/72


Pgina12



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.


13/72


Pgina13



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 documentala secuencia de

tareas que debern realizarse desde el inicio al cierre de los proyectos, los diferentes

participantes, responsables, documentacin aplicable, y los entregables que serngenerados.

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, losdiferentes 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:


14/72


Pgina14



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 funcionamientoproductivo 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 elciclo de vida de desarrollo de la compaa

- Resto de la organizacin: aplicar las actividades definidas en el documento ynotificar posibles mejoras al mismo.

Las entradas y las salidas mnimas de este proceso se resumen en la siguiente tabla:

ENTRADAS SALIDAS

Tipologa de proyectos Documento de Ciclo de Vida

Organigrama funcional

Con relacin a los recursos, las organizaciones debera contar, al menos, con los

siguientes:


15/72


Pgina15



- 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 dedocumentos o procesos que aplican en cada una de las etapas definidas.

- La finalidad del Ciclo de Vida del Software es recoger formalmente la secuenciade 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 larealidad 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.


16/72


Pgina16



Grfico 3: Ejemplo del Ciclo de Vida de Desarrollo del Software para un proyecto genrico.


17/72


Pgina17



2. Proceso de SUMINISTRO


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.





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.


18/72


Pgina18



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.


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


19/72


Pgina19



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 clienteconfirmando la aceptacin de la entrega.


20/72


Pgina20





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

- Operaciones: responsable de la elaboracin de la propuesta y validacin delcontenido 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 lapropuesta 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 SALIDAS

Solicitud de oferta Registro de la solicitud de oferta

Peticiones de modificacin Documentos de oferta almacenados

Si procede, documentos de acuerdos de

confidencialidad almacenados en

repositorio del proyecto

Registro de solicitudes de revisin de la


21/72


Pgina21



propuesta inicial mediante actas de

reunin y/o correos electrnicos.

Registro de las revisiones de la ofertamediante 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


22/72


Pgina22



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, lagestin 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 ensu 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 segeneran 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 implicala aceptacin formal por parte del cliente. Solo cuando el producto entregado

sea el correcto y cumpla con los requisitos establecidos, se podr requerir elregistro formal de aceptacin. En funcin del cliente y del proyecto que se


23/72


Pgina23



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 deberrecopilar 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 mtodoformalizado 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.


24/72


Pgina24



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.


25/72


Pgina25




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.


26/72


Pgina26



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 estincluido 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.



- Desarrollo de negocio/rea Comercial: responsable del cierre del catlogo derequisitos con el cliente.

- Operaciones: responsable de definir con detalle el catlogo de todos losrequisitos (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.



27/72


Pgina27



ENTRADAS SALIDAS

Oferta aprobada Documento de Catlogo de requisitos

Listado de requisitos funcionales y nofuncionales

Actas/correos electrnicos de lasreuniones 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, quepermitira identificar deficiencias en la identificacin y definicin de requisitos por

parte del equipo de proyecto de desarrollo de software.


28/72


Pgina28







- Este proceso tiene una dificultad media de implantacin.

- Es prctica habitual en las PYMEs que el contenido de la oferta se utilice comoun 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 lasactividades 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 lavida 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 requisitosfuncionales y no funcionales. Por requisitos funcionales se entiende a aquellos

que especifican los criterios que se deben utilizar para juzgar el funcionamiento


29/72


Pgina29



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. Unabuena 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 unaimplantacin 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.


30/72


Pgina30



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.



implantado correctamente siempre y cuando la organizacin muestre evidenciasobjetivas 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.


31/72


Pgina31



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 secolocan 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 losrequisitos 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


32/72


Pgina32



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)



- Operaciones: responsable de elaborar y mantener el documento de anlisis derequisitos del proyecto.


ENTRADAS SALIDAS

Catlogo de requisitos 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 requisitosPlantilla de peticiones de cambio.


33/72


Pgina33



Tcnicas de entrevistas y reuniones si fuese necesario

Tcnicas de para la representacin de modelos de datos (diagramas Entidad-

Relacin) si fuese necesarioTcnicas 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.





- Este proceso tiene una dificultad media de implantacin.

- 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


34/72


Pgina34



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 yse 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 deelaboracin 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.


35/72


Pgina35



5. Proceso de PLANIFICACIN DEL PROYECTO


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.


36/72


Pgina36





5.3. Propuesta de aplicacin en la PYME:


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


37/72


Pgina37



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 normalizadapodr 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 comunicacincon 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.



38/72


Pgina38



ENTRADAS SALIDAS

Oferta aprobada Documento de Plan de Proyecto

Listado de requisitos (funcionales y nofuncionales)

Acta de reunin/correo electrnicoasignacin responsables de proyecto

Listado de proyectos vivos y grado de

ocupacin del personal

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




- Este proceso tiene una dificultad media de implantacin.- 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.


39/72


Pgina39



- Tampoco se procede a formalizar internamente los arranques de los proyectoscon las personas que participarn en su desarrollo.

- El objetivo que condiciona el xito de la implantacin de este proceso es contarcon 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 delProyecto (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.


40/72


Pgina40



6. Proceso de EVALUACIN Y CONTROL DE PROYECTOS


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.

Los anteriores objetivos aplican a cualquier proyecto de desarrollo o mantenimientode software acometido en la organizacin.


41/72


Pgina41





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.


42/72


Pgina42



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 estasmodificaciones 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 SALIDASPlan de Proyecto Informes de Seguimiento y Control

Peticiones del cliente Planes de proyecto actualizados

Registro de conclusiones de la reunin de

seguimiento del proyecto

Informe de cierre del proyecto


43/72


Pgina43



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.

6.4. Observaciones prcticas para la PYME




- Este proceso tiene un grado de implantacin alto.

- En general las compaas llevan a cabo un seguimiento no formalizado niestructurado 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


44/72


Pgina44


internacional ISO/IEC 15504 utilizando l

Guia de Implantacion Del Nivel 2 de Spice en Pymes

Documents

Transcript of Guia de Implantacion Del Nivel 2 de Spice en Pymes