CIS-425: Análisis y diseño de
sistemas
Semana 3
Dr. Jesús Borrego
Lead Faculty, COS
Regis University
1
scis.regis.edu ● [email protected]
Agenda
•
•
•
•
•
2
Vocabulario Clave
Capítulo 4 – Model de Requisitos
Actividad 1
Capítulo 5 – Model de datos y procesos
Actividad 2
Vocabulario clave
• Federation
• Methodology
• Systems
Development
LifeCycle
3
• Federación
• Metodología
• Ciclo vitalicio del
desarrollo de
sistemas
Capítulo 4 – Modelo de Requisitos
• El análisis de sistemas es la segunda de las 5
fases del SDLC
• Usaremos el modelo de requisitos, datos,
procesos y objectos para representar el sistema
• Consideraremos varias estrategias para el nuevo
sistema y el plan de transición a las tareas del
diseño del sistema
4
Objetivos
• Describir las actividades de la fase de análisis del
sistema
• Explicar el desarrollo de aplicación conjunta
(joint application development - JAD),
desarrollo rápido de aplicaciones (rapid
application development -RAD), y métodos
ágiles
• Usar un diagrama de descomposición funcional
(functional decomposition diagram -FDD) para
modelar las funciones y procesos del negocio
5
Objetivos
• Describir el Lenguaje de Modelado Unificado
(Unified Modeling Language - UML) y estudiar
ejemplos de diagramas UML
• Enumerar y describir requisitos del sistema,
incluyendo salidas, entradas, procesos,
requirements, including outputs, inputs,
processes, desempeño y controles
• Explicar el concepto de escalabilidad
6
Objetivos
• Usar técnicas de determinación de los hechos,
incluyendo entrevistas, revisión de documentos,
observación, cuestionarios, toma de muestras e
investigación
• Definir el costo total de propiedad (total cost of
ownership - TCO)
• Llevar a cabo una entrevista exitosa
• Desarrollar métodos eficaces de utilizar durante
el desarrollo del sistema
7
Introducción
• En este capítulo se describen técnicas de
modelado de requisitos de modelado y métodos
apropiados para el equipo que los analistas de
sistemas usan para visualizar y documentar
nuevos sistemas
• También se discuten los requisitos del sistema y
las técnicas de investigación que incluyen
entrevistas, revisión de documentos,
observación, encuestas y cuestionarios,
muestreo e investigación
8
Fase del Análisis del Sistema
• El objectivo de la fase del análisis del sistema es
comprender el proyecto propuesto, asegurar
que se apoyen los requisitos empresariales, y
construír una base sólida para desarrollar el
sistema
• Usaremos modelos y otras herramientas para
documentar y visualizar el sistema propuesto
9
Fase del Análisis del Sistema
Tareas de la fase del análisis de sistemas
• Actividades del
Análisis del Sistema
Modelo de
Requisitos
▫ Modelar requisitos
Modelo
de
Objetos
Modelo de
Procesos y
Datos
Estrategias
de
desarrollo
10





Salidas
Entradas
Procesos
Rendimiento
Securidad
Fase del Análisis del Sistema
• Actividades del Análisis de Sistemas
▫ Modelar datos y procesos
▫ Modelar Objectos
▫ Estrategias de Desarrollo
 Documento de requisitos del sistema
