sanchezlucaspablo gopi pr2 ·...

Informe de Calificación Revisión 2 / GOPI: 2ª parte práctica · Otoño 2010

P a b l o S á n c h e z L u c a s

Sistema de Movilidad de Ventas: CLOUD


Pablo Sánchez Lucas 2

Índice

1. Definición general del proyecto .................................................................................... 3 1.1. Marco de referencia ............................................................................................................................................... 3 1.2. Plazos establecidos ................................................................................................................................................. 3 1.3. Ciclo de vida y herramientas para la estimación de costes y planificación ................................... 3 1.4. Análisis de los recursos ........................................................................................................................................ 4 1.4.1. Recursos existentes .............................................................................................................................................. 4 1.4.2. Necesidades de nuevos recursos .................................................................................................................... 5

1.5. Aspectos generales del nuevo sistema ........................................................................................................... 5 1.5.1. Diseño de la base de datos ................................................................................................................................ 5 1.5.2. Perfiles de usuario ................................................................................................................................................ 6 1.5.3. Pantallas del proyecto ........................................................................................................................................ 6 1.5.3.1. Módulo PDA. ........................................................................................................................................................ 6 1.5.3.1. Módulo WEB. ...................................................................................................................................................... 9

1.6. Versión en diferentes idiomas ......................................................................................................................... 12 1.7. Otras consideraciones ......................................................................................................................................... 12

2. Estructura del proyecto y descomposición en actividades ........................................... 13 2.1. Estructura del proyecto ...................................................................................................................................... 13 2.2. Descomposición en actividades ...................................................................................................................... 13

3. Estimación de esfuerzo ............................................................................................... 14 3.1. Estimación de cada actividad ........................................................................................................................... 14 3.2. Estimación por tipo de recurso ....................................................................................................................... 15 3.3. Estimación de esfuerzo de la actividad de construcción de software ............................................. 15 3.3.1. Definición de los parámetros de estimación .......................................................................................... 15 3.3.2. Puntos de función y estimación del esfuerzo (P-‐M) de cada subsistema .................................. 17 3.3.3. Resumen y análisis de los datos generados por Costar ..................................................................... 26

4. Planificación temporal del proyecto ........................................................................... 28 4.1. Definición de la jornada laboral ...................................................................................................................... 28 4.2. Calendario para el desarrollo del proyecto ................................................................................................ 28 4.3. Equipo del proyecto ............................................................................................................................................. 28 4.4. Planificación temporal ........................................................................................................................................ 28 4.4.1. Precedencias de las actividades .................................................................................................................. 29 4.4.2. Precedencias de las actividades de construcción del software ...................................................... 29 4.4.3. Planificación propuesta .................................................................................................................................. 30 4.4.4. Camino crítico ..................................................................................................................................................... 31 4.4.5. Hitos de control .................................................................................................................................................. 31

5. Presupuesto del proyecto ........................................................................................... 32

6. Hoja de resumen del proyecto .................................................................................... 33

7. Mantenimiento del sistema ........................................................................................ 34 7.1. Mantenimiento correctivo ................................................................................................................................. 34 7.1.1. Personal requerido ........................................................................................................................................... 35 7.1.2. Presupuesto correctivo ................................................................................................................................... 36 7.2. Mantenimiento evolutivo ................................................................................................................................... 37 7.2.1. Estimación del esfuerzo .................................................................................................................................. 37 7.2.2. Resumen de los datos generados por la aplicación ............................................................................ 39 7.2.3. Personal requerido ........................................................................................................................................... 40 7.3. Presupuesto de mantenimiento ...................................................................................................................... 41


Pablo Sánchez Lucas

3

1. Definición general del proyecto

1.1. Marco de referencia El proyecto Sistema de Movilidad de Ventas (en adelante SMV) para los vendedores de la línea de productos CalcoFix pretende modernizar el departamento de ventas de la empresa Cloud, considerando el resultado del proyecto el condicionante para extenderlo al resto de sus productos. Después de una lectura detallada del informe de definición, donde se marcan los objetivos, el alcance, la funcionalidad y otros aspectos del proyecto, consideramos que contamos con los suficientes datos para preparar este informe de calificación, que debe servirnos para establecer una primera estimación de costes y planificación temporal para el citado proyecto SMV. En esta revisión del documento de calificación hemos incorporado las nuevas funcionalidades, junto con la estimación de la etapa de mantenimiento del proyecto, que el cliente nos propone después de analizar la primera revisión de este documento.

1.2. Plazos establecidos

La planificación de este proyecto y la estimación del esfuerzo se basan en unos plazos establecidos por el cliente, por lo que el inicio del proyecto se originará en el momento en el que se apruebe este informe de calificación. En nuestro caso supondremos que el presente documento se aprueba el día 10 de Diciembre de 2010, y el cliente desea realizar las primeras pruebas del sistema transcurridos 3 meses para evitar el solapamiento de este proyecto con otro que se desea iniciar, por lo que el proyecto deberá finalizar 15 días después.

1.3. Ciclo de vida y herramientas para la estimación de costes y planificación

Para conseguir una estimación ajustada del volumen de trabajo y una planificación lo más realista posible consideramos necesaria la utilización del ciclo de vida en cascada con el objeto de desarrollar el nuevo SMV.

Dado que el cliente nos ha facilitado claramente los objetivos a cumplir podremos definir cada una de las etapas de manera objetiva.

En la estimación de costos se utilizaremos una herramienta comercial específica para este propósito, como es el Costar (versión 7); y para la planificación temporal utilizaremos el Microsoft Project (versión 2003).

Utilizaremos la métrica de los puntos de función, ya que al no tener registros históricos de desarrollos similares anteriores este SMV nos dará una medida muy cercana a la realidad.



1.4. Análisis de los recursos

En primer lugar realizaremos un estudio de todos aquellos recursos que la empresa Cloud dispone actualmente, ya que, mediante los resultados de este estudio podremos tomar las decisiones más adecuadas.

1.4.1. Recursos existentes

El cliente acepta nuestra propuesta de desarrollar el proyecto en sus propias instalaciones, por un lado para aprovechar los recursos que nos facilita y por otro lado para disponer de un contacto directo con los usuarios de la aplicación, de este echo se desprende que el cliente facilitará una ubicación dentro de sus instalaciones.

El cliente dispone de los siguientes recursos:

• Hardware: Hemos podido comprobar que el cliente ya cuenta con una infraestructura adecuada en cuanto a servidores de desarrollo como de producción, las licencias y servicio de mantenimiento de los productos base ya han sido contratados con anterioridad y existe un acuerdo con el proveedor de telefonía para suministrar las PDA necesarias para los comerciales, por otro lado la ubicación facilitada por el cliente para nuestro equipo de trabajo dispone de conexión directa con todos los servidores.

• Software: Necesitaremos utilizar un software específico para el desarrollo y otro para la producción:

o Software para desarrollo: se dispone de un servidor Linux CentOS versión 5.4 con un motor de base de datos MySQL versión 5.1.53, servidor de páginas web Apache versión 2.2 con intérprete para lenguaje PHP versión 5.3 y Tomcat 6.0.29 para lenguaje Java, principalmente. También se dispone de la herramienta open source de desarrollo: Eclipse IDE, para los lenguajes que se utilizarán: Java (se dispone de licencia) y JavaScript. Por último se dispone de una licencia open source de la aplicación MySQL Workbench para el modelado de diagramas entidad-‐relación ERR y diseño de la base de datos.

o Software para producción: se dispone de un servidor Linux con las mismas características que el descrito para desarrollo: MySQL, Apache, PHP, sobre CentOS. El cliente ya dispone de varios navegadores de Internet como IE 9, IE 8, IE 7, Safari 5, Firefox 3.6, Opera 10.63, Chrome 2.0, Camino 2.0, Netfront 4.1, Ozone y Firefox Mobile. Las PDA utilizarán Android 2.3 como sistema operativo.

