Presentacion proyecto final segundo elemento

BitácoraVirtual
Fundamentos de Ingeniería de Software
Martes 08 de octubre de 2013

1. INTRODUCCION
1.1 Presentación de la empresa
UES Universidad Estatal de Sonora, cuenta con 5 planteles en el estado como lo son la
unidad académica de Hermosillo, unidad académica de San Luis Rio Colorado, unidad
académica de Magdalena, unidad académica de Navojoa y unidad académica de
Benito Juárez.
El proyecto se enfocará en la UES de Benito Juárez, que se encuentra ubicada en Villa
Juárez, Sonora calle Fraternidad s/n entre 5 de Mayo e Hidalgo. Esta unidad académica
cuenta con distintas carreras como lo son:
• Ingeniería en Software
• Lic.Agronegocios
• Lic. Entrenamiento Deportivo
• Lic.Administración
• Lic. Contabilidad
El plantel cuenta con Aulas para clases, Biblioteca, Centro de Cómputo, Sala de Auto
Acceso. El proyecto se enfoca al centro de cómputo y sala de auto acceso.

1.2 Problema a resolver
En la sala de auto acceso, para obtener el acceso a una computadora
el alumno o personal tiene que anotarse en un libro con su nombre, número
de expediente, carrera, hora de entrada y hora de salida, eso se lleva a cabo
para sacar una estadística al día y por mes, pero se lleva tiempo y son
demasiados datos. Se requiere realizar una bitácora para ambas salas, para
resolver en menos tiempo lo que se requiere de información.
En el centro de cómputo se necesita cambiar la bitácora actual y tendría la
misma función que en la sala de auto acceso.

1.3 Objetivo
Realizar un sistema de acceso para el CC y la Sala de Auto-Acceso, con el
propósito de tener un mejor control de la información; agilizar el proceso
de registro de los alumnos y por lo tanto disminuir el tiempo en que lo
hacen; obtener reportes de estadísticas especificas con base a la
información registrada. Todo esto mediante un sistema de información
creado en el lenguajeVisual C#.

1.4 Alcance
El principal alcance que tendrá este sistema es que el alumno podrá tener
acceso a cualquier equipo del plantel con sólo ingresar su matrícula en él
sin tener que registrarse en papeles. Se requiere generar reportes
semanales y mensuales con la información del usuario, por lo que al iniciar
sesión con la matricula, se registrará automáticamente la hora de inicio, y
al cerrar sesión, la hora de salida.
Se registrarán datos como lo son el nombre del alumno o personal
de la escuela; carrera (si es alumno); sexo; número de la máquina y las
horas de inicio-salida

1.4 Alcance
Otro aspecto muy importante que tendrá el nuevo sistema, es que no solo
será utilizado por alumnos, también el personal docente, administrativo y
técnicos en la universidad tendrán un acceso. La información se manejará
por pública y restringida. La información pública, será a la que el
alumnado de la escuela o personas ajenas a ella puedan tener acceso
fácilmente y la restringida es a la que sólo el personal docente, técnico o
administrativo del plantel podrá tener acceso.

2. ORGANIZACIÓN DEL PROYECTO
2.1 Equipo involucrado
Cinthya Lorena Galaviz Álvarez
Karen Nallely Quihuis García
Sandra Myriam IslasYocupicio
María IcelaVázquez Cabada
Brenda Aracely Buitimea García
Miguel Antonio Gonzalez German
2.2 Roles del equipo involucrado
Jefe de Proyecto: Cinthya Lorena Galaviz Álvarez.
Analistas:Sandra Myriam IslasYocupicio, Karen Nallely Quihuis García.
Diseño:Cinthya Lorena Galaviz Álvarez
Programación: María IcelaVázquez Cabada, MiguelAntonio González Germán

2.3 Principios que se aplicarán dentro
del equipo
• En cada etapa, centrarse en la calidad.
• Estar listo para adaptar.
• Formar un equipo eficaz.
• Establecer mecanismos para la comunicación y
coordinación.
• Evaluar el riesgo.
• Divide y vencerás.
• Centrarse en la transferencia de información.
• Tener en mente que alguien dará mantenimiento
al software.
• Alguien debe facilitar la actividad.
• Es mejor la comunicación cara a cara.
• Tomar notas y documentar las decisiones.
• Una vez que se acuerde algo, avanzar; Si no es
posible ponerse de acuerdo en algo, avanzar; Si
una característica o función no está clara o no
puede aclararse en el momento, avanzar.
• Entender el alcance del proyecto.
• Reconocer que la planeación es iterativa.
• Estimar con base en lo que se sabe.

