Proceso de Arquitectura de Software

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 144

InDeSoft S.A. de C.V.

__________________________________________________________________________

SISTEMA DE GESTIÓN DOCENTE 10

UNIVERSIDAD AUTÓNOMA DEL ESTADO DE MÉXICO


CENTRO UNIVERSITARIO TEXCOCO

López Razo Benito Samuel


Trejo de la Cruz Nicolas
Gonzalez Medina Martin Alonso Jafet
Villegas González Juan Carlos
1. Definición del proyecto
1.1. Descripción del proyecto
1.2. Descripción del proyecto
1.2.1. Problema que resuelve
1.2.2. Nombre del proyecto
1.2.3. Quien será el cliente y/o usuarios
1.2.4. Alcance del proyecto
1.3. Charter
1.4 Estimación de tiempo y costo
1.4.1. Estimación del tamaño
1.4.2. Estimación del costo
1.5. Análisis de la factibilidad
1.5.1 Factibilidad Técnica.
2. Recursos del proyecto
2.1. Diseño de las Instalaciones donde se desarrolla
2.2. Ubicación de las instalaciones de desarrollo
2.3. Características del equipamiento
2.4 Recursos Humanos
2.5 Organización
2.6 Tabla de Asignación de Tareas
3. Gestión de Riesgos
3.1 Identificación de Riesgos
3.3. Mitigación de riesgos
4. Plan general del proyecto
4.1 Módulos del Proyecto
4.2 Fases del proyecto
4.5. Entregables
5. Técnicas y herramientas
5.1 Metodología de desarrollo
5.1.1 Elección de metodología de desarrollo
5.1.2 Justificación de la metodología elegida
5.2 Herramientas de software
5.3 Plataforma de Comunicación
5.3.1 Comunicación Externa
5.3.2 Comunicación Interna
5.3.3 Matriz de comunicaciones
6. Diseño del sistema
6.1 Requerimientos funcionales
6.2 Requerimientos no funcionales
6.3 Diseño de la arquitectura del sistema
6.4 Interfaces del sistema
6.5. Diagramas de casos de usos
6.5.1 Alumnos
6.5.2 Cursos
6.5.3 Evaluación
6.5.4 Reportes
6.6. Diagramas de secuencia
6.6.0 Login
6.6.1 Alumnos
6.6.1.3
Eliminar Alumno
6.6.1.4
Asignar Alumno a Curso
6.6.2 Cursos
6.6.2.2
6.6.2.4
6.6.3 Evaluación
6.6.3.1 Agregar valuación
6.6.3.2 Agregar alumno
6.6.3.3 Editar Evaluación
6.6.3.4 Eliminar Evaluación
6.6.4 Reportes
6.7. Diagramas de estados
6. 7. 0 Login
6.7.1 Alumnos
6.7.1.2. Editar Datos del Alumno
6.7.1.3. Eliminar Alumno
6.7.1.4. Asignar Alumno a Grupo
6.7.2 Cursos
6.7.3 Evaluación
6.7.3.1 Agregar Evaluación
6.7.3.2 Agregar alumno
6.7.3.3 Editar Evaluación
6.7.3.4 Eliminar Evaluación
6.7.4 Reportes
6.8. Diagramas de actividades
6.8.0 Login
6.8.1 Alumnos
6.8.1.3 Eliminar Alumno
6.8.1.4 Asignar Alumno a Grupo
6.8.2 Cursos
6.8.3 Evaluación
6.8.3.1 Egregar Evaluación
6.8.3.2 Agregar Alumno
6.8.3.3 Editar Evaluación
6.8.3.4 Eliminar Evaluación
6.8.4 Reportes
6.9. Diseño de la base de datos
6.10. Diagramas de clases
8 GESTIÓN DE LA CONFIGURACIÓN
8.1.Nombre Tecnico del Proyecto
8.2 Nomenclatura para nombrar los Documentos
8.3 Nomenclatura para nombrar los Archivos
8.4 Control de Versiones
8.5 Almacenamiento de Artefactos
8.6 Responsable de Artefactos
9.1. Control del proyecto
9.1.1. Reuniones de seguimiento
9.1.2. Formato de la convocatoria
9.1.3. Formato de la minuta
9.2 Control del proyecto.
9.2.1. Procedimiento de entrega
9.2.2. Responsable de entregables
9.2.3. Resguardo de componentes
9.2.4 Proceso de verificación y validación.
9.3. Entrega final del proyecto
9.3.1. Estrategia de entrega
9.3.2. Evidencia de entrega
9.3.2. Cierre del proyecto
1. Definición del proyecto

1.1. Descripción del proyecto

Se pretende desarrollar un Sistema de Gestión para la Evaluación Continua, que facilite, a los docentes, sus
actividades de evaluación. El sistema permitirá la generación de los reportes finales, de forma que el docente
se preocupe menos por las actividades de registro de evaluaciones y más por incrementar su esfuerzo en el
adecuado aprendizaje de sus alumnos.

1.2. Descripción del proyecto

Objetivo
● Desarrollar un sistema que permita la correcta administración de las diferentes evaluaciones, que
se toman en cuenta para obtener una evaluación final de cada alumno.

Objetivos Especificos
● crear una interfaz gráfica donde el docente pueda gestionar las evaluaciones de sus alumnos
● asegurar la integridad y accesibilidad a la información
● permitir la generación de reportes parciales y finales

1.2.1. Problema que resuelve

En el ejercicio docente una de las principales tareas es evaluar a los alumnos, y cada profesor define su
método de evaluación o incluso es definida por la institución, el problema consiste en llevar el correcto
registro de las calificaciones. Se implementa el uso de libretas, hojas sueltas con cuadrículas o programas
de computadora como word o excel.

La intención es crear un sistema diseñado específicamente para realizar esta tarea, que permita generar
evaluaciones desde un inicio o bien durante el transcurso del curso, que permita agregar alumnos y su
información, y sobre todo que realice los cálculos de manera automática.

1.2.2. Nombre del proyecto

Se asignará SGD10 (Sistema de Gestión Docente 10) como nombre del producto
1.2.3. Quien será el cliente y/o usuarios

Debido a la flexibilidad que se implementará en el programa, éste podrá ser utilizado por cualquier profesor,
desde nivel básico a posgrado.

1.2.4. Alcance del proyecto

Se tienen contempladas diversas características para este sistema, sin embargo se considera conveniente
tener una primera versión funcional del sistema, lanzarlo al mercado y dependiendo de su respuesta,
continuar implementando mejoras.

