3. Metodologías de Gestión de Proyectos

DEPARTAMENTO DE ORGANIZACIN INDUSTRIAL Y GESTIN DE EMPRESAS ESCUELA SUPERIOR DE INGENIEROS DE LA UNIVERSIDAD DE SEVILLA

MTODOS Y TCNICAS PARA LA GESTIN DE PROYECTOS SOFTWARE Pgina 30

3. METODOLOGAS DE GESTIN DE PROYECTOS

3.1. Introduccin

En este captulo describiremos las metodologas ms importantes y difundidas en la gestin de

proyecto, siempre con un enfoque hacia la gestin de los proyectos software.

La Metodologa, (del griego met "ms all", ods "camino" y logos "estudio"), hace referencia

al conjunto de procedimientos basados en principios lgicos, utilizados para alcanzar una gama

de objetivos que rigen en una investigacin cientfica o en una exposicin doctrinal.

En el mbito de la gestin de proyectos, podemos definir una metodologa como un conjunto

de tcnicas, recomendaciones y verificaciones, que permitan sistematizar los procesos en los

que se descompone la gestin de un proyecto.

El uso de una metodologa puede aportar muchas ventajas a la gestin de un proyecto, como

pueden ser:

Facilitar la tarea de planificacin.

Facilitar la tarea del control y seguimiento de un proyecto.

Mejorar la relacin coste/beneficio.

Optimizar el uso de recursos disponibles.

Facilitar la evaluacin de resultados y el cumplimiento de los objetivos.

Facilitar la comunicacin efectiva entre los interesados del proyecto.

Optimizar las fases del proceso de desarrollo.

Facilitar el mantenimiento del producto final.

Permitir la reutilizacin de partes del producto.

Garanta de un nivel de calidad en el producto final.

Ayudar en el cumplimiento de los plazos de tiempo fijados en la definicin del

proyecto.

Definir el ciclo de vida que ms se ajuste a las condiciones y caractersticas del

desarrollo.

Segn la filosofa de desarrollo, las metodologas se pueden clasificar en dos grupos, las

metodologas tradicionales, que se basan en una fuerte planificacin durante todo el

desarrollo y un ciclo de vida ms tradicional, y las metodologas giles, en las que el desarrollo

de software es incremental, cooperativo, sencillo y adaptado.

Las metodologas tradicionales son denominadas, como metodologas pesadas. Centran su

atencin en llevar una documentacin exhaustiva de todo el proyecto y en cumplir con un plan

de proyecto, definido en la fase inicial del desarrollo del proyecto. Otra de las caractersticas

ms importantes dentro de este enfoque, son los altos costes al implementar un cambio y la

falta de flexibilidad. Las metodologas tradicionales se focalizan en la documentacin,

planificacin y procesos (plantillas, tcnicas de administracin, revisiones, etc.).



Las metodologas giles nacen como respuesta a los problemas que puedan ocasionar las

metodologas tradicionales y se basa en dos aspectos fundamentales, retrasar las decisiones y

la planificacin adaptativa. Destacan en la adaptabilidad de los procesos de desarrollo. Estas

metodologas destacan que la capacidad de respuesta a un cambio es ms importante que el

seguimiento estricto de un plan.

A continuacin en este captulo, repasaremos las siguientes metodologas:

METODOLOGAS TRADICIONALES METODOLOGAS GILES

MTRICA V3 Extreme-Programming XP PRINCE2 Scrum SSADM Crystal Methodologies MERISE Adaptive Software Development Feature-Driven Development (FDD) Dynamic Systems Development Method (DSDM) Lean software development Tabla 4 Metodologas

3.2. Metodologas tradicionales

3.2.1. MTRICA V3

3.2.1.1. Introduccin

MTRICA [35] es una metodologa de planificacin, desarrollo y mantenimiento de sistemas de

informacin, promovida por el Ministerio de Administraciones Pblicas del Gobierno de

Espaa para la sistematizacin de actividades del ciclo de vida de los proyectos software en el

mbito de las administraciones pblicas.

Esta metodologa propia est basada en el modelo de procesos del ciclo de vida de desarrollo

ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) as como en la norma

ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability

Determination).

Se han ido desarrollando diferentes versiones, siendo la V3 la ms reciente:

En 1989 apareci la primera versin de Mtrica V.1: Guas metodolgicas que

explicaba paso a paso todas las actividades a realizar para lograr el producto deseado,

en un tiempo y costes aceptados y con una definicin de las personas participantes.

En 1993, se public Mtrica V.2: Gua tcnica, de referencia y de usuario, que

rpidamente fue sustituida por la V.2.1 en julio de 1995 que inclua 5 fases bien

estructuradas que permita una mayor facilidad para el soporte de los cambios futuros

del sistema.



En julio del 2001 se liber la V.3 en la que se han tenido en cuenta las diferentes

tecnologas actuales (cliente/servidor, orientacin a objetos, reutilizacin, etc.). Esta

versin aporta un conjunto de procesos (definidos en la metodologa como interfaces)

orientados a la organizacin y como apoyo al propio proceso de desarrollo. Entre los

interfaces destaca uno especfico para la gestin de los proyectos y que se estudia ms

en detalle.

Las razones ms relevantes para hacer uso de Mtrica son:

Mtrica favorece la implantacin de una orientacin a procesos en las organizaciones.

De esa forma se identifican claramente las actividades a realizar, los elementos

necesarios como inputs o entradas a esa actividad y los resultados o salidas a obtener

Todo ello facilita la normalizacin de procesos en la organizacin

Y la puesta en marcha de acciones de mejora continua.

En definitiva, ayuda a mejorar la productividad y la calidad de los servicios.

3.2.1.2. Descripcin

La metodologa MTRICA V3 tiene un enfoque orientado al proceso y descompone cada uno

de los mismos en actividades, y stas a su vez en tareas. Para cada tarea se describe su

contenido haciendo referencia a sus principales acciones, productos, tcnicas, prcticas y

participantes.

As los procesos de la estructura principal de MTRICA V3 son los siguientes:

Planificacin de Sistemas de Informacin (PSI)

Desarrollo de Sistemas de Informacin (EVS, ASI, DSI, CSI, IAS)

Mantenimiento de Sistemas de Informacin (MSI)

Tambin incluye un conjunto de interfaces que definen una serie de actividades de tipo

organizativo o de soporte al proceso de desarrollo y a los productos, que se debern aplicar

como apoyo a la ejecucin de los procesos principales de la metodologa y para complementar

y garantizar el xito del proyecto

Las interfaces incluidas en la metodologa son:

Gestin de Proyectos (GP)

Seguridad (SEG)

Aseguramiento de la Calidad (CAL)

Gestin de la Configuracin (GC)


MTODOS Y TCNICAS PAR

Tabla 5 Procesos Mtrica V3

Tabla 6 Interfaces Mtrica V3

A continuacin se describirn cada uno de los procesos:

Figura 1 Procesos Mtrica V3

PSI. Planificacin de Sistemas de Informacin:

Objetivo:

Tiene como objetivo p

Sistemas de Informacin de un determinado mbito de la organizacin.

Desarrollo:

Estudio de las necesidades de infor

organizacin afectados por el Plan de Sistemas, con el fin de definir los

requisitos generales y obtener modelos conceptuales de informacin.

Planificacin de Sistemas de Informacin

PSI

Gestin de Proyectos

GP

Seguridad

SEG


MTODOS Y TCNICAS PARA LA GESTIN DE PROYECTOS SOFTWARE

A continuacin se describirn cada uno de los procesos:

Planificacin de Sistemas de Informacin:

Tiene como objetivo proporcionar un marco estratgico de referencia para los


Estudio de las necesidades de informacin de los procesos de la



ProcesosDesarrollo de Sistemas de Informacin

EVS (Estudio de la Viabilidad del Sistema)

ASI (Anlisis del Sistema de Informacin)

DSI (Diseo del Sistema de Informacin)

CSI (Construccin del Sistema de Informacin)