2.3 Principios que se aplicarán dentro
del equipo
• Entender el problema que se trata de resolver.
• Comprender los principios y conceptos básicos
del diseño.
• Elegir un lenguaje de programación que satisfaga
las necesidades del software que se va a elaborar
y el ambiente en el que operará.
• Tomar en consideración el uso de programación
por parejas.
• Seleccionar nombres significativos para las
variables y seguir otros estándares locales de
codificación.
• Realizar el recorrido del código cuando sea
apropiado.
• Llevar a cabo pruebas unitarias y corregir los
errores que se detecten.
• Todas las pruebas deben poder rastrearse hasta
los requerimientos del cliente.
• Las pruebas deben planearse mucho antes de
que den comienzo.
• Las pruebas deben comenzar “en lo pequeño” y
avanzar hacia “lo grande”.
• Se deben proporcionar a los usuarios finales
materiales de aprendizaje apropiados.
• El software defectuoso debe corregirse primero y
después entregarse.

3. ANALISIS DE RIESGOS
3.1 Riesgos del proyecto
El acelerado crecimiento de la tecnología de la información en los últimos 15
años ha generado un creciente número de oportunidades así como un
creciente número de amenazas.
Un alto nivel de inversión en la tecnología, tal cual existe hoy en día, produce
un efecto multiplicador importante en caso de que dichas amenazas se
materialicen, dado que las pérdidas posibles se ven incrementadas en igual
proporción al aumento de la inversión.

Clasificación y flujo de información.
IDENTIFICAR TIPO DE DATOS E INFORMACION Y
CLASIFICARLO:
Confidencial Acceso restringido: personal interno autorizado
Privado Acceso restringido: personal interno.
Sensitivo
Acceso controlado: personal interno, público externo con
permiso.
Público
ANÁLISIS DE FLUJO DE LA INFORMACIÓN:
- Observar cuáles instancias manejan que información
- Identificar grupos externos que dependen o están
interesados en la información.
- Determinar si se deben efectuar cambios en el manejo de
la información.

3.1.1 Identificación de Riesgos
Tipo de riesgo Posible riesgo
Personal
 Programador experimentado abandono el proyecto.
 Capacitación para el personal no está terminada.
 Miembros del equipo enfermaron y no están disponibles en momentos críticos.
 Diseñador experimentado rechazo el proyecto en último momento.
Tecnología
 La base de datos no procesa la información a la velocidad y en el tiempo requerido.
 El servidor no está bien instalado, no funcionara en momentos críticos.
 Varios de los componentes de hardware están fallando y reducen la calidad del software.
Organizacional
 La empresa recorto el presupuesto para el equipo de desarrolladores del software.
 Nuevos requerimientos de la organización obligan a reajustar el software.
 Un cambio en la estructura de la empresa obliga a otra gestión a hacerse cargo del proyecto.
Herramientas  Es ineficiente la reutilización del código.
Requerimientos
 Se proponen nuevos requerimientos de último minuto y requieren un nuevo diseño.
 La organización no comprende el impacto de los cambios en los requerimientos del sistema.
Estimación
 El tamaño del software esta subestimado.
 El tiempo requerido para terminar el software está subestimado.

3.1.2 Análisis de Riesgos
Tipo de problema Probabilidad Efectos
SUCESOS FISICOS:
- Incendio
- Inundación
- Falta de corriente
Baja Catastrófico
CRIMINALIDAD:
- Robo
- Virus
Moderada Serio
Fallo o error en software Moderada Serio
Base de datos no procesa
transacciones por segundo como
se espera.
Moderada Serio
Cambio de requerimientos que
necesitan un rediseño en el
software.
Moderada Serio
Fallas en el hardware limitan la
funcionabilidad de software.
Moderada Serio
Capacitación a personal
incompleta.
Moderada Tolerable
Tamaño del software
subestimado.
Alta Tolerable
NEGLIGENCIA:
- Compartir contraseñas
- No cifrar datos críticos
Alta Tolerable

3.1.3 Planificación de Riesgos
RIESGO ESTRATEGIA
Enfermedad del personal.
Reorganizar al equipo de trabajo para evitar
solapamiento en el personal.
Componentes defectuosos.
Reemplazar los componentes defectuosos
con los nuevos adquiridos de fiabilidad
conocida.
Problemas de reclutamiento.
Alertar a la organización de las potenciales
dificultades y posibles retrasos.
Cambio en los requerimientos.
Valorar el impacto que los cambios que esto
traerá y maximizar la información oculta en
ellos.
Problemas financieros en la organización.
Realizar un documento breve al gestor
principal resaltando las contribuciones
importantes que el sistema traerá a la
organización.
Rendimiento de la base de datos.
Investigar la posible compra de una nueva
base de datos.
Tiempo de desarrollo y tamaño en sistema
subestimado.
Investigar los componentes comprados y la
utilización de un generador de programas.

3.1.4 Supervisión de Riesgos
TIPO DE RIESGO. INDICADOR DE POTENCIAL.
TECNOLOGÍA
Entrega retrasada del software de ayuda o
herramientas de hardware, problemas
tecnológicos reportados.
PERSONAL
Malas relaciones entre miembros del equipo,
baja moral en el personal.
ORGANIZACIONAL
Falta de acciones por el gestor personal de la
empresa.
HERRAMIENTAS
Rechazo del equipo al utilizar las
herramientas, peticiones de estaciones de
trabajo más potentes.
REQUERIMIENTOS
Muchas peticiones de cambios en los
requerimientos.
ESTIMACIÓN
Fracaso en el cumplimiento de los tiempos
acordaos y en eliminación de defectos
encontrados.

