Plan de Administración de Proyecto de Software Final

Tabla de contenido
1.
2.
Plan de Administracin de Proyecto de Software..........................................................................3

1.1.
Introduccin................................................................................................................. 3
1.2.
Propsito del Plan de Proyecto........................................................................................... 4
Mtricas en el Software.......................................................................................................... 4
2.1.
3.
2.1.1.
aSc TimeTables v2015.............................................................................................. 4
2.1.2.
Apeiron................................................................................................................. 6
2.1.3.
Horarios GHC......................................................................................................... 7
2.2.
Mtricas Orientadas a Tamao........................................................................................... 9
2.3.
Mtricas Orientadas a Funcin........................................................................................... 9
mbitos del Proyecto.......................................................................................................... 15

3.1.
5.
Objetivos del Proyecto.................................................................................................. 15
3.1.1.
Objetivo General................................................................................................... 15
3.1.2.
Objetivos Especficos.............................................................................................. 15
3.2.
Requerimientos Principales............................................................................................. 15
3.3.
Rendimiento............................................................................................................... 15
3.4.
Fiabilidad................................................................................................................... 16
3.5.
Restricciones.............................................................................................................. 16
3.5.1.
Tcnicas.............................................................................................................. 16
3.5.2.
Legales............................................................................................................... 16
3.5.3.
Recursos............................................................................................................. 17
3.6.
4.
Software Similares......................................................................................................... 4
Interfaces Externas....................................................................................................... 17
Estimaciones..................................................................................................................... 18
4.1.
K.L.D.C..................................................................................................................... 18
4.2.
COCOMO II............................................................................................................... 18
4.2.1.
De Acuerdo al Tamao............................................................................................ 18
4.2.2.
De Acuerdo a la complejidad.................................................................................... 19
4.3.
Ecuacin del Software................................................................................................... 19
4.4.
Estimacin de Tiempo................................................................................................... 20
Planificacin Temporal........................................................................................................ 20
5.1.
IDENTIFICAR ACTIVIDADES...................................................................................... 21
1
5.2.
ASIGNACION DE TIEMPO.......................................................................................... 22
5.2.1.
Diagrama de Gantt................................................................................................. 23
5.2.2.
Diagrama PERT.................................................................................................... 25
6.
Anlisis de Riesgo.............................................................................................................. 26
7.
Tabla de Recursos............................................................................................................... 28
8.
Organizacin Interna........................................................................................................... 29
8.1.
Estructura del equipo..................................................................................................... 29
Mecanismo de Seguimiento y Control...................................................................................... 30
9.
10.
Bibliografa................................................................................................................... 31
11.
Anexos......................................................................................................................... 32
11.1.
Anexo 1................................................................................................................. 32
11.2.
Anexo 2................................................................................................................. 33
11.3.
Anexo 3................................................................................................................. 33
11.4.
Anexo 4................................................................................................................. 34
11.5.
Anexo 5................................................................................................................. 35
1. Plan de Administracin de Proyecto de Software

