QUÉ ES UN PROYECTO INFORMÁTICO

De la definición de proyectos, vista en el punto anterior, podemos aplicarla a los

proyectos informáticos; y decir que: un proyecto informático es un sistema de
cursos de acción simultáneos y/o secuenciales que incluye personas,
equipamientos de hardware, software y comunicaciones, enfocados en obtener
uno o más resultados deseables sobre un sistema de información.

El inicio de un proyecto informático generalmente está dado en la solicitud de

requerimientos de los usuarios, y siendo que los diferentes sistemas de
Información abordan los diferentes tipos de problemas organizacionales;
podemos clasificar a los Sistemas de Información según sean las aplicaciones
que necesite cada usuario en: Sistemas de Transacciones, Sistemas de
Soporte para la toma de decisiones, y Sistemas Expertos.

Están preliminares celebridades ni del objeto del proyecto hay que conocer la
organización y la requerimientos aen

Los 5 pasos para elaborar estimaciones de proyectos de software

1.- Revisar los requerimientos y el alcance

 Primero se establecen las expectativas de los interesados en cuanto a

la exactitud del estimado:
o Se expresan en un rango (por ejemplo más o menos 50%, 10% o
1%).
o A mayor información disponible, mayor exactitud.
o Por ejemplo, no se puede esperar un estimado de 1% cuando los
requerimientos son vagos o no se han analizado todavía lo suficiente.
 Luego debemos obtener los requerimientos funcionales:
“Los requerimientos funcionales son las descripciones explicitas del
comportamiento que debe tener una solución de software y que información
debe manejar.”
o ¿Existe una solicitud formal de requerimientos o especificación
de diseño funcional?
o ¿Están todos los puntos claramente definidos o existen
ambigüedades por resolver?
 Prestar atención a los requerimientos no funcionales:
Los requerimientos no funcionales son los que especifican criterios para
evaluar la operación de un servicio de tecnología de información, en contraste
con los requerimientos funcionales que especifican los comportamientos
específicos
o Por ejemplo de seguridad, tiempo de respuesta, tiempos para
mantenimientos, entre otros.
o Su no observancia puede hacer fracasar un proyecto.
 Debe indagarse sobre la mayor cantidad de detalles técnicos, las
dependencias externas y los requerimientos originales del negocio que
componen el estimado.
 Establecer claramente cuales funcionalidades estarán incluidas en el
estimado y mencionar explícitamente cuáles no.
 Evaluar las premisas, por ejemplo:
o ¿Estamos asumiendo que vamos a reutilizar software?, ¿ese
software reutilizado está en producción?, ¿fue probado adecuadamente?
o ¿Estamos asumiendo recursos que estarán disponibles, por
ejemplo ciertas personas expertas?, ¿qué ocurriría con el estimado sino
estuvieran disponibles y tuviera que reclutarse personas (con la
correspondiente curva de aprendizaje)?
o Debe evaluarse cualquier aspecto que sea fuente de
incertidumbre.

2.- Dimensionar el trabajo a realizar (desglose de trabajo)

 En este paso, nos enfocamos en el “Que” vamos a estimar.

 Debemos identificar los componentes que vamos a desarrollar, el nivel
de indagación y detalle dependerá del grado de exactitud que queremos dar a
nuestro estimado.
 Si queremos ser detallados, debemos identificar: Tablas y
procedimientos de bases de datos, servicios web, funciones y
procedimientos, pantallas, interfaces con otros componentes, etc.
 Este dimensionamiento no implica definir en detalle cada componente,
no esperamos definir con precisión sus entradas, salidas, posibles valores,
líneas de código, etc. Sin embargo, si esperamos poder identificarlos
individualmente y asignarles niveles de complejidad.
 Esta es la fase más importante para lograr una estimación acertada,
estudios demuestran que es la dimensión la que más influye en el estimado.
 Debe identificarse el nuevo software a desarrollar, pero ¿Qué hay del
