humberto unidad VI

Actividad
Precedencia
Duración
A
Realizar una entrevista
1 días
B
Investigación sobre el lenguaje A
de programación a utilizar
10 días
C
Establecer objetivos y metas
B
8 días
D
Diseño del software
B
10 días
E
Entrevista al cliente
B
1 días
F
Análisis de riesgo
E
3 días
G
Documentación
F,C
5 días
H
Codificación
D
15 días
I
Pruebas
H
5 días
J
Instalación del software
I
2 días
Diagrama PERT/CPM
4
E: 1
1
A:1
2
B:10
F: 3
C: 3
5
G: 5
9
D: 10
J: 2
6 H: 15
Ruta critica: A, B, D, H, I, J
7 I: 5
8
Grafica de Gantt.
A
A_
C
B _
T
C _
I
D _
V
E _
I
F _
D
G _
A
H _
D
I
_
E
J _
S
Dias
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42
Manejo de recursos:
Para la elaboración del software que se va a desarrollar es necesario contar
con los siguientes recursos materiales:
1. Hardware.
 HP pavilion slimline s7320n PC: 200 GB en disco duro, 1024
MB de memoria RAM, procesador Intel Celeron a 1.6 MHz,
2. Software.
 Microsoft visual FoxPro.
 Microsoft Project.
 Microsoft Windows XP profesional.
Tareas a realizar:
Es necesario tomar en cuenta las siguientes actividades en el transcurso de
desarrollo de dicho proyecto.
 La primera actividad a realizar fue Investigar sobre cual seria el proyecto
que abría que adoptar para su elaboración. 22 de septiembre del 2008.
 Realizar una entrevista al cliente para tomar acuerdos sobre sus
necesidades que se tendrían que cubrir con el desarrollo del proyecto
(software). 24 septiembre.
 Después de tomar acuerdos empecé a investigar sobre los posibles
lenguajes de programación que mas se adaptaran a las necesidades del
cliente y mis posibilidades. 25 a 01 octubre.
 Seleccione un lenguaje de programación y una herramienta que me
facilitará la administración del proyecto. 02 octubre.
 Establecí objetivos, metas, alcances, limitaciones y justificación que
conformarían la primera parte del proyecto. 03 a 10 octubre.
 Elabore un previo diseño sobre las posibilidades de forma que adoptaría
mi proyecto. 11 a 22 octubre.
 Realice otra entrevista al cliente para corroborar unos planteamientos de
diseño y pedir información que faltaba por adquirir. 13 octubre
 Empecé a elaborar la ruta crítica, diagramas pert/cpm, manejo de
recursos, grafica de Gantt, especificaciones de tareas y calculo de
costos. 23 a 31 octubre.
 Se realizará un análisis de riesgo y sus posibles soluciones. 03
noviembre a 07.
 Se realizará la programación de código del software. 03 a 28
noviembre.
 Se realizarán las pruebas más prudentes y necesarias para corroborar
que está funcionando correctamente. 03 a 07 diciembre.
Riesgos.
Riesgos técnicos.
Riesgos
Que en un futuro el
programa ya no sea
compatible con el SW y
HW con los que cuentes
los equipos de cómputo.
No prevenir algún tipo
de
error
en
la
codificación y tener que
implementar todo desde
el principio.
Que la interfaz mostrada
del software no sea
agradable
para
el
usuario.
Que el lenguaje de
programación no sea el
adecuado y por lo tanto
no
proporcione
las
herramientas
necesarias.
Que no se termine en
tiempo y hora
establecido.
Que se implementen
nuevas tecnologías de
administración en la
institución.
Solución
Tipo
Proporcionar facilidades Catastrófico.
de modificarse y que
pueda evolucionar sin
tantos problemas.
Estar
realizando Catastrófico.
pruebas continuas para
detectar
posibles
errores.
Llevar
acabo Critica.
retroalimentaciones
continuas.
Analizar cuál de todos Catastrófico.
cumple
con
las
expectativas requeridas
por el software.
Realizar una buena
planeación.
Ver las posibilidades de
que esto pase y tomar
una decisión, si es
conveniente realizar el
software o no.
Critica.
Catastrfico.
Riesgos de proyecto.
Riesgo
Que
por
causas
externas sufra algún
percance en mi persona
y
no
pueda
ser
terminado el proyecto
Que se deje de trabajar
en el proyecto porque al
cliente ya no le interese.
El cliente pida mejoras a
la mitad del proyecto y
tener que hacer una
modificación completa o
dejar de hacerlo.
Tenga que abandonar el
proyecto por problemas
con el cliente por no
tomar
los
acuerdos
necesarios.
Las
condiciones
de
trabajo por parte mía
marginen el desarrollo
del proyecto, es decir,
que no tenga el tiempo
suficiente
para
terminarlo.
Solución
Prevenir lo más posible Crítica.
cualquier
tipo
de
percance.
Tipo
Establecer un acuerdo Crítica.
entre ambas partes.
Establecer puntos en el Marginal.
proyecto, ¿qué se va a
ser? Y ¿cómo se va a
ser? Y así tener en claro
todo.
Dialogar
y
ambas Critica.
partes tener satisfacción
por lo que se está
haciendo.
Programar
las Catastrófico.
actividades y ponerlas
en claro.
Riesgos de negocio.
riesgos
Que la institución no
adopte el proyecto por
causas de licencias y
normalización.
Solución
Tipo
Investigar y saber qué Critica.
es lo que debe de
cumplir un software para
que
pueda
ser
implementado.
Que el producto no Tratar
de
realizarlo Critica.
encaje en la estrategia lomas posible a sus
del cliente, en su necesidades.
trabajo.
No tomar medidas de Tomar en cuenta las Marginal.
análisis
y
por políticas de la empresa.
consecuencia no cumplir
con
las
reglas
establecidas por parte
de la institución.
No se permita el uso de Establecer que es lo que Marginal.
ciertas herramientas por realmente se debe de
parte de la institución utilizar.
ocasionando que no se
pueda seguir con el
desarrollo del proyecto.