11
Fase del Análisis del Sistema
• Habilidades del Analista de Sistemas
▫ Habilidades analiticas
▫ Habilidades Interpersonales
• Métodos y técnicas orientadas a equipos
▫ Desarrollo de aplicación conjunta (Joint
application development - JAD)
▫ Desarrollo rápidas de aplicaciones (Rapid
application development - RAD)
▫ Métodos Agiles
12
Desarrollo de aplicación conjunta
• Participa el usuario
▫ Usuarios tienen sumo interés en el sistema de
información y deben participar completamente
▫ Los sistemas de éxito deben ser orientados al
usuario y los usuarios deben participar
▫ Una estrategia muy popular es el desarrollo de
aplicación conjunta (JAD)
13
Desarrollo de aplicación conjunta
• JAD Participants and Roles
14
Desarrollo de aplicación conjunta
• JAD ventajas y desventajas
▫ Mas cara y puede ser difícil si el group es granda
con relación al tamaño del proyecto
▫ Permite que los usuarios participen efectivamente
▫ Si se usa debidamente, JAD resulta en la
declaración mas precisa de los requisitos del
sistema, un mejor entendimiento de los objetivos
comunes y un mayor compromiso para el éxito del
sistema nuevo
15
Desarrollo de aplicación conjunta
• Es una técnica basada en el equipo que acelera el
desarrollo del sistema y produce un sistema de
información funcional
• Depende en gran medida en la creación de
prototipos y participación de los usuarios
• El proceso interactivo continua hasta que el
sistema es completamente desarrollado y los
usuarios estan satisfechos
16
Desarrollo rápido de aplicaciones
17
Desarrollo rápido de aplicaciones
• Objectivos de RAD
▫ Reducir el tiempo y costo por To cut development
time and expense mediante a la participación de
los usuarios en todas las fases del desarrollo del
sistema
▫ Para tener éxito, el equipo rAD deve tener los
recursos de informática, habilidades y apoyo de
los ejecutivos
▫ Permite al equipo diseñar un sistema que requiere
sistemas complejos visuales
18
Desarrollo rápido de aplicaciones
• Ventajas y desventajas
▫ Los sistemas pueden ser desarrollados más
rápidamente con gran ahorro de costos
▫ Enfoque en detalles del sistema y no hace hincapié
en las necesidades estratégicas de la empresa
▫ Podría permitir menos tiempo para desarrollar la
calidad, consistencia y estándares de diseño
19
Métodos Agiles
• Intenta desarrollar un sistema graduálmente
• Herramienta Agilian incluye apoyo de muchas
herramientas de modelos
• Varios programadores ágiles prefieren no usar
herramientas electrónicas y usan pizarrones y
notas pegadas en la pared
20
Métodos Agiles
• Scrum es un término de rugby (página 149)
• Cerdos y pollos:
▫ Cerdos: dueño del producto, facilitador, equipo de
desarrollo
▫ Pollos: usuarios, gerentes, y otros individuos con
interés en el proyecto
▫ http://www.youtube.com/watch?v=WPoBA18Q_3g
• Sesiones de scrum tienen reglas específicas que
hacen hincapié en bloques de tiempo,
interacción y actividades del equipo que
producen software que puede entregarse al
cliente
21
Métodos Agiles
• Ventajas y desventajas
▫ Flexibles y eficientes para acomodar cambios
▫ Entregas frequentes constantemente validan el
proyecto y reducen riesgos
▫ Los miembros del equipo necesital altas
habilidades técnicas e inteacción personal
▫ Pueden tener cambios enormes en alcance
22
Herramientas y técnicas de models
• Involucra métodos gráficos y lenguaje no técnico
que representa el sistema en varias etapas de
desarrollo
• Se pueden usar varias herramientas
• Diagramas de descomposición Funcional
▫ Functional decomposition diagram - FDD
▫ Modelan funciones del negocio y demuestran
como se organizan en procesos a niveles bajos
23
Herramientas y técnicas de modelos
• Modelo del procesos del negocio (p.151)
▫ Business process model (BPM)
▫ Notación ded modelo de negocios
 Business process modeling notation (BPMN)
▫ Alberca (Pool)
▫ Carriles de natación (Swim lanes)
24
Carril de natación (Swimlane)
25
Herramientas y técnicas de modelos
• Diagramas de flujo de datos
▫ Data flow diagram (DFD)
▫ Demuestra como el sistema almacena, procesa y
transforma datos
▫ Niveles adicionales de información y detalles se
muestran en DFDs relacionados
26
Herramientas y técnicas de modelos
• Lenguaje de modelo unificado (Unified
Modeling Language – UML)
▫ Usado ampliamente para visualizar y documentar
el diseño de software
▫ Diagrams “Use case”
 Actor