1.1.
Introduccin
La computacin desde sus inicios ha sufrido muchos cambios, desde los grandes ordenadores que permitan
realizar tareas en forma limitada, hasta los actuales ordenadores ya sean personales o porttiles que tienen las
mismas e incluso mayores capacidades que los primeros y que estn cada vez ms introducidos en el quehacer
cotidiano de una persona.
Tambin cabe recalcar que acompaando el avance tecnolgico de los ordenadores, nos encontramos con el
desarrollo de las redes de rea local y de las comunicaciones que permitieron conectar ordenadores con
posibilidad de transferencia de datos a alta velocidad.
As mismo esto trajo consigo lo que se conoce como el desarrollo de sistemas distribuidos que puede ser
definido, como una coleccin de computadores autnomos conectados por una red, y con el software
distribuido adecuado para que el sistema sea visto por los usuarios como una nica entidad capaz de
proporcionar facilidades de computacin. El software distribuido permite a los ordenadores coordinar sus
actividades y compartir los recursos del sistema - hardware, software y datos.
Citando con mayor nfasis a las redes de rea local es que nos encontramos con una de las que actualmente
tiene mayor uso, la red inalmbrica la cual permite que la gente se pueda comunicar y realizar clculos
fcilmente, desde donde quieran, cuando quieran y sin cables. Las Redes Inalmbricas facilitan la operacin
en lugares donde la computadora no puede permanecer en un solo lugar.
El conjunto de todos estos conceptos permite aunar intereses y buscar utilidades del agrado de los usuarios,
que permitan mantener el crecimiento en beneficio de prestaciones a nuevos servicios.
Con referencia a nuevos servicios, conocemos que la tendencia de los estudiantes cada semestre universitario
es poder organizar de manera ptima su planificacin de horarios debiendo tener acceso a sus datos de
materias disponibles desde sus dispositivos porttiles, es por ello que hoy en da muchas universidades dentro
y fuera del pas; apuestan por este tipo de sistemas el cual es mucho ms cmodo, ya que se ahorra tiempo y
es ms preciso que otros mtodos tradicionales.
A travs del presente proyecto se pretende implementar una aplicacin Web para la Asistencia de Gestor de
Horarios
1.2.
Propsito del Plan de Proyecto
El propsito de este documento es presentar un plan de proyecto para la administracin del desarrollo de una
aplicacin mvil para la gestin de horarios acadmicos en la UAGRM (Horarios). La intencin de este
documento es presentar un marco de trabajo que permita identificar informacin acerca del proyecto
incluyendo el tipo de proceso de gestin a utilizar, la funcionalidad de la aplicacin, los recursos necesarios
para desarrollarlo, la estimacin en esfuerzo, tiempo y coste del proyecto, hitos a conseguir y una lista de
actividades del proceso.
2. Mtricas en el Software
2.1.
Software Similares
2.1.1.
aSc TimeTables v2015
Crear un horario escolar es bastante complicado, sobre todo cuando se imparten muchas asignaturas, hay una
gran plantilla de profesorado e, incluso, una misma clase se divide para dar materias distintas.
Horarios de Clases es un programa que ofrece una creacin fcil y rpida de horarios con asignaturas, clases,
profesores y horas semanales que imparte cada profesor, posibilitando incluso cubrir todos tipos de
distribuciones especiales o agregar varios profesores a una clase. Adems, la configuracin de las asignaturas,
clases, y profesores puede fijarse individualmente, avisndote el programa de si se puede asignar la clase de
matemticas a cierta hora o si un profesor est disponible el martes a primera hora, por ejemplo.
A partir de sus exigencias, Horarios de Clases genera en unos pocos minutos el horario completo teniendo en
cuenta todas las exigencias organizativas. Distribuye proporcionalmente las asignaturas por toda la semana,
controla las lecciones enteras y divididas y coloca las materias en las aulas que ms convengan. Horarios de
Clases tambin verifica la especificacin del horario y le ayuda a eliminar los fallos estndar para que puedas
hacer cambios manualmente y estar tranquilo por si cometes un error, ya que esta herramienta te avisar.
El programa, que piensa en todo, aade adems 'aSc Suplencias' para que ests preparado para resolver los
problemas cotidianos propios de la gestin de sustituciones, generando informes mensuales y anuales de los
ausentes y de las suplencias segn el tipo de sustitucin.
2.1.2. Apeiron
Es una herramienta para alumnos de la Universidad de Guadalajara (UdG) que ayuda a la elaboracin de horarios
en SIIAU.
2.1.3. Horarios GHC

Es el generador de horarios para centros de enseanza, es una ayuda eficaz para la gestin completa de horarios
escolares.
Destinado a todos los centros escolares de primaria, secundaria, bachillerato, ciclos formativos y otras ofertas
educativas, su objetivo fundamental es encajar los horarios escolares semanales observando todas las condiciones
necesarias en cada centro de enseanza.
Est dividido en tres partes:
Planificador
Posibilidad de configurar dos marcos horarios independientes que se solapan con toda libertad. Mayor facilidad de
uso para la configuracin del horario.
Motor
Mejora de la optimizacin general del horario.

Mayor rapidez en la obtencin de resultados y ms capacidad para hacer que estos sean ms equilibrados.
Editor
Muestra nuevos informes acerca de las condiciones de satisfaccin previamente establecidas: resumen de los
resultados por profesor: huecos, etc.
2.2.
Mtricas Orientadas a Tamao