• Recursos humanos: nuestro equipo de trabajo será el siguiente: o 1 * Jefe de Proyecto, persona de nuestro equipo y confianza para el cliente, con

una dedicación del 100%. o 1 * Analista Funcional, experto en circuitos administrativos de ventas y producción,

con una dedicación del 100%. o 4 * Analistas Programadores, expertos en Java e Internet, con una dedicación del

100%. o 1 * Arquitecto, para diseñar y dar soporte a la implantación de los nuevos

elementos de movilidad, con una dedicación del 50%.



5

1.4.2. Necesidades de nuevos recursos

Una vez analizadas todas las características del proyecto y tras el análisis anterior consideramos que nos son necesarios nuevos recursos de software o hardware, pero por otro lado y para cumplir el plazo establecido con el cliente se necesitará incorporar a dos nuevos miembros al equipo del trabajo: un analista programador y un analista. Se deberán contratar traductores externos en el supuesto de que el sistema tenga que trabajar con un idioma desconocido por el equipo.

1.5. Aspectos generales del nuevo sistema

Puesto que necesitamos tener una visión clara respecto de lo que tenemos que hacer para desarrollar el nuevo SMV, mostramos los siguientes elementos para tener un mayor contacto con la dimensión del proyecto, utilizando herramientas propias de la ingeniería del software, exponiendo la cómo deberá ser la base de datos del sistema, cual será el diagrama de contexto y cómo configurar los perfiles que otorgan el acceso a los datos del nuevo sistema.

1.5.1. Diseño de la base de datos

Nos basaremos en el siguiente diagrama de Entidad-‐Relación (EER) que muestra cómo será la base de datos con la que el nuevo sistema trabajará.



Algunas consideraciones sobre este modelo:

• La tabla de departamentos contendrá los departamentos de la empresa: comercial, producción, marketing, …

• El empleado, agente comercial del departamento de ventas, podrá consultar el stock de los productos incluidos en el pedido del cliente para la reserva de productos necesaria, genrando una órden de expedición; y en caso de no disponer de suficiente stock se generará una orden de fabricación.

• A la hora de realizar un pedido el sistema comprobará las existencias del producto y en función de ellas enviará una orden de expecición al almacén o bien enviará una orden de fabricación.

• En la tabla de clientes el campo id_cliente contiene un valor único y personal que servirá para identificar al cliente en el nuevo sistema.

• Se ha añadido a la tabla “clientes”, 1 campo nuevo (como_llegar) para registrar la nueva funcionalidad solicitada por el cliente.

• Se ha añadido a la tabla “pedidos”, 2 campos nuevos (

1.5.2. Perfiles de usuario

El sistema deberá soportar varios perfiles de usuarios ya que en la definición del proyecto se nos indica los siguientes:

a) Agente comercial, para vendedores de la empresa Cloud y que se encargarán de la comercialización de sus productos.

b) Cliente, para realizar consultas sobre las acciones de los agentes comerciales: estado de un pedido, plazo de entrega, …

c) Responsables de la aplicación, para que los usuarios del departamento de marketing de la empresa puedan aplicar acciones de fuerza de venta, comparativa y evolución de precios frente a la competencia, …

Cada perfil tendrá acceso a diferentes partes del sistema en función de sus necesidades y para todos ellos será necesario la identificación mediante nombre de usuario y clave, de esta forma se controlará a qué partes del sistema puede o debe acceder cada perfil de usuario.

Por otro lado deberemos tener en cuenta e informamos al cliente que la seguridad al 100% en Internet no existe por lo que existirá un cierto grado de riesgo para el sistema y la propia empresa al basar el proyecto sobre esta red.

1.5.3. Pantallas del proyecto

Seguidamente detallaremos las pantallas que dispondrá el sistema teniendo en cuenta que son una primera aproximación y que por lo tanto podrán variar su aspecto en el producto final entregado al cliente, pero igualmente servirán como referencia principal.

1.5.3.1. Módulo PDA.

a) Consulta de catálogo de productos.



7

I. Identificación de usuario (comerciales), pantalla PDA posición vertical:

II. Introducción del código de cliente:

Hemos añadido la nueva funcionalidad solicitada por el cliente para saber cómo llegar hasta la dirección del cliente, mediante un campo de texto y botón de consulta de dirección.

III. Listado de productos de la línea RoboHouseMax, pantalla PDA posición horizontal:



IV. Detalles de producto, pantalla PDA posición horizontal:

b) Contratación de productos:

I. Alta de pedido, pantalla PDA posición horizontal:

II. Confirmación de pedido, pantalla PDA posición horizontal:



9

1.5.3.1. Módulo WEB.

a) Seguimiento del pedido.

I. Identificación de usuario (clientes):

II. Consulta de pedidos:

Hemos añadido las nuevas funcionalidades solicitadas por el cliente para cancelar un pedido seleccionado, modificar la hora de entrega de un pedido e histórico de clientes, mediante botones.

III. Histórico de incidencias:

Hemos añadido una nueva pantalla con las funcionalidades solicitadas por el cliente llevar un histórico de las incidencias producidas por un cliente.



IV. Detalles de pedido seleccionado:

b) Comunicación de pedidos.

I. Identificación de usuario (agentes y dpto. producción):

II. Consulta de pedidos de clientes:



11

c) Administración de la aplicación.

I. Identificación de usuarios (dpto. marketing):

II. Gestión de clientes:

Hemos añadido la nueva funcionalidad solicitada por el cliente para saber cómo llegar hasta la dirección del cliente, mediante un campo de texto para almacenar las indicaciones pertinentes.

III. Gestión de productos:



1.6. Versión en diferentes idiomas

Del informe de definición se desprende que el sistema se debe desarrollar para varios idiomas, sin especificar cuántos, tan sólo se nos informa que inicialmente se trabajará en Catalán.

1.7. Otras consideraciones

Con la intención de ordenar de una forma más óptima los objetivos y alcance del proyecto, queremos subrayar algunos aspectos que nos han quedado totalmente explicados en el informe de definición, como son los siguientes:

• EL SMV se nutrirá de los datos ya existentes y almacenados en el ERP del cliente.

• EL SMV no deberá tener la menor incidencia sobre el resto de usuarios puesto que nuestro trabajo se basa en la integración a nivel de base de datos del nuevo sistema con el ERP ya existente de la empresa Cloud.

• EL nuevo sistema está orientado exclusivamente para los vendedores de la línea de

productos CalcoFix, en función del resultado y posteriormente, se podrá extender al resto de productos.

• Todas las acciones informativas a los futuros usuarios de los objetivos del proyecto y sus

plazos, en ningún caso formarán parte de las actividades de formación previstas y quedarán fuera del alcance de este proyecto.

• Cualquier cambio que se solicite respecto al alcance y al definición del proceso actual

deberán ser comunicados formalmente con la mayor antelación posible, realizándose un análisis de impacto para los cambios solicitados, tanto en plazos como presupuesto.

• La aceptación formal y aprobación de documentos del proyecto deberá realizarse en los

próximos 5 días laborables a la entrega del presente documento. En caso de no ajustarse a este plazo, será necesario realizar un ajuste de los plazos previstos y eventualmente del presupuesto del proyecto.

• El SMV dispondrá de un manual de uso de la aplicación, pero igualmente nuestra empresa

podrá facilitar, a petición futura del cliente, cursos de formación en las propias instalaciones de la empresa Cloud y ésta será la encargada de facilitar los medios para que la formación se pueda realizar de forma efectiva, asumiendo a su vez los costes de desplazamiento del personal de formación de nuestra empresa.

• El nuevo SMV dispondrá de un mantenimiento de 12 meses para realizar todas aquellas

tareas pertinentes al mantenimiento correctivo y evolutivo del nuevo sistema. De igual manera se estimará el presupuesto correspondiente al mantenimiento (correctivo y evolutivo), según los nuevos puntos de función marcados como necesarios por el cliente. En este presupuesto de mantenimiento también se tendrá en cuenta el equipo necesario para poder llevarlo a cabo.