▫ Diagramas de sequencia
27
Lista de verificación de
requerimientos del sistema
• Cinco categorias:
1. Salidas – p. 153
2. Entradas – p.154
3. Procesos – p.154
4. Rendimiento (performance) – p.154
5. Control – p.154-155
28
Crecimiento futuro, costos y
beneficios
• Escalabilidad
▫ Un sistema escalable ofrece un mejor retorno de la
inversión inicial
▫ Para evaluar la escalabilidad, se necesita
información sobre el volúmen futuro proyectado
para todas las salidas, entradas, y procesos
29
Crecimiento futuro, costos y
beneficios
• Costo Total de Propiedad
– Total cost of ownership
(TCO) es especialmente
importante si se estan
consideranto alternativas
– Un problema es que el costo
estimado tiende a subestimar
costos indirectos
30
Investigación de hechos
• Descripción general de investigación
▫ Primero se identifica la información necesaria
▫ Desarrolle el plan de investigación
• ¿Quien, que, donde, cuando, como, porque?
▫ La diferencia entre preguntar que se hace y que
puede o debe hacerse
31
Investigación de hechos
• El Marco Zachman
▫ Zachman Framework for
Enterprise Architecture
▫ Ayuda a gerentes y usuarios
aentender el model y asegura
que las metas del negocio se
traducen en proyectos con
éxito
32
Entrevistas
• Paso 1: Determine a quien
entrevistar
▫ Estructuras informales
• Paso 2: Establecer objectivos
para la entrevista
▫ Buscar las áreas generales
para discutir
▫ Enumere los datos que se
desean obtener
33
Entrevistas
• Paso 3: Desarrolle las preguntas de la entrevista
▫ Creación de una lista estándar de preguntas de la
entrevista ayuda a mantener el rumbo y evitar
tangentes innecesarias
▫ Evite preguntas capciosas
▫ Preguntas abiertas - p. 160
▫ Preguntas cerradas - p. 160
▫ Alcance de las respuestas a las preguntas
34
Entrevistas
• Paso 4: Prepárese para la entrevista
▫ La preparación cuidadosa es esencial para la
entrevista ya que la entrevista es una reunión
importante y no una plática casual
▫ Limite la entrevista a menos de una hora
▫ Mande la lista de temas
▫ Pregunte si se pueden obtener muestras
disponibles
35
Entrevistas
• Paso 5: Realizar la entrevista
▫ Desarrolle plan específico para le reunión
▫ Empieze por presentarse, describir el proyecto y
explicar los objetivos de la entrevista
▫ Escuchar con atención
▫ Proporcione tiempo para pensar acerca de la
pregunta a la persona
▫ Después de la entrevista, debe resumir la sesión y
buscar confirmación
36
Entrevistas
• Paso 6: Documentar la entrevista
– Tomar notas deben mantenerse al mínimo
▫ Después de realizar la entrevista, se debe captar la
información de forma rápida
▫ Después de la entrevista, envíe una nota al
entrevistado para expresar su aprecio
– Especifique la fecha, hora, lugar, propósito de la
entrevista y los puntos mayores discutidos para
que el entrevistado tenga un documento donde
pueda agregar o corregir datos
37
Entrevistas
• Paso 7: Evaluar la entrevista
▫ Aparte de captar los hechos obtenidos en la
entrevista, trate de identificar posibles sesgos
(biases)
• Entrevistas sin éxito
▫ No importa lo bien que se prepare para las
entrevistas, algunos no tienen éxito
38
Otras técnicas de determinación
de los hechos
• Revisión de documentos
• Al ver el sistema en acción se
da una perspectiva adicional y
una mejor comprensión de los
procedimientos del sistema
• Planee sus observaciones por
adelantado
– Efecto Hawthorne (Western
Electric, 1920)
39
Other Fact-Finding Techniques
• Questionnaires and Surveys
▫ When designing a
questionnaire, the most
important rule of all is to
make sure that your
questions collect the right
data in a form that you can
use to further your factfinding
▫ Fill-in form
40
Otras técnicas de determinación
de los hechos
• Investigación
▫ Se puede incluír el Internet,
revistas de IT magazines y
libros para obtener
información, material
técnico, y noticias sobre
desarrollo y actualización
▫ Visita de planta
41
Otras técnicas de determinación
de los hechos
• Entrevistas o cuestionarios
▫ Entrevista es mas familiar y personal
▫ Cuestionarios le dan a mas personas la oportunidad
de proveer comentarios y sugerencias
▫ Brainstorming
▫ Brainstorming estructurado
▫ Brainstorming sin estructura
42
Documentación
• Necesidad de Registro de los Datos
▫ Registrar la información lo mas rápido posible
▫ Use el método mas simple
▫ Registre la información de manera que sea
entendida por otros
▫ Organize su documentación de manera que el
material relacionado se localize fácilmente
43
Documentación
• Herramientas
▫ CASE Tools
▫ Software de Productividad
 Proceso de datos, Word