PROYECT
O
aScTimeTa
bles
TIEMP
O
ERROR
ES
DEFECT
OS
GENTE
ESFUER
ZO
4.9
10
50
10
100
Apeiron
1.2
60
36
Ghc
Horarios
1.6
53
63
KLDC
ESFUEZO=TIEMPOGENTE
PROYECTO
CALIDAD
PRODUCTIVIDAD
aSc TimeTables
11,6
49
Apeiron
56.6
33.33
Ghc Horarios
36.8
25.4
CALIDAD=
ERRORES+ DEFECTOS
KLDC
PRODUCTIVIDAD=
2.3.
KLDC
1000
ESFUERZO
Mtricas Orientadas a Funcin.
aSc TimeTables
Parmetros de Medicin
Entradas de Usuario
Las salidas de usuario
Las peticiones
Archivos
Interfaces Externas
Cuenta
Factor de Peso(-Esfuerzo+)
Simple
Medio
Complejo
Total
13
9
8
42
3
3
4
3
7
5
39
45
32
294
15
4
5
4
10
7
6
7
6
15
10
Cantidad total
425
10
0
El sistema requiere respaldo y recuperacin
confiable?
Se requiere comunicacin de datos
especializada para transferir informacin a la
aplicacin, u obtenerla de ella?
Hay funciones distribuidas de procesamiento?
El desempeo es crtico?
El sistema se ejecutara en un entorno existente
que tiene un uso pesado de operaciones?
El sistema requiere entrada de datos en lnea?
La entrada de datos en lnea requiere que la
transaccin de entrada se construya en varias
pantallas u operaciones?
Los ALI se actualizan en lnea?
Las entradas, las salidas, los archivos o las
consultas son complejas?
Es complejo el procedimiento interno?
El cdigo interno esta reutilizable?
Se incluye la conversin e instalacin en el
diseo?
Est diseado el sistema para instalaciones
mltiples en diferentes organizaciones?
La aplicacin est diseada para facilitar el
cambio y para que el usuario lo use fcilmente?
Esencial
Significativo
Medio
1
x
3
2
x
x
2
x
3
4
x
x
51
( )]
14
PF=Cantidad 0.65+0.01
calidad=
Moderado
Incidental
No Influye
Factor
fi = 425 [ 0.65+ 0.51 ] =493
i=1
errores
PF
=0.10
productividad=
PF
Personas =49.3
11
Apeiron
Parmetros de Medicin
Total
13
8
5
12
1
3
4
3
7
5
39
32
15
120
5
4
5
34
10
7
6
7
6
15
10
Esencial
Significativo
Moderado
Medio
Incidental
211
Factor
El sistema requiere
respaldo y
recuperacin
confiable?
Se requiere
comunicacin de
datos especializada
para transferir
informacin a la
aplicacin, u
obtenerla de ella?
Hay funciones
distribuidas de
procesamiento?
El desempeo es
crtico?
El sistema se
ejecutara en un
entorno existente que
tiene un uso pesado
de operaciones?
El sistema requiere
entrada de datos en
lnea?
La entrada de datos
en lnea requiere que
Simple
Medio
Complejo
No Influye
Entradas de Usuario
Las salidas de usuario
Las peticiones
Archivos
Interfaces Externas
Cantidad total
Cuenta
12
la transaccin de
entrada se construya
en varias pantallas u
operaciones?
Los ALI se
actualizan en lnea?
Las entradas, las
salidas, los archivos o
las consultas son
complejas?
Es complejo el
procedimiento
interno?
El cdigo interno
esta reutilizable?
Se incluye la
conversin e
instalacin en el
diseo?
Est diseado el
sistema para
instalaciones
mltiples en
diferentes
organizaciones?
La aplicacin est
diseada para
facilitar el cambio y
para que el usuario lo
use fcilmente?
( )]
14
calidad=
38
fi =211[ 0.65+0.38 ] =217.33
i=1
errores
PF
=0.27
productividad=
PF
Personas = 36.2
Ghc Horarios
13
Parmetros de
Medicin
Cuenta
Entradas de Usuario
Las salidas de
usuario
Las peticiones
Archivos
Interfaces Externas
13
Simple Medio Complejo
3
4
6
Total
39
12
48
10
12
6
3
7
5
4
10
7
6
15
10
40
84
30
Cantidad
total
El sistema requiere respaldo y

recuperacin confiable?
Se requiere comunicacin de datos
especializada para transferir
informacin a la aplicacin, u
obtenerla de ella?
Hay funciones distribuidas de
procesamiento?
El desempeo es crtico?
El sistema se ejecutara en un entorno
existente que tiene un uso pesado de
operaciones?
El sistema requiere entrada de datos
en lnea?
La entrada de datos en lnea
requiere que la transaccin de entrada
se construya en varias pantallas u
operaciones?
Incidental
Moderado
Medio
Significativo
Esencial
Factor
No Influye
241
2
x
2
x
x
x
x
3
2
1
0
14
Los ALI se actualizan en lnea?

Las entradas, las salidas, los
archivos o las consultas son
complejas?
Es complejo el procedimiento
interno?
El cdigo interno esta reutilizable?
Se incluye la conversin e
instalacin en el diseo?
Est diseado el sistema para
instalaciones mltiples en diferentes
organizaciones?
La aplicacin est diseada para
facilitar el cambio y para que el
usuario lo use fcilmente?
x
x
2
3
2
3
calidad=
errores
PF
productividad=
32
( )]
14
fi =241 [ 0.65+0.32 ] =0.97241=233.77
i=1
PF
Personas =25.9
15
3. mbitos del Proyecto

3.1.
Objetivos del Proyecto
3.1.1.
Objetivo General
Desarrollar una aplicacin multiplataforma para la gestin de horarios universitarios