13

2. Estructura del proyecto y descomposición en actividades

Una vez conocidos la mayoría de los aspectos principales del nuevo sistema y tomadas las primeras decisiones procedemos a sus descomposición en actividades.

2.1. Estructura del proyecto

Teniendo en cuenta los condicionantes que presentamos a continuación, utilizaremos una metodología de desarrollo en cascada:

• El proyecto se puede definir con bastante precisión, es un proceso conocido. • El cliente tiene experiencia con respecto a lo que se pide, ya que se parte de un sistema

actual que está operativo. • Es una aplicación transaccional. • Los clientes son de la misma organización, hay una confianza mutua y una gran

accesibilidad. • El equipo es experto en esta metodología.

Para la estimación del esfuerzo nos basaremos en una descomposición de actividades, subsistemas, puntos de función y el modelo COCOMO II.

2.2. Descomposición en actividades

Las actividades que compondrán el proyecto serán las siguientes:

Descomposición estructural de actividades (WBS)

Cód. actividad Nombre de la actividad del nivel 1 Nombre de la actividad del nivel 2

01 Inicio del proyecto 02 Gestión del proyecto 03 Construcción del proyecto 03.01 Estudio de oportunidad 03.02 Análisis 03.03 Diseño 03.04 Programación y pruebas unitarias 03.05 Pruebas 04 Traspaso de datos 05 Puesta en producción 06 Final del proyecto

El proyecto contempla estrictamente la construcción del proyecto solicitado por el cliente. Las actividades de mantenimiento correctivo, evolutivo y perfectivo quedan fuera del alcance de este



informe de calificación, no obstante, estos aspectos podrán ser objeto de una propuesta posterior si la empresa Cloud lo considera necesario.

3. Estimación de esfuerzo

3.1. Estimación de cada actividad

Estimaremos las actividades 2,4,5 y 6 a partir de un modelo histórico, experiencia, con datos referentes a las mismas actividades en proyectos anteriores.

Para la actividad de la gestión del proyecto se aplicará un 8% sobre el tiempo total una vez estimado.

Y para la estimación de la actividad 3, se empleará un modelo compuesto COCOMO II 2000, que se desarrolla en el apartado 3.3. Estimación de esfuerzo de la actividad de construcción de software.

En la siguiente tabla se muestra el desglose de actividades junto con su estimación y los recursos asignados a cada una de ellas.

Código de la actividad Nombre de la actividad Estimación

(jornadas) Recurso

01 Inicio del proyecto 0,00 -‐ 02 Gestión del proyecto 12,80 Jefe de proyecto 03 Construcción del proyecto 03.01 Estudio de oportunidad 11,4 Jefe de proyecto 03.02 Análisis 26,6 Analista 03.03 Diseño 45,6 Analista Programador 03.04 Programación y pruebas unitarias 60,8 Analista Programador 03.05 Pruebas 34,2 Analista 04 Traspaso de los datos 4,00 Analista Programador 05 Puesta en producción 1,00 Arquitecto 06 Final de proyecto 0,00 -‐

TOTAL 196,4

• 02. Gestión del proyecto: La gestión de proyecto se materializará en reuniones de

seguimiento semanales por parte del jefe de proyecto con el equipo y con el responsable de proyecto de la empresa Cloud. Las reuniones tendrán lugar todos los viernes salvo acuerdo previo o calendario de fiestas, y constarán de dos partes: la primera dedicada principalmente al equipo y la segunda a los responsables de proyecto por parte del responsable de proyecto de la empresa Cloud. La asignación de tiempo a cada parte dependerá de los asuntos a tratar en cada área, pudiendo realizarse ambas partes de forma conjunta si se estima conveniente.

• 06. Puesta en producción: La actividad 6 incluye el soporte al cliente para la puesta en

producción del proyecto SMV y la entrega de los manuales de explotación y operación de la aplicación.



15

3.2. Estimación por tipo de recurso

Las estimaciones obtenidas las mostramos ahora teniendo en cuenta los recursos necesarios para cada actividad, lo cual nos ayudará a la hora de calcular el presupuesto y para poder planificar el proyecto.

Recurso Actividades (josrnadas/persona) Totales

02 03 04 05 Jefe de proyecto 12,80 11,40 0,00 0,00 24,20 Analista 0,00 60,8 0,00 0,00 53,2 Analista programador 0,00 106,4 4,00 0,00 97,1 Arquitecto 0,00 0,00 0,00 1,00 1,00 Totales 12,80 178,60 4,00 1,00 196,4

3.3. Estimación de esfuerzo de la actividad de construcción de software Para hacer la estimación del esfuerzo de la actividad de construcción del software, tal como ya se ha comentado, utilizaremos la versión 7.0 del programa Costar. Tendremos que definir en primer lugar el conjunto de parámetros que requiere este programa y ajustar los valores de los puntos de función y las características del proyecto, del equipo y de la organización. Y en segundo lugar, tendremos que estudiar la descomposición en subsistemas lógicos que permitan una mejor estimación del esfuerzo.

3.3.1. Definición de los parámetros de estimación De acuerdo con los estándares de la empresa Cloud, que ha establecido un criterio para definirlos, para el proyecto actual se fijan los siguientes parámetros para realizar las estimaciones con el Costar: a) Parámetros de contexto:

Grupo Elemento Parámetro Justificación

Modelo de Estimación COCOMO II 2000 Waterfall Metodología escogida

Factores de Escala

Precedentes En su mayor parte, familiar

En gran parte de sus aspectos se trata de un sistema familiar para nuestro equipo de trabajo

Flexibilidad de desarrollo Riguroso

Hace falta desarrollar todas las funcionalidades y alcanzar los requerimientos de manera rigurosa

Riesgos en la arquitectura 60% Mantendremos un valor medio con

respecto a los riesgos

Cohesión del equipo Altamente cooperativo

Los miembros del equipo están acostumbrados a desarrollar proyectos en común y se supone que tienen buenos niveles de cooperación y motivación

Madurez del proceso SEI CMM Nivel 2 Valor por defecto



b) Parámetros de coste:

Grupo* Elemento Parámetro Justificación

Pers

onal

ACAP Alto

Disponemos de personal con experiencia en construcción de software a medida; por lo tanto, la capacidad de análisis es alta

APEX Alto El equipo tiene experiencia en aplicaciones parecidas

PCAP Muy alto La capacidad de utilizar paquetes COTS de nuestros programadores, entendidos como equipo, es muy alta

PLEX Alto Disponemos de personal con bastante experiencia en estos tipos de plataforma

LTEX Alto El personal tiene mucha experiencia en los lenguajes de programación que utilizaremos

Proy

ecto

PCON Alto Al tratarse de personal de la empresa, no tiene que haber problemas de continuidad

TOOL Muy alto Se utilizarán herramientas de software integradas durante todo el ciclo de vida

SITE Muy alto El desarrollo se llevará a cabo única y exclusivamente en las instalaciones de la empresa

SCED Alto La exigencia de respetar la planificación y el calendario es elevada

Plat

afor

ma

TIME Nominal Dejamos un valor por defecto, ya que no creemos que haya restricciones al respecto

STORE Nominal Valor por defecto. Tampoco consideramos restricciones al respecto

PVOL Nominal Estableceremos un valor normal para la volatilidad de la plataforma (red, hardware, sistema operativo, etc.)

Prod

ucto

RELY Muy alto

La importancia de las actividades desarrolladas por el sistema y los datos hacen que su fiabilidad tenga que ser muy alta

DATA Bajo El volumen de la base de datos es bajo

CPLX Bajo La complejidad la consideraremos baja

RUSE Nominal

La reutilización de componentes no comportará un esfuerzo adicional en el desarrollo de este sistema. Dejamos un valor normal

DOCU Bajo Los niveles de documentación requerida son bajos al ser una aplicación de uso interno.

Leng

uaje

Java, JavaScript, PHP y HTML

45 líneas de código por punto función ajustado