IAS (Implantacin y Aceptacin del Sistema)

Mantenimiento de Sistemas de Informacin

MSI

InterfacesSeguridad

SEG

Aseguramiento de la calidad

CAL

Gestin de la Configuracin

GC


Pgina 33

roporcionar un marco estratgico de referencia para los


macin de los procesos de la



Mantenimiento de Sistemas de

Gestin de la Configuracin



Evaluacin de las opciones tecnolgicas y propuesta de un entorno.

Anlisis de las prioridades relacionadas con las distintas variables que

afectan a los Sistemas de Informacin.

Elaboracin de un calendario de proyectos con una planificacin lo

ms detallada posible de los ms inmediatos.

Desarrollo de una sistemtica para mantener actualizado el Plan de

Sistemas de Informacin para incluir en l todos los cambios

necesarios.

Resultados:

Orientar las actuaciones en materia de Desarrollo de Sistemas de

Informacin con el objetivo bsico de apoyar la estrategia corporativa,

elaborando una arquitectura de informacin y un plan de proyectos

informticos para dar apoyo a los objetivos estratgicos.

EVS. Estudio de la Viabilidad del Sistema:

Objetivo:

Anlisis de un conjunto concreto de necesidades para proponer una

solucin a corto plazo, que tenga en cuenta restricciones econmicas,

tcnicas, legales y operativas.

Desarrollo:

Se propondrn diferentes alternativas, que deben ser valoradas (se

estudiar el impacto en la organizacin de cada una de ellas, la

inversin y los riesgos asociados) para determinar una nica solucin.

Los criterios con los que se valoran las propuestas no sern

estratgicos sino tcticos y relacionados con aspectos econmicos,

tcnicos, legales y operativos.

Resultados:

En este proceso se decide si continuar con el desarrollo de la solucin

adoptada o abandonar, despus de valorar su impacto en la

organizacin, el presupuesto necesario y los riesgos que conlleva.

Como productos relacionados con la solucin adoptada se obtiene el

contexto del sistema , el impacto en la organizacin, el coste/beneficio

de la solucin, la valoracin de riesgos, el plan de trabajo, la

planificacin y la solucin propuesta.

ASI. Anlisis del Sistema de Informacin:

Objetivo:

Conseguir la especificacin detallada del Sistema de Informacin, a

travs de un catlogo de requisitos y una serie de modelos que cubran

las necesidades de informacin de los usuarios para los que se

desarrollar el sistema de informacin y que sern la entrada para el

proceso de Diseo del Sistema de Informacin.



Desarrollo:

En primer lugar se describe inicialmente el Sistema de Informacin. Se

delimita su alcance, se genera un catlogo de requisitos generales y se

describe el sistema mediante unos modelos iniciales de alto nivel.

Se recogen de forma detallada los requisitos funcionales que el

Sistema de Informacin debe cubrir, catalogndolos. Adems, se

identifican los requisitos no funcionales del sistema (las facilidades

que ha de proporcionar el sistema, y las restricciones en cuanto a

rendimiento, frecuencia de tratamiento, seguridad, etc.).

Se identifican los subsistemas de anlisis, y se elaboran los modelos de

Casos de Uso y de Clases, en desarrollos orientados a objetos, y de

Datos y Procesos en desarrollos estructurados.

Finalizados los modelos, se realiza un anlisis de consistencia que

puede forzar la modificacin de algunos de los modelos obtenidos y,

posteriormente, se elabora el producto Especificacin de Requisitos

Software.

Se inicia la especificacin del Plan de Pruebas, que se completar en el

proceso Diseo del Sistema de Informacin (DSI).

Resultados:

Se obtiene el catlogo de requisitos del sistema a implementar, as

como los estndares y normas a tener en cuenta, la descripcin

general del entorno tecnolgico y la especificacin de la interfaz de

usuario.

Si el sistema a desarrollar sigue un enfoque Estructurado, adems hay

que aadir el plan de migracin y carga inicial de datos, el contexto del

sistema, la matriz de procesos/localizacin geogrfica, la descripcin

de interfaz con otros sistemas, el modelo de procesos y modelo lgico

de datos normalizado.

Si se sigue un enfoque Orientado a Objetos, hay que aadir la

descripcin de subsistemas de anlisis, la descripcin de interfaces

entre subsistemas, el modelo de clases de anlisis, el comportamiento

de clases de anlisis y el anlisis de la realizacin de los casos de uso.

DSI. Diseo del Sistema de Informacin:

Objetivo:

Definir la arquitectura del sistema y el entorno tecnolgico que le va a

dar soporte, junto con la especificacin detallada de los componentes

del Sistema de Informacin.



Desarrollo:

Las actividades de este proceso se agrupan en dos grandes bloques:

En un primer bloque se obtiene el diseo de detalle del

Sistema de Informacin que comprende la particin fsica,

independiente de un entorno tecnolgico concreto, la

organizacin en subsistemas de diseo, la especificacin del

entorno tecnolgico sobre el que se despliegan dichos

subsistemas y la definicin de los requisitos de operacin,

administracin del sistema, seguridad y control de acceso.

El segundo bloque complementa el diseo del Sistema de

Informacin y en l se generan todas las especificaciones

necesarias para la construccin del Sistema.

Resultados:

Especificaciones de construccin relativas al propio sistema, la

descripcin tcnica del plan de pruebas, la definicin de los requisitos

de implantacin y el diseo de los procedimientos de migracin y

carga inicial, si procede.

CSI. Construccin del Sistema de Informacin:

Objetivo:

Construccin y prueba de los distintos componentes del Sistema de

Informacin, a partir del conjunto de especificaciones lgicas y fsicas

del mismo, obtenido en el Proceso de Diseo del Sistema de

Informacin (DSI). Se desarrollan los procedimientos de operacin y

seguridad, y se elaboran los manuales del usuario final y de

explotacin.

Desarrollo:

En este proceso se genera el cdigo de los componentes del Sistema

de Informacin, se desarrollan todos los procedimientos de operacin

y seguridad y se elaboran todos los manuales de usuario final y de

explotacin.

Adems se realizan los siguientes conjuntos de pruebas:

Pruebas unitarias.

Pruebas de integracin de los subsistemas.

Pruebas del sistema.

Asimismo, se define la formacin de usuario final y, si procede, se

construyen los procedimientos de migracin y carga inicial de datos.

Resultados:

Cdigo fuente de los componentes desarrollados, as como los

procedimientos de operacin y administracin del sistema y los

procedimientos de seguridad y control de acceso.

Por otra parte se elaboran los manuales de usuario y la especificacin

de la formacin a usuarios finales, adems de los productos

correspondientes al proceso de migracin y carga inicial de datos.



IAS. Implantacin y Aceptacin del Sistema:

Objetivo:

Este proceso tiene como objetivo principal la entrega y aceptacin del

sistema en su totalidad, y la realizacin de todas las actividades

necesarias para su paso a produccin.

Desarrollo:

Revisin de la estrategia de implantacin determinada en el Estudio de

Viabilidad del Sistema (EVS).

Preparacin de la infraestructura necesaria, la instalacin de los

componentes, la activacin de los procedimientos manuales y

automticos asociados y la migracin o carga inicial de datos.

Realizacin de las pruebas de implantacin por parte del usuario de

operacin y de las pruebas de aceptacin por parte del usuario final.

Determinar los servicios que requiere el sistema que se va a implantar

una vez que se inicie la puesta en produccin y al nivel con el que se

prestarn dichos servicios.

Resultados:

Plan de implantacin del sistema en su totalidad, el equipo de

implantacin, el plan de formacin del equipo de implantacin

(esquema, materiales, recursos necesarios, planificacin y

especificacin de la formacin de usuarios finales), la evaluacin de las

pruebas de implantacin del sistema y de las pruebas de aceptacin

del sistema, el plan de mantenimiento previo al paso a produccin, el

acuerdo de nivel de servicio del sistema y el Sistema en produccin.

MSI. Mantenimiento del Sistema de Informacin:

