SanchezLucasPablo GOPI PR2 ·...
Transcript of 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
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
Sistema de Movilidad de Ventas: CLOUD
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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 4
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%.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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á.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 6
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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 8
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:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 10
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:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 12
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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 14
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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 16
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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 18
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:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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:
Código del Subsistema Nombre del Subsistema
02 Contratación 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. 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).
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 20
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.
En resumen, los puntos de función serán los siguientes:
Tipo Valor Complejidad Motivo
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
Una vez introducidos, los resultados que nos devuelve Costar 7.0, son los siguientes:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
21
03 – Subsistema de seguimiento del pedido:
Código del Subsistema Nombre del Subsistema
03 Seguimiento del pedido
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 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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 22
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.
En resumen, los puntos de función serán los siguientes:
Tipo Valor Complejidad Motivo
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
Una vez introducidos, los resultados que nos devuelve Costar 7.0, son los siguientes:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
23
04 – Subsistema de comunicación de pedidos:
Código del Subsistema Nombre del Subsistema
04 Comunicación de pedidos
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 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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 24
En resumen, los puntos de función serán los siguientes:
Tipo Valor Complejidad Motivo
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
Una vez introducidos, los resultados que nos devuelve Costar 7.0, son los siguientes:
05 – Subsistema de administración de la aplicación:
Código del Subsistema Nombre del Subsistema
05 Administración de la aplicación
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 de usuario:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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.
En resumen, los puntos de función serán los siguientes:
Tipo Valor Complejidad Motivo
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
Una vez introducidos, los resultados que nos devuelve Costar 7.0, son los siguientes:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 26
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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
27
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 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
IT – Pruebas Integradas 45,6 60,8 76,0 45,6 45,6 273,6
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.
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 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
IT – Pruebas Integradas 5,7 7,6 9,5 5,7 5,7 34,2
Totales 28,5 38,0 51,3 32,3 28,5 178,6
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 28
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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
29
4.4.1. Precedencias de las actividades
Código de la actividad Nombre de la actividad Estimación
(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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 30
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:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 32
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€
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 34
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.
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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:
Código de la actividad Nombre de la actividad Estimación
(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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 36
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 €
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 38
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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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:
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 40
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
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas
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 €
Sistema de Movilidad de Ventas: CLOUD
Pablo Sánchez Lucas 42
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€