FACULTAD DE IGENIERIAS

INGENIERIA DE SISTEMAS E INFORMATICA

INGENIERIA WEB I

SISTEMA DE CONTROL DE EQUIPOS Y ASISTENCIAS

ALUMNOS:
Einar Carbajal Quelcahuanca
Richard Lopez
Carlos Ponce
Jhonathan Quispe

DOCENTE: Ing. Luis Amaro Villanueva Tapia

CICLO IX 2014
ILO PERU
CUADRO COMPARATIVO DE METODOLOGIAS

MODELO ENFOQUE VENTAJAS/DESVENTAJAS APLICABILIDAD
MODELO EN
CASCADA
El inicio de cada
etapa debe
esperar a la
finalizacin de la
inmediatamente
anterior.
Cualquier error de
diseo detectado
en la etapa de
prueba conducen
necesariamente al
rediseo y
programacin del
cdigo afectado
as aumenta
costos del
desarrollo
Rara vez los proyectos siguen
una evolucin secuencial.
Es ampliamente criticado
desde mbito educativo y
empresarial
Utilizado cuando
existen
especificaciones
amplias de los
requerimientos del
cliente
MODELO BASADO
EN PROTOTIPOS
No posee la
funcionalidad
total del sistema
pero sui condensa
la idea principal
del mismo, paso a
paso crece su
funcionalidad, alto
grado de
participacin del
usuario
El cliente puede pensar que el
prototipo es una versin
acabada.
Puede llegar a pasarse por
alto la calidad del software
global o el mantenimiento del
largo plazo.
Las herramientas elegidas
pueden ser inadecuadas.
La clave del xito de este
modelo consiste en definir
bien, desde el principio, las
reglas del juego.
Se utiliza si en el
mercado no se
encuentra el
producto pero el
cliente desea
resultados
inmediatos.
Para sistemas
interactivos
pequeos o de
tamao pequeo.
Para sistemas con
vida corta.
MODELO
INCREMENTAL O
EVOLUTIVO
Modelo Lineal-
Secuencial con el
modelo basado en
Prototipos.
El Sistema no se
entrega de una
vez, se divide y se
entrega
incrementos.
Junto a cada
incremento se
entrega una parte
de funcionalidad
que se ha
Los clientes no tienen que
esperar el producto
completo. El primero
incremento debe satisfacer o
mejor dicho satisface los
requisitos crticos.
Los primeros incrementos
sirven de prototipos y
ayudan a la obtencin de los
posteriores requisitos.
Puede ser difcil ajustar los
requisitos a los incrementos.

Reemplazar el
antiguo desarrollo
con uno nuevo que
satisfaga las nuevas
necesidades segn
las redefiniciones
del problema.

Manejo de
Versiones
establecido.
Los requisitos de
un incremento son
inamovibles; pero
pueden
modificarse en los
incrementos
posteriores
DFD
Representan la
forma en la que
los datos se
mueven y se
transforman
Favorecen la comprensin
del proceso a travs de
mostrarlo como un dibujo. Un
buen diagrama de flujo
reemplaza varias pginas de
texto. Permiten identificar los
problemas y las
oportunidades de mejora del
proceso.

Utilizado para
obtener los
procesos de forma
clara y para saber
de qu manera
fluyen los datos.
MODELO ESPIRAL
Es una mejora del
Modelo Basado en
prototipos
Cada vuelta en la
espiral representa
una fase del
proceso.
No hay fases fijas,
cada vuelta en la
espiral determina
las actividades a
realizar.
La dimensin
radial representa
el coste
acumulado en la
financiacin de las
fases.
La dimensin
angular
representa el
progreso hecho en
completar cada
ciclo de la espiral.
Un ciclo a travs
de la espiral es
simular un paso a
travs de un
modelo en cascada
Requiere comunicacin
permanente con el cliente por
lo tanto si se cambia el
contacto con el cual se realiza
desarrollo es necesario que
est al tanto de lo realizado y
lo pendiente, cliente debe ser
gran conocedor del sistema.

Utilizado para el
desarrollo de
aplicaciones
complejas y/o
especficas. (Ej.
Investigacin
Gentica)


MODELO BASADO
EN
COMPONENTES
(ORIENTADO A
OBJETOS)

Es programacin
orientada a
Objetos. Se
utilizan objetos,
clases y se
reutilizan en
diferentes partes
del sistema.