Objetivo:

Obtencin de una nueva versin del sistema de informacin, a partir

de las peticiones de mantenimiento que los usuarios realizan con

motivo de un problema detectado en el sistema o por la necesidad de

una mejora del mismo.

Desarrollo:

Ante una peticin de cambio de un sistema de informacin ya en

produccin, se realiza un registro de las peticiones, se diagnostica el

tipo de mantenimiento y se decide si se le da respuesta o no, en

funcin del plan de mantenimiento asociado al sistema afectado por la

peticin, y se establece con qu prioridad.

La definicin de la solucin al problema o necesidad planteada por el

usuario que realiza el responsable de mantenimiento, incluye un

estudio del impacto, la valoracin del esfuerzo y coste, las actividades

y tareas del proceso de desarrollo a realizar y el plan de pruebas de

regresin.



Resultados:

Catlogo de peticiones de cambio, el resultado del estudio de la

peticin, la propuesta de solucin, el anlisis de impacto de los

cambios, el plan de accin para la modificacin, el plan de pruebas de

regresin, la evaluacin del cambio y la evaluacin del resultado de las

pruebas de regresin.

MTRICA V3 proporciona cuatro interfaces que definen actividades orientadas a la mejora y

perfeccionamiento de los procesos principales con el fin de garantizar la consecucin del

objetivo del desarrollo

Contempla el siguiente conjunto de interfaces:

GP. Gestin de Proyectos

La Gestin de Proyectos tiene como finalidad principal la planificacin, el

seguimiento y control de las actividades y de los recursos humanos y

materiales que intervienen en el desarrollo de un Sistema de Informacin.

Se estructura en 3 grupos de actividades fundamentales:

Inicio del proyecto (GPI): Una vez concluido el esfuerzo del estudio de

viabilidad del sistema, se realizarn las actividades de estimacin del

esfuerzo y planificacin del proyecto

Seguimiento y Control del Proyecto (GPS): Comprende la asignacin de

tareas, la gestin de las incidencias, los cambios de requisitos que

puedan presentarse y afectar a la planificacin del proyecto. El

seguimiento y Control se realiza durante los procesos de desarrollo del

proyecto (anlisis, diseo, construccin, implantacin y aceptacin del

sistema de informacin) con el objeto de vigilar el correcto desarrollo

de las tareas planificadas.

Finalizacin del proyecto (GPF): Realiza las tareas propias de cierre del

proyecto.

SEG. Seguridad

El objetivo de la interfaz de Seguridad es incorporar en los sistemas de

informacin mecanismos de seguridad adicionales a los que se proponen en la

propia metodologa, asegurando el desarrollo de cualquier tipo de sistema a lo

largo de los procesos que se realicen para su obtencin

La interfaz de Seguridad hace posible incorporar durante la fase de desarrollo

las funciones y mecanismos que refuerzan la seguridad del nuevo sistema y del

propio proceso de desarrollo, asegurando su consistencia y seguridad

CAL. Aseguramiento de la Calidad

El objetivo es proporcionar un marco comn de referencia para la definicin y

puesta en marcha de planes especficos de aseguramiento de calidad

aplicables a proyectos concretos.



Las actividades estn orientadas a verificar la calidad de los procesos y

productos. Son actividades que evalan la calidad y que son realizadas por un

grupo de Garanta de la Calidad independiente de los responsables de la

obtencin de los productos.

GC. Gestin de la Configuracin

El objetivo de la gestin de la configuracin es mantener la integridad de los

productos que se obtienen a lo largo del desarrollo de los sistemas de

informacin, garantizando que no se realizan cambios incontrolados y que

todos los participantes en el desarrollo del sistema disponen de la versin

adecuada de los productos que manejan. As, entre los elementos de

configuracin software, se encuentran no nicamente ejecutables y cdigo

fuente, sino tambin los modelos de datos, modelos de procesos,

especificaciones de requisitos, pruebas, etc.

Se realiza durante todas las actividades asociadas al desarrollo del sistema, y

contina registrando los cambios hasta que ste deja de utilizarse

Facilita el mantenimiento del sistema, aportando informacin para valorar el

impacto de los cambios solicitados y reduciendo el tiempo de implementacin

de un cambio, tanto evolutivo como correctivo. Asimismo, permite controlar el

sistema como producto global a lo largo de su desarrollo, obtener informes

sobre el estado de desarrollo en que se encuentra y reducir el nmero de

errores de adaptacin del sistema, lo que se traduce en un aumento de calidad

del producto, de la satisfaccin del cliente y, en consecuencia, de mejora de la

organizacin.

Para el desarrollo de los proyectos, METRICA V3 utiliza tcnicas ampliamente difundidas y

usadas, como son:

Anlisis coste beneficio

Diagramas UML

Diagramas de Flujo de Datos

Diagrama de Interaccin

Diagramas de paquetes

Diagramas de transicin de estados

Modelado de procesos de la organizacin

Modelo entidad/relacin

Normalizacin y optimizacin

Tcnicas matriciales

Para el interfaz especfico de gestin de los proyectos, Mtrica v.3 aade otras tcnicas como

son:



Estimacin: Usa los mtodos Albrecht y MARKII que es un mtodo evolucionado de

Albrecht, e inventado por Charles Symons. Ambos sirven para medir el tamao

funcional de cualquier aplicacin. MarkII supera los problemas de Albrecht

contemplando el sistema como una coleccin de transacciones lgicas compuestas por

componentes de entrada, de proceso y de salida y que se corresponden con las

funciones del sistema.

WBS (Work Breakdown Structure): Esta tcnica de descomposicin permite

estructurar las actividades sirviendo de lista de comprobacin y de herramienta de

contabilidad analtica del proyecto software. Permite la descomposicin de las

actividades de un proyecto segn su naturaleza en forma de rbol con agrupacin de

actividades en: desarrollo, calidad, gestin, etc. Posteriormente y mediante los

diagramas PERT y GANTT que se deduzcan de dicho rbol, se puede obtener una

planificacin de una forma ms fcil y clara.

PERT (Program Evaluation and Review Technique): Sirve para establecer las

dependencias entre las distintas tareas del proyecto para saber de qu manera han de

encontrarse dichas tareas en la planificacin. Este mtodo parte de la descomposicin

del proyecto en una serie de actividades y estas actividades estn controlados por los

sucesos entendidos stos como acontecimientos o principio o fin de la actividad.

Diagrama de GANTT: Esta tcnica tiene como objetivo la representacin del plan de

trabajo, mostrando las tareas a realizar, el momento de comienzo o fin y la forma en

que las distintas tareas estn unidas entre s. Es la forma clsica de representar el plan

de proyecto.

3.2.2. PRINCE2


PRINCE2 (PRojects IN Controlled Environments) [29], fue desarrollado para el gobierno del

Reino Unido y se utiliza regularmente no solo en el gobierno britnico sino tambin en el

sector privado. Actualmente es el estndar de facto en el Reino Unido.

PRINCE2 es una metodologa estructurada basada en procesos. Ofrece una gua de dominio

pblico para la aplicacin de las mejores prcticas en la gestin de los proyectos.

En 1989 la Agencia Central de Computacin y Telecomunicaciones (CCTA) desarroll la tcnica

PRINCE como un estndar para la gestin de los proyectos de telecomunicaciones del gobierno

del Reino Unido.

En 1996 se liber una versin de PRINCE2 como una metodologa genrica para la gestin de

los proyectos. La ltima versin es la edicin del 2009.



3.2.2.2. Descripcin

PRINCE2 es una metodologa para la gestin de los proy

su vez se componen de 45 subprocesos.

organizacin, y gestin y control de los proyectos.

productos se entreguen en el

La metodologa se puede aplicar a cualquier tipo de proyect

riesgos, el control de la calidad y la eficiencia de los cambios.

Las principales caractersticas de PRINCE2 se centran en el establecimiento de un cic

claro, la definicin y medicin de productos de negocio, el suministro de un conjunto de