Siguiendo esta política se identifican los elementos con los cuales se entregará esta primera versión:
● Sistema web que permite el acceso a cualquier usuario con una conexión a internet
● El sistema se visualizará correctamente en cualquier dispositivo.
● El acceso se realizará por medio de una autentificación
● El docente podrá crear un máximo de 1,000,000 listas (cursos)
● El docente podrá agregar un máximo de 1,000,000 alumnos a cada curso
● El docente podrá agregar un máximo de 1,000,000 evaluaciones en cada curso
● Cada curso podrá ser evaluado de forma diferente
● El docente podrá generar reportes parciales y finales de sus alumnos
● Los reportes se podrán exportar a excel
● Los alumnos no tendrán acceso a esta información
● El sistema trabajará con dos idiomas (Español e Inglés)
1.3. Charter
1.4 Estimación de tiempo y costo
Para estimar el tiempo que se requiere para desarrollar el Software y determinar el costo del
proyecto se realizó el cálculo basado en el Modelo Constructivo de Costos Intermedio
(COCOMO).

En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo.
Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real,
incrementando la precisión de la estimación.

1.4.1. Estimación del tamaño

Para poder determinar la estimación de tamaño se tomaron en cuenta estimaciones descritas


en el libro “estimación de costos y administración de proyectos de Software” y se obtuvo que el
tamaño del software sera de 2.7 KLOC

1.4.2. Estimación del costo

Para cada modo de desarrollo, los 15 atributos del coste intervienen como multiplicadores en el
coste nominal (Kn), para producir el coste ajustado.

Las ecuaciones nominales de coste para el modelo intermedio son:


● modo orgánico Kn = 3.2 Sk1.05
● modo semi encajado Kn = 3.0 Sk1.12
● modo empotrado Kn = 2.8 Sk1.20

Se ha utilizado el modelo orgánico debido al tamaño de líneas de código que tendrá el


software. El desarrollo se estima en 3.07 meses cuando el equipo de trabajo es de 5 personas
y el esfuerzo obtenido es de 15.35 personas/mes

Figura 1.1. Tabla de atributos para la estimación de tiempo de desarrollo del proyecto.
Figura 1.2 Resultados de Estimación de Tiempo para el desarrollo del Proyecto

1.5. Análisis de la factibilidad

Después de definir la problemática presente y establecer las causas que ameritan de un nuevo sistema, es
pertinente realizar un estudio de factibilidad para determinar la infraestructura tecnológica y la capacidad
técnica que implica la implantación del sistema en cuestión, el grado de aceptación que la propuesta genera
a el usuario. Este análisis permitió determinar las posibilidades de diseñar el sistema propuesto y su puesta
en marcha, los aspectos tomados en cuenta
para este estudio fueron clasificados en tres áreas, las cuales se describen a continuación:

1.5.1 Factibilidad Técnica.

De acuerdo a la tecnología necesaria para la implantación del Sistema de Seguimiento de calificaciones se


evaluó bajo dos enfoques: Hardware y Software.

Hardware.

En cuanto a Hardware, específicamente cada terminal que va acceder a el sistema debe cubrir con los
siguientes requerimientos mínimos:
● Procesador Pentium 4 o superior.
● 512 MB de Memoria RAM
● Disco Duro de 60 GB
● Tarjeta de Red.
● Tarjeta de Vídeo.
● Teclado.
● Mouse.

Evaluando el hardware existente y tomando en cuenta la configuración mínima necesaria, ningún usuario
requiere realizar inversión inicial para la adquisición de nuevos equipos, ni tampoco para repotenciar o
actualizar los equipos existentes, ya que los mismos satisfacen los requerimientos establecidos tanto para
el desarrollo y puesta en funcionamiento del sistema propuesto, además hay que agregar que estos
componentes se encuentran en el mercado actualmente a unos precios bajos.

Software (Software libre)


En cuanto al software, sucede lo mismo cualquier usuario cuenta con todas las aplicaciones que se necesitan
para el funcionamiento del sistema, lo cual no amerita inversión alguna para la adquisición de los mismos.

Factibilidad Económica.

No existe ninguna presupuesto a que se deba ajustar el proyecto así que en realidad no se considera como
un factor que influya en el resultado.

De esta manera como el usuario no tiene que hacer ninguna inversión inicial y los costos de desarrollo no
son ningún factor. se asume como completamente factible el proyecto.
2. Recursos del proyecto
2.1. Diseño de las Instalaciones donde se desarrolla

Se ha encontrado una oficina que cumple con las características que satisface las necesidades del equipo:
● Sala de espera
● Sala de reuniones Comentado [1]: Agregar medidas en metros de ancho
● Baños y largo
● Sala de desarrollo, donde el equipo puede trabajar comodamente, ademas de contar con espacio
suficiente para realizar las reuniones diarias
● Sala de descanso, espacio con acceso directo desde la sala de desarrollo, que cuenta con una
pequeña cocina y una sala
● Despacho, donde se puede atender al cliente
2.2. Ubicación de las instalaciones de desarrollo

Se establecerán las oficinas de IndeSoft S.A. de C.V. en la Colonia Lomas de Cristo perteneciente al
municipio de Texcoco Estado de México por los siguientes motivos:
● El equipo de desarrolladores vive en los alrededores a esta localidad lo que nos brinda un ahorro
de tiempo, dinero y esfuerzo para poder arribar a las instalaciones
● El cliente tiene su empresa y domicilio cerca de dichas oficinas, esto nos brinda una posibilidad de
tener una mejor comunicación con el cliente y los posibles sprints en los que el cliente deba estar
presente serán más constructivos
● La zona tiene bajos índices de delincuencia
● El costo de la renta del inmueble se adecua al presupuesto

A continuación se presenta de forma gráfica la ubicación de las oficinas

Localización del Estado donde se ubicaran las instalaciones

Localización del Municipio


Localización de la Zona donde se ubicaran las Instalaciones

Localización específica de las Instalaciones


2.3. Características del equipamiento

Para este proyecto se considera que debido al corto tiempo de desarrollo (tres meses), y para
reducir costos, también porque los riesgos de la propiedad del equipo los asume la arrendadora,
también la arrendadora se compromete a renovar el equipo obsoleto, ya que al estar rentando
los bienes, contará siempre con equipo nuevo y tecnología de punta.

Con esta medida también se evita los problemas que pudieran presentarse en cuanto a la
propiedad y comercialización de los bienes muebles. El registro contable es simple, las rentas
van directamente al rubro de gastos y es deducible 100% ya que se maneja directamente como
un gasto.

Con todas las consideraciones anteriores hemos elegido a la empresa “KC Renta$” 1 es una
empresa mexicana dedicada a la renta de equipo de cómputo y audiovisual cuenta con equipos
seminuevos y nuevos.

1
http://www.kcrentas.com.mx/
Equipo Descripción imagen

Laptop Dell Cuarta generación del