Optimiza los tiempos de
respuesta a los
requerimientos del cliente y
facilita la labor del
programador pues hay un
alto aprovechamiento del
cdigo.
Facilita mantenimiento del
software.

Sistemas robustos y
de alta proyeccin.

CODE AND FIX

No requiere
planeacin y se
trata de codificar y
corregir. Se
trabaja mediante
prueba y error.
Especial para
desarrollos
rpidos y sencillos

Desarrollo Rpido

No garantiza calidad

Desarrollo muy
pequeos con
claridad de
objetivos,
requerimientos
pequeos o de
mantenimientos
con bajo impacto.

CASCADA CON
SUBPROYECTOS

Requiere
planeacin.

Plantea Organizacin y
planeacin de un gran
proyecto
Se pueden realizar varias
partes del proyecto al mismo
tiempo por diferentes
desarrolladores

Adecuada para el
desarrollo de
proyectos
complejos que
estiman de 1 a 3
aos de desarrollo.

ENTREGA POR
ETAPAS

Cascada con
entregas grandes
en diferentes
etapas del
desarrollo.
Cascada con
Evolutivo.

Debe entregarse una etapa
para continuar con la
siguiente

Desarrollos
robustos.
Desarrollo depende
del presupuesto
directamente







1. DIAGRAMA DE FLUJO DE DATOS

Es una representacin grfica del flujo de datos a travs de un sistema de
informacin. Un diagrama de flujo de datos tambin se puede utilizar para la
visualizacin de procesamiento de datos (diseo estructurado). Es una prctica
comn para un diseador dibujar un contexto a nivel de DFD que primero muestra
la interaccin entre el sistema y las entidades externas
Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario
final una idea fsica de cmo resultarn los datos a ltima instancia, y cmo tienen
un efecto sobre la estructura de todo el sistema. La manera en que cualquier
sistema es desarrollado, puede determinarse a travs de un diagrama de flujo de
datos. Tiene niveles, los cuales son:
Nivel 0: Diagrama de contexto.
En el diagrama de contexto se caracterizan todas las interacciones que realiza
un sistema con su entorno (entidades externas), estas pueden ser otros
sistemas, sectores internos a la organizacin, o factores externos a la misma.
Se dibuja un slo proceso que representa al sistema en cuestin y se escribe su
nombre en dicha burbuja como un sustantivo comn ms adjetivos. De l
solamente parten los flujos de datos que denotan las interrelaciones entre el
sistema y sus agentes externos, no admitindose otros procesos ni
almacenamientos en el dibujo.
Resulta de gran utilidad para los niveles posteriores de anlisis como
herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos
DFD de Nivel "0".

Nivel 1: Diagrama de nivel superior.
En el diagrama de nivel superior se plasman todos los procesos que describen
al proceso principal. En este nivel los procesos no suelen interrelacionarse
directamente, sino que entre ellos debe existir algn almacenamiento o
entidad externa que los una. Esta regla de construccin sirve como ayuda al
analista para contemplar que en un nivel tan elevado de abstraccin (DFD
Nivel 1) es altamente probable que la informacin que se maneja requiera ser
almacenada en el sistema.
Nivel 2: Diagrama de detalle o expansin.
En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a
los caminos principales de la informacin dado que aumenta progresivamente
el nivel de detalle. De aqu en adelante se permiten los flujos entre procesos.

ELEMENTOS DE LOS DIAGRAMAS DE FLUJO DE DATOS
PROCESOS. Son un conjunto de tareas o acciones realizadas a partir de un flujo
de datos de entrada para producir flujos de datos de salida. Los procesos
pueden ser realizados por personas, departamentos, mquinas u ordenadores.





ENTIDADES EXTERNAS: Pueden ser personas, programas, organizaciones u
otras entidades que interactan con el sistema pero se encuentran fuera de su
frontera.








FLUJO DE DATOS: Movimiento de datos en determinada direccin desde un
origen hacia un destino en forma de documentos, cartas, llamadas telefnicas
o virtualmente por cualquier otro medio







ALMACN DE DATOS: Es el lugar donde se guardan los datos o al que hacen
referencia los procesos en el sistema. El almacenamiento de datos puede
representar dispositivos tanto computarizados como no computarizados.






VENTAJAS:

- Favorecen la comprensin del proceso a travs de mostrarlo como un
dibujo.
- Un buen diagrama de flujo reemplaza varias pginas de texto.
- Permiten identificar los problemas y las oportunidades de mejora del
proceso.
- Se identifican los pasos redundantes, los flujos de los reproceso, los
conflictos de autoridad, las responsabilidades, los cuellos de botella, y los
puntos de decisin.
- Muestran las interfaces cliente-proveedor y las transacciones que en ellas
se realizan, facilitando a los empleados el anlisis de las mismas.
- Son una excelente herramienta para capacitar a los nuevos empleados y
tambin a los que desarrollan la tarea, cuando se realizan mejoras en el
proceso.
- Es bastante sencillo y el ms utilizado por su fcil comprensin y
programacin.

DESVENTAJAS:

- Consume bastante tiempo de computadora.
- Requiere de muchas lecturas/escrituras en memoria.
- No se elaboran con base en los principios de la programacin estructurada,
ilustran el flujo del programa, pero no su estructura.
- Requiere de un espacio considerable y cuenta con demasiadas
ramificaciones.


EJEMPLO:



2. Modelo Incremental

El modelo incremental es una unin de las mejores funcionalidades del
modelo de cascada y del modelo de prototipos. A medida que se presenta un
prototipo se produce un incremento, que es una iteracin del proceso
anterior pero aplicando las experiencias aprendidas del proceso anterior. A
diferencia del modelo de prototipos, los prototipos de este modelo estn
orientados a ser operacionales en cada incremento y no ser solo una previa
de cmo sera el sistema en su versin final.

El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el
enfoque incremental de desarrollo como una forma de reducir la repeticin
del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma
de decisiones en los requisitos hasta adquirir experiencia con el sistema. Este
modelo se conoce tambin bajo las siguientes denominaciones:

Mtodo de las comparaciones limitadas sucesivas.
Ciencia de salir del paso.
Mtodo de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con
la filosofa interactiva de Construccin de Prototipos. El modelo incremental
aplica secuencias lineales de forma escalonada mientras progresa el tiempo en
el calendario. Cada secuencia lineal produce un incremento del software. El
primer incremento generalmente es un producto esencial denominado ncleo.
En una visin genrica, el proceso se divide en 4 partes:

Anlisis
Diseo
Cdigo
Prueba




Sin embargo, para la produccin del Software, se usa el principio de trabajo en
cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con
los resultados obtenidos en cada incremento. Es el mismo cliente el que
incluye o desecha elementos al final de cada incremento a fin de que el
software se adapte mejor a sus necesidades reales. El proceso se repite hasta
que se elabora el producto completo. De esta forma el tiempo de entrega se
reduce considerablemente.

El Modelo Incremental es de naturaleza interactiva brindando al final de cada
incremento la entrega de un producto completamente operacional. Este
modelo es particularmente til cuando no se cuenta con una dotacin de
personal suficiente. Los primeros pasos los pueden realizar un grupo reducido
de personas y en cada incremento se aadir personal, de ser necesario. Por
otro lado los incrementos se pueden planear para gestionar riesgos tcnicos.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes
que al final terminar siendo la solucin completa requerida por el cliente,
pero stas partes no se pueden realizar en cualquier orden, sino que
dependen de lo que el cliente este necesitando con ms urgencia, de los
puntos ms importantes del proyecto, los requerimientos ms bsicos, difciles
y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de
manera que se disminuya la dificultad y el riesgo en cada versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin)
que podr ser entregada al cliente para que ste pueda trabajar en ella y el
programador pueda considerar las recomendaciones que el cliente efecte
para hacer mejoras en el producto. Estas nuevas mejoras debern esperar a
ser integradas en la siguiente versin junto con los dems requerimientos que
no fueron tomados en cuenta en la versin anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura
completa del sistema, seguido de sucesivos incrementos funcionales. Cada
incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar
su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se
realizan cambios sobre el mismo, sino nicamente correccin de errores. Dado
que la arquitectura completa se desarrolla en la etapa inicial, es necesario
conocer los requerimientos completos al comienzo del desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos,
las funcionalidades que proporcionar el sistema. Se confecciona un bosquejo
de requisitos funcionales y ser el cliente quien se encarga de priorizar que
funcionalidades son mas importantes. Con las funcionalidades priorizadas, se
puede confeccionar un plan de incrementos, donde en cada incremento se
indica un subconjunto de funcionalidades que el sistema entregar. La
asignacin de funcionalidades a los incrementos depende de la prioridad dada
a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el
primer incremento.