actividades para conseguir los productos de negocio ,y el establecimiento de una estructura

organizativa con responsabilidades bien definidas para poder ges

ptima.

PRINCE2 no cubre todos los aspectos de la gestin de los proyectos. Hay ciertos aspectos

propios de la gestin de los proyectos que no estn contemplados en la metodologa como

pueden ser el liderazgo, las habilidades pa

detallada de tcnicas y herramientas propias de la gestin.

PRINCE2 est constituido de Procesos, Componentes y Tcnicas.

Figura 2 Elementos PRINCE2

PRINCE2 se centra en los comp

xito y la finalizacin en plazos y tiempos de los proyectos. La estrategia consiste en construir

procesos para vincular los componentes y reducir los riesgos de los proyectos, al mismo

tiempo que proporciona las tcnicas que los soportan y sugiere un modo efectivo de

organizarlos.

Esta metodologa es una combinacin de ocho procesos, ocho componentes y de tres

tcnicas.

PRINCE2

Componentes



PRINCE2 es una metodologa para la gestin de los proyectos basada en ocho

su vez se componen de 45 subprocesos. La metodologa cubre todos los aspectos de

tin y control de los proyectos. Tiene como objetivo,

se entreguen en el tiempo establecido y con el presupuesto acordado.

metodologa se puede aplicar a cualquier tipo de proyecto, y permite la gestin de los

riesgos, el control de la calidad y la eficiencia de los cambios.

Las principales caractersticas de PRINCE2 se centran en el establecimiento de un cic



organizativa con responsabilidades bien definidas para poder gestionar el proyecto de forma



pueden ser el liderazgo, las habilidades para la gestin de recursos, as como la cobertura

detallada de tcnicas y herramientas propias de la gestin.

st constituido de Procesos, Componentes y Tcnicas.

se centra en los componentes a los que considera fundamentales para la garanta de



ue proporciona las tcnicas que los soportan y sugiere un modo efectivo de

odologa es una combinacin de ocho procesos, ocho componentes y de tres

PRINCE2

Tcnicas

Procesos


Pgina 41

cho procesos que a

a cubre todos los aspectos de

Tiene como objetivo, lograr que los

sto acordado.

o, y permite la gestin de los

Las principales caractersticas de PRINCE2 se centran en el establecimiento de un ciclo de vida



tionar el proyecto de forma



ra la gestin de recursos, as como la cobertura

onentes a los que considera fundamentales para la garanta de



ue proporciona las tcnicas que los soportan y sugiere un modo efectivo de

odologa es una combinacin de ocho procesos, ocho componentes y de tres



Los procesos que se describen son los siguientes:

Figura 3 Procesos PRINCE2

Puesta en marcha del proyecto: Permite un inicio controlado del proyecto. Solo se

realiza al principio del ciclo de vida del proyecto y proporciona una preparacin inicial

para la gestin del resto del proyecto, as como para el control y viabilidad del

proyecto. Este proceso crea la junta del proyecto, y garantiza el acuerdo de las

necesidades de recursos.

Inicio del proyecto: Es otro proceso que solo se realiza una vez durante el ciclo de

vida del proyecto. Sirve para realizar un trazado de cmo se puede gestionar la

totalidad del proyecto, y lo plasma en un contrato, denominado documento de

inicio del proyecto (PID Project Initiation Document). El objetivo de este documento

es el establecimiento de un entendimiento comn de los elementos crticos del

proyecto, as como el acuerdo de la junta del proyecto para la primera etapa de

desarrollo del proyecto.

Direccin del proyecto: Dirige todo el proyecto y define las responsabilidades de la

junta del proyecto en la supervisin del mismo. De acuerdo con su posicin en el

diagrama del modelo de procesos, est por encima de todos e interacta con el resto

de procesos. Proporciona los mecanismos para las autorizaciones de aprobacin de

continuidad al final de cada etapa y al cierre del proyecto. Este proceso es el marco de

suministro de entradas, de recepcin de requisitos y para la toma de decisiones. Es el

nico proceso en el que acta la junta del proyecto, ya que el resto de procesos son

conducidos por el director del proyecto y el resto del equipo de proyecto.

Direccin de Proyecto

Puesta en marcha

Planificacin

Inicio

Planificacin

Control de etapa

Gestin de entrega del producto

Gestin de lmites de etapa

Planificacin

Cierre del proyecto



Gestin de los lmites de la etapa: Este proceso ayuda a realizar la transicin de un

estado finalizado al inicio del siguiente estado, al mismo tiempo que permite

garantizar que el trabajo definido en el estado finalizado se ha realizado de acuerdo

con los requisitos establecidos. Tambin proporciona a la junta de proyecto, una

ayuda para garantizar la viabilidad del proyecto, los planes de desarrollo, la

autorizacin de la nueva etapa de trabajo y un archivado de lecciones aprendidas.

Control de etapa: Suministra una gua para la gestin diaria del proyecto. Incluye:

autorizacin y recepcin de trabajos, gestin del cambio y de versiones, anlisis e

informes, consideraciones de viabilidad, acciones correctiva y escalado de incidencias

a la junta de proyecto. Este proceso de control se realiza de forma iterativa por cada

etapa de desarrollo del proyecto.

Gestin de entrega del producto: Forma parte del sistema de autorizacin de

Prince2. Es el mecanismo que sirve para que los ejecutores del trabajo tcnico

acuerden en los trabajos a realizar, los informes de progreso, etc. Se repite por cada

paquete de trabajo autorizado.

Cierre del proyecto: Es el mecanismo que permite la transicin de entrega del

proyecto a la organizacin. Puede finalizar por haber realizado el trabajo

satisfactoriamente o por terminacin prematura, aunque en cualquier caso, se

almacenan las lecciones aprendidas. El proceso permite garantizar que si el cierre es

por finalizacin del trabajo, sta ha sido realizado a satisfaccin del cliente y todos los

productos han sido aceptados por el cliente, as como los acuerdos para el soporte de

los productos del proyecto.

Planificacin: Es el proceso comn para el resto de los procesos de Prince2. Los

planes se producen identificando los entregables del proyecto, las actividades y

recursos necesarios para crearlos, y todo ello, en una relacin consistente con los

requerimientos identificados en el PID.

Y los siguientes componentes:



Figura 4 Componentes PRINCE2

Proceso de Negocio: La principal condicin de control de un proyecto Prince2 es la

existencia de un caso de negocio viable. El caso de negocio se verifica previamente

pro el equipo de proyecto y es el punto principal de decisin del proyecto. El proyecto

debera ser parado si el proyecto no es viable por alguna razn.

Organizacin: Debido a la necesidad de informar desde el staff al resto de la

estructura organizativa, se necesita una supervisin organizativa para asegurar la

coordinacin de todos esos recursos. Adems, es necesario gestionar las decisiones

de validacin e inventariar las entregas a lo largo de la gestin del proyecto. En

PRINCE2 esta supervisin es lo que Prince2 denomina Project Board.

Planes: Los planes suponen la columna vertebral del sistema de informacin que

gestiona el proyecto, y necesitan por lo tanto ser aprobados y aceptados por los

niveles organizativos apropiados. El componente de planes resalta los conceptos

fundamentales del proyecto resultando ser las tareas fundamentales del proceso de

planificacin del modelo de procesos.

Controles: El control se refiere a la toma de decisiones: su propsito es garantizar

que, por una parte el proyecto genera los productos necesarios definidos en los

criterios de aceptacin y por otra parte, que cumple la programacin de acuerdo con

los recursos y costes planificados. Adems, debe garantizar la viabilidad del proceso

de negocio.

Gestin del riesgo: La gestin del riesgo es fundamental dentro de la gestin del

proyecto, y debe realizarse de una manera disciplinada, ya que muchos de los trabajos

de un proyecto no son previsibles.

Proceso de negocio

Organizacin

Planes

Controles

Gestin del riesgo

Calidad en el entorno del

proyecto

Gestin de la configuracin

Control de cambios



Calidad en el entorno del proyecto