Latitude E6410 procesador Intel® Core™
i5-4310U (3MB Caché,
Un equipo por cada
hasta 3.00 GHz)
integrante del
Windows® 7 Professional,
proyecto.
64-bit, Español (Incluye
licencia y medio de
Windows 8.1 Pro)
Pantalla LED Táctil
Costo por mes de renta: $214.33 M/N.
iluminada con antireflejo de
Costo total por tres meses de renta: $ 642.99
12.5" de alta definición(HD) M/N.
(1920X1080) con
capacidad para WiGig costo por cuatro unidades = $2571.96 M/N.
8 GB1 DDR3L a 1600 MHz
Disco Duro de Estado
Sólido (SSD) de 128GB
Gráficos Intel® HD 4400
3 años de ProSupport,
Servicio en el sitio con
respuesta el siguiente día
laborable
2.99 lbs

Laserjet Pro Velocidad de 22 ppm


impresión en
P1606dn negro

Ciclo de trabajo 10.000 páginas al mes

Resolución 1200 x 1200 dpi

Duplex Automática (estándar)

Lenguaje de HP PCL 6, HP PCL 5e,


Impresión emulación Postscript
Nivel 2 con conmutación
de lenguaje automática

Manejo de Bandeja de entrada para


papel 250 hojas

Máxima Hasta 125 hojas


capacidad de
salida

Tamaño de Bandeja 1: 7,6 x 12,7 a


impresión 21,6 x 35,6 cm; Bandeja
2, 3: 14,7 x 21,1 a 21,6
x 35,6 cm Costo por mes de renta: $197.48 M/N.
Cartuchos de 1 (negro)
impresión Costo total por tres meses de renta: $ 592.44
stándar

Conectividad Puerto paralelo IEEE


M/N.
1284, 1 puerto USB 2.0
Puertos de Un puerto USB
Entrada y (compatible con
Salida especificaciones USB
2.0), un puerto paralelo
compatible con IEEE-
1284B

Memoria 16 MB
stándar

Memoria 144 MB
máxima

Procesador Motorola ColdFire

Capacidad de 26 integradas
tipos de letra

Sistema Windows 98, Me, NT 4.0,


Operativo 2000, XP, Server 2003;
Apple Mac OS 9.x y
posterior, OS X v.10.1 o
posterior

Compatibilidad Sí
con Mac

Tecnología HP ProRes 1200

System Req Mac OS 9.1 y


Mac posteriores: 96 MB RAM;
Mac OS X v 10.1 y
posterior: 128 MB de
RAM

Requerimientos Microsoft Windows 98,


de sistema Pentium, 166 MHz, 64
MB de RAM

Software inst./desinst.,
incluido controladores, Caja de
herramientas para
diagnóstico de status y
configuración, simulador
de panel de control,
ayuda y documentación

Mercado Profesionales

Cable en caja No

Rango de 20 a 80% RH
humedad
operacional

Rango de 10 a 32,5°C
temperatura
operacional

Fuente de Voltaje de entrada de


alimentación 100 hasta 240 VCA (+/-
10%), 50/60 Hz (+/-
3%)

Dimensiones 35 x 35,5 x 25,5 cm

Peso 11,2 kg

Servidor en rack
PowerEdge R630 • Procesador Intel®
Xeon® E5-2403
• Memoria de 8GB
• PERC H310 Costo por mes de renta: $245.50 M/N.
• Dos discos duros Costo total por tres meses de renta: $ 736.50
de 1TB SATA M/N.
• Windows Server®
2012 Essentials
• iDRAC7 Express
Tp-link – Router El amplificador de alta potencia y las
antenas de 5dBi proporcionan 4
(Tl-wr841hp) veces el rango inalámbrico de un
router normal

La señal Wi-Fi mejorada penetra


paredes y obstáculos eliminando
zonas sin recepción

2 veces la velocidad inalámbrica de


un router normal a través de largas
distancias permite la transferencia de
datos sin problemas y el streaming
de multimedia en toda su red

La velocidad inalámbrica de
300Mbps es ideal para el streaming
de video, juegos en línea y VoIP

Configure fácilmente una conexión


segura con encriptación WPA con Costo por mes de renta: $56.58 M/N.
sólo presionar el botón WPS
Costo total por tres meses de renta: $ 169.74
El Asistente de fácil configuración
proporciona una instalación rápida y M/N.
libre de problemas

Compatible con versiones anteriores


de productos 802.11b/g

4 Puertos LAN de 10/100Mbps y 1


Puerto WAN de 10/100Mbps

WEP / WPA / WPA2,WPA-PSK /


WPA2-PSK de 64/128/152-bit
2 Antenas Desmontables Omni
Direccionales de *5dBi (RP-SMA)

Dimensiones 168.5mm x 130mm x


31.5mm

IEEE 802.11n, IEEE 802.11g, IEEE


802.11b

Benq MS504 - Alcance de zoom: 1.1:1


