Estimación de Coste del Personal

El otro día comentabamos de lo importante que es la estimación de costes para calcular el presupuesto de un proyecto.

La estimación que requiere de más experiencia es la de coste de personal, ya que si se sabe que materiales se van a dedicar para el proyecto, el cálculo de su coste es directo.

Sin embargo, del coste de personal, a priori antes de comenzar el proyecto, solamente podemos saber cuanto cobran nuestros empleados por hora, pero no sabemos cuantas horas tendrán que dedicar al proyecto.

Para intentar estimar el coste total del proyecto, existen varios métodos:

1) Técnicas Matemáticas: Utilizan modelos matemáticos que reciben como entrada datos sobre el proyecto a realizar y, tras la aplicación de fórmulas matemáticas, dan la respuesta.

2) Técnicas basadas en el aprendizaje automático: A partir de los datos de muchos proyectos, generan un modelo que, dado otro proyecto del que no se sabe nada realizar la estimación. Dan buenos resultados pero requieren de gran cantidad de datos que en una empresa pequeña no se dispondrán.

3) Técnicas basadas en expertos: Se basa en contratar a expertos para que realicen la estimación. Muy caras, por lo que para un proyecto pequeño no son recomendables.

4) Técnicas Dinámicas: Son técnicas basadas en matemáticas más complejas. Tratan de hacer una simulación matemática mediante funciones recursivas.

En conclusión, lo más apropiado para un proyecto pequeño es aplicar técnicas matemáticas. En nuestro caso, hemos estudiado en la asignatura la herramienta Cocomo 2, que es capaz de realizar estas estimaciones aplicando un modelo matemático. Únicamente es necesario introducir en el programa algunos datos sobre el proyecto, desde la experiencia y habilidad de los desarrolladores hasta la complejidad del proyecto.

Cocomo tiene varios tipos de modelos: el básico, el intermedio y el avanzado. Lo más lógico para un proyecto pequeño sería utilizar el modelo básico o el modelo intermedio.

A continuación, para aquellos que quieran profundizar más en este tema, ofrecemos una recopilación de referencias:
Tutorial de Estimación de Costes
Página Principal de Cocomo
Modelo de Cocomo
Cocomo Básico Online
Cocomo Intermedio Online
Otro calculador Online

Correo desde El Salvador

El otro día recibimos un correo desde El Salvador, de Jorge Valencia, que nos preguntaba por lo siguiente:

"Tengo una consulta para ustedes y se los agradesería mucho su ayuda. Necesito realizar un presupuesto de implementación de un software y no se que elementos tendría que tomar en cuenta.

El software es un programa de inventario para una empresa pequeña. El software es pequeño."

Decir que no somos muy expertos en el tema de estimación y que, como ya dijimos en el post de "Opiniones sobre Oferta", nos parece una tarea que requiere experiencia. Sería recomendable consultar otras fuentes para completar los consejos que podamos dar nosotros.

Aun así, hemos estado recopilando lo que sabíamos al respecto (de ahí la tardanza de la respuesta, sentimos no haber podido contestar antes) y hemos reunido lo siguiente:

En primer lugar, para realizar un presupuesto, (en nuestro caso documento de cálculo de costes), lo más importante es estimar el coste. A partir del coste estimado, se añadirá el porcentaje de beneficios que se quiere obtener, el porcentaje de primas de riesgo y el porcentaje de IVA (o los impuestos a los que esté asociado el proyecto en el país que sea).

El porcentaje de riesgos no debe infravalorarse, hay que valorar el riesgo de impago, riesgos asociados al fracaso del proyecto, etc. En caso de que se produzcan dichos riesgos y hubiese pérdidas económicas, se agradecerá haber incluido dicho porcentaje por riesgos en el resto de proyectos de la empresa.

Pero pasamos a la estimación de coste que, bajo nuestro punto de vista, es el punto más complejo e importante (el resto de factores sacan porcentaje sobre el coste, por lo que éste resulta ser la base de todo el presupuesto). Hay que desglosar y estimar todos los costes asociados al proyecto, por ejemplo: coste de personal, de comidas con el cliente, de material (amortización de hardware y software, gasto en papel para los documentos, electricidad, etc.).

No se debe omitir ningún gasto por pequeño que parezca en un principio ya que una vez se firme el presupuesto con el cliente no habrá marcha atrás y cualquier coste no considerado tendrá que asumirlo la empresa que desarrolla el software.