consigue la calidad esperada por el c

disciplinado. Los requerimientos de calidad de los entregables se basan en las

descripciones del producto que a su vez son preparados por el director del proyecto y

aprobados por la junta del proyecto.

Gestin de la configuracin:

gestin del proyecto el control necesario para la validacin del proyecto y es vital para

el sistema de calidad. Este componente suministra los mecanismos para las

cuestiones de trazabi

Control de cambios:

potenciales cambios, su importancia, costes, impacto en el proceso de negocio y la

decisin de poder gestionar su inclusin o no.

PRINCE2 define las siguientes

Figura 5 Tcnicas PRINCE2

Planificacin basada en el producto:

nos ayudan a la definicin de los productos a entregar:

Product breakdown: diagrama de los pro

Product description: descripcin detallada de (los) producto(s).

Product Flor: descripcin de la interrelacin de productos.

Aproximacin al control de cambios:

toda la gerencia del proyecto basada e

ocurra.

Revisiones de la calidad:

y tambin poder buscar nuevos que puedan ser aplicados. Tambin nos ayuda a tener

procedimientos exitosos as como t

elementos y productos a entregar. En esta tcnica tambin involucra la correcta toma

de decisiones del proyecto, la gestin de proveedores y el control de la informacin.



Calidad en el entorno del proyecto: La gestin de la calidad debe garantizar que se

consigue la calidad esperada por el cliente mediante un sistema de calidad



aprobados por la junta del proyecto.

configuracin: La gestin de la configuracin proporciona al equipo de



cuestiones de trazabilidad del proyecto.

Control de cambios: El control de los cambios del alcance calcula el impacto de los


decisin de poder gestionar su inclusin o no.

siguientes tcnicas:

Planificacin basada en el producto: esta tcnica involucra otros tres elementos que

nos ayudan a la definicin de los productos a entregar:

Product breakdown: diagrama de los productos.


Product Flor: descripcin de la interrelacin de productos.

Aproximacin al control de cambios: esta tcnica nos garantiza someter a procesos

toda la gerencia del proyecto basada en tener bajo control cualquier cambio que

Revisiones de la calidad: esta tcnica nos ayuda a revisar los estndares ya existentes


procedimientos exitosos as como tener un acercamiento a revisar cada uno de los



Planificacin

Control de Cambios

Calidad


Pgina 45

: La gestin de la calidad debe garantizar que se

liente mediante un sistema de calidad



La gestin de la configuracin proporciona al equipo de



El control de los cambios del alcance calcula el impacto de los


esta tcnica involucra otros tres elementos que


esta tcnica nos garantiza someter a procesos

n tener bajo control cualquier cambio que

esta tcnica nos ayuda a revisar los estndares ya existentes


ener un acercamiento a revisar cada uno de los





3.2.3. SSADM


SSADM (Structured Systems Analysis and Design Method) [46] es una metodologa de

aproximacin en cascada para el desarrollo de sistemas de informacin y que puede ser

considerada como una de las ms metodologas estructuradas ms completas.

SSADM fue desarrollada inicialmente por Learmonth y Burchett Management Systems (LBMS)

y continuada por el Central Computing and Telecommunications Agency (CCTA) mediante la

adopcin de un mtodo de desarrollo de sistemas de informacin para el uso en los proyectos

del gobierno del Reino Unido.

Se lanz la primera versin en 1981 y en 1983 se convirti en uso obligatorio para el desarrollo

de todos los proyectos nuevos del gobierno de Reino Unido, y en 1988 fue promocionada

como un Standard abierto. En el ao 2000 CCTA renombr SSADM como Business System

Development

Actualmente, es la metodologa estndar de desarrollo de proyectos del gobierno del Reino

Unido.

3.2.3.2. Descripcin

SSADM se basa en 3 vistas fundamentales:

Modelo lgico de datos: Es el proceso de identificar, modelar y documentar los

requerimientos de informacin de un sistema de tecnologa de la informacin. El

modelo lgico de datos consiste en la estructura lgica de datos (LDS) y su

documentacin asociada. LDS representa las entidades y relaciones.

Modelo de flujo de datos: Es el proceso de identificar, modelar y documentar como

fluyen los datos a travs del sistema de informacin. El Modelo de flujo de datos

consiste en un conjunto de diagramas de flujo de datos (DFD) y su documentacin

asociada. Los DFD representan los procesos, entidades externas y flujos de datos.

Modelo de Eventos de entidad: Es el proceso de identificar, modelar y documentar

como los eventos de negocio que afectan a cada entidad y la secuencia en que

ocurren. Un modelo entidad/evento consiste en un conjunto de historia de vida de las

entidades y la correspondiente documentacin. Es decir, este proceso representa el

comportamiento de un sistema dinmico a lo largo del tiempo.

SSADM considera las estructuras de datos con mayor estabilidad que los procesos, y por lo

tanto, los datos forman la columna vertebral de la metodologa. De este modo, SSADM

pertenece a la familia de los mtodos orientado a los datos.



SSADM es una aproximacin top

descomponiendo gradualmente en niveles inferiores. Adems, aplica tcnicas individuales as

como el modo en que se pasa el control de una a otra una vez que la primera ha finalizado su

actividad.

La gestin del proyecto se centra ms en la monitorizacin de la

producto que en la aplicacin de las tcnicas que lo crean.

SSADM consiste en una arquitectura de especificaci

vez tres reas del sistema de informacin:

Capa externa mediante la que l

Diseo interno

Modelo conceptual que representa los requerimientos de negocio y sobre los que se

basa el diseo interno

SSADM cubre las tres fases fundamentales del ciclo de vida del desarrollo software: Estudio de

viabilidad, Anlisis y Diseo, pero no est diseada para realizar la implementacin y el

mantenimiento de las aplicaciones, lo que hace es suministrar la documentacin completa y

precisa para poder mantener el sistema fcilmente.

Tabla 7 Fases ciclo de vida SSADM

Realizando ya un estudio ms detallado, enunciamos a continuacin las diferentes niveles en

los que se descompone la metodologa. En el siguiente grfico se realiza un mapeo con las

fases ms tpicas del ciclo de vida

Viabilidad

Anlisis

Diseo

Implementacin

Mantenimiento



SSADM es una aproximacin top-down donde se representa el esquema de alto nivel y se va

omponiendo gradualmente en niveles inferiores. Adems, aplica tcnicas individuales as


La gestin del proyecto se centra ms en la monitorizacin de la calidad y la completitud de su

producto que en la aplicacin de las tcnicas que lo crean.

SSADM consiste en una arquitectura de especificacin de tres esquemas, considerando a su

reas del sistema de informacin:

Capa externa mediante la que los usuarios interactan con el sistema


basa el diseo interno







fases ms tpicas del ciclo de vida del desarrollo software.

Estudio de la viabilidad

Anlisis de requerimientosViabilidad

Especificacin d elos requerimientos

Especificacin del sistema lgico

Diseo fsico

No la cubreImplementacin

No la cubreMantenimiento


Pgina 47

down donde se representa el esquema de alto nivel y se va

omponiendo gradualmente en niveles inferiores. Adems, aplica tcnicas individuales as


calidad y la completitud de su

n de tres esquemas, considerando a su

os usuarios interactan con el sistema







Especificacin d elos requerimientos




Tabla 8 Niveles SSADM

Nivel 0. Estudio de Viabilidad

Se define el alcance del sistema de informacin propuesto.

Se investigan las diversas opci

Se selecciona una de las opciones realizando un anlisis coste

Bsqueda de riesgos que puedan poner en peligro la viabilidad del proyecto (el

proyecto podra descartarse).

Nivel 1. Investigacin del entorn

siguientes tareas:

Determinacin si el sistema ser uno nuevo o la ampliacin o sustitucin de

uno existente.

Realizacin de un anlisis completo de requerimientos mediante la

modelizacin del sistema act

existentes y las nuevas necesidades.

Deteccin los puntos dbiles que se deben cubrir.