3.1.2.
Objetivos Especficos
Realizar una
captura de requerimientos, identificando primeramente a los
posibles usuarios del software a desarrollar, para luego poder determinar los
requerimientos de acuerdo a las expectativas del usuario
Analizar los Requerimientos obtenidos para definir los requisitos del software.
Obtener los datos de alumnos y sus carreras para registrar las materias y
posibles horarios
Incluir Patrones de Diseo Estandarizados que permitan mejor Rendimiento y

Calidad del Producto.
3.2.
Requerimientos Principales
RP1: Gestin de Horario

Se debe contar con una interfaz para la creacin y respectivo registro del horario tomando en cuenta las
materias y horas asignadas que tiene determinada carrera donde el estudiante deber elegir las materias a
cursar.
RP2: Consulta de Malla
Se debe tener acceso a la vista de la malla curricular del alumno, mostrando las materias aprobadas, las
materias habilitadas y materias por cursar
3.3.
Rendimiento
El tiempo de respuesta del software debe ser el mnimo teniendo muy en cuenta el desempeo y el estado de la
red del cliente o del establecimiento, debido a que un tiempo de respuesta largo, provocara que el software
16
tenga un tiempo igual o mayor que el uso de los mtodos tradicionales para la planificacin de horarios, lo que
podra provocar desorden y caos.
3.4.
Fiabilidad
El proyecto, al estar involucrado en la planificacin de horarios, sabiendo que este es un proceso de suma
importancia para cada estudiante a travs de su vida acadmica, garantizar este proceso es esencial, de esta
manera se debe prever que ante la posible falla de la red el dispositivo mvil almacena en una base de datos
interna el horario elegido y tambin puede almacenar momentneamente la informacin de su malla curricular
hasta que se conecte nuevamente al servidor. Obteniendo de esta manera un alto grado de fiabilidad.
3.5.
Restricciones
3.5.1.
Tcnicas
El dispositivo mvil al que est destinado el software, deber contar con conexin de datos y/o
permitir conexin va Wireless.
3.5.2.
Hardware de Control para el servidor, con gran almacenamiento de datos.

Legales
No existe ninguna restriccin legal que impida el desarrollo y venta de software, no existe ningn
ordenamiento jurdico que impida o lo restrinja, porque bajo el principio de libertad contractual
puedes realizar un contrato de venta de cualquier cosa o con cualquier objeto, siempre que este no
se encuentre en contra del orden pblico, las buenas costumbres o sobre pase los lmites de la ley.
Es decir se tiene va libre para desarrollar y establecer un contrato de venta de software siempre y
cuando el contratante este en total acuerdo con las condiciones del proyecto.
El software de Horarios, no se ve afectado ni tiene que regirse por alguna ley pblica, ya que es una
herramienta que ayudar a los estudiantes en la planificacin semestral. Solo se ver afectada por
las clusulas que se tenga en el contrato y deber regirse de acuerdo a las normas y polticas
internas de la universidad. Algunas clusulas del contrato pueden ser:
1. Fecha lmite de entrega.
17
2. Si el software presenta alguna falla, el gestor deber subsanar el error.

3. El cliente debe cumplir con las especificaciones y requerimientos necesarios para garantizar
el buen funcionamiento del software.
4. El software debe ser un beneficio y no un perjuicio para el cliente.
5. En caso de que no se cumpla con lo establecido en el proyecto el cliente no est obligado a
comprar el software.
Algunas normas y polticas de la universidad pueden ser:
1. Facilidad de uso para los estudiantes que harn uso del software.
2. El tiempo de armado del horario debe ser menor que el de la manera tradicional (elegir
docentes y ver opciones en papel).
3. Debe poder ver el horario aunque no exista conexin con el servidor
4. No debe mostrar datos confidenciales de los alumnos o de la universidad.
3.5.3.
Recursos
3.6.
El tiempo de desarrollo del software no debe ser mayor a 6 meses.
Interfaces Externas
El software interacta con las siguientes interfaces externas:

Base de datos remota del servidor
18
4. Estimaciones
Para realizar las estimaciones correspondientes al proyecto, se han recurrido a 4 tipos de estimaciones
distintas, algunas de las cuales toman en cuenta diversos factores como lneas de cdigo del programa, grado
de complejidad del proyecto, esfuerzo, objetos a emplearse y otros ms.
4.1.
K.L.D.C.
El propsito de este mtodo es poder estimar cuantas KLDC podra tener un software que recin vamos a
desarrollar.
Proyecto
Proyecto 1
Proyecto 2
Proyecto 3
V e=
Optimista
3.4
Pesimista
KLDC
Ms Probable
Esperado
5.1666
7.2
5.1
(Optimista+ 4Mas Probable+ Pesimista ) (3.4+ ( 45.1 ) +7.2)

