Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

PROYECTO
D o cum e nto
A nteproye cto

Pro ye cto

S iste m a
In fo rm tico
Fu ncio nando

Requerimiento 1: Sistema Informtico Funcionando. Nos comprometemos con las salidas (es la razn
de ser). Son los requerimientos, lgica para conseguir: S-E-P, recoleccin de datos, investigar ms que
quiere el usuario en las S-E-P. Salidas contienen: entradas, consultas (filtros), reportes.
Requerimiento 2: Documento Anteproyecto.
Requerimiento 3: Proyecto. Cuando se analiza que realizar en el proyecto; todo proyecto se puede
realizar.
Usuario (segn Intell): es el centro, lo que importa no es la tecnologa, sino lo que permite hacer esa
tecnologa.

Componentes de la Administracin de Proyectos Grficamente:

Iniciacin

Planeacin
y
Organizacin

Control

Ejecucin

El flujo es bidireccional entre todos los componentes.

Cada componente tiene las etapas del CVDP.
Iniciacin: Demuestra que si se puede iniciar el proyecto, contiene: platica con el jefe informtico, tema,
necesidades, solicitud de trabajo.
Planeacin y Organizacin: En las etapas, tareas y sub-tareas siempre auxiliarse de los usuarios de
negocio.
Control: Debe haber control en los 4 componentes para evitar atrasos en el proyecto, todo atraso de ser
controlado (investigar porque se dio el atraso y buscar como solventarlo) y lograr como recuperase del
Cierre
atraso (tratar de salir de una desgracia).
Ejecucin: En la etapa 2 de la tarea ex-aula no se hace pero hay que considerarse ciertas cosas basadas en
la planeacin y organizacin.
Si solo somos de tecnologa esta mala esa ideologa, si no estamos involucrados en el negocio para que la
empresa sea rentable.
Pensar en la mayor cantidad de cosas a plantear en una solucin para poder cubrir todos los imprevistos.
Todos somos incapaces en algo, no es que seamos locos; los locos han sobrepasado otra etapa u otro nivel
(como los nudistas).
Como desarrolladores hay que flexibilizar las cosas (no ser rgidos) para poder interpretar todo lo del
cliente y de donde sali todo.

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

ADMINISTRACIN DE PROYECTOS
Administracin de Proyectos: Es la aplicacin de conocimientos, habilidades, herramientas y

tcnicas para alcanzar los objetivos del proyecto.

Habilidades: Para recolectar datos, para tratar con los usuarios.
Tcnicas: Formas de trabajar (proceso administrativo, ciclo de vida para el desarrollo de proyectos).

Para que un proyecto sea exitoso debe cumplir estos requisitos:

1) Calidad.
2) Plazos.
3) Presupuestos.
4) Aceptacin del Cliente.
Calidad: En el sistema informtico tiene que haber validaciones a las entradas en la pc cliente y en la pc
servidor (server + SGBD), calidad en los clculos (por ejemplo en la aplicacin hay un clculo que hace la
sumatoria de una columna con otra columna y el usuario quera la multiplicacin de una columna con otra
columna).
Plazos: Realizar las cosas de ms importancia e ir avanzando paso a paso con todas las partes para ir
cumpliendo con el plazo.
Presupuestos: Gastar el dinero que se plante.
Aceptacin del Cliente: Alcance del proyecto. Es lo ms importante.

PROCESOS PARA LA ADMINISTRACIN DE PROYECTOS

Procesos para la Administracin de Proyectos: Es la aplicacin e integracin de procesos

en las diferentes fases del proyecto.

Siempre ver si nuestro proyecto est relacionado con otros proyectos para llevar todo bien integrado. Por
ejemplo: si en otro proyecto hay una tabla clientes y en nuestro proyecto tambin vamos a utilizar datos
de los clientes, es ideal usar esa misma tabla clientes del otro proyecto para integrar las cosas y tener
relacin con todo en la empresa.
Siempre documentar todo lo que se obtiene de los clientes.
1)

Administracin de la Comunicacin:
Es donde se describen las actividades necesarias para asignar una apropiada y oportuna generacin,
recoleccin, difusin y almacenamiento de la informacin de datos del proyecto.
Administracin de comunicaciones es entre usuarios de negocio y usuarios tcnicos, se debe hablar
sobre los atrasos y el rumbo que lleva el proyecto.
Comunicar primero lo malo luego lo bueno de todo lo que ocurre y debemos ir almacenando (un
reporte de lo comunicado) e informando cada 3 das por lo menos. Generacin, recoleccin, difusin y
almacenamiento documentarlo en todo momento.
Un proceso exitoso se logra: Entregarse en el tiempo que tenga las salidas, que no tenga errores y que
sea validado por el usuario.
80% de errores validado por usuarios tcnicos, 15% de errores validados por usuarios de negocio y 5%
de errores que pueden operarse en la del proyecto.
Para que existan resultados debe haber validaciones a las entradas no a las salidas.
Validar en el cliente y en las entradas de la base de datos, tener siempre seguridad.
Llevar siempre una bitcora del proyecto, desde que inicia.
Pedir siempre por adelantado un lapso de tiempo para reuniones con los usuarios de negocio.

2)

Administracin de Riesgos:
Es un proceso sistemtico para identificar, analizar y responder los riesgos del proyecto.
Lo importante es minimizar los resultados de los riesgos y maximizar los resultados positivos de las
oportunidades.
Minimizar los resultados: Saber cmo medio controlarlos. Preguntarse: Si ocurre un riesgo, que se
debe hacer?
La administracin de riesgos es el nuevo enfoque de apaciguar todo tipo de riesgos en la empresa.
A veces se piensa que los riesgos son de afuera hacia adentro pero hoy en da muchas veces es de
adentro hacia afuera.
Hoy en da lo que exige la sper intendencia financiera es que debe haber un oficial de riesgo.
Hay que identificar que puede causar problemas y tener planes de contingencia.

3)

Administracin del Abastecimiento del Proyecto:

Es analizar la adquisicin de bienes y servicios que necesitamos en el proyecto con el fin de cumplir con
el alcance del proyecto.
El abastecimiento es tambin de personal no solo de cosas materiales.
Alcance del proyecto sistema informtico funcionando libre de errores y aceptado por el usuario, en
el tiempo acordado y brindando los resultados solicitados.

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

4)