4. DIVISION DE TRABAJO
4.1 Metodología utilizada para el desarrollo
del sistema
Metodología RUP
4.1.1 Descripción
RUP (Rational Unified Process), es un proceso de desarrollo de software y
junto con el Lenguaje Unificado de Modelado UML, constituye la
metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos. Dicha metodología es
explícita en la definición de software y su trazabilidad, es decir, contempla
en relación causal de los programas creados desde los requerimientos hasta
la implementación y pruebas.

4.1.2 Explicación de adaptación de metodología al proyecto
Dicha metodología será aplicada al desarrollo de nuestro software, ya que al
aplicarla nos brindara una mayor organización dentro del equipo y nos
ayuda a identificar claramente a los profesionales involucrados en el
desarrollo del software y sus responsabilidades en cada una de las
actividades. Esta metodología es explicita en la definición de software y su
trazabilidad por lo que será más fácil analizar los requerimientos de nuestro
software hasta la implementación y pruebas de este, por lo cual podremos
mejorar su desarrollo y diseño..

4.2 Descripción de etapas y tareas a realizar
1) Inicio: Se realiza un plan de fases, donde se identificaran los principales
casos de uso y se identifican riesgos, también se concreta la idea y visión del
producto. Su objetivo es determinar la visión del proyecto.
En esta etapa realizaremos una visión de nuestro proyecto, donde
definiremos su uso, riesgos y objetivos.
2) Elaboración: Se realiza el plan de proyecto, donde se contemplaran los
casos de uso y se mitigan riesgos.
En esta esta etapa se deben planificar las actividades necesarias y recursos
que sean necesarios, especificando características y el diseño del software,
es decir que se debe hacer un análisis de los requerimientos y realizar un
diseño que sea aceptable al software.

3) Construcción: Esta etapa se basa en la elaboración de un producto
totalmente operativo y en la elaboración del manual de usuario.
En esta etapa se realizara el producto final del proyecto, es decir un sistema
que sea ejecutable, también se realizaran pruebas para evaluar la calidad del
software y encontrar errores en el sistema y documentarlos.
4) Transición: Se realiza la instalación del producto en el cliente y se procede
al entrenamiento de los usuarios, su objetivo es obtener el realce del
proyecto.
En esta etapa se entrega el producto final al cliente y se instala. Lo que
incluye manufactura, envió, entrenamiento, soporte y mantenimiento del
producto, todo esto hasta que el cliente quede satisfecho.

4.3 Productos entregables en cada una de las
etapas
1) Inicio: Se debe entregar una introducción del proyecto en forma de
informe con todos los requerimientos de la empresa, así como el
planteamiento del problema y objetivo del proyecto.
2) Elaboración: Se deben entregar los requerimientos del cliente y el diseño
de las pantallas y funcionamiento de estas.
3) Construcción: Se entrega el producto final del proyecto, y realizar un
informe con las pruebas realizadas a este.
4) Transición: El producto es entregado al cliente, se realiza el
entrenamiento a los usuarios finales, y se provee asistencia y ayuda a los
usuarios.

5. REQUERIMIENTOS DE RECURSOS DE
HARDWARE Y SOFTWARE
5.1 Requerimientos de Hardware
Equipo para CC:
Procesador: Intel Pentium 4 – 2.2 GHz
Memoria RAM: 2 Gb
Disco Duro: 300 Gb
SO:Windows 7 Ultimate 32 bits
Equipo para Sala de Auto-Acceso:
Procesador: Intel Core i3 | 3.3 Ghz
Memoria RAM: 4 Gb
Disco Duro: 500 Gb
SO:Windows 7 Ultimate 64 bits

5. REQUERIMIENTOS DE RECURSOS DE
HARDWARE Y SOFTWARE
5.2 Requerimientos de Software
• Para el diseño y programación del sistema se necesita el software
MicrosoftVisual Studio en su versión 2010 o 2012.
• Para la obtención, consulta y registro de los datos de los alumnos y
personal de la universidad se ocupará el manejador de bases de datos SQL
Server.
• El manual del usuario se entregará en un documento de texto en
MicrosoftWord o en un archivo PDF.

6. Programa del proyecto
6.1 Calendarización del Proyecto - Tabla

6. Programa del proyecto
6.1 Calendarización del Proyecto – Diagrama de Grantt

7. Prototipo del Sistema
Pantalla de Bienvenida al encender el equipo

Registro del equipo en la base de datos

Iniciar sesión con la matrícula

Ventana para cerrar sesión

Presentacion proyecto final segundo elemento

Más contenido relacionado

La actualidad más candente

Similar a Presentacion proyecto final segundo elemento

Presentacion proyecto final segundo elemento