=
=5.1666
6
6
4.2.
COCOMO II
COCOMO (Modelo Constructivo de Costos) es un ejemplo de un modelo esttico de estimacin.

4.2.1.
De Acuerdo al Tamao
Tipo de
Objeto
PO = Puntos
Cta
.
Pantalla
10
Informes
8
Componente
4
3GL
P.O.
100
Factor de peso
Simple
Medio
1
2
-
2
5
-
Total
Avanzad
o
3
8
10
20
40
40
Objetos=Puntos
de Funcion
PON = Nmero de puntos objetos
19
P .O . N .=P . O
4.2.2.
.( 100 de Reutilizacion ) 100( 10020 )

=
=80
100
100
De Acuerdo a la complejidad
Proporciones de
productividad
Muy
baja
Baj
a
Capacidad y madurez
del desarrollador
Capacidad y madurez
del entorno
PROD
20
Norm
al
Alta
Muy
Alta
Total
13
7
4
X
7
13
25
50
PROD.
E=
P .O . N . 80
= =4( personas/mes)
Produ . 20
4.3.
Ecuacin del Software

3
LDCB 0.333
1
P
E=
t4
Definicin:
E = esfuerzo en personas- mes o persona-ao.
t = duracin del proyecto en meses o aos.
B = <<factor especial de destrezas>>, en donde incremente a medida que crecen la necesidad de
integracin, pruebas, garanta de calidad, documentacin y habilidad de administracin. Para programas
20
pequeos KLDC = 5 a 15 B = 0.16; para programas intermedios KLDC = 16 a 69 B = 0.28; para

programas mayores de 70 KLDC B = 0.39.
P = <<parmetro de productividad>> que refleja:
Madurez global del proceso y de las prcticas de gestin.
La amplitud hasta donde se utilizan correctamente las normas de la ingeniera del software.
El nivel de los lenguajes de programacin utilizados. El estado del entorno del software.
Las habilidades y la experiencia del software.
La complejidad de la aplicacin.
Valor de P:
P = 2000 software empotrado en tiempo real.
P = 10000 telecomunicaciones y software de sistemas.
P = 28000 aplicaciones comerciales de sistema.
KLDC = 5.1666
Entonces B = 0.16
t = 120 das 4 meses/12=0.333
5166.660.16
10000
E=
0.3334
0.333 3
) 1
E=1.7979 personas-mes
4.4.
Estimacin de Tiempo
Para poder estimar el tiempo, recurrimos a la frmula de Putnam y Myers, obtenida de la ecuacin del software:
T min=8.14
LDC
P
0.43
=8.14
5166.66
10000
0.43
=6.127 meses.
5. Planificacin Temporal
Todo proyecto requiere una planificacin del tiempo a emplear en las diversas actividades que se van a llevar a
cabo para el cumplimiento del mismo, a travs de 2 diagramas se pretende mostrar la distribucin de tiempos
21
planificada, primeramente el diagrama de Gantt, a travs del cual se podr apreciar el tiempo que se le va a otorgar
para la realizacin de cada actividad y las actividades que son requisitos para realizar otras actividades.
Mientras que en el diagrama PERT se podr apreciar las relaciones de cada actividad una con otra y as mismo se
podr ver la ruta critica el proyecto, es decir aquellas actividades que un retraso en las mismas ocasionara un
retraso en todas las dems actividades y por lo tanto un retraso en el proyecto en s.
En planificacin temporal se consideran 2 etapas:
5.1.
IDENTIFICAR ACTIVIDADES
Para desarrollar el software aplicaremos como estrategias las actividades de Scrum