Administracin de Costos:
Son las actividades del presupuesto necesario del proyecto y su control para que la oportunidad de
mejora se finalice con el presupuesto aprobado.
El control permite que el proyecto sobreviva, nos dice cmo se va usando el presupuesto.
Administrar el tiempo es controlar una parte de los costos.
Hay que controlar las cosas que se usan aunque no nos demos cuenta que las utilizamos pueden
afectar en los costos.
En la administracin de costos si se pact (presupuesto) el tiempo y dinero que se va a utilizar en el
proyecto y luego en la ejecucin del proyecto no se cumple lo que se pact, hacer la medida posible
de cumplir los presupuestos.
Todo hay que medirlo en funcin de tiempo y dinero, esas dos variables se pueden administrar al
controlar la administracin de costos.
Lo interesante de la administracin es entender los procesos del negocio.

Administracin de Calidad:
Es tomar en cuenta las polticas de calidad definidas para que la solucin satisfaga las necesidades para
las cuales llego la oportunidad de mejora.
- Disminuir defectos, aumentar la calidad.
Como primer punto: Entregar bien los resultados (buenas capturas de datos, lgica en los resultados).
Como segundo punto: Deben llevar las polticas de calidad (congruente con lo pactado. Ejemplo:
mens tal cual se haba hecho en los prototipos). Los prototipos son los resultados que deben poder
medirse (ser cuantitativos) en: Tiempo, dinero, recurso humano.
Como ingenieros hay que usar el ingenio para hacer que las cosas funcionen y si no funcionan hay que
investigar porque fallan y hacer todo lo posible para que funcionen (solucionar las cosas).
La administracin de la calidad est relacionado con la administracin del tiempo y el dinero, as que la
calidad es otra variable.
La administracin de calidad en resumidas cuentas es reducir defectos para aumentar la calidad. Los
defectos afectan el producto que se est realizando. Ejemplo de defectos es: no obtener los reportes
esperados, tener errores en la captura de datos, etc.
En el desarrollo de proyectos la calidad no es muy manejable, la calidad tiene que ser contemplada
desde las necesidades (recordar que a partir de las necesidades se tiene: necesidades perfil
anteproyecto, de igual forma hay que considerar la calidad en los procesos administrativos lo que
conlleva a considerar la calidad en el ciclo de vida para desarrollo de proyectos).
Las pruebas son parte del control y se realizan para tener calidad.
Un desarrollador debe ser el mejor probador (o testing) de su propio trabajo, realizando hasta las
pruebas ms locas, as reduce la cantidad de fallas que pueda tener su trabajo.
Con las pruebas se encuentran defectos, estos defectos se resuelven y se tiene calidad.

5)

6)

Administracin del Recurso Humano:

Tener claro los procesos que organizan y dirigen el equipo de trabajo en el proyecto para que estn
motivados y generen resultados aceptados.
Hay que aprender a trabajar por objetivos, para lograr metas, para tener una buena paga.
Hay que aprender a motivarse a uno mismo para poder motivar al equipo de trabajo.

GESTIN DE PROYECTOS
Gestin de Proyectos: una de las herramientas bsicas para el proyecto es divisin del trabajo. Esto

es dividir el proyecto en actividades, sub-actividades y tareas para planificacin, presupuestario y control.

Algo complejo partirlo en cosas ms sencillas.
Dividirlo en base al ciclo de vida para desarrollo de proyectos.
Control: Supervisar los presupuestos.
Elementos del proyecto:
Es necesario considerar:
1)

Alcance:
En base a tres factores:

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Recursos

Presupuesto

Alcance

Tiempo

Factores se refiere a limitantes.

Estos tres factores hay que saber conjugarlos para obtener los resultados en el proyecto como el
usuario quiere.
Pensar las cosas en top down en 3 niveles: actividades sub-actividades tareas sub-tareas (en
ltima instancia si las tareas son muy largas para proyectos complejos se crean sub-tareas).
No hay cosas aisladas, hay que buscar el smil de todo en lo que se relaciona.

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

2) Riesgos:
- Es todo aquello que impida alcanzar con xito los objetivos del proyecto.
- Son factores desconocidos o inciertos que requieren de una atencin.
- Los riesgos tienen atributos:
1 - Probabilidad de ocurrencia:
i) Alta. ii) Media. iii) Baja.
2 - Impacto:
i) Alto. ii) Medio. iii) Bajo.
3 - Estrategia de riesgos:
i) Evitarlos.
ii) Aceptarlos.
a) Identificar el riesgo.
b) Preparar los planes de contingencia.
4 - Tipos de riesgos:
i) Financieros.
ii) Tecnolgicos.
iii) Polticos.
iv) Ambientales.
v) Legislativos.
5 - Administracin de riesgos:
i) Llevar una lista de riesgos.
Nombre
Proyecto:
N Riesg Descripci Tip
o.
o
n
o

MANEJO DE RIESGOS
Probabilidad de
Impac
Plan
Plan
Ocurrencia
to
Contingencia A Contingencia B