processing, hojas de cálculo,
bases de manejo de datos,
software de presentación, y
programas de colaboración
 Histogramas
44
Vista previa de modelos lógicos
• Después de modelar los requisitos, los
diseñadores deben de tener un entendimiento
claro de los procesos del negocio y los
requerimientos del sistema
• El siguiente paso es construír un modelo lógico
del sistema
• Los profesionales de informática tienen puntos
de vista diferentes acerca de métodos de
desarrollo de sistemas y no existe una manera
universalmente aceptada por todos
45
Resúmen del capítulo
• El análisis del sistema incluye 3 actividades:
modelar requisitos, datos y procesos
• También incluye considerar la s estrategias de
desarrollo
• El objetivo principal es entender el proyecto
propuesto, asegurarse que apoyará los
requerimientos del negocio y formará la base
para la fase del desarrollo del sistema
46
Resúmen del capítulo
• Los procesos de investigación de requisitos
incluyen entrevistas, revisar documentos,
observaciones, cuestionarios, investigaciones
• Los analistas de sistemas deben captar
cuidadósamente la información obtenida en
cuanto de captura
• Hay varias herramientas que ayudan al analista
a visualizar y documentar el sistema de
información
47
Actividad 1
• Diagrama de flujo de datos (8:35 min):
http://www.youtube.com/watch?v=5iNUye_nFk
• Modelado de negocios (8:16 min.):
http://www.youtube.com/watch?v=M_V_0EI5z
Go
• Análisis de sistemas y DFDs (9:22 min.) –
Inglés:
http://www.youtube.com/watch?v=X9MyqHGP
DaI
48
Capítulo 5: Modelar datos y
procesos
• Describir conceptos y herramientas para
modelar datos y procesos
• Incluye diagramas de flujo de datos, diccionario de
datos, y descripción de procesos
• Describir los símbolos usados en los diagramas
de flujo y explicar las reglas para su uso
• Dibujar los diagramas de flujo en secuencia, de
nivel general a específico
• Explicar como balancear y nivelar un conjunto
de diagramas de flujo de datos.
49
Objetivos
• Describir como usar el diccionario de datos y lo
que contiene
• Usar herramientas de descripción de procesos,
incluyendo inglés estructurado, tablas de
decisiones, y árboles de lógica
• Describir la relación entre modelos lógicos y
físicos
50
Introducción
• En los capítulos 5 y 6, se desarrollará un model0
lógico de un sistema incluyendo la
documentación de los requerimientos
▫ El modelo lógico muestra lo que debe hacer el
sistema
▫ El modelo físico muestra como se debe construír
el sistema
51
Vista de herramientas para modelar
datos y procesos
• Hay varias técnicas visuales que usan los
analistas de sistemas para describir sistemas de
información
• El diagrama de flujo de datos (data flow diagram
- DFD) usa varios símbolos para mostrar como
el sistema transforma entradas en información
útil
52
Diagramas de flujo de datos
• Un diagrama de flujo de datos
muestra como los datos
traversan el sistema de
información, pero no muestra
la lógica o los pasos del
procesos
• El conjunto de diagrama de
flujo de datos provee modelos
lógicos que demuestran lo que
el sistema hace, pero no como
lo hace
53
Diagramas de flujo de datos
• Símbolos
54
Diagramas de flujo de datos
• Símbolos
▫ Proceso
 Recibe datos de entrada y produce salidas que tiene