Altavoces incorporados: Si
Proyector Altura: 9,5 cm
Ancho: 28,3 cm
Brillo de proyector: 3000
lúmenes ANSI
Cables incluidos: Corriente
alterna, VGA
Cantidad de puertos USB
2.0: 1
Cantidad de puertos VGA
(D-Sub): 3
Color del producto: Negro
Compatibilidad de tamaño
de pantalla: 762 - 7620 mm
(30 - 300")
Conector USB: Micro-USB
B
Costo por mes de renta: $439.50 M/N.
Consumo de energía Costo total por tres meses de renta: $
(ahorro): 220W 1318.50 M/N.
Consumo de energía
(inactivo): 0,5W
Consumo energético:
270W
Duración de lámpara:
4500h
Entrada de S-Video: 1
Entrada de audio (L,R): 1
Entrada de video
compuesto: 1
Ethernet: No
Exhibición en pantalla
(OSD): Si
Factor de forma: Escritorio
Formatos gráficos
soportados: 1600 x 1200
(UXGA), 640 x 480 (VGA)
Frecuencia de entrada:
50/60 Hz
Fuente de energía:
Corriente alterna
Full HD: Si
Guía de configuración
rápida: Si
HDCP: No
Idiomas OSD: ARA, BUL,
CHI (SIMPL), CHI (TR),
CZE, DAN, DEU, DUT,
ENG, FIN, ENG, GRE,
HUN, ITA, JPN, KOR, NOR,
POL, POR, RUS, SWE,
THA, TUR
Intervalo de longitud focal:
21 - 23,1 mm
Mando a distancia: Si
Nivel de ruido: 33 Db
Nivel de ruido (modo
económico): 28 Db
Número de altavoces
incorporados: 1

fax bond brother Identificador de llamadas y


detección de tonos
575e característicos. Los clientes
que se suscriban a estos
servicios a través de las
compañías de teléfono
locales podrán usarlas en
este versátil fax también.
Fax y llamadas de teléfono
en una sola línea. Esta
función le ahorra el gasto
de tener líneas diferentes
para el fax y para las
llamadas. La interfaz
incorporada le permite
conectarse a un Costo por mes de renta: $91.35 M/N.
contestador automático Costo total por tres meses de renta: $ 274.05
externo.
M/N.
Cartuchos para imprimir
totalmente montados.
Flexible manipulación del
papel. Capacidad de
manipulación del papel
adaptada a su uso personal
con capacidad de entrada
de 50 hojas y alimentador
automático para 10 hojas.
Realice fotocopias
cómodamente. Además de
su capacidad básica de fax,
este modelo se puede usar
para realizar copias; una
comodidad añadida sin
coste adicional.

REGULADOR ELECTRÓNICO
Sola Basic No INTEGRADO
Break 800va, El MICRO SR INET entrega una
tensión de salida regulada en todo
Entrada 95-140v momento (con batería y con línea
comercial)

BATERÍA SELLADA RECARGABLE


LIBRE DE MANTENIMIENTO
El equipo contiene en su interior una
batería nueva, recargable, sellada,
de larga vida, la cual no requiere
mantenimiento alguno.

SUPRESOR DE PICOS (DE C.A.) Y


DE RUIDO INTEGRADO

En condiciones normales de
operación, la salida del equipo se
encuentra protegida totalmente
contra ruido de alta frecuencia y
transitorios de alta tensión, evitando
que la carga sufra algún daño
ocasionado por éstos

PROTECCIÓN DE LÍNEA
TELEFÓNICA Costo por mes de renta: $153.13 M/N.
El MICRO SR INET proporciona Costo total por tres meses de renta: $ 459.39
protección contra transitorios en la
línea telefónica, ocasionados por M/N.
descargas eléctricas o instalaciones
defectuosas.

De esta manera se evitan daños a 6 unidades = $2756.34 M/N


equipos como computadoras
personales con conexión a
INTERNET, faxes, modems y todos
aquellos que requieran conectarse a
la línea telefónica (interfase RJ-11).

ALARMA AUDIBLE
Si la línea comercial falla, se produce
un tono audible intermitente para
indicar que la unidad está operando
con batería. Para indicar el apagado
inminente del inversor por haberse
agotado la reserva de batería, el tono
audible se volverá continuo durante
los últimos minutos de la descarga.

SISTEMA INTELIGENTE

Los MICRO SR INET ofrecen un


desempeño inteligente en todas sus
funciones gracias a su sistema
basado en la tecnología de
microprocesador.

El funcionar con microprocesador


permite al equipo trabajar con
rapidez, versatilidad y eficiencia,
brindándole a usted la confianza de
una protección segura y efectiva
contra las perturbaciones de la línea
comercial.

PUERTO DE COMUNICACIÓN
COMPATIBLE CON USB
El MICRO SR INET cuenta con una
interfase de comunicación con la cual
se puede monitorear los parámetros
de: Porcentaje de batería disponible,
frecuencia, voltaje y falla de línea.

El costo total por los tres meses que se contempla usar mientras dura el proyecto suma en total
$ 6122.58 M/N. es monto total incluye IVA.
2.4 Recursos Humanos
Para el desarrollo del proyecto SGD10 de InDeSoft, se requieren 4 personas; cuyas hojas de
evaluación de puestos se incluyen a continuación:
2.5 Organización Comentado [2]: agregar descansos y hora de comida
2.6 Tabla de Asignación de Tareas

Una vez establecidos los requerimientos de proyecto y previo análisis de la información


recabada, durante las reuniones semanales, el equipo de desarrollo ha establecido la siguiente
tabla de asignación de tareas:

Nombre deL Puesto Tareas asignadas

Ingeniero de Requerimientos ● Generar las pruebas de aceptación.


● Asegurar que las pruebas de aceptación
sean validadas por el cliente.
● Crear los reportes de avance.
● Diseñar los diagramas de actividades.
● Diseñar los diagramas de estados.
● Generar los prototipos no funcionales.
● Realizar las pruebas de integración
pertinentes.
● Gestionar la información necesaria para el
proyecto.

Ingeniero de Datos ● Generar los esquemas de las bases de


datos.
● Asegurar la redundancia e integridad de los
datos.
● Garantizar la seguridad de los datos ante
ataques cibernéticos.
● Definir y validar posibles cambios en el
modelo de datos.

Ingeniero de Sistemas ● Desarrollar el código necesario de acuerdo a


los requerimientos.
● Garantizar que el código generado sea
validado en las pruebas.
● Generar versiones funcionales del sistema.

Ingeniero de Implementación ● Identificar los requerimientos físicos y


tecnológicos para la implementación del
sistema en un entorno de producción.
● Identificar los requerimientos físicos y
tecnológicos para la implementación del
sistema en un entorno de desarrollo
● Garantizar el funcionamiento del sistema en
el equipo de cómputo donde deberá quedar
instalado.
3. Gestión de Riesgos
3.1 Identificación de Riesgos

Utilizando RBS (Estructura de desglose de Riesgos)

Registro de Riesgos : Tecnicos

Riesgo Prioridad Probabilidad Impacto Causa

No comprender Alta Media Suspenso Bajo nivel de


los requisitos análisis en
requerimientos

No tener Alta Media Suspenso Poco presupuesto


infraestructura
Las Media Baja Suspenso No se tiene la
herramientas de capacitación
programación no necesaria
se saben usar

Los recursos no Alta Media Suspenso Los empleados se


estan retrasan con su
disponibles en su trabajo
momento

Registro de Riesgos : Externos

Riesgo Prioridad Probabilidad Impacto Causa

No comprender Alta Media Suspenso Bajo nivel de


el mercado de análisis en
consumo requerimientos

Cambio en las Alta Media Suspenso El cliente añade


Peticiones del nuevas funciones
cliente

Firma del Media Baja Suspenso Falta de


Contrato tardia presupuesto por
parte del Cliente

Condiciones Baja Baja Suspenso Condiciones


Climáticas climatológicas
(Terremoto, adversas y
Inundación, descuidos del
Incendio) personal.

Registro de Riesgos : De la organización

Riesgo Prioridad Probabilidad Impacto Causa

Entregas Tardías Alta Media Suspenso Poco avance del


en Procesos proyecto

Informes de Alta Media Suspenso El cliente añade


Estados nuevas funciones
necesitan más
tiempo
Se necesitan Media Baja Suspenso Falta de
más recursos Actualización de
tecnológicos Herramientas

Falta de Alta Baja Suspenso Mala estimación


Recursos de costo
Monetarios

Registro de Riesgos : Direccion de Proyectos

Riesgo Prioridad Probabilidad Impacto Causa

Cambio de Alta Media Suspenso Renovacion de


personal contratos

Falta de Alta Media Suspenso Existen problemas


comunicacion de comunicación
en el equipo

Retraso en la Media Baja Suspenso Planificación


entrega del Demasiado
proyecto optimista

3.3. Mitigación de riesgos


Para el siguiente punto analizaremos algunos de los casos en los que algo puede salir mal, y que
pueden ser cruciales por su gravedad o por su complejidad que van a mermar el proyecto
económicamente y en el desempeño del software. También describiremos la forma de evitar más
dificultades y que hacer para darle un a solución adecuada a los problemas más comunes.

Catástrofes naturales y accidentes.

Consideremos que para los casos en que exista una actividad fuera de todo control humano
como incendios, robos, inundaciones, terremotos, etc. y que nadie ni nada está exento de estas
catástrofes. Es muy aconsejable considerar la adquisición de un seguro contra siniestros y robo.
De tal manera que estas pérdidas sean rápidamente cubiertas.

Ausencia prolongada por enfermedad o contingencia de un empleado.

En caso de una enfermedad grave de un empleado que le incapacite continuar con sus
actividades, se cubrirá sus actividades con los empleados de roles afines. De tal manera que el
proyecto de software se puede cubrir en tiempo y en forma.
No se recomienda contratar a una nueva persona para el puesto que ha quedado vacante,
significa tener que capacitar al nuevo miembro y se traduce en tiempo y más dinero.

Cortes energía.

En caso de sufrir de cortes de energía prolongados (más de 2 horas por día) es necesario contar
con una “planta eléctrica de emergencia” esta puede ser rentada o también adquirida para que
en futuros proyectos no se tenga la necesidad de volver a invertir en el mismo rubro otra vez.

3.4 Costo de los riesgos

Riesgos Costo
la empresa “KC rentas$” tiene un seguro por
renta de sus productos con un costo de 10% de $6120 M/N
deducible.

El inmueble donde se labora, se renta, por tanto


la pérdida es el costo de desplazarse a cualquier $3500 M/N
punto de la zona metropolitana y centro de la
ciudad de México es: 2

Pérdida de datos por robo o por catástrofe: $2,000 M/N por dia
puede ir desde un dia de trabajo a pérdida total

Pérdida de un empleado: en caso de enfermedad $1,800 M/N por dia


o por término de labores interrumpida

Cortes de energía eléctrica $1800 M/N por cada dia

por cada día sin recuperar el el equipo perdido o


con fallas en los dispositivos de trabajo tiene un $1800 M/N por cada dia
costo adicional

4. Plan general del proyecto

4.1 Módulos del Proyecto

Para la implementación del proyecto SGD10, se establecieron los siguientes 6


módulos.
2
FLETES Y MUDANZAS ECONOMICAS DE TEXCOCO
FRAY PEDRO DE GANTE SUR 417, SAN LORENZO, TEXCOCO, C.P. 56190, MEX.
Tel: (595)955-7873
Nombre del Descripción
módulo

Registro Cuando un usuario desea emplear el software SGD10, deberá


realizar un registro, para asignarle un usuario y password, con
la finalidad de proteger su información.

Autenticación Cuando un usuario desee ingresar a su sesión, se le


solicitará el usuario y contraseña que asignó durante la
etapa de Registro.

Cursos Una vez iniciada la sesión; el usuario tendrá la opción de:


● Crear un curso.
● Editar un curso.
● Eliminar un curso.
● Ver la lista de cursos registrados
● Ver la lista de los alumnos registrados en cada curso.

Evaluación Dentro de cada curso registrado, el usuario podrá establecer


la forma y los criterios de evaluación, mediante los siguientes
elementos:
● Agregar evaluación.
● Editar evaluación.
● Eliminar evaluación.
Además, existirá la posibilidad de ver:
● Lista de evaluaciones por alumno
● Lista de evaluaciones por grupo.

Alumnos El usuario, podrá además:


● Agregar alumnos
● Editar alumnos
● Borrar alumnos
● Asignar alumnos registrados a un grupo.

Generar Al final del curso, el usuario tendrá la posibilidad de generar


reportes los reportes de evaluación, final tanto por grupo; como por
alumno.
Tales módulos se resumen en la figura siguiente:
4.2 Fases del proyecto
Previo análisis de los datos recabados, y por medio de las reuniones semanales, el
equipo de desarrollo del proyecto SGD10, ha establecido dividirlo en 7 fases, distribuidas
en 7 sprints, que abarcan todos los módulos acordados, mismos que se presentan a
continuación, mediante el uso del software TRELLO.
4.3 SCHEDULE
4.4 PLANES DETALLADOS
METODOLOGIA: SCRUM
Sprints:

Prioridad: Baja (B), Media (M) y Alta (A)


Uso: Poco frecuente (PF), frecuente (F) y normal (N)

Actividad 1: Registro
Prioridad: B

Tiempo: 1 Semana

Actividad 2: Autenticación
Prioridad: B

Tiempo: 1 Semana
Actividad 3: Cursos
Prioridad: 1A
· Lista de cursos
Tiempo: 2 Semanas
· Crear curso
· Editar curso
· Eliminar curso
· Ver lista de alumnos por grupo
Actividad 4: Evaluación
Prioridad: 3A
· Lista de evaluaciones por alumno
Tiempo: 4 Semanas
· Lista de evaluaciones por grupo
· Agregar evaluación
· Editar evaluación
· Eliminar evaluación
Actividad 5: Alumnos
Prioridad: 2A
· Crear alumno
Tiempo: 2 semanas
· Editar alumno
· Eliminar alumno
· Asignar alumno a grupo
Actividad 6: Generar Reportes
Prioridad: M

Tiempo: 2 semanas
4.5. Entregables
A continuación se detalla la lista de los elementos que se entregarán como resultado de cada
etapa:

Análisis: Diagramas de Casos de Uso, Pruebas de Aceptación, Diagramas de Actividades


Diseño: Modelo de la Base de Datos, Prototipos no funcionales, Diseño Gráfico
Desarrollo: Código Fuente, Documentación del Código
Pruebas: Pruebas de Aceptación Validadas
Implementación: Sistema Instalado y funcionando en el Servidor del Cliente

5. Técnicas y herramientas
5.1 Metodología de desarrollo
5.1.1 Elección de metodología de desarrollo

Debido a las caracteristicas del sistema, se identifica la posibilidad de trabajar con


metodologías ágiles, Entre las diversas metodologías que se encuentran en el mercado,
se elige SCRUM como metodología a implementar para el desarrollo del proyecto
5.1.2 Justificación de la metodología elegida

Para desarrollar este proyecto se tienen contemplados los tiempos y los requerimientos,
esto nos permite visualizar cada uno de los elementos que lo han de componer, sin
embargo, sería preferible ir teniendo elementos funcionales, y también sería conveniente
poder tomar decisiones, como omitir ciertos elementos extra, si el tiempo se agota, estas
son ventajas propias de la metodología SCRUM.
Otra de las razones por las cuales se utilizará, es para asegurar la correcta participación
de cada uno de los integrantes del equipo, durante la creación del software, mediante las
reuniones diarias de 15 minutos, así como el uso de sprints para la visualización del
avance del proyecto.
5.2 Herramientas de software

Para la realización del proyecto se utilizarán las siguientes herramientas:

Herramienta Descripción Versión Licencia Costo

Netbeans IDE de desarrollo, utilizado para 8.0.1 CDDL, SIn Costo


crear software en los lenguajes de GPL2
Java, C, PHP, JavaScript, HTML y
CSS

MySQL Herramienta creada para 6.2.3 GPL Sin costo


Workbench administrar, gestionar, y modelar
bases de datos MySQL

XAMPP Servidor Web Local, permite tener 1.8.3 GNU Sin Costo
una instalación funcional de un
servidor en el cpu de cada
programador, incluye Apache,
MySQL, PHP y Pearl

Mercurial Sistema de control de versiones, 3.1.1 GPL Sin Costo


multiplataforma

Firefox Navegador Web 32.0.3 MPL Sin Costo

Pencil Herramienta que permite generar 2.0.5 GPL Sin Costo


mockups y wireframes, para realizar
prototipos funcionales

5.3 Plataforma de Comunicación

El equipo de desarrollo del proyecto SGD10 de InDeSoft, ha establecido como elementos


de comunicación; las herramientas de hardware como son teléfonos o celulares, y
herramientas software (en una computadora), las cuales se emplean de acuerdo a la
naturaleza de la comunicación: In situ o Ex situ, y dependiendo si se trata de
desarrollador-cliente, cliente-desarrollador o desarrollador-desarrollador.

5.3.1 Comunicación Externa

La comunicación externa se realizará mediante:


a) A distancia:
1. Teléfono fijo o celular.
2. Correo electrónico.
3.- Almacenamiento en la nube DropBox