Haraganear no es riesgo es una realidad pero provoca que el proyecto se atrase. Nos atrasamos
porque nos confiamos que somos muy buenos haciendo las tareas.
Siempre tener 3 estrategias de riesgos.
Ejemplo de evitar riesgos: Mantenimiento preventivo de las computadoras, tratar que los riesgos se
consoliden.
Ejemplo de aceptar riesgos:
Identificar Si alguien del equipo de trabajo se va.
Plan Redistribuir las tareas con los miembros del equipo de trabajo que queda, todos los integrantes
del equipo de trabajo deben tener copias de los documentos fuentes, tener personal dispuesto a
cubrirlo, realizar contratos de trabajo, etc.
Evitar los riesgos es antes de que comenzar el proyecto.
Se debe buscar calidad en el sistema informtico desde el anlisis, el diseo y las pruebas.
En la lista de riesgos identificar cinco o seis riesgos importantes.
En los planes de contingencia se tiene: Plan normal (o plan original es con el que se trabaja desde el
inicio), si falla usar el plan A, luego B si falla A, etc. (soluciones o alternativas de solucin).
Al hacer planes de contingencia hay que tomar en cuenta las actividades de la ruta crtica del
diagrama de Gantt.
Siempre estar preparado y pre visualizar percances.
3) Criterios de xito:
- Para medir el xito del proyecto se debe alinearse con el negocio.
- El xito se mide con respecto a los objetivos del negocio cubiertos y costos incurridos.
- El xito se orienta al valor agregado del negocio y los aspectos tcnicos necesarios.
- Factores de xito:
1 - Producto terminado segn especificaciones iniciales y el alcance.
2 - Tiempos de respuesta.
3 - Calidad (# de defectos reportados).
4 - Reutilizacin de componentes.
El producto terminado son las 12 salidas terminadas y en buena calidad. Estar alineado con el negocio,
pasar procesos manuales a procesos mecanizados con 12 requerimientos tiles y diferentes.
Los tiempos de respuestas es en la factibilidad operativa y hay que conocer la factibilidad tcnica.
Volmenes de datos y factibilidad tcnica se deben usar para tener buenos tiempos de respuestas.
Si el nmero de defectos son muchos la calidad es mala (disminuye). Hay que validar con el usuario
para tener la calidad que del usuario. As de una vez el usuario conoce todo lo que se est haciendo en
el proyecto.
Por eso es recomendable que en casa paso del proyecto siempre verificar y validar con el usuario.
La reutilizacin de componentes (est relacionado con la modularidad) es tener centralizada las cosas.
Por ejemplo una funcin para validar las fechas.

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

4) Personas:
- Tener un equipo de trabajo adecuado con las habilidades requeridas para el proyecto.
- Normalmente los equipos de alto rendimiento constan de 3 a 4 personas, incluyendo al lder.
- Organizar el equipo en un conjunto de roles tcnicos y no tcnicos.
- Organizar a la gente implica dar instrucciones claras a cada miembro del equipo de trabajo para que no
existan malos entendidos.
El rol no tcnico es entender al usuario de negocio, lo que implica conocer la unidad de negocio. Este
rol es el que deberamos manejar muy bien.
Primero hay que organizarnos a nosotros mismos para tener buenos resultados, mejor control, tener
xito y as fcilmente poder llevar/organizar un equipo de trabajo de alto rendimiento.
El equipo de alto rendimiento es el que produce lo que tiene que producir. El equipo de trabajo est
formado por usuarios tcnicos y usuarios de negocio.
Al administrar personas hay que definir estndares (dar instrucciones).
El recurso humano y los procedimientos apoyan al sistema informtico para que funcione los siete das
de la semana las veinticuatro horas del da, sin ello no funcionaria.
Primero prevalece el grupo y luego lo individual.
Tener buenas relaciones con los usuarios de negocio ya que ellos nos proporcionan la informacin.
No dejar puntos oscuros con los usuarios, siempre aclarecer y exteriorizar todos los puntos.
Con estos elementos del proyecto podemos tener una visin clara del proyecto:
a) La cual es una descripcin del escenario deseado en el proyecto por el equipo de trabajo que tiene a su
cargo la oportunidad de mejora.
b) Es lo que quiere d la oportunidad de mejora en un futuro.
El escenario es: Los requerimientos/necesidades, los usuarios de negocio, el tema, los objetivos. Tener todo
entendido: Lo que se quiere obtener y tener todo paso a paso. Tener todo paso a paso en top down: 1tema, 2- solicitud de trabajo, 3- perfil, 4- anteproyecto, 5- proyecto.
La visin clara es entender a futuro nuestro proyecto en base a los objetivos y el beneficio.
La visin clara es una forma de decir el alcance (por eso hay que tenerlo de una forma clara). Es la mejor
forma de trabajar juntos los usuarios tcnicos con los usuarios de negocio hacia un destino comn.
Lo que se necesita saber de la empresa es la unidad de negocio y el giro de la empresa para usarlo en los
antecedentes, es ms que suficiente.
Entre ms fcil se resuelvan las cosas y se crean cosas nuevas, mucho ms fcil sern los resultados,
habr mejor mantenimiento con una buena administracin.
Un buen administrador ayuda con sus habilidades a todo el equipo de trabajo.

MTODOS DE DESARROLLO DE PROYECTOS

Mtodo Prctico de Desarrollo de Proyectos:
- Qu es un proceso de desarrollo?: Es el conjunto de actividades necesarias para transformar los
requerimientos de los usuarios en un sistema informtico funcionando
- Un buen proceso desarrollo se basa:
1- Rol: Es el papel que debe ser ejecutado por un individuo en un equipo de trabajo.
2- Actividad: Describe una porcin de trabajo que un rol debe realizar.
3- Artefacto o Producto: Pieza de informacin que es producida, modificada o usada en el proceso.
La administracin siempre estar basada en personas.
Rol: Usuario de negocio o tcnico, hay tambin doble roles, por ejemplo: Jefe que tambin es ayudante.
Evitar roles netamente tcnicos y reforzarlos al negocio porque ellos nos pagan.
Como ya se sabe, se pueden tener actividades, sub actividades y tareas. Y recordar que cada una tiene
salidas, entradas y procesos.
Como recomendacin hacer una encuesta por separado para entradas, procesos y salidas para conocer
las actividades a realizar.
Primero planificar y luego trabajar.
Se debe de trabajar con hitos.
Lo importante es hacer mediciones de todo para tener un mejor control.
Sin importar que no se ejecute y construya la solucin hay que definir igualmente todas las actividades
para las etapas del ciclo de vida para el desarrollo de proyectos.
Las actividades tiene responsables, en los equipos de trabajos todos son lderes y uno es el que coordina
todo, las responsabilidades en las actividades se distribuyen as: 33%, 33% y 34%.
-

Proceso Unificado de Desarrollo de Proyecto:

Fue desarrollado en conjunto con el estndar UML.
Es dirigido por casos de uso.
Se enfoca en la arquitectura del sistema.
Es interactivo e incremental.
Basado en las mejores prcticas de la industria de Informtica.
Arquitectura: Elementos que forman parte del proyecto.
Interactivo: Con que elementos satisfacer las salidas bsicas, como se procesan esos datos.

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Practicas: Entender los requerimientos del usuario, entender la unidad de negocio, realizar pruebas de
conceptos (1- validar documentos fuente, 2- realizar pruebas de validacin) validados y verificados con el
usuario de negocio.
Preguntar las cosas solo dos veces (la primera vez cuando se quiere saber algo y la segunda vez para
confirmar si se capt lo que el usuario nos explic), ms de dos veces da la impresin de que no se
entiende lo que nos dicen o que no ponemos atencin.
Proceso Dirigido Por Casos de Uso:
- Los casos de uso capturan la funcionalidad del sistema en lenguaje del usuario (requerimientos funcionales)
- Los proyectos se crean para servir a los usuarios.
- El xito se basa en las necesidades de los usuarios.
Los casos de uso son aceptados fcilmente por los usuarios, ellos logran hacerse entender y nosotros
logramos enfocar y administrar el desarrollo.