contenido diferente y/o forma diferente
 Contiene la lógica del negocio, también llamada
reglas del negocio
 Se refiere como una caja negra (black box)
55
Diagramas de flujo de datos
• Símbolos
▫ Flujo de datos
 Representa uno o
mas s one or more
detalles de datos
 El símbolo es una
línea fon una o doble
flecha
 Se genera
espontáneamente
56
Diagramas de flujo de datos
• Símbolos
▫ Almacén de datos
 Representa datos que
el sistema almacena
 Las características
físicas del almacén
no son importantes
pues estamos
trabajando con un
modelo lógico
57
Diagramas de flujo de datos
• Símbolos
▫ Símbolo de Entidad
 El nombre aparece
dentro del símbolo
 Terminadores
 Fuente (source)
 Lavabo (sink)
58
Creando diagramas de flujo de
datos
• Crea un modelo gráfico del sistema de
información basado en los resultados obtenidos
• Primero, revisa las reglas para crear DFDs.
Luego aprenderás como aplicar las reglas para
crear DFDs usando on proceso de tres pasos
59
Creando diagramas de flujo de
datos
• Pasos
▫ Dibuja el diagrama de contexto que ocupe una
página
▫ Usa el nombre del sistema de información como el
nombre del proceso en el diagrama de contexto
▫ Cada símbolo debe tener un nombre único
60
Creando diagramas de flujo de
datos
• Reglas
▫ No crucen líneas
▫ Provee un nombre distinto y un número de
referencia para cada proceso
▫ Obtener los mas posibles comentarios y
retroalimentación del usuario
61
Creando diagramas de flujo de
datos
• Paso 1: Dibujar el diagrama de contexto
62
Creando diagramas de flujo de
datos
• Paso 2: Dibujar el DFD
63
Creando diagramas de flujo de
datos
• Paso 2: Dibujar el DFD
▫ Si los datos fluyen en ambas direcciones, se puede
usar una flecha con dos cabezas
▫ Diagrama 0 es una vista explotada del proceso o
▫ Diagrama del padre
▫ Diagrama de los hijos
▫ Funciones primitivas
64
Creando diagramas de flujo de
datos
• Paso 3: Dibujar los diagramas
de bajos niveles
▫ Se debes usar las técnicas de
nivel y balance
▫ Ejemplos de nivel
 Usa series de niveles cada
vez mas detallados para
ilustrar el sistema de
información
 Explotar, partir, o
descomponer
65
Creando diagramas de flujo de
datos
• Paso 3: Dibujar niveles bajos
▫ Ejemplos de balanceo
 Asegura que entradas y
salidas del diagrama del
padre se mantengan en los
diagramas de los hijos
66
Diccionario de datos
• El diccionario de datos, o repositorio de datos, es
el almacén central de información de datos del
sistema
• El analista usa el diccionario para acumular,
documentar y organizar los datos específicos del
sistema
• También define y describe todos los datos
importantes y combinaciones significativas de
los elementos de los datos
67
Diccionario de datos
• Un elemento de datos, también llamado
elemento o campo, es el elemento mas pequeño
con significado
• Elementos de datos se combinan en archivos,
también llamados estructuras de datos
• Un archivo es una combinación significativa de
elementos relacionados que se incluyen en el
flujo de datos o guardados en el almacén de
datos
68
Diccionario de datos
• Usando herramientas CASE para documentar
▫ Lo mas complejo el sistema, lo mas difícil
mantener documentación completa y precisa
▫ Herramientas CASE modernas simplifican
nuestra tarea
▫ El repositorio CASE asegura consistencia de datos
69
Diccionario de datos
• Documentando los elementos
de datos
▫ Deben documentar cada
elemento en el diccionario de
datos
▫ El objectivo es el mismo:
proveer información clara y
comprensiva acerca de los
procesos que conforman el
sistema
70
Diccionario de datos
• Documentando los elementos de datos
▫ Los siguientes atributos se capturan y describen:





Nombre del elemento de dato y etiqueta
Alias
Tipo y tamaño
Valor predeterminado
Valores aceptables – Reglas de dominio y validez
71
Diccionario de datos
• Documentando los elementos de datos
▫ También se captura lo siguiente




Fuente de datos
Seguridad
Usuario(s) responsables
Descripción y comentarios
72
Diccionario de datos
• Documentando los elementos de datos
▫ Atributos típicos







Nombre del flujo de datos o etiqueta
Descripción
Nombre alterno
Fuente de datos
Destino
Archivo
Volúmen y frequencia
73
Diccionario de datos
• Documentando los almacenes de datos
▫ Caracteristicas típicas





Nombre o etiqueta del almacén
Descripción
Nombres alternos
Atributos
Volúmen y frequencia
74
Diccionario de datos
• Documentando los procesos
▫ Caracteristicas típicas
 Nombre o etiqueta del proceso
 Número del proceso
 Descripción del proceso
75
Diccionario de datos
• Documentando las entidades
▫ Caracteristicas típicas





Nombre o etiqueta de las entidades
Descripción
Nombres alternos
Datos de flujo de salida
Datos de flujo de entrada
76
Diccionario de datos
• Documentando los registros
▫ Características típicas de registros incluyen:




Registro o nombre de la estructura de datos
Definición o descripción
Nombres alternos
Atributos
77
Diccionario de datos
• Reportes del diccionario de datos
– Varios reportes valiosos
 Una lista en orden alfabético de todos los elementos de
datos por nombre
• Un reporte que describe cada elemento de datos y que
indica el usuario o departamento responsable por
entrada de datos, actualización o supresión
• Un reporte de todos los datos de flujo y almacenes que
utilizan el elemento de datos particular
• Reportes detallados mostrando todas las características
de los elementos de datos, registros, flujos de datos,
procesos u otros elementos seleccionados para guarder
en el almacén
78
Herramientas de descripción de
procesos
• La descripción del proceso documenta los
detalles de primitivas funcionales, las que
representan un conjunto específico de pasos de
proceso y lógica de negocios
• Se nota que este capítulo trata con el análisis
estructurado, pero las herramientas de
descripción de procesos también se pueden usar
en desarrollo orientado a objetos (Capítulo 6)
79
Herramientas de descripción de
procesos
• Diseño modular
▫ Basado en una combinación de tres estructuras
lógicas, las cuales sirven como bloques de
construcción del proceso
 Secuencia
 Selección
 Iteración - repetición
80
Herramientas de descripción de
procesos
• Inglés estructurado
▫ Debe cumplir con las siguientes reglas
 Solo usa los tres bloques de secuencia, selección y
repetición
 Desliza texto para facilitar entendimiento
 Usa un vocabulario limitado , incluyendo términos