Dado que utilizaremos herramientas de desarrollo tipo RAD -Visual Basic, Java-, hemos seleccionado este valor porque establece la relación más baja entre líneas de código y puntos función. Creemos que esta relación se ajusta más a nuestro caso

* Grupo: atributos que influyen en el coste



17

3.3.2. Puntos de función y estimación del esfuerzo (P-‐M) de cada subsistema

Una vez definidos los parámetros con los que trabajará Costar, determinaremos los puntos de función y el esfuerzo en horas-‐persona para cada uno de los subsistemas de la descomposición estructural siguiente, obtenida a partir de los requerimientos funcionales explicitados en el documento del informe de definición del proyecto.

Descomposición estructural en subsistemas (PBS)

Código Nombre Descripción del subsistema

01 Consulta de catálogo de productos Consulta de productos por parte del agente y consulta de indicaciones

02 Contratación de productos Gestión de pedidos de clientes

03 Seguimiento del pedido

Seguimiento del estado del pedido por el cliente. Cancelación de pedidos. Cambio del horario de entrega. Histórico de Incidencias.

04 Comunicación de pedidos Cambio de estado de pedidos por parte de agentes y departamento de producción

05 Administración de la aplicación

Identificación de clientes y productos que entrarán en el circuito de movilidad por parte del departamento de marketing.

Emplearemos el lenguaje JAVA para desarrollar los 2 primeros subsistemas, por lo que utilizaremos 53 Líneas de Código Fuente (SLOC) por punto de función; y para el resto de subsistemas utilizaremos los lenguajes JavaScript, PHP y HTML, por lo que utilizaremos 45 SLOC por punto de función para estos lenguajes.

Utilizaremos los siguientes factores de ajuste en la aplicación Costar 7.0:



01 – Subsistema de consulta de catálogo de productos:

Código del Subsistema Nombre del Subsistema

01 Consulta del catálogo de productos

De acuerdo con la descripción de esta funcionalidad, se estudia cada uno de los tipos de puntos de función que hay que calcular:

I. Identificación del usuario: a. Pantalla de entrada à EI: 2 DETs (usuario, clave) + 1 DET para mensaje

error ok/ko. 1 FTR (usuarios). Complejidad baja. El agente introduce su código de usuario y clave de acceso al sistema.

b. Fichero à LIF: 2 DETs (usuario, clave). 1 RET (usuarios). Complejidad baja. Fichero al que se consultan los datos de usuario y clave de acceso.

II. Identificación del cliente y consulta de indicaciones: a. Pantalla de entrada à EI: 1 DET (id_cliente) + 1 DET para mensaje error

ok/ko. 1 FTR (clientes). Complejidad baja. El agente introduce el código del cliente para obtener el % de descuento.

b. Fichero à EIF: 1 DET (id_cliente). 1 RET (clientes). Complejidad baja. Fichero para recuperar el dato del descuento.

c. Consulta externa à EQ: 1 DET (como_llegar) + 1 DET para mensaje error ok/ko. 1 FTR (clientes). Complejidad baja. Consulta de retorno de datos (campo “como_llegar”).

III. Listado de productos: a. Pantalla à EO: 4 DETs (id_producto, descripción, pvp, stock). 1 FTR

(productos). Complejidad baja. Se retornan los datos de productos consultados, obteniendo un informe con datos calculados.

b. Fichero à EIF: 7 DETs (campos de la tabla productos). 1 RET (productos). Complejidad baja. Para los datos de productos.

c. Botón detalles à EQ: 3 DETs (foto, año inicio, detalles com.). 1 FTR (productos). Complejidad baja. Para acceder a la pantalla de detalles de producto.

IV. Detalles de productos: a. Pantalla à EQ: 3 DETs (foto, año inicio, detalles com.). 1 FTR (productos).

Complejidad baja. Consulta de retorno de datos de productos.

En resumen, los puntos de función serán los siguientes:



19

Tipo Valor Complejidad Motivo

EI 2 Baja Pantalla de login usuario, identificación de clientes

EO 1 Baja Listado de productos de la línea RoboHouseMax LIF 1 Baja Tabla de usuarios EIF 2 Baja Tabla de productos, tabla de clientes EQ 2 Baja Detalles de producto. Indicaciones para agentes.

Una vez introducidos, los resultados que nos devuelve Costar 7.0, son los siguientes:

02 – Subsistema de contratación de productos:


02 Contratación de productos


I. Alta nuevo pedido: a. Pantalla de entrada à EI: 4 DETs (id_pedido, id_empleado, id_cliente,

fecha pedido) + 1 DET para mensaje error ok/ko. 1 FTR (pedidos).



Complejidad baja. Se introducen los datos en el sistema para un nuevo pedido.

b. Fichero à LIF: 4 DETs (id_pedido, id_empleado, id_cliente, fecha pedido). 1 RET (pedidos). Complejidad baja. Para almacenar los datos del pedido.

c. Listado/detalles à EQ: 3 DETs (cantidad, descripción producto, pvp, importe). 2 FTR (productos, pedidos_det). Complejidad baja. Retorno de datos de productos y detalles de pedidos.

d. Fichero à EIF: 7 DETs (campos de la tabla productos). 1 RET (productos). Complejidad baja. Para los datos de productos.

e. Fichero -‐> LIF: 3 DETs (id_pedido, id_producto, cantidad). 1 RET (pedidos_det). Complejidad baja. Para los datos de detalles de pedidos.

II. Confirmación de pedido: a. Pantalla à EQ: 10 DETs (calle, nº, piso y puerta, población, cp, provincia,

fecha y hora prev., tfl, email, preferencia). 1 FTR (clientes). Complejidad baja. Retorno de datos del cliente.

b. Fichero à EIF: 10 DETs (calle, nº, piso y puerta, población, cp, provincia, fecha y hora prev., tfl, email, preferencia). 1 RET (clientes). Complejidad baja. Para los datos de clientes.

c. Confirmación cliente à EI: 1 DET (id_cliente). + 1 DET para mensaje error ok/ko. 1 FTR (clientes). Complejidad baja. Inserción del código de cliente.

d. Botón actualizar à EI: 10 DETs (calle, nº, piso y puerta, población, cp, provincia, fecha y hora prev., tfl, email, preferencia) + 1 DET para mensaje error ok/ko. 1 FTR (clientes). Complejidad baja.



EI 3 Baja Pantalla de login usuario, confirmación de cliente, botón actualizar

EO -‐ -‐ -‐ LIF 2 Baja Tabla pedidos, tabla pedidos_det EIF 2 Baja Tabla productos, tabla clientes EQ 2 Baja Detalles de producto, consulta de clientes




21

03 – Subsistema de seguimiento del pedido:


03 Seguimiento del pedido


I. Identificación del cliente: a. Pantalla de entrada à EI: 1 DET (id_clientes) + 1 DET para mensaje

error ok/ko. 1 FTR (clientes). Complejidad baja. Identificación del cliente.

b. Fichero à EIF: 14 DETs (campos de la tabla clientes). 1 RET (clientes). Complejidad baja. Para los datos del cliente.

II. Consulta de pedidos: a. Pantalla à EO: 4 DETs (fecha pedido, estado pedido, fecha de entrega,

importe total). 2 FTR (pedidos, pedidos_det). Complejidad baja. Retorno de datos de pedidos.

b. Fichero à LIF: 9 DETs (campos de la tabla pedidos). 1 RET (pedidos). Complejidad baja. Para los datos de pedidos.



c. Fichero à LIF: 4 DETs (campos de la tabla pedidos_det). 1 RET (pedidos_det). Complejidad baja. Para los datos de la tabla detalles de pedidos.

d. Cambio de Hora -‐> EI: 1 DET (fecha_entrega) + 1 DET para mensaje error ok/ko. 1 FTR (pedido). Complejidad baja. Botón para la modificación de la fecha de entrega del pedido.

e. Cancelar/Eliminar pedido -‐> EI: 9 DET (campos tabla pedidos) + 1 DET para mensaje error ok/ko. 1 FTR (pedido). Complejidad baja. Botón para la cancelación del pedido.