b) En las instalaciones de trabajo:


3. Reuniones programadas.

5.3.2 Comunicación Interna


La comunicación entre los miembros del equipo desarrollador se llevará a cabo
empleando:
a) A distancia:
1. Teléfono celular.
2. Aplicaciones de mensajería y/o chat (WhatsApp, Hangout)
3. Aplicaciones de gestión de actividades: Trello.
4. Correo electrónico.
b) En las instalaciones de trabajo
1. Pizarrón.
2. Post Stick.
3. Proyector.

5.3.3 Matriz de comunicaciones


Los mecanismos de comunicación se pueden observar en la siguiente matriz de
comunicaciones:

Emisor Medio Receptor Objetivo Ex situ In situ

Integrante - Teléfono fijo o Cliente - Resolver duda


de equipo simple
celular
- Correo
electrónico

Integrante - Reuniones Cliente - Aclaración


de equipo programadas. importante
- Informe de
avances

Integrante - Teléfono fijo o Integrante Resolver duda


de equipo celular de equipo simple
- Aplicaciones
de mensajería.
- Correo
electrónico

Integrante - Trello Integrante - Asignar tareas


de equipo de equipo - Verificar avances

Integrante - Pizarrón Integrante - Asignar tareas


de equipo - Proyector de equipo - Verificar avances
- Reuniones diarias

