You are on page 1of 15

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
finalización de la
inmediatamente
anterior.
Cualquier error de
diseño detectado
en la etapa de
prueba conducen
necesariamente al
rediseño y
programación del
código afectado
así aumenta
costos del
desarrollo
Rara vez los proyectos siguen
una evolución 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
participación del
usuario
El cliente puede pensar que el
prototipo es una versión
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
pequeños o de
tamaño pequeño.
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 críticos.
Los primeros incrementos
sirven de prototipos y
ayudan a la obtención de los
posteriores requisitos.
Puede ser difícil ajustar los
requisitos a los incrementos.

Reemplazar el
antiguo desarrollo
con uno nuevo que
satisfaga las nuevas
necesidades según
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 comprensión
del proceso a través de
mostrarlo como un dibujo. Un
buen diagrama de flujo
reemplaza varias páginas 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 dimensión
radial representa
el coste
acumulado en la
financiación de las
fases.
La dimensión
angular
representa el
progreso hecho en
completar cada
ciclo de la espiral.
Un ciclo a través
de la espiral es
simular un paso a
través de un
modelo en cascada
Requiere comunicación
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
específicas. (Ej.
Investigación
Genética)


MODELO BASADO
EN
COMPONENTES
(ORIENTADO A
OBJETOS)

Es programación
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
código.
Facilita mantenimiento del
software.

Sistemas robustos y
de alta proyección.

CODE AND FIX

No requiere
planeación y se
trata de codificar y
corregir. Se
trabaja mediante
prueba y error.
Especial para
desarrollos
rápidos y sencillos

Desarrollo Rápido

No garantiza calidad

Desarrollo muy
pequeños con
claridad de
objetivos,
requerimientos
pequeños o de
mantenimientos
con bajo impacto.

CASCADA CON
SUBPROYECTOS

Requiere
planeación.

Plantea Organización y
planeación 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
años 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 representación gráfica del flujo de datos a través de un sistema de
información. Un diagrama de flujo de datos también se puede utilizar para la
visualización de procesamiento de datos (diseño estructurado). Es una práctica
común para un diseñador dibujar un contexto a nivel de DFD que primero muestra
la interacción entre el sistema y las entidades externas
Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario
final una idea física de cómo resultarán los datos a última instancia, y cómo tienen
un efecto sobre la estructura de todo el sistema. La manera en que cualquier
sistema es desarrollado, puede determinarse a través 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 organización, o factores externos a la misma.
Se dibuja un sólo proceso que representa al sistema en cuestión y se escribe su
nombre en dicha burbuja como un sustantivo común más adjetivos. De él
solamente parten los flujos de datos que denotan las interrelaciones entre el
sistema y sus agentes externos, no admitiéndose otros procesos ni
almacenamientos en el dibujo.
Resulta de gran utilidad para los niveles posteriores de análisis 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 algún almacenamiento o
entidad externa que los una. Esta regla de construcción sirve como ayuda al
analista para contemplar que en un nivel tan elevado de abstracción (DFD
Nivel 1) es altamente probable que la información que se maneja requiera ser
almacenada en el sistema.
 Nivel 2: Diagrama de detalle o expansión.
En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a
los caminos principales de la información 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, máquinas u ordenadores.





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








 FLUJO DE DATOS: Movimiento de datos en determinada dirección desde un
origen hacia un destino en forma de documentos, cartas, llamadas telefónicas
o virtualmente por cualquier otro medio







 ALMACÉN 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 comprensión del proceso a través de mostrarlo como un
dibujo.
- Un buen diagrama de flujo reemplaza varias páginas 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 decisión.
- Muestran las interfaces cliente-proveedor y las transacciones que en ellas
se realizan, facilitando a los empleados el análisis de las mismas.
- Son una excelente herramienta para capacitar a los nuevos empleados y
también a los que desarrollan la tarea, cuando se realizan mejoras en el
proceso.
- Es bastante sencillo y el más utilizado por su fácil comprensión y
programación.

DESVENTAJAS:

- Consume bastante tiempo de computadora.
- Requiere de muchas lecturas/escrituras en memoria.
- No se elaboran con base en los principios de la programación 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 unión 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 iteración del proceso
anterior pero aplicando las experiencias aprendidas del proceso anterior. A
diferencia del modelo de prototipos, los prototipos de este modelo están
orientados a ser operacionales en cada incremento y no ser solo una “previa”
de cómo sería el sistema en su versión final.

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el
enfoque incremental de desarrollo como una forma de reducir la repetición
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 también bajo las siguientes denominaciones:

 Método de las comparaciones limitadas sucesivas.
 Ciencia de salir del paso.
 Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con
la filosofía interactiva de Construcción 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 núcleo.
En una visión genérica, el proceso se divide en 4 partes:

 Análisis
 Diseño
 Código
 Prueba




Sin embargo, para la producción 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 dotación de
personal suficiente. Los primeros pasos los pueden realizar un grupo reducido
de personas y en cada incremento se añadirá personal, de ser necesario. Por
otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes
que al final terminará siendo la solución 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 más urgencia, de los
puntos más importantes del proyecto, los requerimientos más básicos, difíciles
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 versión.
De este modo podemos terminar una aplicación ejecutable (primera versión)
que podrá ser entregada al cliente para que éste pueda trabajar en ella y el
programador pueda considerar las recomendaciones que el cliente efectúe
para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a
ser integradas en la siguiente versión junto con los demás requerimientos que
no fueron tomados en cuenta en la versión 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 corrección 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
asignación 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.


Características:
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
 El usuario se involucra más.
 Difícil de evaluar el costo total.
 Difícil 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.
 También 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 sólo al ámbito de cada
incremento.
 Resulta más sencillo acomodar cambios al acotar el tamaño 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 planeación, tanto administrativa como técnica.
 Requiere de metas claras para conocer el estado del proyecto.


Conclusión:

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 algún modo. El modelo
permite una implementación con refinamientos sucesivos (ampliación y/o
mejoras). Con cada incremento se agrega nueva funcionalidad o se cubren
nuevos requisitos o bien se mejora la versión previamente implementada del
producto software.




3. DEFINICION DE METODOLOGIA A USAR EN EL SISTEMA DE
CONTROL DE EQUIPOS Y ASISTENCIAS
La metodología 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 metodología podremos identificar de manera rápida los
procesos y funciones del sistema y definir también que datos fluyen entre cada
proceso.

DFD NIVEL 0: DIAGRAMA DECONTEXTO

SISTEMA DE CONROL DE
EQUIPOS Y ASISTENCIAS
USUARIO
OATI
Confirma recepción 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