f. Modificar estado -‐> EI: 1 DET (estado) + 1 DET para mensaje error ok/ko. 1 FTR (pedido). Complejidad baja. Botón para la modificación del estado del pedido.

III. Histórico de incidencias: a. Pantalla -‐> EO: 3 DETs (id_cliente, num_cancelaciones, num_cambios).

1 FTR (pedidos). Complejidad baja. Retorno de datos de pedidos. b. Fichero -‐> LIF: 3 DETs (id_cliente, num_cancelaciones, num_cambios). 1

RET (pedidos). Complejidad baja. Para los datos de pedidos.

IV. Detalles de pedido seleccionado: e. Pantalla à EQ: 3 DETs (cantidad, descripción producto, pvp). 1 FTR

(productos). Complejidad baja. f. Fichero à EIF: 7 DETs (campos de la tabla productos). 1 RET (productos).

Complejidad baja. g. Botón Actualizar à EQ: 1 DET. 1 FTR. Complejidad baja.



EI 4 Baja Pantalla de entrada de cliente.

EO 2 Baja Pantalla de pedidos agrupados por cliente

LIF 3 Baja Tabla de pedidos, tabla pedidos_det

EIF 2 Baja Tabla de productos, tabla clientes

EQ 2 Baja Detalles de pedidos, botón actualizar




23

04 – Subsistema de comunicación de pedidos:


04 Comunicación de pedidos


I. Identificación de usuario: a. Pantalla de entrada à EI: 2 DET (id_usuario, clave) + 1 DET para mensaje

error ok/ko. 1 FTR (usuarios). Complejidad baja. Entrada para la identificación del usuario y clave.

b. Fichero à LIF: 2 DETs (id_usuario, clave). 1 RET (usuarios). Complejidad baja. Para los datos de usuarios.

II. Consulta de pedidos: a. Pantalla à EO: 4 DETs (fecha pedido, estado pedido, fecha de entrega,

importe total). 2 FTR (pedidos, pedidos_det). Complejidad baja. Consulta de datos de pedidos.

b. Fichero à LIF: 7 DETs (campos de la tabla pedidos). 1 RET (pedidos). Complejidad baja. Para los datos de pedidos.

c. Fichero à LIF: 4 DETs (campos de la tabla pedidos_det). 1 RET (pedidos_det). Complejidad baja. Para los datos de detalles de pedidos.

d. Botón Actualizar à EQ: 1 DET. 1 FTR. Complejidad baja. e. Aviso à EO: 1 DET (estado pedido). 2 FTR (pedidos, clientes). Complejidad

baja. Para la generación de un aviso.





EI 1 Baja Pantalla de entrada de usuario-‐empleado

EO 2 Baja Pantalla de pedidos agrupados por cliente, aviso

LIF 3 Baja Tabla de pedidos, tabla pedidos_det, tabla usuarios

EIF -‐ -‐ -‐

EQ 1 Baja Botón actualizar


05 – Subsistema de administración de la aplicación:


05 Administración de la aplicación


I. Identificación de usuario:



25

a. Pantalla de entrada à EI: 2 DET (id_usuario, clave) + 1 DET para mensaje error ok/ko. 1 FTR (usuarios). Complejidad baja. Entrada de datos para la identificación de usuarios.

b. Fichero à LIF: 2 DETs (id_usuario, clave). 1 RET (usuarios). Complejidad baja. Para los datos de usuarios.

II. Gestión de clientes: a. Actualización de clientes à EQ: 12 DETs (campos tabla clientes). 1 FTR

(clientes). Complejidad baja. Consulta de actualización de datos de clientes. b. Fichero à EIF: 12 DETs (campos de la tabla clientes). 1 RET (clientes).

Complejidad baja. Para los datos de clientes. c. Botón actualizar à EI: 12 DETs (campos tabla clientes) + 1 DET para

mensaje error ok/ko. 1 FTR (clientes). Complejidad baja. III. Gestión de productos:

a. Actualización de productos à EQ: 5 DETs (id_producto, año inicio, foto, detalles comp., mobilidad). 1 FTR (productos). Complejidad baja. Consulta de actualización de datos de productos.

b. Fichero à EIF: 5 DETs (id_producto, año inicio, foto, detalles comp., mobilidad). 1 RET (productos). Complejidad baja. Para los datos de productos.

c. Botón actualizar à EI: 5 DETs (id_producto, año inicio, foto, detalles comp., mobilidad) + 1 DET para mensaje error ok/ko. 1 FTR (productos). Complejidad baja.



EI 3 Baja Pantalla de entrada de usuario, botón actualizar clientes, botón actualizar productos

EO -‐ -‐ -‐

LIF 1 Baja Tabla usuarios

EIF 2 Baja Tabla clientes, tabla productos

EQ 2 Baja Gestión clientes, gestión productos




3.3.3. Resumen y análisis de los datos generados por Costar

A continuación resumiremos los datos obtenidos en el apartado anterior por la aplicación Costar 7.0:

Resumen Subsistemas Totales

Consulta de

catálogo de

productos

Contratación de

productos

Seguimiento del pedido

Comunicación de pedidos

Administración de la

aplicación

Tamaño 1291 1798 2232 1370 1253 7944

Fase (Actividad) Esfuerzo en persona-mes

RQ – Requisitos 0,1 0,1 0,2 0,1 0,1 0,6 PD – Análisis 0,2 0,3 0,4 0,3 0,2 1,4 DD – Diseño 0,4 0,5 0,7 0,4 0,4 2,4 CT – Programación y Pruebas Unitarias

0,5 0,7 0,9 0,6 0,5 3,2

IT – Pruebas Integradas 0,3 0,4 0,5 0,3 0,3 1,8

Los datos de la tabla anterior están expresados en personas-‐mes y para poder realizar una mejor gestión, convertiremos los datos de la tabla en horas, para ello utilizaremos el estándar de 152 horas-‐mes.



27


Consulta de

catálogo de

productos

Contratación de

productos




aplicación

Tamaño 1291 1798 2232 1370 1253 7944

Fase (Actividad) Esfuerzo en horas-persona RQ – Requisitos 15,2 15,2 30,4 15,2 15,2 91,2 PD – Análisis 30,4 45,6 60,8 45,6 30,4 212,8 DD – Diseño 60,8 76,0 106,4 60,8 60,8 364,8 CT – Programación y Pruebas Unitarias

76,0 106,4 136,8 91,2 76,0 486,4


Totales 228,0 304,0 410,4 258,4 228,0 1.428,8

Del mismo modo convertiremos los datos de la tabla anterior a jornadas para obtener el total de jornadas que son necesarias para cada actividad. Partiremos de la base que una jornada de trabajo consta de ocho horas.


Consulta de

catálogo de

productos

Contratación de

productos




aplicación

Tamaño 1291 1798 2232 1370 1253 7944 Fase (Actividad) Esfuerzo en jornada-mes RQ – Requisitos 1,9 1,9 3,8 1,9 1,9 11,4 PD – Análisis 3,8 5,7 7,6 5,7 3,8 26,6 DD – Diseño 7,6 9,5 13,3 7,6 7,6 45,6 CT – Programación y Pruebas Unitarias

9,5 13,3 17,1 11,4 9,5 60,8


Totales 28,5 38,0 51,3 32,3 28,5 178,6



4. Planificación temporal del proyecto

4.1. Definición de la jornada laboral

Actualmente la jornada laboral es de ocho horas laborales durante cinco días a la semana. No se considera, en principio, la necesidad de realizar horas extra ni de trabajar ningún fin de semana.

4.2. Calendario para el desarrollo del proyecto

La fecha inicial del proyecto será una vez que el cliente de la empresa CLOUD apruebe el presente documento y la fecha de finalización del mismo será tres meses después de ésta.