Integrante - Post Stick Integrante En ausencia del


de equipo de equipo receptor:
- Asignar tareas
- Aclaraciones
simples.

6. Diseño del sistema


6.1 Requerimientos funcionales
Se requiere desarrollar un sistema capaz de almacenar la información de cursos, alumnos y sus
respectivas calificaciones, para tal fin deberá cumplir con las siguientes condiciones:
● El usuario debe tener la posibilidad de acceder al sistema las 24 horas del día, los 365 días
del año,
● La información almacenada, no podrá ser eliminada de la base de datos.
● El usuario podrá generar todos los cursos que necesite
● El usuario podrá crear todos los alumnos que necesite
● El usuario podrá asignar todos los alumnos que desee a cada curso
● El usuario podrá crear todos los elemento de evaluación que necesite
● El usuario asignará un valor numérico entre 0 y 10 para cada evaluación, para cada alumno
● El usuario podrá generar un reporte por cada curso
● Para ingresar al sistema, el usuario deberá contar con una cuenta, y una contraseña
● Si el usuario no tiene una cuenta, podrá crear un en el momento
● Si el usuario no recuerda su contraseña, podrá solicitar un cambio de la misma
6.2 Requerimientos no funcionales
Con la finalidad tener el sistema funcionando correctamente debemos asegurar ciertas condiciones básicas,
entre las cuales tenemos de dos tipos las de software y las de hardware, mismas que enlistaremos
acontinuación:
● Software
○ El sistema deberá ser capaz de conectarse a la base de datos, para lectura y escritura de
datos
○ La base de datos deberá ser accedida solo de forma local
○ El sistema deberá evitar inyeccion de codigo
○ El sistema deberá evitar peticiones xss (Cross-site scripting)
○ El sistema trabajará bajo la arquitectura de REST ( Representational State Transfer)
● Hardware
○ Equipo de cómputo que trabajará como Servidor funcionando correctamente, con un
programa que permita servir las peticiones de los clientes
○ Instalación de Apache escuchando por el puerto 80
○ Instalación de MySQL escuchando por el puerto 3306
○ Ip fija para el equipo servidor
○ Conexión a internet las 24 horas, los 365 días de la semana

6.3 Diseño de la arquitectura del sistema


A continuación se muestra la arquitectura propuesta para el sistema donde podemos visualizar que el
transporte de datos se realizará por medio de un API, usando REST como estándar para la generación del
mismo, se observa la conexión directa entre el sistema y la base, así como el uso de tecnologías tanto del
lado del cliente como del servidor, conocidas como frameworks, mismas que facilitarán el desarrollo y así
mismo asegurarán la estructura del sistema, ya que son estos frameworks los que definen cómo se hacen
las cosas y donde va cada elemento.
6.4 Interfaces del sistema Comentado [3]: comentario de las pantallas
6.5. Diagramas de casos de usos

6.5.1 Alumnos
6.5.2 Cursos

6.5.3 Evaluación
6.5.4 Reportes

6.6. Diagramas de secuencia


6.6.0 Login

6.6.1 Alumnos

6.6.1.1 Crear Alumno


6.6.1.2
Editar Alumno
6.6.1.3

Eliminar Alumno
6.6.1.4

Asignar Alumno a Curso

6.6.2 Cursos

6.6.2.1
6.6.2.2
6.6.2.3
6.6.2.4
6.6.3 Evaluación
6.6.3.1 Agregar valuación
6.6.3.2 Agregar alumno
6.6.3.3 Editar Evaluación

6.6.3.4 Eliminar Evaluación


6.6.3.4
6.6.4 Reportes
6.7. Diagramas de estados

6. 7. 0 Login

6.7.1 Alumnos
6.7.1.1. Crear Alumno

6.7.1.2. Editar Datos del Alumno


6.7.1.3. Eliminar Alumno
6.7.1.4. Asignar Alumno a Grupo
6.7.2 Cursos

6.7.2.1
6.7.2.2
6.7.2.3
6.7.2.4
6.7.2.4
6.7.3 Evaluación
6.7.3.1 Agregar Evaluación
6.7.3.2 Agregar alumno
6.7.3.3 Editar Evaluación
6.7.3.4 Eliminar Evaluación
6.7.4 Reportes
6.8. Diagramas de actividades
6.8.0 Login