MODELOS DE CICLOS DE VIDA

Ciclo de Vida para el Desarrollo de Proyectos:
- El desarrollo puede verse como una cadena de actividades con productos intermedios, esa visin es la del
CVDP.
1
- El ciclo de vida para el desarrollo de proyectos es:

Planea
miento

Produc
cin y
Mante
nimien
to

Elabor
acin

- Desglose del ciclo de vida para el desarrollo de proyectos:

Necesida
des

Anlisis

Diseo

Construc
cin

Pruebas

Documen
tacin

Plan de
Impleme
ntacin

Resultad
os

Administracin de Proyectos Informticos

La elaboracin es la parte de desarrollo y es probada y aceptada por l usuario.

Entre la elaboracin y la produccin y mantenimiento hay un ciclo continuo de mejora.
El CVDP es una herramienta de trabajo para el facilitador del trabajo y administrar los proyectos.
En el proceso de desarrollo de software, tenemos: Conjunto de actividades que generan productos
intermedios, estos a su vez son transformados en otros productos por otros procesos.

Modelos de Ciclos de Vida (MCV):

- Para este enfoque se mencionaran tres modelos:
1) Cascada:
- Histricamente este es el primero de todos los modelos.

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Se hacen dos testeos separados por el paso de parmetros al unir las dos partes del sistema.
Aqu los resultados se presentan al usuario en etapas refinadas en forma excesiva a diferencia del
modelo de ciclo de vida en prototipo, cuando se da entrega por etapas se conoce que se va a construir.
Lo importante de este modelo es que la solucin se va entregando por partes.
2) Prueba y Error:
- Pobre o nulo en el uso de anlisis y diseo.
Requicitos
Pobres

Prueba y
Error

Resultados
Incompletos

En este modelo no se tiene documentacin.

Este modelo no debe ser usado.
3) Prototipo:
- Hace pruebas de escritorio, de validacin de usuario.
- El cliente recibe resultados parciales, con los cuales puede experimentar su uso y depurar lo que se le
instala.

Disear, Construir e Instalar el Modulo

Conceptualizacin
Completar
y Entregar
el Modulo
Refinar
el Prototipo
Hasta que Se Acepte
RAD

Conceptualizacin es la parte del anlisis; disear, construir e instalar el modulo es la parte del
diseo.
La conceptualizacin incluye el diagrama de sistemas o de contexto donde se tienen todas las salidas,
entradas y procesos.
Disear: Es solo la porcin que se va a desarrollar.
Construir: Programar y probar la funcionalidad de forma individual e integral.
Parametrizar: Darle a los usuarios solo lo que necesita por medio de perfiles.
RAD: Desarrollo rpido de aplicaciones, siempre basado en las mejores prcticas de la industria.
Elaborar informes cortos o sea resmenes sobro los logros obtenidos (+/-) en los puntos de control de
las tareas trabajadas.

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Este es un modelo de ciclo de vida en el que se desarrolla el concepto del sistema a medida que
avanza el proyecto.
Normalmente se inicia desarrollando los aspectos que el usuario define como iniciales del sistema.
Se presenta la parte de la aplicacin desarrollada al cliente y se contina el desarrollo del prototipo
con las retroalimentaciones que se reciben de los usuarios.
Este modelo se utiliza cuando los requerimientos cambian con alguna rapidez o cuando el usuario no
provee en forma adecuada los requerimientos.
Punto fundamental para ir evolucionando son las salidas priorizndolas desde la ms alta prioridad a la
de menor prioridad, ac se le entregan soluciones parciales al usuario con este modelo.
Se le vende la idea al usuario de ir mejorando continuamente el prototipo.
El inconveniente de este modelo de ciclo de vida es el de no conocer al inicio del proyecto lo que
tardara en crear un proyecto aceptable.
- Dentro de cada modelo de ciclo de vida va asociado un ciclo de vida para el desarrollo de proyectos, puede
ser: Tradicional, estructurado u orientado a objetos.
Elementos a Usar en el Proceso Administrativo del Proyecto:
1- Seleccionar el MCV y CVDP.
2- Administracin de personal.
3- Organizar el equipo de trabajo.
4- Entregas del proyecto:
i) Todas las actividades/tareas/sub-tareas deben generar resultados tangibles para dar seguimiento del
progreso obtenido.
El CVDP tradicional es el lenguaje natura (de forma narrativa), el CVDP estructurado es en base a
estructuras y diagramas, el CVDP orientado a objetos es en base a UML.
Cada actividades/tareas/sub-tareas es un sub-sistema y tienen sus propias S-E-P. utilizar siempre todo
como un sub-sistema con S-E-P y solucionarlo con el ciclo de vida para el desarrollo de proyectos.
Los resultados aunque sean chiquitos, pero siempre hay resultados.
Los resultados tangibles es todo lo que se puede medir, responde al cunto.
Entregar porciones del proyecto para que el usuario se entere de lo que se est produciendo y nos vaya
corrigiendo para ir elaborando lo que el usuario quiere y para que el usuario no crea que no se est
haciendo nada (que no se est realizando el proyecto) o que el proyecto, para que al final no llegar con
la solucin terminada y resulte que no es lo que quera el usuario (por no irle informando al usuario el
progreso del proyecto).
Es recomendable primero probar con datos malos los mdulos que se desarrollen del sistema y en el
progreso en el que se validan ir probando con datos buenos y as sucesivamente para ir produciendo un
proyecto con pocos errores.
Todas las cosas que estn en el plan de trabajo hay salidas desde la entrada de datos y para ello debe
haber un convertidor (procesos).
Seguimiento del progreso del proyecto es por ejemplo: si una actividad est programada a terminar el
10-oct y termina el 8-oct es un progreso excelente, si termina el 10-oct es un progreso muy bueno, si
termina el 15-oct es un progreso ms o menos bueno, si termina el 20-oct es un progreso malo del
proyecto.
Se tiene que definir la entrega del proyecto, en el cual debemos considerar:
- Actividades o tareas a realizar, se debe estructurar de forma que genere resultados tangibles para dar
seguimiento.
- Definir puntos finales sobre las tareas y producir informes con los logros alcanzados.
Del proceso administrativo se va a utilizar un modelo de ciclo de vida de proyectos.
El plan de accin es tener el proceso administrativo ms un modelo de ciclo de vida.
Resultados tangibles son hechos que nos permiten lograr avances en nuestro proyecto.
Si algo se atrasa entra en accin el plan de contingencia que incluye tres elementos:
- Tareas.
- Resultados o informes de avances.
- Plan de contingencia.
Se debe tener un plan de accin primordialmente de la ruta crtica.
Los informes gerenciales que se presentan deben tener por a lo mucho 10 15 lneas y hay revisarlo
por lo menos dos veces.
Herramientas de Software para Administracin de Proyectos Informticos:
- Para agilizar la administracin de proyectos es necesario el uso de herramientas de productividad que
permitan el control y toma de decisiones para lograr xito en el proyecto en base a calidad, tiempo,
costos y documentacin adecuada.
- Algunos software:
1- Project Kickstart.
2- Open Project.
3- MS Project.
Una herramienta de productividad es solo apoyo para planificar los tiempos.