Teniendo en cuenta las fechas en las que estamos con la proximidad de las festividades de navidad y año nuevo coincidiendo con el desarrollo del proyecto, no se contemplarán los festivos nacionales en la planificación del proyecto.

Una vez realizadas estas consideraciones sabemos que disponemos de 80 días laborables, menos 1 día de festividad:

• 6 de enero à día de reyes, Epifanía

Quedando definitivamente 79 días (80-‐1=79) laborables para desarrollar el proyecto.

4.3. Equipo del proyecto

Dada la necesidad de realizar una primera aproximación a la planificación y teniendo en cuenta la disponibilidad del equipo, se asignarán al proyecto todas las personas disponibles de acuerdo a cada uno de los perfiles considerados necesarios para la descomposición de actividades, que serán: un jefe de proyecto, un analista funcional, cuatro analistas-‐programadores y un arquitecto al 50%.

4.4. Planificación temporal

Emplearemos la aplicación comercial Microsoft Project versión 2003 para llevar a cabo la planificación.

En primer lugar estableceremos las precedencias necesarias entre las actividades que hay que desarrollar dentro del proyecto en función de su actividad, recurso, etc.



29

4.4.1. Precedencias de las actividades


(jornadas) Recurso Precedencia

01 Inicio del proyecto 0,00 -‐ -‐ 02 Gestión del proyecto 12,80 Jefe de proyecto 01 03 Construcción del proyecto 03.01 Estudio de oportunidad 11,40 Jefe de proyecto 01 03.02 Análisis 26,6 Analista 03.01 03.03 Diseño 45,6 Analista Programador 03.02 03.04 Programación y pruebas unitarias 60,8 Analista Programador 03.03 03.05 Pruebas 34,2 Analista 03.04 04 Traspaso de datos 4,00 Analista Programador 03.05 05 Puesta en producción 1,00 Arquitecto 04 06 Final de proyecto 0,00 -‐ 05

4.4.2. Precedencias de las actividades de construcción del software

Teniendo en cuenta que utilizaremos un ciclo de vida en cascada, no se podrá pasar a la siguiente etapa hasta que no esté completamente finalizada la anterior.

Con el fin de tratar de evitar este inconveniente de la metodología empleada dividiremos cada uno de los ciclos en sub ciclos, ya que cada subsistema se podrá desarrollar de forma independiente, acortando el tiempo de desarrollo y mejorando la gestión de los recursos.

La toma de esta decisión nos obligará a modificar los datos globales que hemos obtenido de la aplicación Costar versión 7.0 por cada sistema, por datos de subsistema. Uniremos los subsistemas en tres bloques, sin olvidar que nos estamos refiriendo al proceso de construcción de software.

Por lo tanto deberemos utilizar nuevamente los datos proporcionados por la aplicación Costar versión 7.0:13,3

Resumen Bloques Totales Recursos Bloque 1 Bloque 2 Bloque 3 Fase (actividad)

Esfuerzo jornadas/persona

PD-‐Análisis 9,5 13,3 3,8 26,6 Analista

DD-‐Diseño 17,1 20,9 7,6 45,6 Analista Programador

CT-‐ 22,8 28,5 9,5 60,8 Analista Programador IT-‐Pruebas 13,3 15,2 5,7 34,2 Analista



4.4.3. Planificación propuesta

Gracias a la herramienta Microsoft Project 2003, junto con los datos anteriores proponemos la siguiente planificación:

Con las nuevas funcionalidades propuestas por el cliente obtenemos que el nuevo sistema estaría desarrollado en 100 días, y dado que el cliente necesita que el proyecto esté en funcionamiento lo antes posible para no solaparte con otro proyecto nuevo, por lo que no nos queda otra alternativa que añadir un segundo analista a nuestro equipo, con la finalidad de poder cumplir con el plazo establecido, el echo de añadir un nuevo miembro al equipo podría producir un efecto no deseado.

Podemos comprobar que tras realizar este cambio, el proyecto podrá estar finalizado en 78, 4 días, cumpliendo así con el plazo previsto.

La planificación temporal de las actividades y sub actividades será la siguiente:



31

4.4.4. Camino crítico

La herramienta Microsoft Project 2003 nos facilita también el diagrama del camino crítico (PERT), pero dada la secuencia de actividades y los recursos empleados no es significativo.

4.4.5. Hitos de control

Mediante los hitos de control revisaremos en todo momento el estado del proyecto, y en caso de necesidad, podremos establecer acciones de control sobre el desarrollo del mismo, con la capacidad de valorar las desviaciones entre la realidad y la planificación previa para poder tomar las mejores medidas correctoras para alcanzar los objetivos del proyecto.

Al tratarse de un proyecto que se desarrolla a lo largo de 3 meses, es probable que se produzcan desviaciones.

Para corregir con garantías estas posibles desviaciones, se establecerán una serie de hitos de control, quedando reflejados en la siguiente tabla:

Fecha Hito de Control Participantes

10/12/10 Aprobación del informe de calificación Jefe de proyecto y cliente

10/12/10 Inicio del proyecto Jefe de proyecto, todo el equipo 10/12/11 Revisión y aprobación del estudio de oportunidad Jefe de proyecto, cliente

02/02/11 Revisión y aprobación del análisis Jefe de proyecto, analista



11/02/11 Seguimiento intermedio del diseño Jefe de proyecto, analista, cliente

16/02/11 Seguimiento del diseño y la programación del bloque 1 Jefe de proyecto, analista 2/02/11 Seguimiento del diseño y la programación del bloque 2 Jefe de proyecto, analista

04/03/11 Seguimiento de las pruebas Jefe de proyecto, analista, cliente

06/04/11 Seguimiento de la producción Jefe de proyecto, analista, cliente 7/04/11 Final de proyecto (cierre) Jefe de proyecto, cliente, todo el equipo

5. Presupuesto del proyecto

Con toda la información recopilada hasta ahora estamos en disposición de elaborar el presupuesto para llevar a cabo el nuevo Sistema de Movilidad de Ventas de la empresa Cloud.

Para realizar los cálculos de costes referentes a los recursos humanos tomaremos como referencia los facilitados por el jefe financiero estableciendo los precios de los recursos internos y los aplicaremos en la tabla de actividades:

Tarifas de precios de recursos internos

Recurso Coste/Hora Coste/Jornada Jefe de Proyecto 48 € 384 € Analista 36 € 288 € Analista Programador 24 € 192 € Arquitecto / 50% 35 € 280 € / 140€

Como decíamos el coste por actividades será el siguiente:

Cód. de la actividad Nombre de la actividad Estimación

(jornadas) Recurso Coste (euros)

01 Inicio del proyecto 0,00 - 0

02 Gestión del proyecto 12,80 Jefe de proyecto 4.915€

03 Construcción del software 0

03.01 Estudio de oportunidad 11,40 Jefe de proyecto 4.378€

03.02 Análisis 26,6 Analista 7.661€

03.03 Diseño 45,6 Analista Programador 8.755€

03.04 Programación y pruebas unitarias 60,8 Analista Programador 11.674€

03.05 Pruebas 34,2 Analista 9.850€

04 Traspaso de datos 4,00 Analista Programador 768€

05 Puesta en producción 1,00 Arquitecto (50%) 140€

06 Final del proyecto 0,00 - 0

Total 48.141€



33

6. Hoja de resumen del proyecto

Proyecto GP – Generación de Presupuestos

Resumen

Fecha inicio 10/12/10

Fecha puesta en explotación 06/04/11

Fecha finalización 07/04/11

Hitos de Control Previstos

Fecha Hito de Control Participantes

10/12/10 Aprobación del informe de calificación

Aprobación del informe de calificación Jefe de proyecto y cliente

10/12/10 Inicio del proyecto Inicio del proyecto Jefe de proyecto, todo el equipo

03/01/11 Revisión y aprobación del estudio de oportunidad

Revisión y aprobación del estudio de oportunidad Jefe de proyecto, cliente

04/02/11 Revisión y aprobación del análisis Revisión y aprobación del análisis Jefe de proyecto, analista