6.8.1 Alumnos
6.8.1.1. Crear Alumno

6.8.1.2 Editar Alumno


6.8.1.3 Eliminar Alumno
6.8.1.4 Asignar Alumno a Grupo
6.8.2 Cursos
6.8.2.1

6.8.2.2
6.8.2.3
6.8.2.4
6.8.2.5
6.8.3 Evaluación
6.8.3.1 Egregar Evaluación
6.8.3.2 Agregar Alumno
6.8.3.3 Editar Evaluación
6.8.3.4 Eliminar Evaluación
6.8.4 Reportes
6.9. Diseño de la base de datos

diagrama del esquema que se utilizará para almacenar los datos


6.10. Diagramas de clases

diagrama de las clases que se ocuparán en el sistema, incluye atributos y métodos

6.11. Diagramas de la interfaz


pantalla de inicio de sesión, se observa la capacidad de cambio de idioma

pantalla de lista de alumnos


ejemplo de pantalla responsiva (tabletas y celulares)

pantalla de lista de cursos


pantalla con el cambio de tema (el usuario tendrá opciones predeterminadas)

pantalla que muestra el cambio de idioma


pantalla que muestra el cierre de sesión

pantalla que muestra el cambio de menu lateral (iconos texto - iconos)


pantalla con formulario para agregar curso

pantalla con notificación de éxito en la creación/edición/eliminación de elementos


pantalla con notificación de error en la creación/edición/eliminación de elementos

pantalla de evaluaciones de un curso, debajo de nombre del alumno, encontramos un +, sirve para
agregar alumnos al curso
pantalla con formulario para agregar alumno

pantalla donde se muestra opción para agregar evaluaciones al curso


pantalla con formulario para agregar una evaluación

pantalla con selector de fechas para evaluación


pantalla donde se muestran las opciones de editar y eliminar una evaluación

6.12 Mapa de Navegabilidad


mapa de navegabilidad,donde se muestra las acciones dentro de cada página

6.13 Componentes de sistema


diagrama de componentes, donde se muestra la relación entre los elementos públicos (*.html) y
los elementos que deben ser accedidos por medio del API (*.php)

6.14 Implementación

diagrama de despliegue, donde se muestran los componentes que se ejecutarán en el cliente y


aquellos que se ejecutarán en el servidor

6.15 Metodología de pruebas


diagrama que muestra la implementación de pruebas en el desarrollo del sistema

6.16 Herramientas de prueba de pruebas


Para verificar y validar el funcionamiento del sistema, se utilizarán tres tipos de pruebas, de
aceptación, de integración y unitarias, las dos primeras implican la interacción de una persona para
poder realizarlas, la última implica el uso de software para realizarlo. Debido al uso del framework
Codeigniter para el desarrollo del sistema, tenemos que ocupar una herramienta que trabaje
correctamente con este.
La herramienta seleccionada es Toast, http://jensroland.com/projects/toast, el cual se elije
considarando sus caracteristicas:
● Ligero
● Integración con Codeigniter
● Sintaxis parecida a JUnit
● Trabaja desde el navegador
● Permite realizar pruebas individuales, en grupo o todas en un solo momento

7 Calidad del Sistema


Para asegurar la calidad del sistema, se adoptará el modelo basado en los procesos, en el cual
se busca analizar las actividades del proceso que más influyen en la calidad del producto.

Para ello se empleará el modelo NMX-I-NYCE 2005 de Moprosoft.

7.1 Calidad en los procesos


El modelo de procesos, está basado en las siguientes normas:

● NYSE NMX-0-059/01 definición de conceptos y productos.


● NYSE NMX-0-059/02 requisitos de procesos
● NYSE NMX-0-059/03 guía de implantación de procesos.
● NYSE NMX-0-059/04 para la evaluación de procesos.

Para garantizar la calidad en el proceso, se tendrán en cuenta las características y necesidades


de cada módulo; en las siguientes etapas:

Es necesario recalcar que debido a que el modelo de desarrollo de software es SCRUM, se


implementará la técnica de Desarrollo Dirigido por Test (TDD) En cada una de las etapas, se
tendrán como directivas generales; las siguientes características:
Característica Definición

Tolerancia a fallos Es la capacidad de mantener un nivel de prestaciones


en caso de fallo.

Capacidad de recuperación Capacidad de restablecer un cierto nivel de


prestaciones y de recuperar los datos en caso de fallos

Cumplimiento de fiabilidad El software se adherirá a regulaciones relacionadas con


la fiabilidad.

Entendimiento Permitirá al usuario entender si el software es


adecuado y cómo puede ser usado para unas tareas o
condiciones de uso particulares

Facilidad de aprendizaje El usuario podrá aprender a usar el software de forma


simple y sencilla.

Facilidad de administración El software que permitirá al usuario administrarlo y


controlarlo.

Usabilidad El software será entendido, aprendido, usado y


atractivo para el usuario.

Estabilidad El software evitará efectos inesperados.

Eficiencia Capacidad del producto para propiciar las prestaciones


apropiadas, bajo las condiciones determinadas

Además se tendrán en cuenta los dos elementos que involucran el desarrollo del proyecto: el
equipo y el cliente; por lo cual se implementarán los siguientes test:
7.2 Métodos de Verificación

Para verificar las características de calidad mencionadas en la sección anterior, se emplearán las
siguientes pruebas:

● Pruebas Unitarias, para realizar las pruebas unitarias se empleará el software de Toast
CodeIgniter. Dicho software realiza las pruebas unitarias de forma automática, generando un
reporte que tiene la apariencia siguiente:

y del que se extraerán los datos para llenar el Templete correspondiente:


● Pruebas de Integración Las pruebas de integración se realizarán al término de cada
Sprint, y consisten en que el verificador ingresará al elemento desarrollado simulando ser
un usuario común y verificará la estabilidad del sistema, y comprobará que funcione y se
comporte de acuerdo a los requerimientos establecidos al inicio; en caso de hallar algún
fallo, se reportará mediante el documento correspondiente, que se detalla a continuación.
7.3 Métodos de validación

Para validar que el sistema se desarrolla de acuerdo con los requerimientos del cliente y con la calidad
esperada, se realizarán:

● Pruebas de aceptación, que consisten en acordar con el cliente al inicio de cada Sprint,
la forma de operación del sistema, las cuales se registrarán en el documento
correspondiente, el cual empleará el templete mostrado a continuación:
7.4 Responsable de calidad