PLAN DE COMUNICACIN

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Plan de Comunicacin:
- Las fases iniciales de los proyectos son excelentes vehculos para establecer comunicacin entre los usuarios
de negocios y los usuarios tcnicos involucrados en el proyecto, para este elemento creamos reuniones.
En la elaboracin de planes de desarrollo se forja el trabajo de equipo.
Para llevar a cabo el proyecto se realizan reuniones de trabajo.
El equipo de trabajo tiene que entregar informes del progreso del proyecto al jefe de los usuarios de
negocio y al jefe de los usuarios tcnicos, as todos conocen como se va desarrollando el proyecto. Y
siempre dar copia de los reportes a los integrantes del equipo de trabajo (a los usuarios de negocio y a
los usuarios tcnicos). La documentacin debe ser cuasi-perfecta. Si somos buenos documentadores, solo
de eso se puede trabajar.
Al entregar los informes hay que:
- Presentar un plan de trabajo con diagrama de Gantt con: Tiempos, actividades de trabajo.
- Hacer luego un resumen de utilidad: Mostrar la utilidad del plan de trabajo.
Utopas: Buscar cero defectos por calidad.
Todo lo que se hace en un trabajo tcnico se debe saber para qu va servir (entender lo que se usa).
La comunicacin debe ser directa (verbalmente en reuniones presenciales de trabajo sobre el proyecto)
con los usuarios comunicacin personal. Comunicacin impersonal usando internet como medio de
comunicacin (video llamadas, chats, etc.).
El plan de comunicaciones es como vamos a divulgar (informes, consultas, etc.) todo a los usuarios de
negocio y a los usuarios tcnicos.
En la reuniones cuando se sale del tema hay que ser suspicaz e inteligente para decir no diciendo si sin
ofender.
Base para Reuniones:
- Se debe tener un objetivo claro.
- Sirven para formacin y entrenamiento.
- Tener cuidado en detalles para lograr resultados en cada uno de los trabajos a desarrollar.
Objetivo claro (objetivo general): Lo que se quiere alcanzar en la reunin (cosas pequeas).
Factor de xito en la Administracin de Proyectos Informticos:
- Tipos de reuniones:
1- Revisin del estado del proyecto. A veces da miedo.
2- Planificacin de actividades del proyecto.
3- Recopilar requerimientos.
4- Solucin de problemas y toma de decisiones. Ver que se hace.
5- Discusin de mejoras en algunas cosas. Ver alternativas.
6- Presentacin y anlisis de resultados.
Logstica:
- Cada sesin de trabajo debe tener agenda y calendario.
- Disponer del alcance, lista de tareas y expectativas a cubrir para lograr un valor agregado.
Roles:
- Director de la reunin: Lder del equipo de trabajo, organiza cada reunin en base a la de tareas, logstica y
dirige la reunin.
- Secretario: Registra las actividades desarrolladas, anota cosas importantes y planea cursos de accin, se
asegura que los tems de la accin son compartidos con los asistentes despus de la reunin.
- Cronometrador: Asegura mantener la agenda y el tiempo, colabora para que siga la agenda de la reunin.
- Miembros: Participantes en la reunin para aportar conocimiento.
En los roles de la reunin todos somos lderes, cualquiera puede dirigir una reunin, solo hay que saber
comunicarse con los dems miembros de la reunin (hacer lo humanamente posible en base a la lista de
tareas y logstica) y todos deben solicitar hablar en la reunin para que haya orden y respeto para que no
se salga de control la reunin.
El secretario anota cosas importantes, las acciones discutidas, las decisiones a trabajar, las cosas que
quedan pendientes, todo esto lo realiza en una minuta o resumen de la reunin y es responsable de
pasarlo al resto del equipo de trabajo. Los puntos pendientes se deben tratar en la siguiente reunin que
se realice, para ello hay que convocar una reunin solo para terminar una lista de tareas con puntos
pendientes en reuniones anteriores y no montar ms puntos en la lista de tareas con puntos pendientes,
para eso hay que organizar otra reunin aparte para tratar los nuevos puntos de una nueva lista de
tareas.
El cronometrador vigila el tiempo sobre los temas que se tratan, tiene en cuenta costo/beneficio, criterio
para poder detener un tema y pasar al siguiente tema o punto de la lista de tarea de la agenda de la
reunin. Si se sigue la agenda se le facilita el trabajo al cronometrador.
Cada agenda debe tener un objetivo.
Todos los miembros de la reunin tienen que aportar en algo a los puntos que se estn tratando de la
lista de tareas de la agenda, porque todos lo asisten a la reunin tienen al menos dos roles, el rol de
miembro y otro adicional (director, secretario o cronometrador).
Polticas:

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

-

Cada participante debe recibir la agenda y materiales.