Caractersticas:
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
El usuario se involucra ms.
Difcil de evaluar el costo total.
Difcil de aplicar a los sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.


Ventajas:
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya
que se implementa la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada
realimentado, reduciendo sus desventajas slo al mbito de cada
incremento.
Resulta ms sencillo acomodar cambios al acotar el tamao de los
incrementos.


Desventajas:
El modelo incremental no es recomendable para casos de sistemas de
tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de
alto ndice de riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto.


Conclusin:

Un modelo incremental lleva a pensar en un desarrollo modular, con entregas
parciales del producto Software denominados "incrementos" del sistema, que
son escogidos en base a prioridades predefinidas de algn modo. El modelo
permite una implementacin con refinamientos sucesivos (ampliacin y/o
mejoras). Con cada incremento se agrega nueva funcionalidad o se cubren
nuevos requisitos o bien se mejora la versin previamente implementada del
producto software.




3. DEFINICION DE METODOLOGIA A USAR EN EL SISTEMA DE
CONTROL DE EQUIPOS Y ASISTENCIAS
La metodologa que se escogi para el desarrollo de un sistema de control de
equipos y asistencias, es la de Diagramas de Flujos de Datos (DFD) porque
gracias a esta metodologa podremos identificar de manera rpida los
procesos y funciones del sistema y definir tambin que datos fluyen entre cada
proceso.

DFD NIVEL 0: DIAGRAMA DECONTEXTO

SISTEMA DE CONROL DE
EQUIPOS Y ASISTENCIAS
USUARIO
OATI
Confirma recepcin Solicita recepcion
Registra recepcion
Registra laboratorio
Modifica registro
Elimina registro
Genera recepcion


DFD NIVEL 1:

1
GENERACION DE
REGISTROS
2
MODIFICACION
DE REGISTROS
3
ELIMINACION DE
REGISTROS
4
RECEPCION
USUARIOS
LABORATORIOS
EQUIPOS OATI
LABORATORIOS
USUARIOS
OATI
VALIDACION
RECEPCION
GUARDA
GENERA
USUARIO
SOLICITA RECEPCION

DFD NIVEL 2: EXPLOTACION PROCESO 1

1.1
.REGISTRO DE
LABORATORIOS
1.2
.REGISTRO DE
EQUIPOS
1.3
.REGISTRO DE
USUARIOS
OATI
EQUIPOS LABORATORIOS USUARIOS
GUARDA GUARDA GUARDA
CREA
CREA
CREA
1.4
.REGISTRO DE
ENCARGADOS DE
OATI
OATI
CREA
GUARDA




DFD NIVEL 2: EXPLOTACION PROESO 2

2.1
MODIFICACION DE
REGISTROS DE
LABORATORIOS
2.2
MODIFICACION DE
REGISTROS DE
EQUIPOS
2.3
MODIFICACION DE
REGISTROS DE
USUARIOS
OATI
EQUIPOS LABORATORIOS USUARIOS
GUARDA GUARDA GUARDA
MODIFICA
MODIFICA
MODIFICA
2.4
MODIFICACION DE
REGISTROS DE
ENCARGADOS DE
OATI
OATI
MODIFICA
GUARDA

DFD NIVEL 2: EXPLOTACION PROESO 3

3.1
ELIMINACION DE
REGISTROS DE
LABORATORIOS
3.2
ELIMINACION DE
REGISTROS DE
EQUIPOS
3.3
ELIMINACION DE
REGISTROS DE
USUARIOS
OATI
EQUIPOS LABORATORIOS USUARIOS
GUARDA GUARDA GUARDA
ELIMINA
ELIMINA
ELIMINA
3.4
ELIMINACION DE
REGISTROS DE
ENCARGADOS DE
OATI
OATI
ELIMINA
GUARDA



DFD NIVEL 2: EXPLOTACION PROESO 4

4.1
SOLICITUD
OATI
INGRESA SOLICITUD
4.2
REGISTRO DE
RECEPCION
4.3
FINALIZACION DE
RECEPCION
USUARIOS
SE INCLUYE DATOS
RECEPCION
SE GUARDA
GUARDA FINALIZACION