La calidad del proyecto estará a cargo del Ingeniero de Implementación, quien tendrá las
funciones siguientes:
1. Al inicio de cada Sprint, el Ingeniero de Implementación en conjunto con el Ingeniero de
Requerimientos, solicitará las pruebas de aceptación establecidas con el cliente.
2. Una vez terminado el diseño y codificación, se iniciará con el período de pruebas unitarias
mediante el empleo del software Toast CodeIgniter, del que se extraerán los datos para
llenar el templete de pruebas unitarias.
3. Una vez realizadas las pruebas unitarias, se realizarán las pruebas de integración; para
ello se requerirá de las pruebas de aceptación generadas al inicio del sprint, las cuales
serán probadas ahora a nivel funcional, y cuya realización será anotada en el registro de
pruebas unitarias, el cual contempla el posible hallazgo de fallos o inestabilidad en el
sistema. Las pruebas unitarias serán evolutivas, es decir, que conforme se vayan
terminando los módulos, éstos se irán agregando a las pruebas de tal manera que se
realice una visión integral del sistema.

8 GESTIÓN DE LA CONFIGURACIÓN
8.1.Nombre Tecnico del Proyecto

SGD 10 version 1.0


8.2 Nomenclatura para nombrar los Documentos

8.3 Nomenclatura para nombrar los Archivos


8.4 Control de Versiones

La necesidad de tener un control sobre los cambios y modificaciones dentro de los archivos y el
desarrollo en general del software se ha convertido en parte fundamente de la ingeniería de
software.

Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los
elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de
un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo
o modificación.

En el desarrollo del proyecto SGD10 desarrollado por InDeSoft S. A. de C. V. se determinó usar


como Servidor de versiones la plataforma BitBucket (https://bitbucket.org/) y como herramienta
tecnologíca Mercurial (http://mercurial.selenic.com/)

El equipo de desarrollo es consciente de su trabajo y todos los aspectos que esto conlleva
implicitamente. Hablando de control de versionamientos es necesario que todos los días al iniciar
las actividades dentro de la empresa cada desarrollador deberá realizar un pull (descargar la
última versión que se encuentra en el servidor) y al terminar las actividades diarias deberán hacer
un push (generar una nueva versión). El push y pull son elementos que se tienen en el IDE
Netbeans, el cual es utilizado para desarrollar SGD10 dentro del módulo de PHP.Es necesario
decir que Netbeans esta configurado con Bibucket que es nuestro servidor de versiones.

8.5 Almacenamiento de Artefactos


Como se ha mencionado anteriormente la comunicación con el cliente es un pilar para el
desarrollo adecuado del Software, por lo cual se han definido dos repositorios. El primer
repositorio será para nuestro cliente.

El repositorio con el cliente consta de una carpeta compartida dentro de la plataforma DropBox
donde se depositaran todos los documentos terminados y que servirán para presentarlos con el
cliente.

El repositorio con los desarrolladores consta de una carpeta compartida dentro de la plataforma
Google Drive donde se depositaran todos los documentos no terminados que servirán para los
documentos creados y sobre los cuales se va a trabajar.

8.6 Responsable de Artefactos


Dentro del equipo que trabaja dentro del proyecto SGD10 el ingeniero de requerimientos tiene
como responsabilidad ingresar los documentos respectivos a las plataformas DropBox y Google
Drive ya que esta en constante comunicación con el cliente y con el equipo de desarrollo

CAPÍTULO 9
CONTROL DEL PROYECTO

9.1. Control del proyecto


9.1.1. Reuniones de seguimiento
Los entregables serán planeados y entregados conforme a la cantidad de “sprints” que se han
propuesto en el calendario del proyecto.
Para SGD10 hay 17 semanas de trabajo y 14 “sprints” , se creará un reporte para cada
documento que confirme la actividad realizada.
9.1.2. Formato de la convocatoria
Formato de convocatoria, reunión, junta, etc. Cuando se envía la comunicación de convocatoria
(existiendo diferentes tipos), éste se envía a las a una serie de personas en concreto o que
tienen relación con los temas a tratar o un determinado fin.
9.1.3. Formato de la minuta

Las minutas de trabajo pueden ser tan extensas o tan breves como sea necesario, de la
misma manera pueden ser tan detalladas, haciendo literalmente una transcripción, o
tan sencillas y generales, como una lista de resoluciones y decisiones tomadas en la
reunión. aqui el formato:
9.2 Control del proyecto.
9.2.1. Procedimiento de entrega
9.2.2. Responsable de entregables

Para efecto de formalizar todo el trato con los clientes ,e llresponsable de vigilar el contenido
de los entregables el encargado será directamente el director de la organización, quien estara a
cargo de todas las actividades y responsabilidades derivadas de esta actividad.

9.2.3. Resguardo de componentes

Los modulos de programación se guardarán al final de las sesiones de trabajo en “google drive”
bajo la cuenta y administración del Ing. López Razo Benito Samuel, encargado de los reportes.
También habrá un respaldo físico en unidades de CD por cada sprint y/o modulo creado.

9.2.4 Proceso de verificación y validación.

Este proceso se hace con el cliente y con director de “InDeSoft”. este proceso se tiene como
evidencia los documentos que más adelante se muestra para dejar evidencia de los avances
del proyecto y también para la entrega final del software, el lugar serán las instalaciones de la
compañía y las fechas serán las que estan planeadas en el calendario de entregas.

9.3. Entrega final del proyecto


9.3.1. Estrategia de entrega

La estrategia de entrega para el proyecto de software será a través de los entregables que se
encuentran calendarizados, las reuniones del director general con el cliente y de los documentos
que avalan el avance de los módulos entregados. Toda la documentación será archivada para
un registro para posibles seguimientos.
9.3.2. Evidencia de entrega
A continuación se muestran los formularios para la entrega y validación de evidencia:
Acta de entrega.
Acta de aceptación
9.3.2. Cierre del proyecto

El objetivo del Reporte de postmortem de Proyecto consiste en:

Identificar los problemas generados durante el desarrollo de un proyecto para mejorar el


desempeño de los participantes en futuros proyectos. Los sub objetivos del reporte de
postmortem de proyecto son:

● Generar un banco de problemas de proyecto para proponer soluciones a futuros


problemas en el desarrollo de nuevos proyectos.
● Generar un resumen de sugerencias de solución de problemas para prevenir futuros
problemas en el desarrollo de los proyectos.
● Estrategias para desarrollar el reporte de postmortem de proyectos.
● Para el llenado del informe se sugiere realizar un llenado lineal, es decir, siguiendo el
orden en que aparecen las secciones.

Contenido del reporte de postmortem de proyecto:

1. Portada
2. Introducción
3. Situación Actual
4. Administración de Proyectos
5. Recursos Humanos
6. Evaluación Requerimientos Funcionales y Técnicos
7. Presupuesto
8. Infraestructura
9. Plan de Implementación
10. Problemas Post Producción
11. Logros / Problemas
12. Recomendaciones

Funcionalidades del sistema, así como aprobación del plan de trabajo e impactos de algunos
puntos sobre el mismo, resultaron no ser confiables.

Recomendaciones: Es un concentrado con la información de los problemas (clasificados según


su tipo) y que contiene una serie de recomendaciones para resolver o prevenir el problema.

También podría gustarte