Actividad
A 1 Definicin del Backlog del Producto
A 1.1 Definir Ideas del Producto
A 1.2 Detallar Ideas
A 1.3 Analizar Ideas
A 1.4 Disear Ideas
A 1.5 Priorizar Ideas
A 2 Sprint 1(Maestros)
A 2.1 Planificacin del Sprint
A 2.2 Ejecucin del Sprint
A 2.3 Retrospectiva del Sprint
A 2.4 Refinamiento del Backlog del Producto
A 3 Sprint 2(Materias)
A 4 Sprint 3(Alumnos)
A 5 Sprint 4(Horarios)
22
5.2.
ASIGNACION DE TIEMPO
Actividad
A 1 Definicin del Backlog del Producto
A 1.1 Definir Ideas del Producto
A 1.2 Detallar Ideas
A 1.3 Analizar Ideas
A 1.4 Disear Ideas
A 1.5 Priorizar Ideas
A 2 Sprint 1
A 3 Sprint 2
A 4 Sprint 3
A 5 Sprint 4
Despus de
A 1.1
A 1.2
A 1.3
A 1.4
A1
A 1.5
A 2.1
A 2.2
A 2.3
A2
A 2.4
A 3.1
A 3.2
A 3.3
A3
A 3.4
A 4.1
A 4.2
A 4.3
A4
A 4.4
A 5.1
A 5.2
A 5.3
Duracin de la Actividad
11 das
2 das
2 das
3 das
3 das
1 da
20 das
1 da
1 7das
1 da
1 da
20 das
1 da
17 das
1 da
1 da
20 das
1 da
17 das
1 da
1 da
25 das
1 da
22 das
1 das
1 da
23
5.2.1.
Diagrama de Gantt
24
25
5.2.2.
Diagrama PERT
26
6. Anlisis de Riesgo
El impacto puede tener alguno de los siguientes valores:
NI =
M =
SG =
CR =
No Influye
Medio
Significativo
Critico
27
PLAN DE AVERSION
%
RIESGO
PROBABI
LIDAD
IMPAC
TO
REDUCCION
PROBABILIDAD
REDUCCION IMPACTO
- Jerarqua de
R1: Integrante del

equipo de desarrollo
40
SG
renuncia al proyecto.
- Firmar un contrato.
Programadores.
- Mejorar ambiente de trabajo.
- Usar estndares de
- Motivar al equipo de desarrollo.
- Realizar mantenimiento.
R2: Fallas del
Hardware.
25
SG
- Adquirir buenos productos.
codificacin.
- Tener accesorios para

reemplazar el hardware
daado.
-Tener personal de mantenimiento.
R3: Perdidas de
Informacin.
15
CR
- Usar diferentes
- Realizar peridicamente copias de dispositivos de
seguridad de la informacin
almacenamiento (CD, Pen
- Contar con antivirus actualizados
Drive, etc) que sean
en todos los equipos.
seguros, de buena calidad,

etc.
- Tener una buena comunicacin

R4: Cambios en los
Requerimientos.
50
CR
- Flexibilidad de adaptacin.
con el cliente.
- Realizar entrevistas adecuadas.
R5: Mala estimacin

de tiempo de
60
SG
desarrollo.
- En el momento de realizar la
- Contemplar dentro de la
planificacin de tiempos y
planificacin de tiempo una
actividades, realizarla siguiendo
posible demora asumiendo
un calendario en el cual contemple
cualquier tipo de
posibles eventualidades y tiempos
eventualidad.
reales de trabajo de los integrantes

del equipo.
R6: Mala eleccin

de la plataforma de
desarrollo del
10
SG
software.
- Realizar capacitaciones para el
- Elegir una buena
personal.
plataforma de desarrollo.
- Realizar estudios para elegir la

mejor plataforma.
- Tener informacin actualizada de
las plataformas de desarrollo.
R7: Incumplimiento
de contrato por parte
40
CR
- Elaborar contratos bajo normas
- Hacer cumplir las normas
legales.
establecidas en el contrato.
del cliente.
R8: Incumplimiento
- Cumpliendo del plan de proyecto- Establecer tareas claras para
28
Costo
Adquisicin
Total
Costo U Neto
10 /
03/2015
13/06/20
15
600 $
25%
150 $
600 $
Compra
10 /
03/2015
13/06/20
15
85 $
25%
21.25 $
42.5 $
Compra
10 /
03/2015
13/06/20
15
440.3$
33%
295 $
1180.2$
Compra
C# ( Visual Studio )
10 /
03/2015
13/06/20
15
699 $
30%
209 $
209 $
Compra
SQL
10 /
03/2015
13/06/20
15
501 $
30%
150 $
150 $
Compra
EnterpriceArchitect
(A4)
10 /
03/2015
13/06/20
15
335 $
30%
100.5 $
100.5 $
Compra
10 /
03/2015
13/06/20
15
279.99 $
33%
92.4 $
369.6 $
Compra
10 /
03/2015
13/06/20
15
1200$
1800 $
3600$
Contrato
Secretaria
10 /
03/2015
13/06/20
15
100 $
100 $
100 $
Contrato
Limpieza
10 /
03/2015
13/06/20
15
60 $
60 $
120 $
Contrato
Unitario
Hasta
Recurso
Cant.
Desde
%Depr.
Costo
Fechas
Modalidad
7. Tabla de Recursos
Hardware
PC (A1)
Impresora Color
(A2)
Software
SO (A3)
MicrosoftOffice (A5)
Gente
Desarrollador
(Anlisis, diseo,
prueba,
implementacin)
Infraestructura
29
Local
10 /
03/2015
13/06/20
15
150 $
150 $
150 $
Alquiler
Serv. de Agua
Potable (A6)
10 /
03/2015
13/06/20
15
25 $
25 $
25 $
Servicio
Internet (A7)
10 /
03/2015
13/06/20
15
40 $
40 $
40 $
Servicio
Telfono fijo
(A8)
10 /
03/2015
13/06/20
15
25 $
25$
25$
Servicio
Serv. de
Electricidad
(A9)
10 /
03/2015
13/06/20
15
38 $
38 $
38 $
Servicio
Material de
Escritorio
10 /
03/2015
13/06/20
15
250 $
250 $
250 $
Compra
Refrigerio
10 /
03/2015
13/06/20
15
35 $
35 $
35$
Compra
Viticos
10 /
03/2015
13/06/20
15
20 $
20 $
20 $
Compra
Logstica
6832.8 $
8. Organizacin Interna
8.1.
Estructura del equipo.
La estructura de equipo que se utilizar en el desarrollo del proyecto, ser Descentralizada Democrtica (DD),
planteada por Mantei, la cual especifica lo siguiente:
Este equipo de ingeniera del software no tiene un jefe permanente. Ms bien, se nombran coordinadores de
tareas a corto plazo y se sustituyen por otros para diferentes tareas.
Las decisiones sobre problemas y los enfoques se hacen por consenso del grupo.
La comunicacin entre los miembros del equipo es horizontal. En consecuencia, el organigrama ser el
siguiente:
DESARROLLA
DOR
DESARROLLA
DOR
30
9. Mecanismo de Seguimiento y Control