La estimación que requiere de más experiencia es la de coste de personal, ya que si se sabe que materiales se van a dedicar para el proyecto, el cálculo de su coste es directo. Sin embargo, consideramos que dicha estimación es un tema suficientemente importante como para dedicarle otro post para él solo, que publicaremos en un par de días.

Hasta la próxima. Para cualquier duda, dejadla en los comentarios y la contestaremos lo antes posible.

Listado de Bibliografía

¡Hola a todos nuestros fieles blogueros! Esta entrada va a ser muy breve. Únicamente era para comentaros que hemos añadido un apartado (en la esquina inferior derecha) donde iremos poniendo un listado de la bibliografía (en estilo APA) que estamos utilizando para el desarrollo de nuestro sistema de información.

Por la cantidad de documentos que llevamos ya, es amplia y variada: existen el libro principal que estamos siguiendo (el Pressman), otros sobre UML, EJB's, diseño de sistemas operativos, arquitectura de redes, computación distribuida, etc.

En fin, nos parece bastante útil y sobre todo que puede ayudar a muchos compañeros.

Seguimiento del Documento de Análisis del Sistema

Buenos días. Vamos a comentar los resultados del último informe de seguimiento, ya que los hemos considerado interesantes para analizar. Ya comentaremos otro día en mayor profundidad la realización de informes de seguimiento pero hoy nos centraremos en los recursos (tiempo en minutos) utilizados para las tareas de análisis.

Si se observa el gráfico anterior, teniendo en cuenta que la zona sombrada eran los recursos estimados y la línea eran los recursos dedicados, se pueden sacar dos conclusiones principales:

1) La tarea de análisis se comenzó más tarde de lo planificado.

2) Se consumieron muchísimos más recursos de los estimados.

Todo esto, derivó en un retraso en la entrega del documento que nos fue imposible remediar. Es por esto, que hemos querido analizar las causas para que no se vuelva a repetir y compartirlas con todos vosotros para que no os suceda lo mismo que a nosotros (siempre parece que es imposible que ocurra hasta que ocurre).

El principal motivo por el que se comenzó tarde la tarea de análisis fue porque para la mayoría de apartados se necesitaba disponer de los requisitos de software definidos al principio del documento y la realización de estos requisitos dependía de la definición de requisitos de usuario que no habíamos completado correctamente en el anterior documento.

Además, en el momento que se comenzó el análisis, aún no estaban 100% definidos los requisitos de usuario del Estudio de Viabilidad del Sistema. Esto provocó que, al finalizar dichos requisitos, todos los apartados del análisis se vieron afectados, por lo que se produjo el ya mencionado aumento de recursos (tiempo) para este documento.

Esto ya nos dejó al límite para poder terminar análisis. Sin embargo, la última causa del retraso, fue un error en la estimación del tamaño del diseño de clases de análisis, lo que unido a que ya íbamos totalmente apurados, hizo que venciese el plazo de entrega antes de que pudiésemos unir y revisar todas las partes.

En conclusión, ante cualquier error en un documento hay que solucionarlo de inmediato, para que no afecte a documentos posteriores y siempre intentar llegar con tiempo de sobra al final para poder solucionar los imprevistos si alguien se apura en su parte (esto es más fácil de decir que de hacer pero siempre debe intentarse).

Hasta la próxima.

IT Crowd

Mientras realizamos la interminable fase de diseño, para relajarnos un poco hemos pensado recomendaros una serie de humor sobre informáticos. Ya era de esperar que todavía no hubiera una serie de humor por y para los "freaks".

La verdad es que parodian bastante bien nuestra profesión porque aunque parezca mentira hay personajillos con un nivel de freakismo igual o superio que Roy y Moss. Sin embargo, su punto fuerte pero a la vez débil es que las bromas o gracias que hacen es para un público muy concreto: los informáticos, así que si pensáis recomendar esta serie algún compañero ajeno al mundo de la informática, no creo que triunféis...

Pues hasta aquí la entrada de hoy, a continuación os pasamos un par de fragmentos encontrados por YouTube sobre IT Crowd. Ahm!!!! Para aquellos que no les gusten las series en inglés o subtituladas en español, n esta semana o la que viene la van a poner en Canal +.