11/02/11 Seguimiento intermedio del diseño y la programación

Seguimiento intermedio del diseño y la programación

Jefe de proyecto, analista, cliente

18/02/11 Seguimiento del diseño y la programación del bloque 1

Seguimiento del diseño y la programación del bloque 1 Jefe de proyecto, analista

25/02/11 Seguimiento del diseño y la programación del bloque 2

Seguimiento del diseño y la programación del bloque 2 Jefe de proyecto, analista

16/03/11 Seguimiento de las pruebas Seguimiento de las pruebas Jefe de proyecto, analista, cliente

18/03/11 Seguimiento de la explotación Seguimiento de la explotación Jefe de proyecto, analista, cliente

21/03/11 Final de proyecto (cierre) Final de proyecto (cierre) Jefe de proyecto, cliente, todo el equipo

Código de la actividad Nombre de la actividad Estimación (jornadas) Recurso

01 Inicio del proyecto 0,00 -

02 Gestión del proyecto 12,80 Jefe de proyecto

03 Construcción del software

03.01 Estudio de oportunidad 11,40 Jefe de proyecto

03.02 Análisis 26,6 Analista

03.03 Diseño 45,6 Analista programador

03.04 Programación y pruebas unitarias 60,8 Analista programador

03.05 Pruebas 34,2 Analista

04 Traspaso de datos 4,00 Analista programador



05 Puesta en producción 1,00 Arquitecto (50%)

06 Fin del proyecto 0,00 -

Total 196,4

Cantidad de profesionales que participarán en el proyecto

Perfil profesional Cantidad Jefe de proyecto 1

Analista 2

Analista programador 4

Arquitecto (50%) 1

Presupuesto

Total 48.141€

7. Mantenimiento del sistema En este apartado calcularemos la estimación del esfuerzo y coste necesario para el mantenimiento y evolución del sistema, por un periodo de 12 meses.

Centraremos la estimación del mantenimiento por servicio:

• mantenimiento correctivo: desde donde se corregirán aquellos defectos en el sistema detectados por los usuarios durante la explotación del mismo. Distinguiendo dos tipos básicos de este tipo de mantenimiento:

o Reparaciones de emergencia, que deberán acometerse en breves espacios de tiempo.

o Reparaciones planificadas, que deberán acometerse en espacios de tiempo más prolongados, teniendo en cuenta la supervisión de las anteriores.

• mantenimiento evolutivo: desde donde se adaptará el sistema a las nuevas necesidades planteadas por el cliente.

El mantenimiento del nuevo sistema se iniciará al día siguiente de la entrega del mismo.

7.1. Mantenimiento correctivo

Realizaremos una estimación de errores producidos por puntos de función, con la finalidad de obtener el número total de errores cometidos en el proyecto.



35

Dada nuestra experiencia en proyectos anteriores similares a este, tomaremos estos valores como referencia y basados en nuestra experiencia anterior:

• Nº de incidencias por cada 100 puntos de función à 5,4 incidencias • Nuestra empresa resuelve las incidencias con una media de à 1,2 jornadas. • Los datos que nos devuelve el Costar en cuanto a puntos de función de cada subsistema,

tenemos un total de à 191 PF

De los datos anteriores podemos resolver que:

• El proyecto tiene 191 puntos de función, por lo tanto el número de incidencias será à (191 pf * 5,4 incidencias) / 100 à 10,31 incidencias.

• Como nuestra media para cada incidencia es de 1,2 jornadas, para las 10,31 incidencias que se prevén, obtendremos à 1,2 * 10,31 à 12,38 jornadas para 10,31 incidencias.

7.1.1. Personal requerido

Cada perfil profesional necesario para el mantenimiento del nuevo sistema requiere que reúna componentes completos y variados para cubrir esta etapa. Todos los miembros deben saber trabajar en equipo, emplear metodologías estructuradas y prestando especial atención a los detalles, ya que, este echo puede suponer un gran ahorro de tiempo y esfuerzos.

Normalmente la mayoría de las incidencias se han cubierto por el Analista programador, pero en alguna ocasión se ha requerido de la intervención del Analista cuando la incidencia ha sobre pasado el ámbito de la codificación y por lo tanto afecta a un error de diseño o análisis.

Por lo tanto creemos necesaria la participación de prácticamente todo el equipo de trabajo, ya que, cada uno podrá corregir cada uno de los errores de las áreas donde se hayan producido. Durante este proceso de mantenimiento podríamos necesitar volver a alguna de las etapas del ciclo de vida para su revisión o desarrollo de nuevas funcionalidades solicitadas por el cliente.

Mediante la siguiente tabla reflejaremos las jornadas dedicadas por cada tarea y los posibles errores que se pueden producir en el sistema:


(jornadas) % Incidencia (jornadas) Recurso

1 Inicio del proyecto 0 -‐

2 Gestión del proyecto 12,8 6,52% 0,81 Jefe de proyecto

3 Construcción del proyecto

03.01 Estudio de oportunidad 11,4 5,80% 0,72 Jefe de proyecto 03.02 Análisis 26,6 13,54% 1,68 Analista

03.03 Diseño 45,6 23,22% 2,87 Analista Programador

03.04 Programación y pruebas unitarias

60,8 30,96% 3,83 Analista Programador

03.05 Pruebas 34,2 17,41% 2,16 Analista



4 Traspaso de datos 4 2,04% 0,25 Analista Programador

5 Puesta en producción 1 0,51% 0,06 Arquitecto 6 Final de proyecto

TOTALES 196,4 100,00% 12,38

Los porcentajes dedicados por cada profesional del equipo, son los siguientes:

% Incidencia (jornadas) Recurso

12,32% 1,53 Jefe de Proyecto 30,96% 3,83 Analista 56,21% 6,96 Analista Programador 0,51% 0,06 Arquitecto

100,00% 12,38

El reparto de la carga laboral intenta cubrir todas las posibilidades de error que se puedan producir en cada fase del ciclo de vida del sistema, echo por el cual mantenemos todo el equipo en diferentes proporciones de trabajo.

Y el total de horas dedicadas por cada miembro de nuestro equipo supondrá un 50% de las horas laborales para cubrir todos los aspectos del ciclo de vida de desarrollo del software.

7.1.2. Presupuesto correctivo

El presupuesto del mantenimiento correctivo lo calculamos mediante la siguiente tabla, aplicando los precios vigentes de recursos internos de nuestra empresa:

Tarifas de precios de recursos internos

Recurso Coste/Hora Coste/Jornada Jefe de Proyecto 48 € 384 € Analista 36 € 288 € Analista Programador 24 € 192 € Arquitecto / 50% 35 € 280 €

% Incidencia (jornadas) Recurso Coste

12,32% 1,53 Jefe de Proyecto 585,77 € 30,96% 3,83 Analista 1.103,76 € 56,21% 6,96 Analista Programador 1.336,13 € 0,51% 0,06 Arquitecto 17,65 €



37

100,00% 12,38 TOTALES 3.043,31 €

7.2. Mantenimiento evolutivo

Para poder calcular el coste del mantenimiento evolutivo en base a las funcionalidades a desarrollar equivalentes a 2.000 puntos de función por año solicitadas por el cliente, tendremos en cuenta los datos obtenidos en la productividad y distribución de tareas considerada en la etapa inicial del proyecto para considerar su viabilidad en este punto.

Para comprobar dicha viabilidad del proyecto deberemos comprobar qué puntos de función obtenidos después de las modificaciones propuestas por el cliente en el informe de cambios al documentos de definición, teniendo en cuenta siempre que la finalización del mantenimiento se producirá transcurridos 12 meses.

7.2.1. Estimación del esfuerzo

Para realizar la estimación del esfuerzo utilizaremos la aplicación Cocomo II y para ello en primer lugar convertiremos los 2.000 puntos de función a número de líneas SLOC que tendrá el nuevo sistema.

No utilizaremos la aplicación Costar por tratarse de una versión demo, limitada a 5.000 líneas de código.