Nivel 2. Opciones de negocio del sistema

siguientes tareas:

Estudio del conjunto de

Definir las soluciones de negocio (no confundir con las tecnolgicas), teniendo

en cuenta los aspectos tcnicos y fsicos.

Nivel 3. Definicin de requerimientos

Transformacin de los

quiere del sistema.

Aplicacin de tcnicas de modelado para pasar de anlisis a diseo.

Estudio de Viabilidad

Anlisis de requerimientos

Especificacin de requerimientos


Diseo



Estudio de Viabilidad: Durante esta fase se realizan las siguientes actividades:

Se define el alcance del sistema de informacin propuesto.

Se investigan las diversas opciones para el desarrollo del proyecto.

Se selecciona una de las opciones realizando un anlisis coste


proyecto podra descartarse).

Investigacin del entorno actual: Durante esta actividad se realizan las


uno existente.


modelizacin del sistema actual con el objeto de extraer los problemas

existentes y las nuevas necesidades.

Deteccin los puntos dbiles que se deben cubrir.

Nivel 2. Opciones de negocio del sistema: Durante esta actividad se realizan las

Estudio del conjunto de requisitos obtenido del nivel anterior.


en cuenta los aspectos tcnicos y fsicos.

Nivel 3. Definicin de requerimientos: Durante esta tarea se realiza:

Transformacin de los requerimientos en las especificaciones de lo que se

quiere del sistema.


Nivel 0. Viabilidad

Nivel 1. Investigacin del entorno actual

Nivel 2. Opciones del sistema de negociorequerimientos

Nivel 3. Definicin de requerimientosEspecificacin de requerimientos

Nivel 4. Opciones tcnicas del sistema

Nivel 5. Diseo Lgico


NIvel 6. Diseo fsico


Pgina 48

: Durante esta fase se realizan las siguientes actividades:

ones para el desarrollo del proyecto.

Se selecciona una de las opciones realizando un anlisis coste-beneficio.


: Durante esta actividad se realizan las



ual con el objeto de extraer los problemas

: Durante esta actividad se realizan las

requisitos obtenido del nivel anterior.


requerimientos en las especificaciones de lo que se


Nivel 1. Investigacin del entorno actual

Nivel 2. Opciones del sistema de negocio

Nivel 3. Definicin de requerimientos

Nivel 4. Opciones tcnicas del sistema



Nivel 4. Opciones tcnicas del sistema:

Se proponen las alternativas tcnicas de implementacin a partir de los

resultados del nivel anterior.

Se especifican las distintas opciones hardware, software y de plataforma de

desarrollo para poder seleccionar la ms adecuada.

Esta tarea se realiza en paralelo con el diseo lgico.

Nivel 5. Diseo lgico:

Se obtiene el proceso de diseo lgico independientemente del entorno

tcnico particular.

El diseo resultante podr ser implementado en diversas plataformas.

Puede ser un modelo de cmo el sistema satisfar los requerimientos del

usuario.

Nivel 6. Diseo fsico:

La informacin obtenida en la fase anterior se utiliza para trasladar al diseo

fsico, el entorno tcnico seleccionado.

Se utilizan tcnicas de seleccin del entorno, ya que SSADM simplemente se

limita a suministrar unas directrices genricas.

En relacin a las tcnicas de representacin, las ms usuales que utiliza SSADM seran las

siguientes:

Diagramas de flujo de datos (DFD): es una representacin grfica del "flujo" de datos

a travs de un sistema de informacin. Un diagrama de flujo de datos tambin se

puede utilizar para la visualizacin de procesamiento de datos.

Figura 6 Diagramas de Flujo de Datos



Diagramas de datos lgicos:

Estructura lgica de datos (LDS): Se basa en el modelo entidad/relacin de

CHEN, en el que se dibuja el diagrama inicial de E/R y se ajusta posteriormente

convirtiendo las relaciones en entidades compuestas e identificando nuevas

relaciones.

Diagramas de entidad / relacin: Se utiliza para representar estructuras de

datos del mundo real.

Diagramas de comportamiento de entidad: se utilizan dos variantes:

Diagramas Historia de vida de entidades (ELH): Representan todo el proceso

de creacin, actualizacin y desaparicin de una entidad a lo largo del tiempo.

Diagramas de correspondencia (ECD): Relacionan el nmero mximo de

ocurrencias de una entidad que puede intervenir en una ocurrencia de

relacin.

3.2.4. MERISE

3.2.4.1. Introducin

MERISE [47] es una metodologa de la Administracin francesa, creada por iniciativa del

Ministerio de Industria Francs y desarrollada por Tardieu, Rochfeld y Colleti.

Comienza a desarrollarse en 1972, y se publica la primera versin a finales de 1976 con el

objetivo de crear una metodologa para las necesidades de la administracin francesa por

parte del CTI (Centre Technique Informatique) del Ministerio de Industria Francs.

En 1977 surgi la metodologa RACINES tratando la informatizacin como un acto estratgico

que maneja un recurso de una manera reflexiva y ordenada.

A lo largo de 1979 MERISE se orient hacia el anlisis y diseo de sistemas de informacin,

aportando un plan de trabajo y tcnicas de modelado para la fabricacin de aplicaciones

coherentes para el rea de gestin de empresas, suponiendo una interseccin entre

informtica y organizacin e integrando los sistemas as diseados en el marco comn

diseado por RACINES.

En 1982, y tambin, bajo el patrocinio del Ministerio de Industria Francs se procedi a

actualizar RACINES y a definir sus interfaces con MERISE formando un cuerpo metodolgico

completo bajo la denominacin de MERISE.



3.2.4.2. Descripcin

La metodologa MERISE introduce dos ciclos complementarios:

El ciclo de abstraccin

El ciclo de decisin.

Figura 7 Ciclos MERISE

El ciclo de abstraccin se basa en tres niveles:

Nivel conceptual: Es donde se define el qu es decir, los objetivos y limitaciones.

En este nivel se realiza un tratamiento de los datos segn el modelo conceptual de

datos y los procesos segn el modelo conceptual de procesos.

Nivel Organizativo: Es donde se define la orga

implantar para alcanzar los objetivos asignados

datos y el modelo organizativo de tratamientos para la realizacin de los procesos.

Nivel fsico u operativo

necesarios para el proyecto. U

modelo operativo de tratamiento para los procesos.

MERISE cubre las cuatro fases fundamentales del ciclo de vida de desarrollo del software:

Estudio de viabilidad (Estudio preliminar),

el mantenimiento de las aplicaciones, lo que hace es suministrar la documentacin completa y


Ciclo de Abstraccin



MERISE introduce dos ciclos complementarios:

cin

El ciclo de abstraccin se basa en tres niveles:

donde se define el qu es decir, los objetivos y limitaciones.


datos y los procesos segn el modelo conceptual de procesos.

: Es donde se define la organizacin adecuada que hay que

implantar para alcanzar los objetivos asignados, y se realiza un tratamiento de los


Nivel fsico u operativo: Es donde se realiza la integracin de los medios tcnicos

necesarios para el proyecto. Utiliza el modelo fsico de datos para los datos y el

modelo operativo de tratamiento para los procesos.


(Estudio preliminar), Anlisis, Diseo, e Implementacin.



Ciclo de decisin


Pgina 51

donde se define el qu es decir, los objetivos y limitaciones.


nizacin adecuada que hay que

y se realiza un tratamiento de los


cin de los medios tcnicos

tiliza el modelo fsico de datos para los datos y el


Implementacin. Pero no cubre




Tabla 9 Ciclo de Vida MERISE

Cada una de estas fases se describe en el siguiente grfico:

Tabla 10 Fases MERISE

Viabilidad (Estudio Preliminar)

Anlisis

Diseo

Implementacin

Mantenimiento

Estudio Preliminar

Estudio detallado

Realizacin y puesta en marcha

Diseo fsico

Implementacin



Cada una de estas fases se describe en el siguiente grfico:

Estudio preliminar

Estudio detalladoViabilidad