estándard usados en el diccionario de datos y
palabras específicas que describen las reglas del
proceso
81
Herramientas de descripción de
procesos
• Inglés estructurado
▫ Será muy familiar a los estudiantes de
programación porque resembla pseudocódigo
▫ El propósito principal del inglés estructurado es la
descripción de la lógica de negocios
82
Herramientas de descripción de
procesos
• Tablas de decisión
▫ Muestra la estructura lógica, con todas las
combinaciones posibles y acciones de condiciones
y acciones resultantes
▫ Es importante considerar cada posible resultado
para asegurar que nada se olvide
83
Herramientas de descripción de
procesos
• Tablas de decisión
▫ El número de reglas se dobla cada vez que se
agrega una condición
▫ Puede tener mas de dos resultados posibles
▫ Normalmente son la mejor manera de explicar
condiciones complejas
84
Herramientas de descripción de
procesos
• Arboles de decisión
85
Modelos logical o físicos
• Aunque las herramientas de análisis
estructurado se usan para desarrollar un modelo
lógico para el sistema de información nuevo,
también se pueden usar para desarrollar
modelos físicos
• Un modelo físico muestra como se implementan
los requerimientos
86
Modelos logical o físicos
• Modelos de secuencia
▫ Muchos analistas de sistemas crean modelos
físicos del sistema actual y luego desarrollan un
modelo lógico del mismo antes de crear el modelo
lógico del sistema nuevo
▫ Realizar este paso extra les permite entender
mejor el sistema
87
Modelos logical o físicos
• Enfoque de cuatro modelos
▫ Desarrollo del modelo físico del sistema actual, el
modelo lógico del mismo, un modelo lógico del
sistema nuevo y un modelo físico del sistema
nuevo
▫ La única desventaja del enfoque de cuatro
modelos es el tiempo y costo adicional
88
Resúmen
• Durante el proceso de modelos de datos y procesos,
el analista de sistemas desarrolla modelos visuales
para demostrar como el sistema transforma datos en
información útil
• El producto final del modelo de datos y procesos es
un modelo lógico que apoya operacions de negocios
para satisfacer las necesidades del usuario
• Modelos de datos y procesos requiere tres
herramientas básicas: diagramas de flujo de datos,
un diccionario de datos y descripciones de procesos
89
Resúmen
• Diagramas de flujo de datos (DFDs) muestran
gráficamente el movimiento y transformación de
datos del sistema de información
• DFDs usan cuatro símbolos
• El grupo de DFDs es como una pirámide con el
diagrama de contexto en el punto mas alto
90
Resúmen
• El diccionario de datos es la herramienta central
para el análisis estructurado
• Cada proceso primitivo funcional se documenta
con inglés estructurado, tablas de deicsión y
árboles de decisión
• Herramientas de análisis estructurado se pueden
usar para desarrollar un modelo lógico durante
la fase del análisis del sistema y un modelo físico
durante la fase del diseño del sistema
91
Actividad 2
• Presentar requerimientos al cliente
92
¿Preguntas?
93
Proyecto
•
•
•
•
94
Escenario del proyecto final
Caso de estudio
Asignaciones del proyecto para el resto del curso
Nuestro cliente
Escenario del proyecto final
• Ustedes son miembros del equipo de desarrollo y trabajan para mi
empresa
• Son expertos en redes, bases de datos, diseño Web, comercio
electrónico, desarrollo de software y gestión de proyectos
• Van a tener una entrevista con el cliente para documentar sus
requerimientos
• Trabajarán como equipo pero su grado será basado en su
participación. Van a dividir su trabajo cada semana.
• Documenten su trabajo cada semana.
95
Proyecto
• Clase 1: Conocen al cliente
▫ Antes de la siguiente semana, preparen su ‘Problem Statement’ en inglés
• Clase 2:
▫ Preparen una lista de preguntas para captar los requerimientos – antes de
la clase
▫ Van a entrevistar al cliente basado en el proyecto
• Clase 3:
▫ Preparen un reporte documentando los requisitos en español
▫ Presentarán el documento al cliente, en clase
▫ Obtandrán aprobación verbal y prepararán el documento de la
especificación
• Clase 4:
▫ Preparen documento de viabilidad y especificaciones – antes de la clase
▫ Presentarán al cliente – en inglés
▫ Obtandrán firma del cliente
96
Proyecto - II
• Clase 5:
▫ Preparen diseño de alto nivel y presentar al cliente
 Incluír red, base de datos, pantallas, reportes, costo, etc.
▫ Presenten al cliente en clase
 Obtengan apruebo del cliente
• Clase 6:
▫ Preparen diseño detallado y presentar al cliente
▫ Obtengan apruebo del cliente
• Clase 7:
▫ Entragan el proyecto final
 Se presentará en la última clase
• Clase 8:
▫ Presentación final al cliente
97
Proyecto Final
• Contenido – en inglés:
▫
▫
▫
▫
▫
▫
▫
Management Summary
Existing System
Proposed System
Impact of proposed system
Analysis of proposed system
Implementation Schedule
Project Presentation
• Vean el ejemplo en la página Web
98
¿Preguntas?
• Manden correo electrónico a
[email protected]
99
Descargar

ABET