Tomando el valor 45 líneas por punto de función del apartado 3.3.2 (Puntos de función y estimación del esfuerzo de cada subsistema), podemos obtener que:

2000 pf * 45 SLOC = 90.000 líneas de código que deberemos añadir al nuevo proyecto durante el plazo de mantenimiento del mismo.

Utilizaremos los siguientes valores de ajuste para los parámetros de contexto del mantenimiento del proyecto:

Grupo Elemento Parámetro Justificación

Modelo de estimación COCOMO II 2000 Metodología escogida

Factores de la escala Precedentes Muy familiar Sistema muy conocido por el equipo, ya que es el mismo desde el inicio



Flexibilidad de desarrollo Riguroso Es necesario desarrollar las nuevas funcionalidades de manera rigurosa

Riesgos de la arquitectura 60% Valor medio

Cohesión del equipo Altamente cooperativo Disponemos de un equipo completamente compenetrado y motivado

Madurez del proceso SEI CMM Nivel 2 Valor por defecto

Utilizaremos los siguientes valores de ajuste para los parámetros de coste del mantenimiento del proyecto:

Grupo* Elemento Parámetro Justificación

Pers

onal

ACAP Alto

Disponemos de personal con experiencia en construcción de software a medida; por lo tanto, la capacidad de análisis es alta

APEX Alto El equipo tiene experiencia en aplicaciones parecidas

PCAP Muy alto La capacidad de utilizar paquetes COTS de nuestros programadores, entendidos como equipo, es muy alta

PLEX Alto Disponemos de personal con bastante experiencia en estos tipos de plataforma

LTEX Alto El personal tiene mucha experiencia en los lenguajes de programación que utilizaremos

Proy

ecto

PCON Alto Al tratarse de personal de la empresa, no tiene que haber problemas de continuidad

TOOL Muy alto Se utilizarán herramientas de software integradas durante todo el ciclo de vida

SITE Muy alto El desarrollo se llevará a cabo única y exclusivamente en las instalaciones de la empresa

SCED Alto La exigencia de respetar la planificación y el calendario es elevada

Plat

afor

ma

TIME Nominal Dejamos un valor por defecto, ya que no creemos que haya restricciones al respecto

STORE Nominal Valor por defecto. Tampoco consideramos restricciones al respecto

PVOL Nominal Estableceremos un valor normal para la volatilidad de la plataforma (red, hardware, sistema operativo, etc.)

Prod

ucto

RELY Muy alto

La importancia de las actividades desarrolladas por el sistema y los datos hacen que su fiabilidad tenga que ser muy alta

DATA Bajo El volumen de la base de datos es bajo

CPLX Bajo La complejidad la consideraremos baja



39

RUSE Nominal

La reutilización de componentes no comportará un esfuerzo adicional en el desarrollo de este sistema. Dejamos un valor normal

DOCU Bajo Los niveles de documentación requerida son bajos al ser una aplicación de uso interno.

Leng

uaje

Java, JavaScript, PHP y HTML

45 líneas de código por punto función ajustado

Dado que utilizaremos herramientas de desarrollo tipo RAD -Visual Basic, Java-, hemos seleccionado este valor porque establece la relación más baja entre líneas de código y puntos función. Creemos que esta relación se ajusta más a nuestro caso

* Grupo: atributos que influyen en el coste La aplicación nos devuelve los siguientes datos:

7.2.2. Resumen de los datos generados por la aplicación

Los datos devueltos por la aplicación Cocomo II para la estimación del esfuerzo, son los siguientes:

Resumen Recursos Fase (actividad) Esfuerzo persona/mes RQ-‐Requisitos 5,484 Jefe de Proyecto

PD-‐Análisis 13,317 Analista DD-‐Diseño 19,111 Analista Programador

CT-‐Prog. Y Prueb. 24,905 Analista Programador IT-‐Pruebas 21,004 Analista

Total 78,34

Utilizaremos el estándar de 152 horas/mes para realizar la conversión del esfuerzo calculado a horas/mes, obteniendo:



Resumen Recursos Fase (actividad) Esfuerzo persona/mes en horas

RQ-‐Requisitos 833,568 Jefe de Proyecto PD-‐Análisis 2024,184 Analista

DD-‐Diseño 2904,872 Analista Programador CT-‐Prog. Y Prueb. 3785,56 Analista Programador

IT-‐Pruebas 3192,608 Analista Total 11.907,22

Para obtener los resultados anteriores del esfuerzo calculado a persona/jornada, procederemos dividiendo estos resultados por 8 horas que tiene cada jornada, resultando:

Resumen Recursos Fase (actividad) Esfuerzo jornada/persona

RQ-‐Requisitos 0,6855 Jefe de Proyecto

PD-‐Análisis 253,023 Analista DD-‐Diseño 363,109 Analista Programador

CT-‐Prog. Y Prueb. 473,195 Analista Programador IT-‐Pruebas 399,076 Analista

Total 1.488,40

7.2.3. Personal requerido

Para realizar los cálculos utilizaremos el modelo Cocomo II de grado de complejidad intermedia y el tipo de proyecto según Boehm semiacoplado, puesto que es el que mejor se ajusta a esta fase del proyecto.

Nos basaremos en los parámetros proporcionados por: “COCOMO Intermedio: atributos que influyen en el coste (CDA)” (apuntes de esta asignatura, pág. 42) y Wikipedia (http://es.wikipedia.org/wiki/COCOMO), para realizar los cálculos:

• El esfuerzo calculado mediante la aplicación Cocomo II es à E=78,34 • El tiempo requerido por el proyecto en meses à TDEV = c ·∙ (E)d à TDEV = 2,5 ·∙ (78,34) 0,35

à TDEV = 2,5 ·∙ 4,60 à TDEV = 11,5 • Nº de personas requeridas por el proyecto à Costeh = E / TDEV à Costeh = 78,34 / 11,5 à

Costeh = 6,81 à 7 personas.

En función de los resultados obtenidos podemos concluir que necesitaremos:

Recursos Cantidad Jefe de proyecto 1 Analista 1



41

Analista 4 Técnico de sistemas 1 Total 7

Aplicamos las tarifas vigentes para obtener el coste del mantenimiento:

Resumen Recursos Coste Fase (actividad) Esfuerzo jornada/persona RQ-‐Requisitos 0,6855 Jefe de Proyecto 33 € PD-‐Análisis 253,023 Analista 9.109 € DD-‐Diseño 363,109 Analista Programador 8.715 € CT-‐Prog. Y Prueb. 473,195 Analista Programador 11.357 € IT-‐Pruebas 399,076 Analista 14.367 € Total 1.488,40

43.580 €

7.3. Presupuesto de mantenimiento

Teniendo en cuenta los presupuestos de mantenimiento correctivo y evolutivo anteriores:

% Incidencia (jornadas) Recurso Coste Mant.

Correctivo 12,32% 1,53 Jefe de Proyecto 585,77 € 30,96% 3,83 Analista 1.103,76 € 56,21% 6,96 Analista Programador 1.336,13 € 0,51% 0,06 Arquitecto 17,65 €

100,00% 12,38 TOTALES 3.043,31 €

Resumen Recursos Coste Fase (actividad) Esfuerzo jornada/persona RQ-‐Requisitos 0,6855 Jefe de Proyecto 33 € PD-‐Análisis 253,023 Analista 9.109 € DD-‐Diseño 363,109 Analista Programador 8.715 € CT-‐Prog. Y Prueb. 473,195 Analista Programador 11.357 € IT-‐Pruebas 399,076 Analista 14.367 € Total 1.488,40

43.580 €



Podemos concluir que finalmente el presupuesto de mantenimiento será el siguiente:

Presupuesto de Mantenimiento

Total mantenimiento correctivo 3.043,31 € Total mantenimiento evolutivo 43.580 € Total 46.623 €

El precio final aproximado del nuevo sistema podría estar entorno a los à 95.000€

sanchezlucaspablo gopi pr2 ·...

Documents