Enviar invitacin anticipada con ubicacin y horarios.
El lder debe garantizar que los miembros asistan con actitud correcta y mente abierta.
Asegurarse de mantener el tiempo estipulado.
Garantizar que todos los miembros participen.
Asegurarse que el secretario envi la minuta o resumen de la reunin.
Las polticas son para que todo tenga un orden y haya paz en las reuniones.
En la invitacin adjuntar la agenda, la invitacin enviarla siempre por correo electrnico.
Hay que respetar los horarios porque la gente de negocio tiene siempre trabajo pendiente que hacer en
sus labores de la empresa.
Formas de planear reuniones de trabajo:
- Asignar tiempo de inicio y finalizacin de la reunin.
- Preparar una versin preliminar de los aspectos a tratar en la agenda; dar una copia a cada miembro.
- Iniciar a tiempo la reunin.
- Anotar los aspectos que requieran acciones.
- Mantener la discusin dentro del tema.
- Enviar por correo electrnico los puntos importantes y resumen de la reunin.

Normas para Elaborar la Agenda:

Llegar a un acuerdo sobre los puntos de la agenda a tratar y la asignacin de tiempos.
Solicitar voluntarios para: secretario, facilitador y cronometrador.
Informar sobre el avance o retraso del proyecto (Mximo 10 minutos).
Los temas a tratar deben estar en orden de prioridad. Se recomienda que el tema sobre el avance/retraso
del proyecto sea el primer punto a tratar.
- Revisar la disposicin a trabajar y quienes sern los responsables.
- Respetar la agenda.
Siempre hay que planificar, ejecutar y controlar al elaborar la agenda y se debe poner tiempos a darle a
los involucrados para tener una retroalimentacin.
Identificar lo bueno o malo independientemente de si hay avances o atrasos.
Revisar las decisiones a trabajar.
La agenda es la lista de tareas.
Hay que tener cuidado con el tiempo de los usuarios de negocio porque ellos nos dan la pauta.
Si no podemos (o no sabemos) algo, mejor porque vamos a aprender y si sabemos, es an mejor porque
podemos mejorar en ese algo. Siempre pensar en positivo.
El secretario, el facilitador o el cronometrador pueden ser tambin usuarios de negocio y pueden ser
mejor porque ellos son exigentes.
Antes de ir a la reunin hacer un anlisis de cmo va el proyecto si hay adelanto/atraso o cabal como
debera de ir. Ver el progreso del proyecto en base a las tareas realizadas en porcentaje, al final se dice si
el proyecto va un porcentaje adelantado/atrasado (sumando los porcentajes de la tareas
adelantadas/atrasadas) e identificar porque hay avance/retraso para ver qu fue lo bueno/malo que se
hiso en las tareas (hay que tener un buen ojo clnico para identificar todo eso).
Hay que aprender primero a autoevaluarnos para identificar (conocer) y hacerse responsable (tener
criterio) de las causas por las que se pueda atrasar un proyecto.
Si hay justificacin en los atrasos, estos deben ser reales, validos, importantes.
Todo lo de la lista de tareas debe tener prioridades pero no dejar sin tratar los puntos que se dejen por
ltima prioridad.
Tambin hay que priorizar las decisiones de mayor importancia, despus las urgentes (porque puede
que no sean importantes).
Tener documentado los responsables de las decisiones en toda tarea debe haber un responsable a
llevarla a cabo para que despus nadie se haga el que no sabe cundo tena asignado una tarea por
hacer.
Hay que aprender a auto-capacitarnos porque invertir en capacitaciones es muy costoso.
Si un campo requiere una longitud de 1 al menos dejarlo de 2 o a lo mucho de longitud 3 porque si se
llega a 9 y se necesita ms valores con esto se prev y se solventa falta de espacio para los caracteres
en los campos. por ejemplo para el nombre de una persona hacer:
- nombre1 char(25) porque al menos se debe almacenar un nombre de una persona.
- nombre2 char(75) para poder almacenar el segundo nombre de una persona y si se da el caso tambin
poder almacenar un tercer nombre en el mismo campo.
- apellido1 (25) porque al menos se debe almacenar un apellido de una persona.
- apellido2 (75) para poder almacenar el segundo apellido de una persona y si se da el caso tambin poder
almacenar el apellido de casada en el mismo campo.
Cul es la diferencia de validar y verificar? Cul es primero?
- Validacin: Es una prueba o un control que hacemos probando el producto tal y como lo hara el cliente,
por eso la flecha de validacin se dirige hacia las necesidades del cliente. Es la comprobacin con
respecto a su usabilidad final, es decir para ver si funciona o no el producto para lo cual se construy.
Ejemplo: Un microondas pues si al final de la cadena de produccin sus funciones tcnicas funcionan ha
sufrido una validacin del producto.
- Verificacin: Es un control ms especfico y normalmente previo a la validacin, en la verificacin
comprobamos la conformidad de uno o ms requisitos del producto, el cumplimiento de todos estos
requisitos har posible que el producto pueda utilizarse tal y como se ha diseado, por eso se dirige a las
-

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

especificaciones. Es una comprobacin propiamente dicha. Ejemplo: Un operario, todas las maanas
comprueba con su patrn que su balanza de pesaje esta calibrada, para comenzar su jornada laboral con
garantas que lo que se va a pesar estar dentro de sus estndares.
- en resumen: Validar es dar por bueno, verificar es comprobar que algo est dentro de la verdad (que es
tal y como se dijo) y revisar es observar peridicamente su desarrollo.
Corroborar la informacin de un reporte si es lo que debe generar de resultado.