El seguimiento y control de un proyecto se lo realiza para asegurar que el equipo de desarrollo cumple
con el Plan de Proyecto, esto se realiza con el fin de medir costo, tiempo y performance del proyecto.
Entre las tareas a realiza se encuentran:
Seguir y revisar los resultados y logros del proyecto
Revisar el Plan de Proyecto para reflejar los resultados obtenidos y ajustar las tareas restantes en
caso de ser necesario
Analizar el progreso en la ejecucin del Plan.
Tomar acciones correctivas en caso de desvos.
Fijar nuevas metas.
El seguimiento y control se lo pretende realizar de la siguiente manera:
Realizar reuniones peridicas del estado del proyecto en las que todos los miembros del equipo
presentan un informe de los progresos y de los problemas.
Evaluar los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniera de
software.
Determinar si se han conseguido los hitos formales del proyecto en la fecha programada, para
ello se deben definir primeramente los objetivos que se esperan conseguir al llegar a cada uno de
los hitos
Comparar la fecha real de inicio con las previstas para cada tarea del proyecto.
Reuniones informales con los profesionales del software para obtener su valoracin subjetiva del
progreso hasta la fecha y los problemas que se avecinan
31
10. Bibliografa
Rumbaugh, James; Jacobson, Ivar; Booch, Grady El Proceso Unificado de Desarrollo de
Software .
Rumbaugh, James; Jacobson, Ivar; Booch, Grady El Proceso Unificado .
http://www.slideshare.net/pervys/estimacin-software-por-puntos-de-funcin
http://www.sparxsystems.com.au/products/ea/purchase.html
http://plataformaeclipse.com/
http://es.wikipedia.org/wiki/Eclipse_%28software%29#Caracter.C3.ADsticas
http://www.monografias.com/trabajos16/sistemas-distribuidos/sistemas-distribuidos.shtml
http://www.augcyl.org/?q=glol-intro-sistemas-distribuidos
http://www.webadictos.com.mx/2009/06/04/software-para-restaurantes-quickorder/
http://www.genoco.com/link/interactive_iphone+starbucks.html
http://www.tritech.com.do/pixelpoint/pixepointpos.htm
http://darkjrof.wordpress.com/2011/01/08/linesofcodewichtels-contador-de-lineas-de-codigo/
ejercicios de pert con Excel, https://www.youtube.com/watch?v=8iBW3nejTKM ,(consulta el

08/06/2015)
hacer facilmente una red pert, https://www.youtube.com/watch?v=8iBW3nejTKM ,(consulta el

08/06/2015)
como hacer un diagrama de Gantt, https://www.youtube.com/watch?v=5UdWNgZ96nA ,