(Estudio Preliminar)

Realizacin y Puesta en marcha

Diseo fsico

ImplementacinImplementacin

No la cubreMantenimiento

En esta fase se analiza la situacin existente y la propuesta de una solucin global atendiendo a los criterios de gestin, de la organizacin y decisiones adoptadas por el comit directivo del proyecto.

Estudio Preliminar

En esta fase se define la solucin a nivel funcional.Estudio detallado

En esta fase se realiza la instalacin, formacin del personal, as como la implantacin de los medios tcnicos y organizativos y la recepcin por parte del usuario.

Realizacin y puesta en marcha

Es la fase donde se describe el entorno tcnico con la distribucin de los datos en los ficheros y los tratamientos en mdulos de programas.

En esta fase se codifican los programas con sus correspondientes pruebas.Implementacin


Pgina 52

Realizacin y Puesta en marcha

En esta fase se analiza la situacin existente y la propuesta de una solucin global atendiendo a los criterios de gestin, de la organizacin y decisiones adoptadas por el comit directivo del proyecto.

En esta fase se define la solucin a nivel funcional.

En esta fase se realiza la instalacin, formacin del personal, as como la implantacin de los medios tcnicos y organizativos y la recepcin

Es la fase donde se describe el entorno tcnico con la distribucin de los datos en los ficheros y los tratamientos en mdulos de programas.

En esta fase se codifican los programas con sus correspondientes



Se definen tres equipos para el desarrollo de un proyecto:

Comit director: Su funcin es fijar los objetivos y tomar las decisiones importantes en

el desarrollo del mismo, interviniendo al final de cada etapa para realizar el control y

seguimiento del proyecto y aprobando los informes de las mismas. Este equipo de

trabajo estar formado por los directivos de cada rea afectada, los responsables de

los servicios implicados, el responsable del servicio de informtica y el jefe del

proyecto.

Comit de usuarios: Su funcin es realizar un seguimiento sistematizado para la

comprobacin a lo largo del desarrollo de los cumplimientos de las actividades

asignadas, mediante la comprobacin de los diseos de las pantallas, validacin de

informes y de listados, resolucin de problemas, etc. Estar compuesto por los

responsables de los servicios afectados.

Equipo de desarrollo: Su misin es elaborar los informes y documentacin

contemplados en cada una de las fases de desarrollo, as como la realizacin de los

anlisis, programacin, pruebas, instalacin y puesta en marcha. Este equipo estar

formado por el jefe del proyecto y los analistas y programadores asignados al mismo,

as como el representante del grupo de usuarios.

Figura 8 Equipos MERISE

La metodologa MERISE utiliza las siguientes tcnicas:

DFD (Diagramas de flujo de datos): Para la representacin grfica de la organizacin

identificando los flujos de informacin entre los diferentes actores.

Modelo conceptual de datos (Modelo entidad/relacin): Para la representacin

mediante estructuras del mundo real, pudiendo optar por cualquier tipo de base de

datos.

Modelo lgico de datos: Para adaptar el modelo conceptual de datos al sistema gestor

de base de datos elegido.

Equipo de desarrollo

Comit de

usuarios

Comit director



Modelo conceptual de tratamientos: Para representar las acciones a realizar sobre los

datos con el objeto de obtener los resultados previstos. Para ello, utiliza las redes

Petri.

Modelo organizativo de tratamientos: Para describir cmo se va a organizar la

ejecucin de las mismas.

Modelo operacional de tratamientos: Se parte de la descomposicin de los

procedimientos y fases anteriores y se obtienen los procedimientos manuales, las

fases en tiempo real, las fases en tiempo diferido donde se incluyen las entradas,

tratamientos y listados.

3.3. Metodologas giles

3.3.1. Extreme-Programming (XP)


La programacin extrema o eXtreme Programming (XP) fue creada por Kent Beck en 1999, a

travs de su libro Extreme Programming Explained: Embrace Change [48]. Est

especialmente diseada para el desarrollo de software.

XP es una metodologa gil centrada en la potenciacin de las relaciones interpersonales

como clave para lograr el xito. Promueve el trabajo en equipo, prestando atencin al

aprendizaje de los desarrolladores, y estableciendo un buen clima de trabajo.

XP utiliza la realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin

fluida entre todos los participantes, simplicidad en las soluciones implementadas y

determinacin frente a los cambios. Los principios y prcticas que describe pueden parecer de

sentido comn, pero se llevan al extremo, de ah su nombre.

XP es especialmente adecuada para proyectos con requisitos imprecisos, cambiantes, y donde

existe un alto riesgo tcnico.



3.3.1.2. Descripcin

A continuacin se presentarn las caractersticas ms relevantes de

siguientes elementos:

Figura 9 Caractersticas XP

Historia de usuario: Esta

Se trata de tarjetas de papel en las cuales el cliente describe brevemente las

caractersticas que el

funcionales.

El tratamiento de las historias de usuario es muy

Cada historia de usuario

programadores puedan im

Un ejemplo de ficha podra recoger los siguientes campos:

Fecha Prueba Funcional Prioridad Estimacin tcnica Notas Comentarios

Tabla 11 Ficha XP



A continuacin se presentarn las caractersticas ms relevantes de XP organizadas en

Esta tcnica se utiliza para especificar los requisitos del software.


caractersticas que el sistema debe tener, sean requisitos funcionales o no

El tratamiento de las historias de usuario es muy dinmico y flexible.

Cada historia de usuario debe ser entendible y suficientemente concreta

edan implementarla en unas semanas.

Un ejemplo de ficha podra recoger los siguientes campos:

Customer Story and task card

Tipo de Actividad (nueva, correccin, mejora)Nmero de Historia Referencia Descripcin Lista de Seguimiento Por Terminar Etc.

Historia de usuario

Roles

Proceso

Prcticas


Pgina 55

XP organizadas en los

tcnica se utiliza para especificar los requisitos del software.


sistema debe tener, sean requisitos funcionales o no

exible.

debe ser entendible y suficientemente concreta para que los

Tipo de Actividad (nueva, correccin, mejora)



A efectos de la planificacin, las historias pueden durar de una a tres semanas de de

programacin (para no superar el tamao de una iteracin).

Las historias de usuario se descomponen en tareas de programacin (task cards) y

asignadas a los programadores para ser implementadas durante una nica iteracin.

Roles: Los roles propuestos son:

Programador (Programmer). El programador escribe las pruebas unitarias y

desarrolla el cdigo del sistema.

Cliente (Customer). Escribe las historias de usuario y las pruebas funcionales

para validar su implementacin. Adems, asigna prioridades a cada una de las

historias de usuario,decidiendo cules se implementan en cada iteracin

segn aporten mayor valor al negocio.

Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas

funcionales. Ejecuta las pruebas regularmente, di funde los resultados en el

equipo y es el responsable de las herramientas que dan soporte a dichas

pruebas.

Encargado de seguimiento ( Tracker). Proporciona realimentacin (feedback)

al equipo. Tambin verifica el grado de acierto entre las estimaciones

realizadas y el tiempo real dedicado, para mejorar futuras estimaciones.

Realiza el seguimiento del progreso de cada una de las iteraciones.

Entrenador (Coach). Responsable del proceso global. Provee de guas al

equipo de forma que se apliquen las prcticas XP y se siga el proceso

correctamente.

Consultor. Es un miembro externo del equipo con un conocimiento especfico

en algn tema necesario para el proyecto, en el que puedan surgir problemas.

Gestor (Big boss). Es el vnculo entre clientes y programadores. Ayuda a que el

equipo trabaje de forma efectiva creando las condiciones adecuadas. Su labor

fundamental es de coordinacin.



Proceso: El ciclo de desarrollo se puede resumir en

En todas las iteraciones,

presionar al programador a realizar ms trabajo que el estimado, ya que se perder

calidad en el software

De la misma forma el cliente tiene la obligacin

producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con

cada una de las iteraciones.

El ciclo de vida ideal

Exploracin