BUENAS PRCTICAS
- El desarrollo de proyectos informticos est en constante evolucin.
- Con metodologa AGILE incluye especial atencin al seguimiento de la calidad del software.
Metodologa AGILE es el desarrollo de software basado en procesos giles, esto el enfoque gil de la
gestin de proyectos tanto para proyectos de desarrollo de software como para otros muchos proyectos
de desarrollo en otras reas y se valora:
- A los individuos y su interaccin por encima de los procesos y las herramientas.
- El software que funciona por encima de la documentacin exhaustiva.
- La colaboracin con el cliente por encima de la negociacin contractual.
- La respuesta al cambio, por encima del seguimiento de un plan.
Tenemos algunas prcticas beneficiosas para el desarrollo de software:
1) Entender los requisitos.
2) Crear documento de requisitos con todos los requerimientos obtenidos.
3) Ser proactivo al reunirse con los usuarios en cualquier aclaracin o ampliacin de requisitos y ser sincero si
un requisito es poco realista.
4) El equipo de prueba debe participar en el anlisis de requisitos.
5) Comenzar a construir despus de entender totalmente el diseo de la solucin.
6) Esforzarse en cumplir reuniones de revisiones con los miembros del equipo de trabajo (negocio, tcnico).
7) Configurar un ambiente de desarrollo similar al ambiente de produccin.
8) Realizar pruebas despus de la construccin de cada elemento funcional (pantallas, reportes, mens,
validaciones, seguridad, etc.).
9) Ofrecer actualizaciones frecuentes de los progresos realizados al cliente.
10) Hacer una lista de cosas que puede variar entre el ambiente de desarrollo y el ambiente de produccin.
11) Elaborar documentacin de usuario con la mayor sencillez posible.
12) Realizar siempre pruebas de regresin.
Punto 1:
Los requisitos son requerimientos que se van a implementar en el software.
Al reducir los defectos aumenta la calidad; esto se logra al realizar pruebas absurdas.
Siempre buscar, detectar y corregir errores aumentar la calidad lo que implica aumentar ganancias.
Punto 2:
Los ingenieros de una gran cantidad de informacin que reciben toman lo que le interesa y lo documentan
(hbitos de informacin a partir de un anlisis).
Punto 3:
Proactivo es anticipar, es pensar en todos los riesgos y documentarlos. Reactivo es actuar cuando ocurren
las cosas.
Anticiparnos a lo que vamos a las reuniones (agenda, lista de tareas, local, tiempo) y no esperar lo que
caiga.
Los requisitos de los usuarios hay que recapitalizar las ideas, anotar todo e investigarlo para entenderlo, no
hay que desechar nada que nos diga el usuario aunque nos parezcan raras y como nos parece raro no le
tomamos importancia y puede que sea importante para el usuario, as conocemos a la unidad de negocio.
Esa cosas rara o poco realistas (utopas) que nos puedan mencionar los usuarios, hay que hacerlas
realidades.
Punto 4:
El equipo de prueba realiza casos de pruebas (pensar en todo tipos de pruebas correctas/incorrectas) esto
conlleva a la seguridad.
Desde el inicio detectar casos de pruebas en todas las etapas del proyecto, corregir pruebas y asociarlo a
la seguridad.
Es una mala prctica usar el CVDP de prueba y error.
Punto 5:
Al analizar/investigar los requisitos de los usuarios, se logran buenos diseos. Tener buenos y claros los
requerimientos para tener un buen anlisis y un buen diseo.
Todo ingeniero se basa en ir del inicio al fin y viceversa esto se logra al dominar todo lo que hemos
aprendido de los usuarios de negocio sin dificultad lo que genera no dar medias soluciones.
Punto 6:
Si un requisito es vago o poco especifico, hay que platicarlo y hacerlo especifico con el usuario.
Punto 7:
El concepto de ambiente que nos interesa es: Informtico, desarrollo, produccin (cuando est instalado el
software).
Punto 8:

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Hacer pruebas chiquitas despus de terminar cualquier cosa, es mejor probar en poquitos para evitar fallas
grandes. No esperar hacer pruebas cuando ya se tienen todos los elementos terminados.
Punto 9:
Presentar avances (buenos/malos) del desarrollo, ser siempre honestos. Esto tomarlo como costo/beneficio.
Punto 10:
Cuando se hacen cosas raras en el desarrollo, hay que tomar hacerlas en desarrollo y produccin anotando
todo los procesos y pasos que se realizan, as no ocurrirn imprevistos en el ambiente de produccin.
Esta lista es para verificar lo que se ha configurado y al instalarlo en el ambiente de produccin funcione.
Definir en el plan de implementacin las pruebas realizadas o por realizar.
Punto 11:
La documentacin de usuario la debe entender una persona que solo sepa leer/escribir.
Punto 12:
Regresin es: Tener dos elementos elaborados y probados individualmente y en conjunto, agregar un
elemento ms y probar ahora los tres elementos que se tienen individualmente y en conjunto y as
sucesivamente cada vez que se agrega un nuevo elemento, al final el primer elemento se ha probado nveces y se puede estar seguro que el primer elemento tiene menos fallos.

ESTIMACIONES
Estimacin del Esfuerzo:
- En la elaboracin del plan de accin deberamos considerar: Estimar el esfuerzo para el desarrollo del
proyecto.
- Es necesario definir lo que costara la elaboracin de la aplicacin en base a horas-personas, y dinero.
Modelo Propuesto para Estimar:
A) Contenido:

Usuarios

Necesidad
es

Plan de
Trabajo

Tareas a
Realizar

Usuario
de
Negocio y
TIN

Las necesidades es lo que se va a usar para el plan de trabajo.

El plan de trabajo es la accin.
B) DFD:

Los resultados que quiere el usuario van asociados a las validaciones y verificacin de los datos de salidaentradas-procesos. Los procesos contienen depsito de archivos internos y externos. Los archivos
internos son de la aplicacin, son a los que se les hace el abc (altas-bajas-cambios o adicionar-borrarcambiar que representa el mantenimiento de una tabla: insert-delete-uptate). Los archivos externos son
los que estn fuera de la aplicacin, porque la aplicacin no les da el abc si no que se los da otra
aplicacin, lo nico que hace nuestra aplicacin son select a los datos de los archivos externos. Los
archivos externos se relacionan con la aplicacin para evitar la redundancia de tablas, solo se hace una
integracin. Para conocer cules son los archivos externos hay que investigar que interrelacin tiene
nuestro proyecto con otros proyectos ya funcionando de la empresa para evitar la redundancia de las
tablas que se utilizan en la empresa.
De los documentos fuente se sacan las tablas (archivos internos) que se van a utilizar en nuestra
aplicacin (tablas-campos-datos). Las tablas no son catlogos.
Los resultados que quiere el usuario son los requerimientos refinados.
Estimar lo que costara se a partir de la factibilidad operativa.
Dividir en actividades/tareas/sub-tareas es lo que se va a realizar con todos los elementos necesarios
(responsable, costo, tiempo, fecha de inicio y fin).

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Historial de la empresa de otros proyectos que se pueden utilizar, si no se tiene un historial de la empresa
se puede crear (no cuesta).
Con las estimaciones se completa el plan de trabajo, la lista de actividades del diagrama de Gantt.
1) Obtener lo que el Usuario Quiere:
- Tener claridad en lo solicitado por el usuario para obtener mediciones correctas.
2) Estimar los que Costara:
- Podemos considerar lo siguiente:
a) Experiencia Individual: Es toda la prctica adquirida en el desarrollo de aplicaciones.
b) Experiencia en la Empresa: Se basa en obtener informacin histrica de otros proyectos para
obtener conocimiento y aplicarlos a nuestro proyecto.
Lo solicitado por el usuario hay que entender (es lo fundamental) bien las salidas (reportes, consultas
o listados), es lo que necesita para trabajar en su unidad de negocio. Gestionar, validar, guardar, etc.
No son nombres de reportes (no son salidas) son nombres procesos.
Obtener informacin histrica sobre los proyectos desarrollados e identificar cosas buenas y malas
para trabajar nuestro proyecto.
Mtodos para Estimacin en Proyecto:
1) Basados en la experiencia.
a) Juicio del experto.
i) Individual.
ii) Mtodo de trabajo Delphi.
1 - Se dan las especificaciones a un grupo de expertos.
2 - Discuten el producto y la estimacin en reuniones.
3 - Envan sus estimaciones en forma individual al coordinador del proyecto.
4 - Cada experto recibe retroalimentacin sobre su estimacin y de los otros expertos en forma
annima.
5 - Se renen de nuevo para discutir las estimaciones.
6 - Cada uno revisa su estimacin mejorada y la enva al coordinador del proyecto.
7 - Se repite el proceso hasta que la estimacin sea aceptada.
b) Analgica.
- Es comparar las especificaciones de un proyecto con las especificaciones de otro proyecto. Esta
tcnica puede variar por los factores: tamao del proyecto, complejidad del proyecto, usuarios.
Estimar es medir algo de lo que queremos hacer.
La utilizacin de mtodos es el corazn de la administracin de proyectos informticos. Los mtodos
tambin se usan en base a la experiencia en desarrollo del CVDP.
Como grupo se usa el mtodo de trabajo Delphi. El mtodo Delphi es juntar a un grupo de personas
con criterios (ser capaces de tener lgica propia y analizar por su propia cuenta) individuales y
luego hacer una integracin de las estimaciones de cada uno del grupo.
Las especificaciones son los resultados esperados (necesidades), estas especificaciones son de
salidas, entradas y algunas veces de procesos (para los archivos). Especificaciones tcnicas de S-EP.
El producto es el sistema informtico funcionando libre de errores. Cada persona del grupo hace
una estimacin de las unidades funcionales del producto (las S-E-P), estas estimaciones individuales
(por cada persona del grupo) son clasificadas detalladamente por cada elemento del proyecto,
luego se las envan al integrador/coordinador del proyecto y l se las reenva todas juntas en un
solo documento integrado incluyendo las estimaciones de las dems personas del grupo pero sin
decir quien hiso las estimaciones, lo que interesa es guiar a las personas del grupo para que
vean/analicen como han trabajado los dems en base a su experiencia en otros proyectos (es
importante compartir conocimiento/experticia, siempre hay que aportar al grupo).
Como recomendacin repetir tres veces el mtodo de trabajo Delphi porque las personas del grupo
deben tener un grado de experiencia y a la primera iteracin se debe generar buenas estimaciones
y as no se pierde tiempo realizando las estimaciones del proyecto.
El mtodo Delphi se va a usar en la etapa 2 de la tarea ex-aula por el grupo de expertos para las
estimaciones del proyecto y hay incluir en los anexos el resumen (integracin de la estampaciones
individuales hecha por cada persona del grupo) de las tres iteraciones del mtodo.
Otro mtodo basado en la experiencia es el de analoga pero no es muy bueno porque compara el
proyecto que se va a desarrollar con otros proyectos ya realizados. Un proyecto no puede ser
comparado con otros proyectos, cada proyecto es considerado nico, no se va a calcar lo que est
en un proyecto en otro proyecto porque de esta forma se van replicando los errores y fallas
ocurridos en el proyecto que se est copiando. Cada proyecto es diferente porque varan muchos
factores a pesar de que sean para lo mismo, cada proyecto es personalizado a una unidad de
negocio (empresa, giro de la empresa, etc.) por lo tanto no pueden haber proyectos parecidos.
Lo nico que hay que conservar de otros proyectos es la experiencia (conocimiento convertido en
experiencia aplicado a un nuevo proyecto) obtenida al haber realizado proyectos pasados.
El tamao de los proyectos son distintos porque las salidas no son las mismas por lo tanto no hay
proyectos iguales.
Tambin varan los tipos de usuarios siendo ms colaboradores o menos colaboradores.
Los sistemas informticos gerenciales son ms difciles que los sistemas informticos
transaccionales por el tipo de usuarios, los SIG son proyectos pequeos pero de dificultad grande.

Clases Examen Parcial 2 de Administracin de Proyectos Informticos 2012

Hacer las cosas customizadas especficamente/especialmente para cada proyecto, para ello hay
que indagar profundamente para diferenciar un proyecto de otro. Los proyectos hay que verlos
detalladamente/individualmente/independientemente de otros proyectos, que los proyectos estn
interrelacionados con algunos procesos o algunas tablas aun as siguen siendo independientes.
Se pueden utilizar otros proyectos como lineamientos pero no es lo mismo a que se usen como
plantilla (no se va a copiar su lgica y contenido, solo su estructura) porque los proyectos tiene
comportamientos diferentes.
La administracin se basa en las personas (recurso humano), a controlar el recurso humano y
motivarlos porque es una familia de trabajo y hay que velar por el grupo.
2) Basados en componentes del producto.
a) Bottom up.
- Se compone el proyecto en unidades pequeas y luego se analizan para formar componentes ms
grandes hasta formar el sistema completo. Se estima por cada componente pequeo.
b) Tod down.
- Se ve todo el proyecto se descompone en bloques o partes, se estima el costo total de cada
componente.
Buscar cmo se estima basado en los componentes del sistema. Primero se estima en base al
tiempo que se va a invertir en cada unidad seccionada en salidas, entradas y procesos (incluyendo
mens, validaciones, pantallas, etc.).
Las estimacin se hacen en base al tiempo no se evala en base a dinero.
Con el mtodo bottom up se hacen las estimaciones de abajo hacia arriba.
Con el mtodo top down se hacen las estimaciones de arriba hacia abajo.
Lo saludable es hacer las cosas individualmente para poder reutilizarlas (asociadas a la
modularidad) en otras partes del proyecto dando la pauta para hacer ms fcil las cosas incluso las
pruebas de regresin.
- Concusin de los mtodos para estimacin en proyecto: Por lo tanto para estimar es necesario medir.