(consulta realizada el 08/06/2015)
http://www.slideshare.net/pervys/estimacinporpuntosdefuncin
http://www.slideshare.net/pervyspresentacion-estimaciondesw
32
11.Anexos
11.1. Anexo 1
HP Omni 100-5010uk Desktop PC: Precio: 600$us.
Con Genuine Windows 7 Home Premium de entretenimiento digital superior
Un procesador AMD Athlon II 170u procesador para un rendimiento sobresaliente
2 GB de memoria para un rendimiento rpido y eficiente
500 GB de disco duro para almacenar todos sus archivos digitales
50,8 cm (20 ") de pantalla ancha LCD
La ltima ATI Radeon HD 7270 para los juegos y aplicaciones 3D
Teclado USB y ratn
Cmara web VGA integrada con micrfono incorporado - ideal para las redes sociales y las
comunicaciones
Crear etiquetas de calidad serigrfica discos con LightScribe, ver pelculas y mucho ms
con la doble capa SuperMulti DVD RW
Caractersticas de expansin: 6 puertos USB 2.0 (2 en parte), fuente de auriculares /

micrfono portuarias. Puerto trasero de lnea de audio, 6-en-1 lector de tarjetas de memoria
33
11.2. Anexo 2
Impresora Multifuncional Hp 2050 MPF: Precio: 85 $
Especificaciones:
Imprime, escner y copiadora
Velocidad de Impresin: 20ppm negro y
color
Ciclo de trabajo mensual: 1000 paginas
Calidad de impresin: 4800 x 1200 dpi
Tecnologa de Impresin: Inyeccin de tinta
16ppm
Manejo De Papel
Bandeja de entrada: 60 hojas
Bandeja de salida: 25 hojas
Tamaos de papel admitidos: Oficio, Carta, A4, B5, A6, SOBRE DL
Escner:
Cama Plana
Resolucin: 1200dpi
Profundidad en bits: 24bits
Tamao de cama de escner: 216 x 297mm
11.3. Anexo 3
Sistema Operativo
34
11.4. Anexo 4
Herramienta de UML Enterprice Architect
35
11.5. Anexo 5
MicrosoftOffice
36

Plan de Administración de Proyecto de Software Final

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Plan de Administración de Proyecto de Software Final

Hochgeladen von

Copyright:

Verfügbare Formate

Tabla de contenido

Plan de Administracin de Proyecto de Software..........................................................................3

Propsito del Plan de Proyecto........................................................................................... 4

aSc TimeTables v2015.............................................................................................. 4

Mtricas Orientadas a Tamao........................................................................................... 9

Mtricas Orientadas a Funcin........................................................................................... 9

mbitos del Proyecto.......................................................................................................... 15

Objetivos del Proyecto.................................................................................................. 15

Ecuacin del Software................................................................................................... 19

Estructura del equipo..................................................................................................... 29

Mecanismo de Seguimiento y Control...................................................................................... 30

1. Plan de Administracin de Proyecto de Software

Propsito del Plan de Proyecto

aSc TimeTables v2015

2.1.3. Horarios GHC

Mejora de la optimizacin general del horario.

Mtricas Orientadas a Tamao

Mtricas Orientadas a Funcin.

fi = 425 [ 0.65+ 0.51 ] =493

fi =211[ 0.65+0.38 ] =217.33

El sistema requiere respaldo y

Los ALI se actualizan en lnea?

fi =241 [ 0.65+0.32 ] =0.97241=233.77

3. mbitos del Proyecto

Objetivos del Proyecto

Desarrollar una aplicacin multiplataforma para la gestin de horarios universitarios

captura de requerimientos, identificando primeramente a los

Incluir Patrones de Diseo Estandarizados que permitan mejor Rendimiento y

RP1: Gestin de Horario

Hardware de Control para el servidor, con gran almacenamiento de datos.

2. Si el software presenta alguna falla, el gestor deber subsanar el error.

El tiempo de desarrollo del software no debe ser mayor a 6 meses.

El software interacta con las siguientes interfaces externas:

(Optimista+ 4Mas Probable+ Pesimista ) (3.4+ ( 45.1 ) +7.2)

COCOMO (Modelo Constructivo de Costos) es un ejemplo de un modelo esttico de estimacin.

.( 100 de Reutilizacion ) 100( 10020 )

Ecuacin del Software

pequeos KLDC = 5 a 15 B = 0.16; para programas intermedios KLDC = 16 a 69 B = 0.28; para

Para desarrollar el software aplicaremos como estrategias las actividades de Scrum

R1: Integrante del

- Mejorar ambiente de trabajo.

- Motivar al equipo de desarrollo.

- Adquirir buenos productos.

- Tener accesorios para

-Tener personal de mantenimiento.

Drive, etc) que sean

en todos los equipos.

seguros, de buena calidad,

- Tener una buena comunicacin

R5: Mala estimacin

planificacin de tiempo una

actividades, realizarla siguiendo

posible demora asumiendo

un calendario en el cual contemple

posibles eventualidades y tiempos

reales de trabajo de los integrantes

R6: Mala eleccin

- Realizar capacitaciones para el

- Elegir una buena

- Realizar estudios para elegir la

- Elaborar contratos bajo normas

- Hacer cumplir las normas

- Cumpliendo del plan de proyecto- Establecer tareas claras para