existente?, modificaciones de componentes, pruebas para ver si funcionan y
otros aspectos deben tomarse en cuenta.
 Para identificar los componentes, puede recurrirse a la opinión de los
expertos, una metodología formal (desglosar por funciones o por casos de
uso por ejemplo), e inclusive dimensionamiento estadístico si disponemos de
información histórica de estimados pasados.
3.- Elaborar un primer estimado base del proyecto de software

Pues bien, ya sabemos que vamos a estimar, ahora debemos enfocarnos en el

“¿Cómo?”, para esto existen una amplia gama de técnicas de estimación, por
ejemplo:
 Métodos de medición de Proyectos: Estimación de 3 puntos, Técnicas
Delphi, COCOMO, Putman, y más recientemente Planning Poker (para
proyectos con metodología ágil).
 Métodos de medición de Puntos Función: FPUG FPA, MKII-FPA,
COSMIC FFP, FiSMA, Estimación temprana de NESMA, SiFP o Puntos
Función 3D.
 Otros métodos de medición funcional: Puntos de características
(Feature Points), Puntos de Casos de Uso o Puntos Objeto.
 Métodos de medición no funcional: Lógica Difusa (Fuzzy Logic),
Catalogo de Componentes (Standard Components), Puntos de Historia, T-
SHIRT Sizing o SNAP.

Entre los métodos de medición de proyectos (clásicos) más usados, está la

estimación de 3 puntos, que consiste en tomar el desglose de trabajo y
establecer un estimado optimista, moderado y pesimista por un experto. Otra
de las técnicas clásicas es la Delphi, que consiste en enviar la información a 3
expertos independientes y ponderar sus estimados.

Las técnicas clásicas dependen del conocimiento del experto, mientras que las
técnicas de puntos función o medición funcional, se basan más en
metodologías que calculan con precisión cada componente, ponderando la
complejidad de cada uno, e introduciendo modificadores según lo estable del
sistema o experiencia del equipo.

¿Cuál es el método más adecuado?, pues depende de la situación y además

es un tema con suficientemente amplitud para escribir otro post sobre él.

4.- Identificar y analizar los riesgos

 De acuerdo, tenemos nuestro primer estimado base, ahora

debemos considerar los riesgos.
 El riesgo no necesariamente es una amenaza si se gestiona
adecuadamente.
 Se deriva de la incertidumbre existente en cada componente a
desarrollar. Por ejemplo:
o Si una actividad depende de una premisa, existe el riesgo que
esta no se cumpla y esto tenga un impacto.
o Todas las actividades tienen insumos (un producto previo) y
recursos, si estos no están disponibles, ocurre un impacto. Ej. Proyectos
externos, recursos escasos, personal no disponible o costoso.
 Se caracteriza por pérdida de tiempo, costo, calidad, a esta pérdida se le
conoce como el impacto del riesgo.
 Para responder al riesgo se establecen acciones y planes de respuesta,
por ejemplo:
o Hacer provisiones en los estimados (agregar holgura).
o Agregar trabajo (más actividades y por ende mayor es la
estimación), para contemplar el trabajo que se está haciendo para mitigar el
riesgo.
 Más información sobre identificación de riesgos en este enlace.
 Una vez identificados los riesgos, debemos volver al paso 2 y 3 para
revisar nuevamente nuestros estimados.

5.- Validar y revisar el estimado

 Por último, siempre es una buena práctica realizar una evaluación formal
de los estimados.
 Para que sea objetiva debe ser realizada por alguien que no participó en
la elaboración de la estimación.
 En la evaluación, se revisa:
o Las bases del estimado, desglose de tareas, premisas,
restricciones.
o Si el procedimiento de estimación cumplió la metodología
establecida.
 Debe enfocarse en identificar:
o Premisas no ciertas o con alta probabilidad de no cumplirse.
o Riesgos no identificados.
o Posibles requerimientos extraordinarios.
o Requerimientos ocultos no identificados.