Planificacin de la Entrega

Iteraciones

Produccin

Mantenimiento

Muerte del Proyecto.

Prcticas: Una de las grandes virtudes de XP es conseguir disminuir la curva

exponencial, que supone la inclusin de cambios a lo largo de la vida del proyecto.

Esto se consigue gracias a las nuev

desarrollo de software y gracias a la aplicacin de las siguientes prcticas definidas:

El programador construye ese



: El ciclo de desarrollo se puede resumir en los siguientes pasos

Figura 10 Ciclo de desarrollo XP

En todas las iteraciones, tanto el cliente como el programador, aprenden. No se debe


calidad en el software y/o no se cumplirn los plazos.

De la misma forma el cliente tiene la obligacin de gestionar el mbito de entrega del


una de las iteraciones.

El ciclo de vida ideal de XP consiste de seis fases:

Planificacin de la Entrega (Release)

Mantenimiento

Muerte del Proyecto.

: Una de las grandes virtudes de XP es conseguir disminuir la curva


Esto se consigue gracias a las nuevas tecnologas disponibles para ayudar en el


El cliente define el valor de negocio a

implementar

El programador estima el esfuerzo

necesario para su

implementacin

El cliente selecciona qu construir, de

acuerdo con sus prioridades y las restricciones de

tiempo

El programador construye ese

valor de negocio


Pgina 57

los siguientes pasos:

aprenden. No se debe


el mbito de entrega del


: Una de las grandes virtudes de XP es conseguir disminuir la curva


as tecnologas disponibles para ayudar en el




El juego de la planificacin. Existe una comunicacin frecuente y fluida entre el

cliente y el equipo de desarrollo. El equipo tcnico realiza una estimacin del

esfuerzo requerido para la implementacin de las historias de usuario y los

clientes deciden sobre el mbito y tiempo de las entregas, y de cada iteracin.

Entregas pequeas. Es necesario producir rpidamente versiones del sistema

que sean operativas, aunque no cuenten con toda la funcionalidad del sistema.

Cada versin ya constituye valor para el negocio. Una entrega no debera tardar

ms 3 meses.

Metfora. El sistema es definido mediante una metfora o un conjunto de

metforas compartidas por el cliente y el equipo de desarrollo. Podemos definir

una metfora como una historia compartida que describe cmo debera

funcionar el sistema.

Diseo simple. Se debe disear la solucin ms simple que pueda funcionar y

ser implementada en un momento determinado del proyecto.

Pruebas. El desarrollo del cdigo est dirigido por las pruebas unitarias. stas

son establecidas por el cliente antes de desarrollarse el cdigo, y son ejecutadas

constantemente ante cada modificacin del sistema.

Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del

cdigo con el objetivo de eliminar cdigo duplicado, mejorar su legibilidad,

simplificarlo y hacerlo ms flexible para facilitar los futuros cambios. Se mejora la

estructura interna del cdigo sin alterar su comportamiento externo.

Programacin en parejas. Toda la produccin de cdigo debe realizarse con

trabajo en parejas de programadores. Esto conlleva ventajas implcitas (menor

tasa de errores, mejor diseo, mayor satisfaccin de los programadores,.., etc.).

Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier

parte del cdigo de la aplicacin en cualquier momento.

Integracin contina. Cada pieza de cdigo es integrada en el sistema una vez que

est lista. As, el sistema puede llegar a ser integrado y construido varias veces en

un mismo da.

Evitar horas extras. No se deben trabajan horas extras en dos semanas seguidas.

Este tipo de actuaciones normalmente encubre un problema de planificacin que

debe corregirse. El trabajo extra desmotiva al equipo.

Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para

el equipo. ste es uno de las principales clave del xito del proyecto XP. El cliente

dirige constantemente el trabajo hacia lo que aportar mayor valor de negocio y

los programadores pueden resolver de manera inmediata cualquier duda asociada.

La comunicacin oral es ms efectiva que la escrita.

Estndares de programacin. XP enfatiza que la comunicacin de los

programadores sea a travs del cdigo, con lo cual es indispensable que se sigan

ciertos estndares de programacin para mantener el cdigo legible.



Para obtener el mayor beneficio posible de estas prcticas, se recomienda su

aplicacin conjunta, ya que unas se apoyan en otras. La mayora de las prcticas

propuestas por XP no son novedosas sino que de alguna forma ya haban sido

propuestas en ingeniera del software, o incluso demostrado su valor en la prctica. El

mrito de XP es integrarlas de una forma efectiva, y complementarlas con otras ideas

desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.

3.3.2. Scrum


El concepto de Scrum [28] tiene su origen en un estudio de 1986, The New New Product

Developement Game (Hirotaka Takeuchi y Ikujiro Nonaka ). Este estudio versaba sobre los

nuevos procesos de desarrollo utilizados en productos exitosos en Japn y los Estados Unidos

(cmaras de fotos de Canon, fotocopiadoras de Xerox, automviles de Honda, ordenadores de

HP y otros).

Los equipos que desarrollaron esos productos partan de requisitos muy generales, as como

muy novedosos, y deban salir al mercado en mucho menos del tiempo del que se tard en

lanzar productos anteriores. Estos equipos seguan patrones de ejecucin de proyecto muy

similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente

productivos y multidisciplinares con la colaboracin entre los jugadores de Rugby y su

formacin de Scrum (mel en espaol).

Fue ya en 1993, cuando Jeff Sutherland, John Scumniotales y Jeff McKenna concibieron,

ejecutaron y documentaron el primer Scrum para desarrollo gil en desarrollo de software,

utilizando el estudio de gestin de equipos de Takeuchi y Nonaka como base en Easel

Corporation.

Scrum fue presentado formalmente en 1995 por Je Sutherland y Ken Schwaber en el

OOPSLA95. En 2001, Schwaber y Mike Beedle describieron la metodologa en el libro Agile

Software Development with Scrum.

Actualmente existe, la Gua de Scrum (The Scrum Guide), que representa la gua de

conocimiento oficial de Scrum (Scrum Body Of Knowledge), escrita por Ken Schwaber and

Jeff Sutherland. La ltima versin data de Febrero de 2010.



3.3.2.2. Descripcin

Scrum es una de las metodologas giles ms utilizadas en la actualidad. Est destinada

principalmente al desarrollo y mantenimiento de proyectos software.

Utiliza un proceso iterativo que divide el desarrollo de un producto en ciclos de

de duracin (sprints). En cada uno de los ciclos, el equipo trabaja sobre una lista de requisitos

priorizada, dando lugar, al acabar cada ciclo, a un producto entregable. Este

optimiza la previsibilidad y el

Los principales beneficios que

Entrega de resultados

prioritarios en ese momento, ya compl

Gestin regular de las expectativas del cl

Resultados anticipados (time to market).

Flexibilidad y adaptacin respecto a las necesidades del cliente, cambios en el

mercado, etc.

Gestin sistemtica del Retorno de Inversin (ROI).

Mitigacin sistemtica de los

Incremento de la productividad y

Alineamiento entre el cliente y el equipo de desarrollo.

Equipo motivado.

Scrum se basa en tres pilares:



Scrum es una de las metodologas giles ms utilizadas en la actualidad. Est destinada

principalmente al desarrollo y mantenimiento de proyectos software.

Utiliza un proceso iterativo que divide el desarrollo de un producto en ciclos de

). En cada uno de los ciclos, el equipo trabaja sobre una lista de requisitos

priorizada, dando lugar, al acabar cada ciclo, a un producto entregable. Este

el control de riesgos.

Los principales beneficios que aporta Scrum, son:

Entrega de resultados con periodicidad quincenal o mensual (los requisitos ms

prioritarios en ese momento, ya completados) lo cual proporciona grandes ventajas.

Gestin regular de las expectativas del cliente y basada en resultados tangibles.

Resultados anticipados (time to market).

Flexibilidad y adaptacin respecto a las necesidades del cliente, cambios en el

Gestin

Documents

3. Metodologías de Gestión de Proyectos