Portafolio de Diseño Hidraúlico, Quinto Semestre UTMACH

UNIVERSIDAD TÉCNICA DE MACHALA
FACULTAD DE INGENIERÍA CIVIL

ESCUELA DE INFORMÁTICA
CARRERA DE INGENIERÍA DE SISTEMAS
PORTAFOLIO DE LA ASIGNATURA
DISEÑO ORIENTADO A OBJETOS
CURSO
5TO. SEMESTRE PARALELO “A”

(PROMOCION#. 12)
ESTUDIANTE RESPONSABLE
ERIKA PAOLA TINOCO
DOCENTE RESPONSABLE
ING. JOFFRE CARTUCHE
PERIODO - 2014
MACHALA – EL ORO – ECUADOR

SYLLAB
US DE
LA
ASIGN
ATURA
CARRERA DE INGENIERÍA DE SISTEMAS
SYLLABUS ESTANDARIZADO
1. DATOS GENERALES
Asignatura: Código de la Asignatura:
Diseño orientado a objetos IS-504
Eje Curricular de la Asignatura: Año:
Profesional 2014-2015
Horas presenciales teoría: Ciclo/Nivel:
4 horas semanales/80 horas semestrales Quinto semestre
Horas presenciales práctica: Número de créditos:
5 créditos
Horas atención a estudiantes: Horas trabajo autónomo:
10 horas semanales 4 horas semanales/80 horas semestrales
Fecha de Inicio: Fecha de Finalización:

12/Mayo/2014 28/septiembre/2014
Prerrequisitos:
Análisis Orientado a Objetos
Correquisitos:
2. JUSTIFICACION DE LA ASIGNATURA
El Diseño de Sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en

función de aquella configuración que tenga más posibilidades de satisfacer los objetivos
planteados tanto desde el punto de vista funcional como del no funcional
Siendo UML el estándar internacional para el modelado en las etapas del Análisis y Diseño
OO, es la herramienta que se utiliza en todos los procesos de desarrollo de software.
 Determinar plenamente los casos de uso reales del sistema para una correcta
implementación del software.
 Realizar el diagrama de casos de uso para modelar el sistema mediante la heramienta

Software.
 Definir la estructura e interfaz del sistema a desarrollarse, aplicando conocimientos

sobre los casos de uso reales de acuerdo a estándares recomendados.
 Usar Patrones de acuerdo al Proyecto.
 Representar clases y relaciones para el mapeo del programador de acuerdo a UML.

 Expresar aspectos del diseño a través del diagrama de clase de modo que sea confiable
y seguro para su desarrollo.
Por ello el Diseño es una etapa imprescindible para el desarrollo de proyectos.
3. OPERACIONALIZACION DE LA ASIGNATURA CON RESPECTO A LAS

COMPETENCIAS DEL PERFIL PROFESIONAL
3.1. Objeto de estudio de la asignatura

El objeto de la asignatura Diseño de sistemas orientado a objetos es dotar a los estudiantes
de la formación necesaria, para que puedan utilizar técnicas avanzadas de especificación
formal, diseño y evaluación en el desarrollo de sistemas complejos satisfaciendo así la
necesidad del usuario en la obtención de sistemas de calidad que sean adaptativos,
accesibles y seguros.
3.2. Competencia de la asignatura

El estudiante será competente para aplicar las actividades del Diseño de sistemas dentro
del paradigma de orientación a objetos, diseñar e implementar los componentes internos y
externos de una clase, convertir el análisis en diseño lógico y físico.
3.3. Relación de la asignatura con los resultados de aprendizaje

CONTRIBUCIÓN
RESULTADOS DEL APRENDIZAJE EL ESTUDIANTE DEBE:
(alta, media, baja)
a) Habilidad para aplicar el conocimiento de alta Aplicar los diagramas caso de uso y actividad
las Ciencias Básicas de la profesión en sistemas complejos de modelar.
Aplicar los diagramas de clases e
b) Pericia para diseñar y conducir
media implementación una vez realizado todos los
experimentos, así como para analizar e
interpretar datos. procesos anteriores para su desarrollo.
c) Destreza para manejar procesos de media Determinar correctamente las clases para la
Ingeniería de Sistemas elaboración de un correcto diagrama
media Integrar y dirigir equipos de trabajo, liderando

d) Trabajo multidisciplinario. su área de mayor competencia con empatía.
e) Resuelve problemas de Ingeniería de Expresar aspectos del diseño a través del

Alta diagrama de clase de modo que sea confiable
Sistemas.
y seguro para su desarrollo.
f) Comprensión de sus responsabilidades alta Asumir los roles designados por el líder del
profesionales y éticas proyecto, entregando productos de calidad.
Exponer informes técnicos bien
alta estructurados, utilizando diversos recursos de
g) Comunicación efectiva
comunicación para su difusión.
Aplicar patrones de diseño para solucionar
h) Impacto en la profesión y en el contexto media los problemas de forma rápida y coherente de
social acuerdo a una situación concreta.
media Determinar los atributos visibles de acuerdo a

i) Aprendizaje para la vida las relaciones entre clases.
baja Aplicar correctamente la asignación de
j) Asuntos contemporáneos responsabilidades a los objetos.
k) Utilización de técnicas e instrumentos alta Utilizar herramientas privativas y libres para

modernos el Lenguaje Unificado de Modelado (UML).
l) Capacidad para liderar, gestionar o media Tener la capacidad de formar grupos de

emprender proyectos trabajo con actividades interdisciplinarias.
3.4. Proyecto o producto de la asignatura:

El programa culmina con un Proyecto integrador, que tiene por objetivo consolidar los
conocimientos de la asignatura, donde el estudiante continúa su proyecto de Análisis de
Sistemas para culminarlo e implementarlo en la Institución.
4. PROGRAMA DE ACTIVIDADES:
4.1. Estructura de la asignatura por unidades:
UNIDAD COMPETENCIAS RESULTADOS DE APRENDIZAJE

1.Retroalimenta las bases de análisis para
1. Manejar terminología apropiada para
I. Del Análisis al Diseño iniciar un diseño sustentado de acuerdo a
el desarrollo del Diseño de Sistemas
las necesidades de usuario.
1.Determina plenamente los casos de uso 1. Manejar adecuadamente la
II. Casos de uso reales y reales del sistema. navegabilidad de ayuda y ventanas.
Diseño de la interfaz 2.Utiliza correctamente la heramienta 2. Desarrollar prototipos útiles para
Rational Rose. comprender mejor el sistema.
1.Localiza a través de los diagramas los
III. Diagramas de interacción 1. Ubicar minuciosamente los objetos
objetos que interactúan con los demás
1.Comprende la asignación de
responsabilidades a los objetos según
IV. Patrones para asignar Patrones GRASP. 1.Aplicar correctamente la asignación
responsabilidades 2.Aplica patrones de diseño para de responsabilidades a los objetos
solucionar los problemas de forma
rápida y coherente de acuerdo a una
situación concreta.
1.-Determinar correctamente las clases
1.-Expresa aspectos del diseño a través del para la elaboración de un correcto
V. Diagrama de clases del diseño diagrama de clase de modo que sea diagrama.
confiable y seguro para su desarrollo
1.Determina la Arquitectura del Sistema

1. Aplicar la Arquitectura del Diseño
2.Aplica los diagramas de implementación
VI. Algunos aspectos de Diseño 2. Conocer y aplicar otros diagramas si
una vez realizado todos los procesos
fuera necesario.
anteriores para su desarrollo.
4.2. Estructura detallada por temas:
UNIDAD I: DEL ANÁLISIS AL DISEÑO

SEMANAS DE ESTRATEGIAS DE
TEMAS CONTENIDOS HORAS
ESTUDIO APRENDIZAJE
Definición Elaboración de
Objetivos organizadores gráficos,
1
Introducción al Ciclo de Desarrollo mapas conceptuales y
12/05/14 –
diseño de Transición del Análisis al redes semánticas, 5
17/05/14
sistemas. Diseño resúmenes, analogías,
Arquitectura del sistema. preguntas intercaladas.
Ejercicios
TOTAL DE HORAS DE UNIDAD I 5
UNIDAD II: CASOS DE USO REALES Y DISEÑO DE LA INTERFAZ

ESTUDIO APRENDIZAJE
2. Casos de uso reales.
Definir casos de uso reales
19/05/14 – Formato expandido o
24/05/14 detallado
Casos de uso Talleres sobre diseño de
Diseño de la realización de 10
3. Reales casos de uso.
los casos de uso,
26/05/14 – Herramienta CASE
31/05/14 Ejercicios
Evaluación
4. Principios y reglas de oro en
02/06/14 – el diseño de la IU, estilos de
07/06/14 interacción,
Formatos individuales de
5. Diseño de Interfaz, Catálogos de Talleres sobre diseño de una
10
interfaz controles y elementos de interfaz.
09/06/14 – diseño, Modelo de
14/06/14 Navegación y ayuda,
Formatos de Impresión,
Prototipo de interfaz.
TOTAL DE HORAS DE UNIDAD II 20
UNIDAD III: DIAGRAMAS DE INTERACCIÓN

ESTUDIO APRENDIZAJE
Definición, Actividades y
dependencias, tipos de
Elaboración de talleres
6. Diagramas de Diagramas, Como preparar
sobre elaboración de
Interacción Diagramas de Colaboración,
diagramas.
16/06/14 – Notación Básica, Modelos de
5
21/06/14 diagramas.
El aprendizaje basado en
proyectos colaborativos,
Herramienta Representación gráfica en
Análisis de Casos,
CASE UML. Ejercicio
Resolución de Problema,
preguntas intercaladas.
TOTAL DE HORAS DE UNIDAD III 5
UNIDAD IV: PATRONES GRASP

ESTUDIO APRENDIZAJE
Introducción, Utilidad, Elaboración de cuadros de
Responsabilidad y métodos, comparación sobre los
7. 5
las Responsabilidad y los diferentes roles en la
23/06/14 –
Patrones y UML Diagramas de Interacción, elaboración de un sistema.
28/06/14
8.
30/06/14 –
EXAMEN DEL HEMISEMESTRE
05/07/14
9.-
07/07/14 – Definición de Patrones, Talleres para
5
12/07/14 notación de UML, Tipos de realizar diagramas de UML
Patrones, Contenido de
patrones.
TOTAL DE HORAS DE UNIDAD IV 10
UNIDAD V: DIAGRAMA DE CLASES DEL DISEÑO

ESTUDIO APRENDIZAJE
Introducción, Actividades y
10. dependencias, cuándo crear
14/07/14 – diagramas de clase de
19/07/14 Diseño. Objetos y Clases,
Investigaciones sobre
Multiplicidad, Atributos y
11. conceptos de clases y su
Diseño de clases Operaciones, Relaciones de 10
dependencia dentro de la
21/07/14 – clases, Dependencias,
elaboración de un software.
26/07/14 Generalización, Asociaciones
y navegabilidad, Estrategias
para elaborar un Diagrama de
Clases.
12.
28/07/14 –
02/08/14
Herramienta Talleres usando la
Ejercicios. 10
13.
Software herramienta Software
28/07/14 –
01/08/14
TOTAL DE HORAS DE UNIDAD VI 20
UNIDAD VII: ALGUNOS ASPECTOS DEL DISEÑO

ESTUDIO APRENDIZAJE
14. Arquitectura del Arquitectura Clásica de Tres El aprendizaje basado en 5
04/08/14 – Sistema Capas, Vistas, modelos, proyectos colaborativos,
09/08/14 Características, ventajas, Análisis de Casos,
desventajas, aplicación. Resolución de Problema,
Comparación, preguntas intercaladas.
El aprendizaje basado en
15. Mapeo de los La programación y el proyectos colaborativos,
11/08/14 – Diseños para la proceso de desarrollo, mapeo Análisis de Casos, 5
16/08/14 Codificación de diseños para codificación Resolución de Problema,
preguntas intercaladas.
16. Modelo de Implementación, Talleres sobre diagramas de
Diagramas de
25/08/14 – Diagramas de Componentes. implementación. 5
implementación
30/08/14 Diagrama de despliegue
17.
01/09/14 –
Desarrollo de un proyecto
06/09/14 Proyecto Práctica de Laboratorio 5
dirigido
08/09/14 – EXAMEN FIN DE

13/09/14 SEMESTRE
15/09/14 – EXAMEN DE
20/09/14 SUSPENSO Y
MEJORAMIENTO
20
5. METODOLOGIA: (ENFOQUE METODOLOGICO)
La metodología de enseñanza en las clases y las actividades académicas se aplicará de

acuerdo a la temática a abordar y estas podrán ser:
5.1. Métodos de enseñanza
a) Clases magistrales, donde se expondrán los temas de manera teórica, mostrando y

analizando ejemplos, y
b) Trabajo en grupo, para elaborar los elementos de la literatura científica (fichas, citas
y referencias bibliográficas), como recurso operativo para elaborar el documento
científico.
c) Trabajo autónomo u horas no presenciales, que será el material básico para
estructurar la carpeta del estudiante, al que se agregará el trabajo en grupo:
1. Tareas estudiantiles, resúmenes, mapas conceptuales, informes técnicos,
elaboración de los ejemplos en hoja electrónica, dibujos digitalizados en forma
individual.
2. Investigaciones bibliográficas, individuales o por grupos sobre profundización de temas a tratarse.
3. Trabajos de campo, realizados grupalmente como encuestas, o censos.
d) Formas organizativas de las clases, los alumnos asistirán a clase con el material guía
adelantando la lectura del tema de clase de acuerdo a la instrucción previa del docente,
sobre los puntos sobresalientes o trascendentales que se van a exponer. De estos
análisis saldrán los trabajos bibliográficos e informes técnicos que deberán desarrollar
y entregar posteriormente.
e) Medios tecnológicos que se utilizaran para la enseñanza:
 Pizarrón para tiza líquida y marcadoresde varios colores.

 Libros, códigos, especificaciones y revistas técnicas de la biblioteca.
 Equipo de proyección multimedia y material académico en Power Point.
 Herramientas de información y comunicación.
o Aula Virtual
o Blog
o Google Apps
 Visual Paradigm for UML, Rational Rose.
El programa culmina con un Proyecto integrador, que tiene por objetivo consolidar los
conocimientos para la definición de procesos, en el marco de un proceso de mejora continua
de una organización comercial o educativa.
6. COMPONENTE INVESTIGATIVO DE LA ASIGNATURA:

Los tipos de investigación que se realizará en la asignatura son:
 Investigación Formativa.- Referida al aprendizaje por descubrimiento y construcción

del conocimiento por parte de los estudiantes. Este método consiste en que el profesor
a partir de una situación problémica, logra que el estudiante busque, indague, y
encuentre situaciones similares, así mismo que haga revisiones de literatura,
(bibliografía, códigos y especificaciones) recoja datos, los organice interprete y
encuentre soluciones a las dificultades planteadas, además esto les permitirá
incorporarlo en su proyecto que se avanza de acuerdo a lo programado.
 Investigación Aplicada.- Utilizando los conocimientos adquiridos durante la
asignatura en la práctica, deben aplicarlos en el análisis de las instituciones que
necesitan la implementación de un sistema informático.
 Investigación de Campo.- Selección de la Institución donde aplicarán los
conocimientos que le permitirán comprender y resolver los problemas de la institución
con una solución informatizada. (Estudios preliminares, de factibilidad, de requisitos,
modelados de Análisis (casos de uso, actividades, secuencia, conceptual).
7. PORTAFOLIO DE LA ASIGNATURA
El portafolio de la asignatura contendrá la siguiente información:
 Datos informativos
 Syllabus del módulo
 Tareas, trabajos de investigación
 Apuntes sobre temas de la clase
 Evaluaciones por unidad
 Evaluaciones parciales
 Proyecto de fin de módulo
8. EVALUACIÓN
El objetivo de la evaluación es poder comparar lo asimilado por el estudiante con lo que debió
asimilar, de tal manera que para el docente se convierta en un termómetro que le indica hasta
donde llegó con los conocimientos a los estudiantes.
8.1. Evaluaciones Parciales:
Trabajos individuales y en grupo.
Pruebas orales y escritas.
Trabajos de investigación.
8.2. Parámetros de Evaluación:
PARAMETROS DE EVALUACION PORCENTAJES

Pruebas parciales dentro del proceso 10
Presentación de informes escritos 10
Investigaciones bibliográficas 10
Participación en clase 10
Trabajo autónomo 10
Prácticas de laboratorio 10
Prácticas de campo 10
Exámenes Finales 30
Total 100
9. BIBLIOGRAFÍA
9.1. Bibliografía Básica:
 WEITZENDFELD, Alfredo (2005), Ingeniería de software Orientada a Objetos

con UML Java e Internet. THOMSON. México
9.2. Bibliografía Complementaría:
 PRESSMAN, Roger, 2010. Ingeniería de Software Un enfoque Práctico.

Séptima Edición. Editorial McGraw Hill. Mexico.
 PERDITA, Stevens, Utilización de UML en Ingeniería de del Software con
objetos y componentes;
 ALARCON, Raul 2005. Diseño Orientado a Objetos con UML, EIDOS.
ESPAÑA.
 SOMMERVILLE, Ian 2005. Ingeniería de Software
 WHITTEN Jeffrey, Bentley Lonnie y Barlow Victor (1998). Análisis y Diseño
de Sistemas de Información.
 BOOCH Grady, RUMBAUGH James, JACOBSON Ivar. El Lenguaje
Unificado de Modelado
10. DATOS DEL O LOS DOCENTES:

Joffre Jeorwin Cartuche Calva
Analista en Sistemas Informáticos
Ingeniero en Sistemas Informáticos
Egresado de Master en Ingeniería de Software
Dirección: Arizaga y Babahoyo
Correo electrónico: jcartuche@yahoo.com, joffre1939@hotmail.com
11. FIRMA DEL O LOS DOCENTES RESPONSABLES DE LA ELABORACIÓN
DEL SYLLABUS
_______________________
Joffre Jeorwin Cartuche Calvaz
12. FECHA DE PRESENTACION:
Machala, Abril del 2014

PRESENT
ACION
GENERAL
DEL
ESTUDIA
NTE
Carrera de Ingeniería de Sistemas
AUTORRETRATO
MI nombre es Erika Tinoco, soy estudiante de la asignatura de Diseño

Orientado a Objetos, actualmente curso el 5to Semestre en la carrera de
Ingeniería de Sistemas de la Escuela de Informática de la Facultad de Ingeniería
Civil de la Universidad Técnica de Machala. Soy una persona responsable, me
gusta ser puntal con la presentación de mis tareas, muy respetuosa con todos y soy
buena para el trabajo en conjunto.
Mis metas son aprender los que más pueda de cada una de las materias,
desarrollar mi creatividad para poder lograr muchas cosas, graduarme en la carrera
de Ingeniería de Sistemas sin perder mi ética profesional y así ser capaz de
solucionar cualquier problema correspondiente a la carrera.

Apellidos: Tinoco Chamaidan Nombres: Erika Paola
Curso: tercero Semestre: Quinto Paralelo: A Sección: Diurna
C.I.: 0706051901 Fecha de nacimiento:29/08/1994 Edad: 19 años
Correo electrónico: Facebook: Erickiita Tinoco
Erikita_094@hotmail.com
Convencional: Celular 1: 039326825 Celular 2: 088123725
Domicilio
Provincia: El Oro Cantón: Santa Rosa Parroquia:
Dirección: Barrio 24 de mayo, calle Enrique Suarez Referencia: frente a la cancha Aero soccer
Pimentel
Sexo: Femenino Estado Civil: Soltera
Croquis de su domicilio:
Cancha
Aero
Sucre
Enrique Suarez Pimentel
soccer
Mi casa
Colegio Chávez
Franco
Datos del Padre

Apellidos y Nombres: Tinoco Blacio José Adalberto Celular:0982712215
Donde trabaja: Machala
Dirección del trabajo: Antes de la Universidad
Dirección domiciliaria: Santa rosa Barrio 24 de Mayo
Datos de la Madre
Apellidos y Nombres: Chamaidan Chamaidán Mireya Marilú Celular:0988123725
Donde trabaja: no trabaja
Dirección del trabajo:
Dirección domiciliaria: Santa rosa Barrio 24 de Mayo
Datos del cónyuge (en caso de tenerlo)

Apellidos y Nombres: Celular:
Donde trabaja:
Dirección domiciliaria:
Número de hijos: Observaciones:
Datos del Trabajo: (en caso de tenerlo)

Donde trabaja: Sector:
Teléfono 1: Teléfono 2:
Cargo que desempeña:
Carrera de Ingeniería de Sistemas

MISIÓN
La Universidad Técnica de Machala es una Institución reconocida en su área de influencia
formadora de profesionales, con capacidades científico-técnicas, ética, solidaria, con identidad
nacional, que aporta, creativamente, a través de la docencia, investigación, vinculación y
gestión, a la solución de los problemas del desarrollo sostenible y sustentable.
VISIÓN
La Universidad Técnica de Machala para el año 2013 es una institución acreditada, lidera el
desarrollo territorial, forma y perfecciona profesionales competentes, emprendedores,
innovadores, críticos y humanistas.

MISIÓN
Alcanzar un alto nivel de eficiencia técnico profesional que permita a la Facultad contribuir
activamente en el desarrollo socio-económico provincial, regional y nacional con
profesionales altamente calificados.
VISIÓN
La Facultad de Ingeniería Civil en cumplimiento de sus funciones de Docencia, Investigación,
Proyección Social, y; apoyo de la gestión administrativa está en una búsqueda permanente de
la excelencia académica, con la participación planificada, coordinada y coherente de sus
actores, a través de procesos educativos eficientes, eficaces y de efectividad en la formación
de profesionales; en concordancia al desarrollo científico-tecnológico y a las necesidades del
desarrollo Provincial, Regional y Nacional en el campo de las Ciencias Físicas y Matemáticas.
La Escuela de Informática fue creada mediante resolución No. 087/1995 (25 de
Octubre/1995)
La Carrera de Ingeniería de Sistemas fue creada mediante resolución No. 077/2001 (7 de
mayo de 2001)
La Misión y Visión fueron aprobadas mediante resolución No. 452 del H. C. D. (Honorable
Consejo Directivo) del 13 de Diciembre del 2011.
MISIÓN
Formar profesionales en Ingeniería de Sistemas con capacidades científicas, técnicas,
tecnológicas y humanísticas, competitivas y comprometidas con el desarrollo sostenible y
sustentable del buen vivir.
VISIÓN
La carrera de Ingeniería de Sistemas para el año 2013 es la unidad acreditada y líder en el
desarrollo y transferencia de soluciones informáticas, acorde a los avances científicos y
tecnológicos.
Perfil Profesional
El Ingeniero de Sistemas de la Universidad Técnica de Machala es un
profesional con espíritu empresarial, ético con características de
creatividad, innovación, capacidad investigativa, deseo permanente de
trabajar, de aprender y perfeccionarse con amor propio, con amplia
sensibilidad social y con capacidad promotora de desarrollo de la
comunidad donde se desempeñe y que estará capacitado para:
Generar empresas en las áreas de las tecnologías de la informática y las

comunicaciones.
Asesorar, dirigir, intervenir y auditar proyectos informáticos.
Planificar, dirigir, analizar, diseñar e implementar Sistemas de

Información.
Evaluar, negociar e innovar la Tecnología.
Trabajar en equipos interdisciplinarios y proponer soluciones en forma

consensuada.
Identificar y definir procesos organizacionales en el ámbito en el cual se

desempeñe.
Evaluar y seleccionar los recursos humanos informáticos de acuerdo a

las necesidades de la organización.
UNIDAD I
DEL ANALISIS AL DISEÑO
DIARIO METACOGNITIVO:1.1
UNIVERSIDAD TECNICA DE MACHALA

FACULTA DE INGENIERIA CIVIL
ESCUELA DE INFORMATICA
CARRERA DE INGENIERIA EN SISTEMAS
CLASE N°: 1 PERÍODO 12/05/2014 al 16/05/2014

TIEMPO: 3 horas
FECHA:
13/05/2014
 Presentación y Encuadre de la Materia

TEMA DISCUTIDO:  Parámetros de Evaluación
DESARROLLO
Objetivos de desempeño:
 Conocer los parámetros de evaluación para que los estudiantes se informe la manera que
serán evaluados.
Competencia General:
 Destacar información acerca del tiempo de duración del módulo para que el estudiante
organice su tiempo.
Datos interesantes discutidos:
Actividades durante la clase
El ingeniero expuso a los estudiantes sobre el método de evaluaciones de este semestre en su

materia, el valor y puntaje de cada cosa y como se llevaría la materia. Explicó a qué se refería el
término crédito y a cuantas horas clase representaba lo cual nos indicó que 1 crédito conciernen a
16 horas clases y 16 horas de trabajo autónomo.
Tratamos acerca de los parámetros de evaluación que va a llevar el docente. Los mismos que son:
PARAMETROS DE EVALUACION PORCENTAJES
1er. PARCIAL
Evaluaciones 2
Prácticas de Laboratorio/Participación en 1
Clase
Investigaciones/Deberes 1
Portafolio 1
Examen 2
Proyecto 3
Total 10
Una vez que se establecieron los puntajes de evaluación de la materia, el ingeniero Joffre nos dio un
formato para presentar las tareas Extraclase quedando de la siguiente forma.
 Introducción
 Objetivos
 Marco Teórico
 Conclusiones
 Recomendaciones
Luego de esto se hizo un repaso de lo visto en el módulo anterior llamado análisis orientado a objetos.
 Casos de Uso
 Lenguaje UML
 Modelado de Negocio
 Diagrama de Secuencia
 Modelo Conceptual
 Estudio de Factibilidad
Y al final realizamos una actividad Intraclase que constaba en crear una definición sobre lo que es la
Ingeniería de software, en la cual expuso cada grupo sobre lo que entendía de una definición en ingles
proporcionada por el Docente.
CONCEPTOS DE INGENIERIA DE SOFTWARE
(1968 NATO)
Promueve y establece ya sea fundamentos teóricos o disciplinas prácticas similares a

fundamentos de la rama de la Ingeniería.
(1985 Fairley)
Gestiona la producción de software y mantenimiento; permite llevar un control para poder

desarrollar y modificar a tiempo el mismo.
(1990 SEI)
La ingeniería aplica sistemas de conocimientos científicos para dar soluciones rentables o

problemas de software.
La ingeniería de software principios de la informática y matemática.
(1990 SCHACH)
Es disciplina para la producción de software de calidad tomando en cuenta los requerimientos

y presupuestos dados y ser entregado.
Q (Calidad)
T $
(1990 IEEE)
Es sistemática, confiable y está enfocada en el desarrollo de operaciones.
(1996 Somerville Ian)
Específica, desarrolla, gestiona y evolucionan los sistemas de software que no se rigen por
materiales y métodos necesarios para su desarrollo.
Reflexionar:
a) ¿Qué cosas fueron difíciles?

Un poco complejo fue entender y acoplar las palabras dadas por el docente en papel para
formular un concepto sobre la ingeniería de software.
b) ¿Cuáles fueron fáciles?

Comprender los parámetros de calificación.
c) ¿Por qué?
Porque eran términos que ya habíamos manejado semestres anteriores.
d) ¿Qué aprendí hoy?

Como se calificara la materia y comprender claramente que es la ingeniería de software.
DIARIO METACOGNITIVO:1.2

TIEMPO: 2 hora
FECHA:
15/05/2014
 Ciclo de Desarrollo
TEMA DISCUTIDO:
 Transición del análisis al diseño
DESARROLLO
 Conocer los parámetros de evaluación para que los estudiantes se informe la manera que
serán evaluados.
 Retroalimentación las bases de análisis para iniciar un diseño sustentado de acuerdo a

las necesidades de usuario.
Análisis y recordatorio de todo lo visto en el semestre anterior en la materia que conecta con
Diseño que es Análisis Orientado a Objetos.
Resumen conceptual de lo que se vio, incluyendo imágenes, etc.
INGENIERÍA DEL SOFTWARE
La ingeniería del software permite al diseñador de programas, realizar su tarea de

construcción de software como un problema de ingeniería haciendo uso de guías, principios y
normas que le permitirán el correcto desarrollo de su labor. Adicionalmente, dispondrá de un
conjunto de herramientas que le permitirán la evaluación, validación, depuración y corrección
del software desarrollado.
CICLO DE VIDA DEL SOFTWARE
Es la forma mediante la cual se describen los diferentes pasos que se deben seguir para el
desarrollo de un software, partiendo desde una necesidad hasta llegar a la puesta en marcha de
una solución y su apropiado mantenimiento. El ciclo de vida para un software comienza
cuando se tiene la necesidad de resolver un problema, y termina cuando el programa que se
desarrolló para cumplir con los requerimientos, deja de ser utilizado.
Existen varias versiones del ciclo de vida del software entre las cuales se destacan: el ciclo de
vida clásico o en cascada, el modelo en espiral, el desarrollo de prototipos, el modelo por
incrementos y el modelo extremo [6].
ETAPAS DEL CICLO DE VIDA DEL SOFTWARE
El ciclo de vida clásico del software siendo uno de los más utilizados tal como lo plantean
diferentes autores, está conformado en su versión ampliada por siete etapas que se pueden
representar mediante un modelo en cascada así:
- INGENIERÍA DE SISTEMAS: En esta etapa el analista luego de un minucioso y detallado

estudio de los sistemas de una organización, detecta un problema o una necesidad que para su
solución y/o satisfacción es necesario realizar un desarrollo de software.
- ANÁLISIS: En esta etapa se debe entender y comprender de forma detallada cual es la

problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal
manera que se obtenga la información necesaria y suficiente para afrontar su respectiva
solución. Esta etapa es conocida como la del QUÉ se va a solucionar.
- DISEÑO: Una vez que se tiene la suficiente información del problema a solucionar, es
importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa
es conocida bajo el CÓMO se va a solucionar.
- IMPLEMENTACIÓN: partiendo del análisis y diseño de la solución, en esta etapa se

procede a desarrollar el correspondiente programa que solucione el problema mediante el uso
de una herramienta computacional determinada.
- PRUEBAS: Los errores humanos dentro de la programación de los computadores son

muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina
de escribir un programa de computador, es necesario realizar las debidas pruebas que
garanticen el correcto funcionamiento de dicho programa bajo el mayor número de
situaciones posibles a las que se pueda enfrentar.
- DOCUMENTACIÓN: Es la guía o comunicación escrita en sus diferentes formas, ya sea

en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un
programa. La importancia de la documentación radica en que a menudo un programa escrito
por una persona, es modificado por otra. Por ello la documentación sirve para ayudar a
comprender o usar un programa o para facilitar futuras modificaciones (mantenimiento).
La documentación se compone de tres partes:
a. Documentación Interna: Son los comentarios o mensajes que se añaden al código fuente
para hacer más claro el entendimiento de los procesos que lo conforman, incluyendo las
precondiciones y las pos condiciones de cada función.
b. Documentación Externa: Se define en un documento escrito con los siguientes puntos:
Descripción del Problema
Datos del Autor
Algoritmo (diagrama de flujo o Pseudocódigo)
Diccionario de Datos
Código Fuente (programa)
c. Manual de Usuario: Describe paso a paso la manera cómo funciona el programa, con el
fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.
- MANTENIMIENTO: una vez instalado un programa y puesto en marcha para realizar la
solución del problema previamente planteado o satisfacer una determinada necesidad, es
importante mantener una estructura de actualización, verificación y validación que permitan a
dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos
planteados durante su vida útil. Para realizar un adecuado mantenimiento, es necesario contar
con una buena documentación del mismo.
Para terminar de entender la problemática en la cual se desarrolla este libro es importante

tener unos conceptos claros y precisos de lo que es el Análisis y el Diseño de Algoritmos.
Reflexionar:
¿Qué cosas fueron difíciles?
En esta clase no hubo cosas complejas debido a que eran cosas que ya se vieron
anteriormente.
¿Cuáles fueron fáciles?
Recordar sobre las fases de desarrollo de un software.
¿Por qué?
Porque ya se tenía conocimientos sobre ello y se han realizado proyectos respecto al tema.
¿Qué aprendí hoy?
Respecto al ciclo de vida del software se vio una fase más que no se la había estudiado y
quedo clara debido a q su explicación se dio mediante ejemplos prácticos.
UNIDAD II
CASOS DE USO REALES Y DISEÑO DE
INTERFAZ
TIEMPO:
3 horas
FECHA:
20/05/2014
TEMA DISCUTIDO:
Casos de uso Reales

Desarrollar de acuerdo a lo que se vio en clase
Contenidos:
 Casos de uso reales.

 Definir casos de uso reales
Aprender la importancia y utilización de los casos de uso en un diseño de sistema
El docente explicó con material didáctico de diapositivas ante nosotros los alumnos
sobre la definición de los casos de uso la manera de cómo utilizarlos , en que herramientas
podemos diseñar estos diagramas y poner en practica con ejemplos propuestos para un
mejor entendimiento
Descriptores analizados
Diagrama de caso de usos
¿Qué es un caso de uso?
Todo sistema tiene como mínimo un diagrama de caso de uso que es una representación
gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso).
Un diagrama de casos de uso muestra, los distintos requisitos funcionales que se esperan
de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras
aplicaciones).
Un diagrama de casos de uso es una representación gráfica de parte o el total de los

actores y casos de uso del sistema, incluyendo sus interacciones.
Ejemplo
ACTOR
Representa quien o que inicia una acción dentro del sistema, en otras palabras, es
simplemente un rol que es llevado acabo por una persona o cosa. Un Actor en un diagrama
Uso-Caso es representado por una figura en forma de persona.
CASO DE USO
Representa quien o que inicia una acción dentro de un caso de uso es una tarea que debe
de poder llevarse a cabo con el apoyo del sistema que se está desarrollando.
Se representa mediante un ovalo.
LÍMITE DE SISTEMA
CASO DE USO:
Empleado para delimitar los límites del sistema, y representado por un rectángulo con color
de fondo distintivo.
LIMITE DE SISTEMA:
BENEFICIOS
UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
 Comunicación
 Identificación
 Verificación
Comunicaci CasoDeUso Verificació

ón n
Identificaci
ón
Users
End User Domain Expert
COMUNICACIÓN
Este elemento representa la relación que existe entre un Uso-Caso y un Actor, dicho
elemento es representado simplemente por una línea recta que se extiende de la figura del
actor hacia el ovalo del uso-caso
COMUNICACIÓN:
EJEMPLO
El siguiente diagrama muestra la funcionalidad de un sistema Restaurante

muy simple
INCLUSIÓN
Una instancia del Caso de Uso origen incluye también el comportamiento descrito por el
Caso de Uso destino
Se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo
comportamiento común en un caso de uso aparte
Se representa como una dependencia estereotipada con <<include>>
Ocurre cuando se tiene una porción de comportamiento que es similar en más de un caso
de uso y no se quiere copiar la descripción de tal conducta
REPRESENTACIÓN INCLUSIÓN
EXTENSIÓN
 Significa que un caso de uso base incorpora implícitamente el comportamiento de

otro caso de uso en el lugar especificado indirectamente por el caso de uso que
extiende al base
 Se usa esta relación cuando se tiene un caso de uso que es similar a otro, pero que
hace un poco más.
 El Caso de Uso origen extiende el comportamiento del Caso de Uso destino
<<extend>>
Caso de Uso Destino

Reflexionar:
Aclarar conocimientos erróneos que se tenían sobre el uso de los include y extends
La conceptualización de los casos de usos
¿Por qué?
Porque en semestres anteriores ya se estudió en la materia de Análisis Orientado a Objetos
Conocer cuando aplicar include o extends al momento de diagramar un caso de uso


2 horas
TIEMPO:
FECHA: 22/05/2014
TEMA DISCUTIDO:
Casos de uso Reales
Contenidos:
Formato expandido o detallado
Poder realizar un formato expandido de un diagrama de casos de uso.
Se realizó un repaso de la clase anterior para luego continuar con la explicación del
formato expandido de casos de uso como desarrollarlo a partir de un diagrama de casos de
uso ya diseñado, se conoció que parámetros deben de ir en este formato, como deben de ir
y cuales no deben estar en dicho formato.
Diagrama de caso de usos, formato expandido
Formato expandido
Describe un proceso en mayor detalle, concentrándose en el curso de los eventos:
describen los detalles de la interacción entre el sistema y sus actores
Descripción formato Expandido
Primera Sección:
 Caso de Uso: Nombre del Caso de Uso

 Actores: Lista de Actores (agentes externos), en el cual se indica quien inicia
el caso de uso
 Propósito: Intención del caso de uso.
 Precondición: Descripción de las condiciones que deben satisfacerse antes
de dar inicio al caso de uso. No se prueban en el caso de uso se asumen que
son verdaderas
 Resumen: Repetición de la descripción de alto nivel
 Tipo: 1. Primario, secundario u opcional 2. Esencial (caso de uso expandido
libre de aspectos tecnológicos y detalle de implementación (diseño, interaz
usuario, etc.), Real (caso de uso expandido que describe concretamente el
proceso a partir de su diseño concreto actual, sujeto a las tecnologías
específicas de entrada
 Referencia Cruzada : Casos de uso y funciones relacionadas con el
sistema.
Segunda Sección: Curso normal de eventos (Escenario principal de éxito y pasos).
o Detalle de la conversación iterativa entre los actores y el sistema.

o Se explica la secuencia genérica más común no las situaciones
alternativas.
Descripción formato Expandido
Ultima Sección: Curso alternativo de eventos
 Describe las opciones o excepciones más importantes que pudiesen

presentarse en el curso normal de eventos. Si son muy complejas pueden
convertirse en otro caso de uso o sección.
Ejemplo:
CU-RQF02 Control operativo de la flota cliente
Requerimientos [listado de los requerimientos que están ligados al caso de uso]
Casos de Uso NA
Relacionados
Actores Administrador, cliente.
Tipo Primario
Desarrollar una aplicación software que facilite la operativa de la

Descripción empresa y facilitarle al cliente controlar la operativa interna de su flotilla
vehicular.
Precondiciones Cliente debe estar registrado para tener acceso.
Postcondiciones NA
Curso Típico de Actor Sistema

Eventos
1. El actor ingresa al sistema ingresa 2. Sistema debe solicitar usuario y
al sistema. password para el ingreso.
3. El actor ingresa usuario y 4. El sistema valida datos

password. ingresados y presenta menú de
opciones.
5. El actor selecciona opción de
ingresar cliente y parametrizacion. 6. El sistema valida datos y registra
datos en la base de datos.
7. El actor sale de la opción.
Curso Alternativo:
R4. Datos incorrectos el sistema presenta mensaje de datos incorrecto.
R6. Presentar mensaje de cliente registrado
Importancia Alta
Comentarios [se especifica cualquier comentario para el caso de uso]
Reflexionar:
Un poco complejo la redacción del curso típico de eventos que colocar en respuesta
del actor y del sistema.
El resto de partes que conforman el cuadro de caso de uso expandido y todo

respecto a eso.
¿Por qué?
Porque se mostraron ejemplos prácticos sobre este tema.
A realizar el caso de uso expandido.


3 horas
TIEMPO:
FECHA: 27/05/2014
TEMA DISCUTIDO:
Casos de uso Reales
Contenidos:
 Diseño de la realización de los casos de uso,

 Herramienta CASE
Aprender la importancia y utilización de los casos de uso en un diseño de sistema
El docente explicó con material didáctico de diapositivas ante nosotros los alumnos
sobre la definición de los casos de uso la manera de cómo utilizarlos, en que herramientas
podemos diseñar estos diagramas y poner en práctica con ejemplos propuestos para un
mejor entendimiento
Diagrama de caso de usos, herramientas CASE
La documentación del UML ha propiciado el desarrollo de herramientas CASE, las cuales

cubren el ciclo de vida del software y además cuentan con el soporte para la documentación
de los modelos desarrollados en ellas
Enterprise Architect
Enterprise Architect combina el poder de la última especificación UML 2.1 con alto
rendimiento, interfaz intuitiva, para traer modelado avanzado al escritorio, y para el equipo
completo de desarrollo e implementación. Con un gran conjunto de características y un valor
sin igual para el dinero, EA puede equipar a su equipo entero, incluyendo analistas,
evaluadores, administradores de proyectos, personal del control de calidad, equipo de
desarrollo y más, por una fracción del costo de algunos productos competitivos. Verifique el
rango completo de las herramientas y características case en detalle.
Alta capacidad - Características finales superiores a un precio justo
Enterprise Architect es una herramientas comprensible de diseño y análisis UML, cubriendo

el desarrollo de software desde el paso de los requerimientos a través de las etapas del
análisis, modelos de diseño, pruebas y mantenimiento. EA es una herramienta multi-usuario,
basada en Windows, diseñada para ayudar a construir software robusto y fácil de mantener.
Ofrece salida de documentación flexible y de alta calidad. El manual de usuario está
disponible en línea.
Velocidad, estabilidad y buen rendimiento
El Lenguaje Unificado de Modelado provee beneficios significativos para ayudar a construir

modelos de sistemas de software rigurosos y donde es posible mantener la trazabilidad de
manera consistente. Enterprise Architect soporta este proceso en un ambiente fácil de usar,
rápido y flexible. Para una mirada rápida al modelado UML en Enterprise Architect vea
nuestro tutorial UML y documentos.
Características Principales
 Diseño y construcción de UML.
 Casos de Uso, Modelos Lógico, Dinámico y Físico.
 Extensiones personalizadas para modelado de procesos y más.
 Documentación de alta calidad compatible con MS Word.
 Intuitivo y simple de usar.
 Bajo costo de Licencias.
 Modelado de Datos, Ingeniería directa de Base de Datos a DDL e
Ingeniería inversa de Base de Datos desde ODBC.
 Multi-usuario (solamente para ediciones Profesional y Corporativa).
 Ingeniería de Código Directa e Inversa (ediciones Corporativa y
Profesional solamente) - Soporte para ActionScript 2.0, Java, C#, C++,
VB.Net, Delphi, Visual Basic, Python y PHP.
 Facilidad de Importación/Exportación XMI.
 Corrector Ortográfico
Reflexionar:
Entender sobre las herramientas CASE
EL diseño y realización de Casos de Uso.
¿Por qué?
Porque explico el docente un ejemplo sobre cómo realizar los procesos principales.
Sobre las Herramientas CASE.


2 horas
TIEMPO:
FECHA: 29/05/2014
TEMA DISCUTIDO:
Casos de uso Reales
Contenidos:
 Ejercicios
Reforzar conocimientos sobre los casos de uso por medio de ejercicios prácticos
El docente facilito un enunciado para trabajarlo en clases sobre casos de uso

debíamos de diagramar cada uno según los requerimientos que nos presentó en el
enunciado
Diagrama de caso de usos, herramientas CASE
El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema.

Un caso de uso representa una unidad discreta de interacción entre un usuario
(humano o máquina) y el sistema. Un Caso de Uso es una unidad simple de trabajo
significativo; por ejemplo, "Validarse en el sistema", "Registrarse en el sistema" y
"Crear un pedido" son todos casos de uso.
Cada caso de uso tiene una descripción que describe la funcionalidad que se
construirá en el sistema propuesto. Un caso de uso puede "incluir" la funcionalidad
de otro caso de uso o "extender" a otro caso de uso con su propio comportamiento.
Enterprise Architect combina el poder de la última especificación UML 2.1 con alto
rendimiento, interfaz intuitiva, para traer modelado avanzado al escritorio, y para el equipo
completo de desarrollo e implementación. Con un gran conjunto de características y un valor
sin igual para el dinero, EA puede equipar a su equipo entero, incluyendo analistas,
evaluadores, administradores de proyectos, personal del control de calidad, equipo de
desarrollo y más, por una fracción del costo de algunos productos competitivos. Verifique el
rango completo de las herramientas y características case en detalle.
Una descripción de caso de uso generalmente incluirá:
Comentarios generales y notas describiendo el caso de uso
Requisitos -cosas que el caso de uso debe permitir hacer al usuario, tales como
<capacidad para actualizar pedido>, <capacidad para modificar pedido>, etc.
Restricciones -reglas acerca de qué se puede y qué no se puede hacer-. Incluye:
Pre-condiciones que deben ser verdaderas antes de que el caso de uso se ejecute,
por ejemplo <crear pedido> debe preceder a <modificar pedido>
Post-condiciones que deben ser verdaderas una vez que el caso de uso se ejecutó,
por ejemplo <el pedido está modificado y es consistente>invariantes: éstas son siempre
verdaderas -por ejemplo, un pedido debe tener siempre un número de cliente.
Escenarios -descripciones secuenciales de los pasos que se toman para llevar a
cabo el caso de uso. Pueden incluir escenarios múltiples, para satisfacer circunstancias
excepcionales y caminos de proceso alternativos
Diagramas de escenarios -diagramas de secuencia para describir el flujo de trabajo-

similar al punto 4 pero descrito gráficamente.
Atributos adicionales como fase de implementación, número de versión, rango de

complejidad, estereotipo y estado
Actores
Un actor es un usuario del sistema. Incluye usuarios humanos y otros sistemas

computarizados. Un actor usa un caso de uso para desempeñar alguna porción de trabajo
que es de valor para el negocio. El conjunto de casos de uso al que un actor tiene acceso
define su rol global en el sistema y el alcance de su acción.
Relaciones de Inclusión y Extensión entre Casos de Uso
Un Caso de Uso puede incluir la funcionalidad de otro como parte de su procesamiento

normal. Generalmente se asume que los casos de uso incluidos se llamarán cada vez que
se ejecute el camino base. Un ejemplo puede ser listar un conjunto de órdenes de clientes
de las cuáles poder elegir antes de modificar una orden seleccionada; en este caso, el Caso
de Uso <listar órdenes> se puede incluir en el Caso de Uso <modificar orden> cada vez que
éste se ejecute.
Un Caso de Uso puede ser incluido por uno o más casos de uso, ayudando así a reducir la
duplicación de funcionalidad al factorizar el comportamiento común en los casos de uso que
se reutilizan muchas veces.
Un Caso de Uso puede extender el comportamiento de otro Caso de Uso; típicamente

cuando ocurren situaciones excepcionales. Por ejemplo, si antes de modificar un tipo
particular de orden de cliente, un usuario debe obtener la aprobación de alguna autoridad
superior, entonces el Caso de Uso <obtener aprobación> puede extender opcionalmente el
Caso de Uso normal <modificar orden>.
CASOS DE USO
- Nivel 1. DIAGRAMA GENERAL (Caso de Uso general)
EL caso de uso “expandido” es lo mismo que el diagrama de casos de uso, es de forma

narrativa de la iteración de usuario y sistema.
Diagrama de caso de uso, representación gráfica de la iteración entre usuario y sistema.
Pero es necesario describir las acciones internas por lo que surge el nivel 2
- Nivel 2  diagrama de caso de uso DETALLE
- Nivel 3  Diagrama de Casos de uso Extendido

Agrupación del caso de uso nivel 1 y nivel 2
Reflexionar:
No hubo problemas en esta clase
Desarrollo de ejercicios prácticos
¿Por qué?
Porque hubo una explicación bastante clara.
A modelar casos de Uso y sus administrar


3 horas
TIEMPO:
FECHA: 03/06/2014
TEMA DISCUTIDO:
Diseño de interfaz
Contenidos:
 Principios y reglas de oro en el diseño de la IU
Conocer los principios del diseño de interfaces
El docente por medio de material didáctico se explicó cuál es el principio y las

reglas de oro para el diseño de interfaz , se realizaron preguntas y actuación en
clases para mejor entendimiento hacia los alumnos
IU, diseño de interfaz
Principios de Diseño:
 „ Colocar a los usuarios en el control de la interfaz

 „ Reducir la carga de memoria de los usuarios
 „ Hacer la interfaz de usuario consistente
Colocar al usuario en el control
 „ Emplear los modos adecuadamente

 „ Permitir a los usuarios emplear teclado y ratón
 „ Permitir a los usuarios cambiar la atención
 „ Mostrar mensajes y texto descriptivo
 „ Proporcionar acciones inmediatas y reversibles
 „ Proporcionar caminos significativos y salidas
 „ Acomodar a los usuarios con diferentes niveles de habilidad
 „ Hacer la interfaz de usuario transparente
 „ Permitir al usuario personalizar la interfaz
 „ Permitir a los usuarios manipular los objetos de la interfaz
Empleo de los Modos Adecuado
„ Los modos no son siempre malos, pero la idea es que el usuario pueda cambiar de
modos y no sea forzado a ello.
 „ Aplicación Modal
 „ Sistema Modal
„ Impresora sin papel NO cuadro modal
Permitir Teclado y Ratón
„ Los usuarios deben poder hacer su trabajo tanto con ratón como con teclado
(Common User Access, IBM)
„ Se puede optimizar la interfaz para los usuarios de ratón, pero hay que
proporcionar una forma de realizar tareas con teclado
„ Ventajas:
 „ facilidades para usuarios de otros entornos

 „ facilidades para usuarios con necesidades especiales
 „ continuidad ante fallos o inexistencia del ratón
„ Existen un gran número de guías que no siguen este principio.
Permitir Cambio de Atención
 „ La interfaz debe ser diseñada para que los usuarios pueden interrumpir sus
acciones actuales y continuar con ellas más tarde
 „ No se debe forzar al usuario a completar secuencias predefinidas
 „ Los sistemas deben proporcionar información significativa del estado de las
actividades en curso
 „ Las tareas en segundo plano han de permitir reclamar la atención del
usuario presentando recordatorios en la interfaz
Mostrar Mensajes y Texto

Descriptivos
„ El lenguaje a emplear debe ser claro y fácil de entender para los mensajes
(instrucciones, etiquetas, botones,...) y la documentación
Reflexionar:
No existieron problemas en la clase de hoy
Conocer las reglas para tener una buena interfaz
¿Por qué?
Fue interesante y bien explicada
Cuáles son las reglas de oro para diseñar correctamente una interfaz

2 horas
TIEMPO:
FECHA: 05/06/2014
TEMA DISCUTIDO:
Diseño de interfaz
Contenidos:
 Estilos de interacción
Conocer el estilo de interacción de un diseño de interfaz
El docente realizo un repaso de la clase anterior para reforzar conocimiento,

recordar y hacer que el nuevo tema sea aún más fácil de comprenderlo, el cual se lo
explico por diapositivas para conocer cuáles son los estilos de interacción que
existen al diseñar una interfaz.
Estilo de Interacción
Término genérico para agrupar las diferentes maneras en que los usuarios se
comunican o interaccionan con el ordenador
Estilos predominantes son:

 „ Interfaz por línea de comandos
 „ Menús y formularios
 „ Manipulación directa
 „ Interacción asistida
Menús
 „ Se muestran las opciones disponibles para el usuario en pantalla

 „ La selección se hace mediante la tecla inicial, introduciendo el número
asociado o moviéndose mediante las teclas de cursor
 „ Se acude al reconocimiento más que al recuerdo
 „ Son ineficientes cuando tienen demasiados ítems
Menus II
 Las opciones deben ser significativas y estar agrupadas. El problema

principal es que ítems incluir y cómo agruparlos (no por orden alfabético)
 Se debe permitir su personalización por parte del usuario
 Serán utilizados en conjunción con otros estilos de interfaz
Reflexionar:
No existieron temas complejos
En lo general estaba muy sencillo
¿Por qué?
Por darse una explicación muy bien realizada
Cuáles son los estilos de interacción


3 horas
TIEMPO:
FECHA: 10/06/2014
TEMA DISCUTIDO:
Diseño de interfaz
Contenidos:
 Formatos individuales de Interfaz
 Catálogos de controles y elementos de diseño
Conocer los formatos individuales de interfaz y los catálogos de controles
El docente realizó un repaso de la clase anterior para reforzar conocimiento,

luego explicó por medio de proyector del aula los temas mencionados anteriormente
para así conocer cuáles son los formatos individuales de interfaz y los catálogos de
controles.
Interacción, diseño de interfaz
En el caso de un análisis orientado a objetos, estos formatos individuales van

completando las especificaciones de los casos de uso.
En un análisis estructurado se tiene en cuenta, para la realización de esta tarea, el

modelo de datos y el modelo de procesos generados en paralelo en las actividades
Elaboración del Modelo de Datos (ASI 6) y Elaboración del Modelo de Procesos (ASI
7).
También se considera el catálogo de requisitos, para especificar las interfaces

relacionadas con las consultas.
En la definición de cada interfaz de pantalla se deben definir aquellos aspectos

considerados de interés para su posterior diseño y construcción:
 Posibilidad de cambio de tamaño, ubicación, modalidad (modal del sistema,
modal de aplicación), etc.
 Dispositivos de entrada necesarios para su ejecución.
 Conjunto y formato de datos asociados, identificando qué datos se usan y
cuáles se generan como consecuencia de su ejecución.
 Controles y elementos de diseño asociados, indicando cuáles aparecen
inicialmente activos e inactivos al visualizar la interfaz de pantalla.
Productos
De entrada
Especificación de Interfaz de Usuario (ASI 8.2)
En Análisis Orientado a Objetos:
Especificación de Casos de Uso (ASI 2.4)
Modelo de Casos de Uso (ASI 2.4)
De salida
 Especificación de Interfaz de Usuario:

o Formatos Individuales de Interfaz de Pantalla
o Catálogo de Controles y Elementos de Diseño de Interfaz de Pantalla
Técnicas
Casos de Uso
Reflexionar:
Los catálogos de controles no se entendieron bien
Los formatos individuales
¿Por qué?
Por darse una explicación muy bien realizada

Conocer los formatos individuales de la interfaz


2 horas
TIEMPO:
FECHA: 12/06/2014
TEMA DISCUTIDO:
Diseño de interfaz
Contenidos:
 Modelo de Navegación y ayuda

 Formatos de Impresión,
 Prototipo de interfaz.
Conocer una herramienta para crear diseño de interfaces (Mockups)
El docente nos facilitó el instalador de un programa que sirve para diseñar

interfaces llamado Mockups que es el programa que utilizaremos para diseñar
nuestras interfaces del proyecto final, se explicó como colocar algunos
componentes, como editar una tabla
Mockups, prototipo de interfaz

Ilustración 1. Arrastramos una Ventana que se encuentra en Containers /Windows
Ilustración 2. Agregamos una datatable para poder editar sus columnas

Ilustración 3. Se da doble clic y se añade con comas el nombre de la columna que
se desea ingresar
Ilustración 4. Resultado Final

Reflexionar:
No existieron temas complejos
Realizar diseño en el programa Mockups
¿Por qué?
Es un programa sencillo de manejarlo
Crear diseño de interfaces en Mockups

UNIDAD III
DIAGRAMAS DE INTERACCION
UNIDAD IV
PATRONES GRASP

2 horas
TIEMPO:
FECHA: 24/06/2014
TEMA DISCUTIDO:
Patrones y UML
Contenidos:
 Aplicar correctamente la asignación de responsabilidades a los objetos
 Comprende la asignación de responsabilidades a los objetos según Patrones GRASP.
El docente facilito un enunciado para trabajarlo en clases sobre casos de uso

debíamos de diagramar cada uno según los requerimientos que nos presentó en el
enunciado
 Patrones UML
 Representación de Clases
 Atributos y Métodos
PATRONES Y UML:
UML es una creación de Grady Boch, James Rumbaugh e Ivar Jacobson. Estos caballeros
son apodados recientemente "Los tres caballeros", ellos trabajaron en distintas empresas
durante la década de los ochenta y principios de los noventa y cada uno diseño su propia
metodología para el análisis y diseño orientado a objetos. Sus metodologías predominaron
sobre las de sus competidores. A mediados de los noventa empezaron a intercambiar ideas
entre si y decidieron desarrollar su trabajo en conjunto.
UML (Lenguaje de Modelado Unificado) es el lenguaje de modelado de sistemas de software

más conocido y utilizado en la actualidad. Es un lenguaje grafico para visualizar, especificar,
construir y documentar un sistema.
UML es un lenguaje de modelado para especificar o describir métodos o procesos. Se utiliza

para definir un sistema, para detallar los artefactos en el sistema y para documentar y
construir. En otras palabras, es el lenguaje en el que esta descrito el modelo.
REPRESENTACION DE ATRIBUTOS Y METODOS:
1. Publica: Todos los objetos la pueden usar (+).
2. Protegido: Solo las subclases lo pueden ver (#).
3. Privado: Solo el objeto al que pertenece lo puede ver (-).
4. Friéndola: Solamente los que pertenecen al mismo paquete lo pueden ver (*).
Nota: En los atributos en lo posible no se debe utilizar la visibilidad pública.
REPRESENTACION DE CLASES:
1. Publica: Declaración general de una clase que puede ser modificada por un objeto.
2. Abstracta: Cuando por lo menos uno de sus métodos debe ser abstracto.
3. Final: Es una clase que no puede ser modificada por ningún objeto.
CLASE:
Es la unidad básica que encapsula toda la información de un objeto (instancia de una clase).
A través de ella podemos modelar el entorno en estudio.
En UML, una clase es representada por un rectángulo que posee tres divisiones:
En donde:
1. Superior: Contiene el nombre de la clase.
2. Intermedio: Contiene los atributos que caracterizan la clase.
3. Inferior: Contiene los métodos u operaciones, los cuales son la forma como
interactúa el objeto con su entorno.
RELACIONES ENTRE CLASES:
 Herencia (Especialización/Generalización): Indica una subclase que hereda los

métodos y atributos especificados por una súper clase, por ende la subclase además
de poseer sus propios métodos y atributos, poseerá los métodos y atributos visibles
de la súper clase.
 Agregación: para modelar objetos complejos, no bastan los tipos de datos básicos
que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se
requiere componer objetos que son instancias de clases definidas por el desarrollo
de la aplicación.
 Asociación: Permite asociar objetos que colaboran entre sí. Cabe destacar que no es
una relación fuerte, es decir, el tiempo de vida de un objeto no depende de otro.
 Dependencia o Instanciación (uso): Representa un tipo de relación muy particular, en

la que una clase es instanciada y se denota por una flecha punteada.
 Composición: Son asociaciones que representan acumulaciones muy fuertes. Esto

significa que las composiciones también forman relaciones completas, pero dichas
relaciones son tan fuertes que las partes no pueden existir por sí mismas.
Únicamente existen como parte del conjunto, y si este es destruido las partes
también lo son.
 Realización: Es una relación semántica entre clasificadores, en donde un clasificador

especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden
encontrar relaciones de realización: entre interfaces y las clases o componentes que
las realizan, y entre los casos de uso y las colaboraciones que los realizan
Reflexionar:
No hubo problemas en esta clase
Entender sobre los métodos y objetos que intervienen en los diagramas.
¿Por qué?
Porque toma conceptos generales de programación y base de datos.
A realizar diagramas de clases


2 horas
TIEMPO:
FECHA: 26/06/2014
TEMA DISCUTIDO:
Diagramas de Interacción
Contenidos:
 Aplicar correctamente la asignación de responsabilidades a los objetos
EL docente realizo una presentación y explicación sobre los diagramas de

interacción.
Diagramas de interacción
Muestran una interacción, que consiste de un conjunto de objetos y sus relaciones,
incluyendo los mensajes que puedan ser realizados entre ellos. Son importantes
para modelar los aspectos dinámicos de un sistema y para construir sistemas
ejecutables a través de ingeniería hacia adelante e ingeniería inversa.
Comúnmente contienen:
 Objetos
 Enlaces
 Mensajes
Pueden servir para visualizar, especificar, construir y documentar los aspectos

dinámicos de una sociedad particular de objetos, o pueden ser usados para modelar
un flujo particular de control de un caso de uso.
Los diagramas de interacción están conformados por los diagramas de secuencia y

los diagramas de colaboración.
Diagramas de secuencia
Enfatiza el orden de tiempo de los mensajes. Gráficamente, este diagrama es una

tabla que muestra objetos ordenados junto al eje de las X y los mensajes, son
ordenados en incremento de tiempo junto al eje de las Y.
Diagrama de colaboración
Enfatiza la organización estructural de los objetos que envían y reciben mensajes.

Gráficamente, es una colección de vértices y arcos.
Para hacer un diagrama de secuencia
 Colocar los objetos que participan en la interacción en la parte de arriba del

diagrama, a través del eje de las X.
 Colocar los objetos que inician la interacción a la izquierda y los objetos más
subordinados a la derecha.
 Colocar los mensajes que estos objetos envían y reciben junto al eje de las Y,
en orden de incremento de tiempo de arriba hacia abajo.
 Existe la línea de vida del objeto, que representa la existencia de un objeto en

un período de tiempo.
 Existe el foco de control, que muestra el período de tiempo en el que el objeto

se encuentra representando una acción
Para hacer un diagrama de colaboración
 Colocar los objetos que participan en la interacción como los vértices en una
gráfica.
 Interpretar las ligas que conectan a estos objetos como los arcos de la
gráfica.
 Adornar estas ligas con los mensajes que los objetos envían y reciben.
 Establecer una ruta, para indicar como un objeto es ligado a otro. Podemos
unirle un estereotipo al final de una liga.
 Establecer un número de secuencia, para indicar el orden de tiempo de un

mensaje. Éste debe ser único.
Diferencias entre los diagramas se secuencia y colaboración

Diagrama de secuencia:
 Línea de vida de los objetos: representa la existencia de un objeto sobre un

período de tiempo.
 Foco de control: muestra el período de tiempo durante el cual un objeto está

representando una acción.
Diagrama de colaboración:
 Ruta: indica como un objeto es ligado a otro.
 Número secuencial: para indicar el orden de tiempo de un mensaje.


3 horas
TIEMPO:
FECHA: 08/06/2014
TEMA DISCUTIDO:
Diagramas de Interacción
Contenidos:
 Taller para Realizar Diagramas UML
EL docente realizo una presentación y explicación sobre los diagramas de

interacción.
UNIDAD V
DIAGRAMA DE CLASES DEL DISEÑO
UNIDAD VI
ALGUNOS ASPECTOS DEL DISEÑO
INTRA
CLASE
TAREA INTRACLASE
ACTIVIDAD N°: 1 FECHA: MARTES 13 de mayo de 2014

TEMA: - SEI (SOFTWARE ENGINEERING INSTITUTE)
UNIDAD N° 1: - DEL ANÁLISIS AL DISEÑO
- Conocer el concepto y propósito del Instituto de
OBJETIVO:
Ingeniería de Software
PROBLEMA: - ¿Qué es el SEI?
- Habilidad para aplicar el conocimiento de las Ciencias
INDICADOR DE
Básicas de la profesión.
EVALUACION:
- Comunicación efectiva.
VALORES: - Responsabilidad, honradez, ética.
TIEMPO: - 20 min
- ERIKA TINOCO
INTEGRANTE (S):
- LUIS TOBAR
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□ Intraclase □Individual
□Taller □Práctica de laboratorio
□ Extraclase □Grupal □Práctica de clase
□Síntesis, esquemas
□Resolución de problemas,
CALIFICACIÓN ejercicios
□Caso de estudio
□Ensayo, artículo
□Investigativa □Informe de exposición
□Vinculación con la colectividad
CONCEPTUALIZACION:
Es el establecimiento y uso de principios solidos de la Ingeniería a fin de

obtener software económico que sea fiable y que funciones en Máquinas
Reales.
TAREA INTRACLASE
ACTIVIDAD N°: 2 FECHA: JUEVES 15 de mayo de 2014

TEMA: - INTRODUCCIÓN AL DISEÑO DE SISTEMAS
UNIDAD N° 1: - DEL ANÁLISIS AL DISEÑO
- Analizar el concepto y actividades de la Ingeniería de
OBJETIVO:
Requisitos.
PROBLEMA: - ¿Qué es la Ingeniería de Requisitos?
INDICADOR DE
Básicas de la profesión.
EVALUACION:
- Comunicación efectiva.
VALORES: - Responsabilidad, honradez, ética.
TIEMPO: - 20 min
- ERIKA TINOCO
INTEGRANTE (S):
- LUIS TOBAR
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□ Intraclase □Individual □Taller □Práctica de laboratorio
□Práctica de clase
□ Extraclase □Grupal □Síntesis, esquemas
□Resolución de problemas,
CALIFICACIÓN □Caso de estudio ejercicios
□Ensayo, artículo
□Investigativa □Informe de exposición
□Vinculación con la colectividad
EXTRA
CLASE
TAREA EXTRACLASE # 1
ACTIVIDAD N°: 1 FECHA 15/05/2014 FECHA 20/05/2014

ENVIO: ENTREGA:
TEMA: Introducción al diseño de sistemas.

UNIDAD N° 1: DEL ANÁLISIS AL DISEÑO.
OBJETIVO: - Contestar las preguntas de la guía.
PROBLEMA: Desconocimiento de las respuestas de las preguntas propuestas.
INDICADOR DE EVALUACION: CALIFICACIÓN

Básicas de la Profesión.
- Comunicación Efectiva.
- Utilización de técnicas e instrumentos modernos.
CRITERIOS DE EVALUACIÓN: A criterio del docente de acuerdo al indicador de Siempre A Nunca
(100%) veces (10%)
evaluación del Syllabus (algunos ejemplos:) (75%)
CAPACIDAD DE COMUNICACIÓN.
EN EXPOSICIONES
 Responde claramente a las preguntas que se le realizan.

 Demuestra seguridad en el tratamiento de los temas.
 Toma en cuenta los elementos vocales y verbales (mantiene: tono, énfasis, claridad
durante la presentación). Mantiene el mismo tono de voz durante la exposición. Habla con
claridad y en forma coherente durante la exposición. Resalta aspectos importantes del tema
 Toman en cuenta los elementos visuales, (postura, viste de acuerdo a la ocasión,
accesorios, gestos, ademanes). Sostiene una postura adecuada durante la exposición. Utiliza
un vestuario adecuado para hacer la presentación
EN IMPRESOS
 Entrega documentación impresa y digital. (Siguiendo las normas y convenciones para

la escritura y sin falta de ortografía) . La redacción del documento debe ser clara. Debe incluir
todas las fuentes de donde tomó la información.
 Cumple con el formato, normas y estructura para la elaboración del
documento.
APLICACIÓN DE VALORES.
 Puntualidad. Entrega de trabajo a tiempo

 Responsabilidad ética. El trabajo es inédito y respeta la propiedad intelectual
 Responsabilidad profesional. Cumple con las normas técnicas.
USO DE RECURSOS:
 Recursos bibliográficos fidedignos y con validez científica

 Recursos tecnológicos adecuados
CAPACIDAD DE REFLEXIÓN.
 Incluye ejemplos claros que permiten un mejor entendimiento del tema.

CONOCIMIENTO TÉCNICO.
 Destreza con las herramientas informáticas.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□ Intraclase □Individual □Taller □Práctica en laboratorio
□ Extraclase □Grupal □Síntesis, esquemas □Práctica en clase
□Caso de estudio □Resolución de problemas,
□Investigativa ejercicios
□Vinculación con la colectividad □Ensayo, artículo
□Informe de exposición
ROLES Y RESPONSABILIDADES DE LOS PARTICIPANTES EN LA TAREA:
NOMBRE ESTUDIANTE ROL DESCRIPCIÓN
ERIKA TINOCO Investigador Responder las preguntas
TÉCNICAS EMPLEADAS
Investigación, lectura, resumen y análisis.
INTRODUCCIÓN.
La Ingeniería del Software es la rama de la ingeniería que crea y mantiene las
aplicaciones de software usando tecnologías y prácticas de las ciencias de la
computación, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros
campos
Hoy en día, el software es una parte integral de la mayoría de los sistemas. Para
ejecutar proyectos software de forma satisfactoria y construir productos de alta
calidad, los profesionales del software necesitan entender las características únicas
del software y el enfoque usado para desarrollar y mantener software
MARCO TEÓRICO.
Modelos de desarrollo de Software Orientado a Objetos

Un Modelo de desarrollo define una filosofía o marco de actuación para obtener un
software que sea ajustable a unas determinadas características, por ejemplo, que el
producto final esté constituido por un conjunto de procedimientos o funciones que
sean independientes o que esté constituido por una serie de clases en las que los
datos junto con las funciones forman entidades autónomas.
Algunos de los modelos de desarrollo de software son:
1. Modelo de desarrollo incremental.

 Divide el proyecto en fases, según su tamaño y objetivos ser alcanzados en
cada fase.
 El modelo incremental mantiene el modelo en cascada, pero lo repite “n”
veces.
Se presupone que todos los requisitos son conocidos al comienzo
2. Modelo de desarrollo evolutivo.

 Es muy similar al modelo de desarrollo incremental, en el modelo evolutivo se
asume que no todos los requerimientos son conocidos desde el primer
momento.
 En una primera fase, se desarrolla la primera versión, que recoge los
requisitos conocidos. Posteriormente, los usuarios utilizan el software
desarrollado, generándose una nueva lista de requerimientos, con la que se
desarrolla una nueva versión en la siguiente fase y así sucesivamente.
 El usuario ve la materialización del proyecto más rápido que si hubiera que
hacer un estudio largo para concretar las especificaciones. Además, puede
modificar o añadir los requerimientos sin afectar al proyecto y conseguir algo
que se ajuste mejor a sus necesidades.
3. Es un modelo compatible con el modelo de cascada y puede ser combinado con
el modelo incremental
3. Modelo de prototipado de requerimientos.
 Consiste en realizar implementaciones parciales del sistema para poder
experimentar y validar o modificar los requerimientos del mismo
 El prototipo se construye deprisa y se da a los usuarios para que lo prueben y
evalúen. Los usuarios dan sus comentarios sobre lo bueno y lo malo, sobre lo
que les gustó y lo que no les gusto. Los comentarios se recogen y sirven para
hacer la especificación del sistema real.
Este modelo se suele utilizar como parte de la tarea de especificación de requisitos o
justo antes de la misma
4. Modelo concurrente.
 Se representa de forma esquemática como una serie de tareas junto con sus
estados asociados. Da respuesta a la situación habitual de los proyectos, en
la que se realizan varias tareas simultáneamente, aunque se encuentran en
distintos estados.
 Se puede replantear la especificación de requisitos mientras se sigue
desarrollando.
 Este modelo define una serie de eventos que disparan transiciones de unos
estados a otros para cada una de las tareas o actividades del proyecto de
desarrollo software.
 Este modelo proporciona, una visión exacta del estado actual del proyecto.
5. Ciclos de vida Orientado a Objetos
Existen varios ciclos de vida Orientado a Objetos, pero solo mencionaremos los más
conocidos. Los ciclos de vida Orientados a Objetos se examinan el dominio del
problema como un conjunto de objetos que interactúan entre sí.
Este ciclo de vida permite acelerar el desarrollo de sistemas de manera iterativa e
incremental, permitiendo la generalización de los componentes para que sean
reutilizables.
6. Ciclo de vida fuente.

 Se divide en 3 fases:
1. Planificación del negocio
2. Construcción
Es la más importante y se divide a su vez en otras cinco actividades
o Planificación
o Investigación
o Especificación
o Implementación
o Revisión
3. Entrega
 Además de las 3 fases, existen 2 periodos:
1. Crecimiento: Es el tiempo durante el cual se construye el sistema.
2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se
planifica igual que el periodo anterior.
Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede
estar en una fase diferente en un momento cualquiera
7. Ciclo de vida remolino
 El modelo remolino es algo similar al modelo cascada, pero en el modelo
remolino también se toman en cuenta otros factores, que son:
o Amplitud: Toma el tamaño de desarrollo.
o Profundidad: Nivel de abstracción
o Madurez: Es el grado de compleción, corrección y elegancia.
o Alternativas: Diferentes soluciones a un problema.
Alcance: Tomamos en cuenta los adjetivos del sistema, ya los requisitos van
cambiando
8. Ciclo de vida pinball

 En este modelo de ciclo de vida la pelota representa un proyecto, y el jugador
es el equipo de desarrollo.
Los pasos en el ciclo de vida de pinball pueden ocurrir de la siguiente manera: Se
procede de forma iterativa a encontrar clases, atributos métodos e interrelaciones y
definir colaboraciones, herencia, agregación y subsistemas
SOLUCIÓN O RESULTADOS.
CONCLUSIONES Y RECOMENDACIONES.
 Tener una idea sobre lo que trata la ingeniería de software.
 Por medio de estas preguntas reforzamos más los conceptos de la ingeniería

de software.
 Al momento de realizar las preguntas, las respuestas de las mismas sean

claras y concisas para que para que pueda ser comprendida con mayor
facilidad.
Bibliografía
F.Javier Zarazaga Soria, Javier Nogueras Iso. 2008. Introduccion a la Ingeniería de Software . [En
línea] Febrero de 2008. [Citado el: 19 de Mayo de 2014.]
http://webdiis.unizar.es/~zarazaga/workPage/docencia/ingSoft1/trasparencias/is1_01.pdf.
Reinoso, Guillermo Bustos. 2012. Ingeniería de Software. Modelado Orientado a Objetos. [En línea]
19 de Agosto de 2012. [Citado el: 17 de Mayo de 2014.]
http://eii.ucv.cl/pers/gbustos/PDF/Evalua.PDF.
http://www.fcav.uat.edu.mx/persona/documentos/1%2FADS/tema2.pdf
http://img.redusers.com/imagenes/libros/lpcu097/capitulogratis.pdf
TAREA EXTRACLASE

ENVIO: ENTREGA:
TEMA: - REQUISITOS FUNCIONALES
UNIDAD N° 1: - “DEL ANÁLISIS AL DISEÑO”
OBJETIVO: - Identificar los requisitos funcionales del ejercicio propuesto.
PROBLEMA: - ¿A partir del enunciado dado, establezca los requerimientos

funcionales?
- Habilidad para aplicar el conocimiento de las Ciencias Básicas
de la Profesión.
- Identificar, formular, resolver problemas de ingeniería de
Sistemas.
CRITERIOS DE EVALUACIÓN: Siempre A veces Nunca
(100%) (75%) (10%)
EN EXPOSICIONES

 Toma en cuenta los elementos vocales y verbales (mantiene: tono, énfasis, claridad durante la
presentación). Mantiene el mismo tono de voz durante la exposición. Habla con claridad y en forma
coherente durante la exposición. Resalta aspectos importantes del tema
 Toman en cuenta los elementos visuales, (postura, viste de acuerdo a la ocasión, accesorios,
gestos, ademanes). Sostiene una postura adecuada durante la exposición. Utiliza un vestuario adecuado
para hacer la presentación
EN IMPRESOS
 Entrega documentación impresa y digital . (Siguiendo las normas y convenciones para la escritura
y sin falta de ortografía). La redacción del documento debe ser clara. Debe incluir todas las fuentes de donde
tomó la información.
 Cumple con el formato, normas y estructura para la elaboración del documento.

USO DE RECURSOS:


TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□ Intraclase □□Individual □Taller □Práctica en laboratorio

Extraclase
□Grupal □Síntesis, esquemas □Práctica en clase
- ERIKA TINOCO Resolución Resuelve el taller planteado

LUIS TOBAR
-
TÉCNICAS EMPLEADAS
Lectura, Análisis, Desarrollo.

SISTEMA PARA EL CONTROL MARKET
PRESENTACIÓN DEL CASO A ESTUDIAR
Supermercados S.A (nombre ficticio de la empresa) es una empresa que se dedica a la
comercialización al detalle de diversos productos de consumo masivo. Cuenta con una cadena
de locales de autoservicio en distintas zonas del área metropolitana y planea expandir su
influencian a otras zonas de lima y callao.
Todas las áreas de la empresa y sus diferentes locales se interconectaran mediante una red
metropolitana.
Cada una de las áreas tiene requerimientos específicos, y se pretende resolverlos utilizando
aplicaciones ofimáticas.
Para efectos del desarrollo del presente caso, delimitaremos el área de estudio a todas las
operaciones que se llevan a cabo en el almacén central, y que tienen relación con él.
La base de datos que se diseñara registrara todas las operaciones que se ejecutan en el
almacén central, y estará habilitada para que todas las áreas de la organización puedan
utilizarla.
Almacén central podrá controlar las entradas y salidas de productos, y las demás áreas podrán
efectuar consultas a la base de datos.
REQ – 01
REPOSICIÓN DE MERCADERÍA EN UN LOCAL
En la reposición de mercadería el responsable de inventario genera una orden de pedido al

almacén central solicitando los productos en el cual debe constar con los siguientes datos:
- Número del pedido

- Fecha del pedido
- Código del producto
- Descripción del producto
- Unidad de medida
- Cantidad solicitada
- Cantidad de ítems solicitados.
El número de pedido deberá tener un dato correlativo seguido por un guion separador y dos
dígitos adicionales que identifican el local que hace el pedido y luego es enviado al almacén
central.
En la orden de pedido debe constar el total de ítems solicitados y la respectiva firma y sello.
REQ – 02
DESPACHO DE MERCADERÍA DESDE EL ALMACÉN HASTA UN LOCAL

En el despacho de mercadería el almacén recibe la orden de pedidos, luego revisa su stock de
productos y genera una Guía de Remisión de los productos que tiene a disposición, y
aquellos productos que no se encuentren en stock genera una orden de compra y es enviada al
departamento de compras para que realice la gestión de compras de los productos solicitados.
El despacho de mercadería permitirá realizar lo siguiente:
La guía de remisión deberá contener lo siguiente:
 Numero de Guía de Remisión

 Numero de pedido al cual se despacha
 Numero de local a cual es enviado
 Fecha de salida
 Nombre del Transportista
 Total de Ítems despachados
 Código de Producto
 Descripción
 Cantidad
 Precio de Venta al público
 Firma y Sello del despachador
REQ – 03
SOLICITUD DE MERCADERÍA A UN PROVEEDOR

En la solicitud de mercadería cuando un almacén detecta un bajo nivel de inventario o poco
stock de algún producto, el bodeguero generara una orden de compra y es enviado al
departamento de Compras y este departamento se comunica con los Proveedores para
negociar los precios de los producto.
La Orden de Compra deberá contener los siguientes datos:
 Nro. Orden de Compra

 Fecha de la Orden de Compra
 Nombre del Proveedor
 Código del Producto
 Descripción del Producto
 Unidad de Medida
 Precio del Proveedor
 Precio de la Compra
 Cantidad Solicitada
 Cantidad Recibida
 Estado
 Total de Ítems solicitados
 Firma y sello Almacenero
La orden de compra es enviada al proveedor con los campos cantidad recibida y estado vacío
con la finalidad que el proveedor deberá llenar esos campos si es que cuentan con el stock
respectivo y con los precios establecidos.
REQ – 04
RECEPCIÓN EN ALMACÉN DE LA MERCADERÍA ENVIADA POR EL PROVEEDOR

En la recepción de mercadería el proveedor envía los productos con la respectiva orden de
compra y la cantidad de los productos enviados y el estado actual del producto
El bodeguero recibe la mercadería con la orden de compra y registra la fecha de ingreso y

actualiza el inventario
REQUERIMIENTOS FUNCIONALES
1.1 PROBLEMA.
Supermercados S.A.A. es una empresa dedicada a la comercialización al detalle de diversos

productos de consumo masivo. Cuenta con una cadena de locales de autoservicio en distintas
zonas del área metropolitana, y planea expandir su influencia a otras zonas de Lima y Callao.
Todas las áreas de la empresa y sus diferentes locales se interconectaran mediante una red
metropolitana. Cada una de las áreas tiene requerimiento específicos, y se pretende resolverlos
utilizando aplicaciones ofimáticas.
Para efectos del desarrollo del presente caso, delimitaremos el área de estudio a todas las
operaciones que se lleva a cabo en el Almacén Central, y que tienen relación con él.
1.2 JUSTIFICACIÓN.
Para poder llevar un mejor control de todos los movimientos, requerimientos que tiene el
almacén con sus sucursales dispondrán de un sistema automatizado a través del cual se
registrara todas las operaciones que se ejecutan en el Almacén Central, podrá controlar las
entradas y salidas de productos, y las demás áreas podrán efectuar consultas a la base de
datos.
Para lo cual se ha visto conveniente realizar los siguientes módulos en el sistema informático
que son:
Módulo de Reposición de Mercadería en un Local.
Objetivos:
 Administrar las órdenes de pedido.

 Administrar los productos.
 Administrar las categorías en la que se dividen los productos.
 Administrar los proveedores.
 Administrar los locales.
Beneficios:
 Generar pedidos de un local directamente al almacén.

 Gestionar el inventario de los productos, mediante categorías.
 Control de servicio de los proveedores hacia los locales.
Módulo de Despacho de Mercadería desde el Almacén hasta un Local
Objetivos:
 Administrar Guías de Remisión.

 Administrar Transportistas.
Beneficios:
 Facilidad en el control del inventario de productos.
 Información fiable y al alcance de forma rápida.
 Control personal encargado de movilizar los productos

establecidos.
Módulo de Solicitud de Mercadería a un Proveedor
Objetivo:
 Gestión Orden de Compra.

Beneficios:
 Control de stock de productos.
Módulo de Recepción en el Almacén de la mercadería enviada por el

Proveedor
Objetivos:
 Actualizar la Orden de compra.

 Actualizar el stock con el control de Inventarios del Almacén
Beneficios:
 Mantener un control de inventario actualizado.
1.3 ESPECIFICACIÓN DE REQUERIMIENTOS
1.3.1 REQ-01
BITÁCORA
Fecha de 30/09/2012 Versión del V.1.0
elaboración: documento:
REQ – 01
REPOSICIÓN DE MERCADERÍA EN UN LOCAL
Fecha 30/09/2012 Responsable Bruno Díaz
Observaciones: Requerimientos funcionales de las historias:
En la reposición de mercadería el responsable de inventario
genera una orden de pedido al almacén central solicitando los
productos en el cual debe constar con los siguientes datos:
- Número del pedido
- Fecha del pedido
- Código del producto
- Descripción del producto
- Unidad de medida
- Cantidad solicitada
- Cantidad de ítems solicitados.
El número de pedido deberá tener un dato correlativo seguido
por un guion separador y dos dígitos adicionales que identifican
el local que hace el pedido y luego es enviado al almacén
central.
En la orden de pedido debe constar el total de ítems solicitados y
la respectiva firma y sello.
La reposición de mercadería permitirá realizar lo siguiente:
REQ-01.1 permite ingresar los datos solicitados del pedido para
el local.
REQ-01.2 permite modificar los datos del pedido.
REQ-01.3 permite eliminar los datos de la orden del pedido.
REQ-01.4 permita buscar un pedido en base a su número o por
la fecha realizada.
Usuario Administrador, Despachador.
REQ01- REPOSICIÓN DE MERCADERÍA
1.3.1.1 Administración de Pedidos: Se encarga de gestionar el pedido, el responsable de hacerlo en este caso es el despachador, permitiendo realizar la
orden de pedido por medio de la cual se solicita los productos, así como también tendrá acceso a modificar, buscar las órdenes, pero solo el
administrador puede eliminarlas.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
Debe ser número correlativo seguido por un

NumPedido guion donde los dos últimos dígitos
identifican el local.
Ingreso de
REQ-01.1 Inserción datos del FechaPedido Día, mes y año Alta
pedido Estos valores son de una tabla producto REQ-
CodigoProducto, Descripcion, Unidad, Cantidad
01.5
TotalItems Representa el total de productos solicitados.
Modificación
REQ-01.2 Modificación de los datos Datos RQ01.1 Trabaja con RQ-01.1 Alta
del pedido
Eliminación
REQ-01.3 Eliminación de Datos del Datos RQ01.1 Para eliminar se necesita el NumPedido. Baja
pedido
Consulta de
REQ-01.4 Consultar los Datos del Consultar NumPedido, FechaPedido Trabaja con RQ-01.1 Media
pedido
1.3.1.2 Administración de Productos: Permite el ingreso de los productos, conjuntamente con sus características, modificación, eliminación y
consulta. El Administrador y el bodeguero podrán realizar estas operaciones. (Excepto que el bodeguero no tendrá acceso a eliminar).
Debe tener un numero entero autoincrementar,

Id Producto
no debe ser valor nulo
Debe tener un numero entero no debe ser

IdCategoria valor nulo este código proviene de la tabla
Categoria.
Debe tener un numero entero no debe ser

Ingreso de datos del Idproveedor valor nulo este código proviene de la tabla
REQ-01.5 Inserción Proveedor. Alta
producto
En caso de venta se disminuiría el stock de

productos.
Stock Actual
En caso de recepción de producto se
incrementa el stock
Nombres ,Unidad Medida, Precio Proveedor, Costo Iva,

No deben ser nulos
Precio Venta, Utilidad, Stock Mínimo
Modificación de los
REQ-01.6 Modificación Datos REQ-01.5 Trabaja con REQ-01.5 Alta
datos del producto
Eliminación de los
REQ-01.7 Eliminación Datos REQ-01.5 Para eliminar se necesita el IdProducto. Baja
datos del producto
Consulta de los datos Los datos pueden ser consultados por nombre,
REQ-01.8 Consulta IdProducto, Nombre Media
del producto categoría, proveedor.
1.3.1.3 Administración de Categorías: Permite ingresar nuevas categorías, así también modificar, eliminar, consultar; estas categorías serán las que
clasifiquen a los productos. De la misma forma tendrán acceso el bodeguero y el administrador, siendo el primero no podrá eliminar ninguna
categoría.
IdCategoría
Debe tener un numero entero autoincremental,

no debe ser valor nulo
Ingreso de datos de la
REQ-01.9 Inserción Alta
categoría
Nombre, detalle No deben ser nulos
Modificación de los datos de

la categoría
Eliminación de los datos de la

REQ-01.11 Eliminación Datos REQ-01.9 Para eliminar se necesita el IdCategoría. Baja
categoría
Consulta de los datos de la Los datos pueden ser consultados por nombre,
REQ-01.12 Consulta Nombre , IdCategoría Media
categoría IdCategoría.
1. Administración de Proveedor: Permite la gestión de los proveedores de los productos: insertar, modificar, eliminar, consulta. El responsable
de realizar estas operaciones es el departamento de compras, el cual tiene los permisos de insertar, modificar y consultar más no eliminar ya
que este privilegio lo tiene el Administrador.
IdProveedor Debe tener un numero entero

autoincrementar, no debe ser valor nulo
Ingreso de datos del

REQ-01.13 Inserción CedulaProveedor
proveedor No debe ser nulo y debe ser la cedula del Alta
Proveedor
Nombres, Representante, Dirección, Ciudad, Departamento,

No deben ser nulos
Teléfono.
datos del proveedor
Eliminación de los
REQ-01.15 Eliminación Datos REQ-01.13 Para eliminar se necesita el IdProveedor. Baja
datos del proveedor
Los datos pueden ser consultados por

Consulta de los datos
REQ-01.16 Consulta Nombre , Id Proveedor, Representante Nombre, Id Proveedor, Código Media
del proveedor
Proveedor, Ciudad.
2. Administración de Local: Permite la gestión de los datos de los locales para realizar acciones sobre la misma como: insertar, modificar,
eliminar, consulta. El responsable de realizar estas operaciones se encuentra en el almacén Principal. Teniendo los permisos de insertar,
modificar y consultar más no eliminar ya que este privilegio lo tiene el Administrador.
IdLocal
Debe tener un numero entero

REQ-01.17 Inserción Ingreso de datos del local Alta
Dirección, Teléfono, Fax, Ciudad No deben ser nulos
Modificación de los datos

del local
Eliminación de los datos

REQ-01.19 Eliminación Datos REQ-01.17 Para eliminar se necesita el IdLocal. Baja
del local
Consulta de los datos del Los datos pueden ser consultados por Id
REQ-01.20 Consulta Id Local, ciudad Media
local Local, Distrito
1.3.2 REQ-02
BITÁCORA
REQ – 02
DESPACHO DE MERCADERÍA DESDE EL ALMACÉN HASTA UN LOCAL
En el despacho de mercadería el almacén recibe la orden de pedidos, luego
revisa su stock de productos y genera una Guía de Remisión de los productos
que tiene a disposición, y aquellos productos que no se encuentren en stock
genera una orden de compra y es enviada al departamento de compras para
que realice la gestión de compras de los productos solicitados.
El despacho de mercadería permitirá realizar lo siguiente:
La guía de remisión deberá contener lo siguiente :
 Numero de Guía de Remisión
 Numero de pedido al cual se despacha
 Numero de local a cual es enviado
 Fecha de salida
 Nombre del Transportista
 Total de Ítems despachados
 Código de Producto
 Descripción
 Cantidad
 Precio de Venta al público
 Firma y Sello del despachador
REQ-02.1permite crear una nueva guía de remisión con los productos
solicitados.
REQ-02.2 permite modificar los datos de una guía de remisión.
REQ-02.3 permite eliminar los datos de la guía de remisión.
REQ-02.4 permita buscar una guía de remisión, ya sea esta por el número de
guía o fecha.
Usuario: Administrador, Bodeguero
REQ02- REPOSICIÓN DE MERCADERÍA
1.3.2.1 Administración de Guías: Permite la gestión de los guías de remisión: inserción, modificación, eliminación y búsqueda. El responsable de
realizar estas operaciones es el despacho de mercadería (bodeguero), a excepción de la eliminación, se recibe la orden de pedido y su stock, de
acuerdo a esto genera la orden de remisión con los productos que tiene.
Debe tener un numero entero autoincrementar, no debe

IdGuia
ser un valor nulo.
Debe tener un número entero, no debe ser valor nulo, este

IdLocal
código proviene de la tabla Local. REQ-01.17.
Ingreso de datos del Debe tener un número entero, no debe ser valor nulo, este
REQ-02.1 Inserción IdTrans Alta
pedido código proviene de la tabla Transporte. REQ-02.5.
IdProducto
código proviene de la tabla Producto. REQ-01.5
IdNumPedido
código proviene de la tabla Pedido. REQ-01.1
fechaSalida, PVP, Cantidad No deben ser nulos.
Total de Items Despachados Representa el total de ítems despachados

REQ-02.2 Modificación Datos RQ02.1 Trabaja con RQ-02.1 Alta
datos del pedido
Eliminación de Datos
REQ-02.3 Eliminación Datos RQ02.1 Para eliminar se necesita el IdGuia Baja
del pedido
Consulta de los Datos
REQ-02.4 Buscar Consultar IdNumPedido, IdGuia. Trabaja con RQ-02.1 Media
del pedido
1. Administración de transportistas: Permite la gestión de los transportistas permitiendo la inserción, modificación, eliminación y
búsqueda. El responsable de realizar estas operaciones es el despacho de mercadería (bodeguero) a excepción de eliminación ya que esta
acción será realizada solamente por el Administrador.

Idtrans
Debe tener un numero entero
Ingreso de datos
REQ-02.5 Inserción Cedtrans No debe ser nulo y debe ser la cedula del Alta
del transportista
Transportista
Nombres, Dirección, Teléfono. No deben ser nulos
Modificación de
Modificació
REQ-02.6 los datos del Datos REQ-02.5 Trabaja con REQ-02. 5 Alta
n
proveedor
Eliminación de
REQ-02.7 Eliminación los datos del Datos REQ-02. 5 Para eliminar se necesita el Idtrans. Baja
proveedor
Consulta de los Los datos pueden ser consultados por
REQ-02.8 Consulta datos del Nombre , Idtrans, Cedtrans Nombre, Id transportista, cedula Media
proveedor transportista.
TAREA EXTRACLASE

ENVIO: ENTREGA:
TEMA: - CONTINUAR CON LOS REQUISITOS FUNCIONALES
OBJETIVO: - Identificar los requisitos funcionales del ejercicio propuesto.
PROBLEMA: - ¿A partir del enunciado dado, establezca los requerimientos

funcionales?
de la Profesión.
- Identificar, formular, resolver problemas de ingeniería de
Sistemas.
(100%) (75%) (10%)
EN EXPOSICIONES

EN IMPRESOS
 Entrega documentación impresa y digital . (Siguiendo las normas y convenciones para la escritura
 Cumple con el formato, normas y estructura para la elaboración del documento.

USO DE RECURSOS:


TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA

Extraclase
- ERIKA TINOCO Resolución Resuelve el taller planteado
- LUIS TOBAR
-
TÉCNICAS EMPLEADAS
Lectura, Análisis, Desarrollo.

1.3.3 REQ-03
BITÁCORA
REQ – 03
SOLICITUD DE MERCADERÍA A UN PROVEEDOR
Observaciones Requerimientos funcionales de las historias:
En la solicitud de mercadería cuando un almacén detecta un bajo nivel de
inventario o poco stock de algún producto, el bodeguero generara una orden
de compra y es enviado al departamento de Compras y este departamento se
comunica con los Proveedores para negociar los precios de los producto.
La Orden de Compra deberá contener los siguientes datos:
 Nro. Orden de Compra
 Fecha de la Orden de Compra
 Nombre del Proveedor
 Código del Producto
 Descripción del Producto
 Unidad de Medida
 Precio del Proveedor
 Precio de la Compra
 Cantidad Solicitada
 Cantidad Recibida
 Estado
 Total de Ítems solicitados
 Firma y sello Almacenero
La orden de compra es enviada al proveedor con los campos cantidad recibida
y estado vacío con la finalidad que el proveedor deberá llenar esos campos si
es que cuentan con el stock respectivo y con los precios establecidos.
La solicitud de mercadería al proveedor permitirá realizar lo siguiente:
REQ-03.1permitira crear una nueva orden de compras.
REQ-03.2 permite modificar los datos de la orden de compra.
REQ-03.3 permite eliminar los datos de la orden de compra.
REQ-03.4 permita buscar una orden de compra cuando lo desee pertinente ya
sea esta por el número, fecha de emisión e inclusive el nombre del proveedor.
Usuario Administrador, Bodeguero, Jefe de Compras
REQ03- SOLICITUD DE MERCADERÍA A UN PROVEEDOR
1.3.3.1 Administración de Orden de Compra: Permite la gestión de órdenes de compra permitiendo la inserción, modificación, eliminación y
búsqueda. El responsable de realizar estas operaciones es el despacho de mercadería (Bodeguero), que recibe la orden de pedido y su stock, de
acuerdo a esto genera la orden de Compra con los productos que no tiene con el fin de adquirirlos. Lo recibe el despacho de compras y lo revisa para
comunicarse con los proveedores.
Debe tener un numero entero autoincrementar, no debe ser

IdOrden
valor nulo.
Debe tener un numero entero no debe ser valor nulo este
IdProveedor
código proviene de la tabla Proveedor. REQ-01.13
Debe ser un dato tipo Date, no debe ser valor nulo, Día, mes
FechaIngreso, FechaEmisión
y año.
Debe tener un numero entero no debe ser valor nulo este
IdProducto
REQ- Ingreso de datos de código proviene de la tabla Producto. REQ-01.5
Inserción Alta
03.1 Orden Deben ser valores enteros cuando se genere la orden de
CantidadSolicitada
compra.
Deben ser valores enteros no nulos cuando se genere la
CantidadRecibida orden de compra, el departamento de compras será la
encargada de llenar estos campos.
PrecioProveedor Debe tener un numero decimal no debe ser valor nulo
Deben ser tipos de datos decimal, el precio de compra debe
PrecioCompra
estar vacío al momento de generar la orden de compra.
Estado Debe ser nulo
REQ-03.2 Modificación Modificación de Orden Datos RQ03.1 Trabaja con RQ-03.1 Alta
REQ-03.3 Eliminación Eliminación de Orden Datos RQ03.1 Para eliminar se necesita el IdOrden. Baja
REQ-03.4 Consultar Consulta de Orden IdOrden, FechaOrden Trabaja con RQ-03.1 Media
1.3.4 REQ-04
BITÁCORA
REQ – 04
RECEPCIÓN EN ALMACÉN DE LA MERCADERÍA ENVIADA POR EL
PROVEEDOR
En la recepción de mercadería el proveedor envía los productos con la
respectiva orden de compra y la cantidad de los productos enviados y el
estado actual del producto
El bodeguero recibe la mercadería con la orden de compra y registra la fecha
de ingreso y actualiza el inventario
La recepción de mercadería permitirá realizar lo siguiente:
REQ-04.1 permitirá el ingreso de productos solicitados en la orden de
compra.
REQ-04.2 permite la actualización del stock actual del producto y el precio
del proveedor en el inventario.
REQ-04.3 permite eliminar los productos en existencia.
REQ-04.4 permita buscar una Orden de Compra puede ser por el
número de orden de compra, fecha de ingreso.
Usuario Administrador, Bodeguero, Jefa Compras, proveedor
REQ04- RECEPCIÓN EN ALMACÉN DE LA MERCADERÍA ENVIADA POR EL PROVEEDOR
1.3.4.1 Administración de Orden de Compra: Permite la gestión de órdenes, el responsable de realizar estas operaciones es el bodeguero que puede
realizar la búsqueda ya que los demás privilegios los tiene el administrador. El bodeguero recibe la orden de compra con los campos faltantes ahora
llenos por el proveedor, procediendo a actualizar el inventario.

IdOrden
IdProveedor Este campo debió haber sido llenado por el
bodeguero al momento de generar la orden de
FechaEntrada, FechaOrden
compra.
IdProducto La jefa de compra puede modificar el campo
Cantidad Solicitada IdProveedor si el producto solicitado no tiene el
proveedor asignado.
Debe ser un valor entero y debe ser actualizado por

Cantidad Recibida
Ingreso de datos de la jefa de compras.
REQ-04.1 Modificación Este campo debió haber sido llenado por el Alta
Orden
Precio Proveedor bodeguero al momento de generar la orden de
compra
PrecioCompra
Debe ser un valor decimal y debe ser actualizado por
la jefa de compras al momento de realizar la compra
con el proveedor.
Debe ser un valor tipo cadena, puede ser agotado o
Estado entregado, este campo es actualizado por la jefa de
compras.
REQ-04.2 Eliminación Eliminación de Orden Datos REQ-04.1 Para eliminar se necesita el IdOrden. Baja
REQ-04.3 Consultar Consulta de Orden Consultar IdOrden, FechaOrden Trabaja con RQ-04.1 Media
UNIDAD ACADEMICA DE INGENIERIA CIVIL
CARRERA DE INGENIERIA DE SISTEMAS
ENVIO: ENTREGA:
TEMA: IEEE 830

UNIDAD N°1: Del análisis al diseño
OBJETIVO: Estudiar y analizar el formato del Estándar IEEE 830 para recolección de requisitos.
PROBLEMA: Investigar sobre IEE 830
INDICADOR DE DESCRIPCIÓN
EVALUACION:
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□ Intraclase□ E □ Individual □Taller
□Práctica en laboratorio
□Práctica en clase
xtraclase
□ Grupal □Caso de estudio □Resolución de problemas,
□Informe de exp
CALIFICACIÓN sición

NOMBRE ROL DESCRIPCIÓN
Erika Paola Tinoco Investigador - Analista Realizador de Investigación
INTRODUCCION
En este documento se muestra el formato de Especificación de Requisitos

Software (ERS) según la última versión del estándar IEEE 830. Según IEEE,
un buen Documento de Requisitos, pese a no ser obligatorio que siga
estrictamente la organización y el formato dados en el estándar 830, sí
deberá incluir, de una forma o de otra, toda la información presentada en
dicho estándar. El estándar de IEEE 830 no está libre de defectos ni de
prejuicios, y por ello ha sido justamente criticado por múltiples autores y
desde múltiples puntos de vista, llegándose a cuestionar incluso si es
realmente un estándar en el sentido habitual que tiene el término en otras
ingenierías. El presente documento no pretende pronunciarse ni a favor ni en
contra de unos u otros: tan sólo reproduce, con propósitos fundamentalmente
docentes, como se organizaría un Documento de Requisitos según el
estándar IEEE 830.
Especificación de Requisitos según el estándar de IEEE

830(IEEE Std. 830-1998 )
Índice
1. Introduccion................................................¡Error! Marcador no definido.
1.1. Proposito...........................................¡Error! Marcador no definido.
1.2. Ambito´ del Sistema..........................................................................3
1.3. Definiciones, Acronimos y Abreviaturas............................................3
1.4. Referencias......................................................................................4
1.5. Visi´on General del Documento........................................................4
2. Descripcion General..............................................................................4
2.1. Perspectiva del Producto..................................................................4
2.2. Funciones del Producto....................................................................4
2.3. Caracter´ısticas de los Usuarios.......................................................5
2.4. Restricciones....................................................................................5
2.5. Suposiciones y Dependencias..........................................................5
2.6. Requisitos Futuros............................................................................6
3. Requisitos Especıficos..........................................................................6
3.1. Interfaces Externas...........................................................................7
3.2. Funciones.........................................................................................7
3.3. Requisitos de Rendimiento...............................................................8
3.4. Restricciones de Disen˜o..................................................................9
3.5. Atributos del Sistema........................................................................9
3.6. Otros Requisitos...............................................................................9
4. Apendices...................................................¡Error! Marcador no definido.
Introducción
En esta sección se proporcionara una introducción a todo el documento de Especificación
de Requisitos Software (ERS). Consta de varias subsecciones: propósito, ámbito del
sistema, definiciones, referencias y visión general del documento.
Propósito
En esta subsección se definirá el propósito del documento ERS y se especificara a quien
va dirigido el documento.
Ámbito del Sistema

En esta subsección:
Se podrá dar un nombre al futuro sistema (p.ej. Mi Sistema)
Se explicar a lo que el sistema hará y lo que no hará.
Se describirán los beneficios, objetivos y metas que se espera alcanzar con el

futuro sistema.
Se referenciaran todos aquellos documentos de nivel superior (p.a. en Ingeniería de

Sistemas, que incluyen Hardware y Software, debería mantenerse la consistencia
con el documento de especificación de requisitos globales del sistema, si existe).
Definiciones, Acrónimos y Abreviaturas

En esta subsección se definirán todos los términos, acrónimos y abreviaturas utilizadas
en la ERS.
Referencias
En esta subsección se mostrar ‘a una lista completa de todos los documentos
referenciados en la ERS.
2 DESCRIPCION GENERAL
Visión General del Documento
Esta subsección describe brevemente los contenidos y la organización del resto de la
ERS.
Descripción General
En esta sección se describen todos aquellos factores que afectan al producto y a sus
requisitos. No se describen los requisitos, sino su contexto. Esto permitirá definir con
detalle los requisitos en la sección 3, haciendo que sean más fáciles de entender.
Normalmente, esta sección consta de las siguientes subsecciones: Perspectiva del
producto, funciones del producto, características de los usuarios, restricciones, factores
que se asumen y futuros requisitos.
Perspectiva del Producto

Esta subsección debe relacionar el futuro sistema (producto software) con otros
productos. Si el producto es totalmente independiente de otros productos, también debe
especificarse aquí. Si la ERS define un producto que es parte de un sistema mayor, esta
subsección relacionar ‘a los requisitos del sistema mayor con la funcionalidad del
producto descrito en la ERS, y se identificarán las interfaces entre el producto mayor y el
producto aquí descrito. Se recomienda utilizar diagramas de bloques.
Funciones del Producto

En esta subsección de la ERS se mostrar ‘a un resumen, a grandes rasgos, de las
funciones del futuro sistema. Por ejemplo, en una ERS para un programa de contabilidad,
esta subsección mostrar ‘a que el sistema soportara el mantenimiento de cuentas,
mostrara´ el estado de las cuentas y facilitar a la facturación, sin mencionar el enorme
detalle que cada una de estas funciones requiere.
Las funciones deberán mostrarse de forma organizada, y pueden utilizarse gráficos,
siempre y cuando dichos gráficos reflejen las relaciones entre funciones y no el diseño del
sistema.
2 DESCRIPCION GENERAL
Características de los Usuarios

Esta subsección describirá las características generales de los usuarios del producto,
incluyendo nivel educacional, experiencia y experiencia técnica.
Restricciones
Esta subsección describir a aquellas limitaciones que se imponen sobre los
desarrolladores del producto
Políticas de la empresa
Limitaciones del hardware
Interfaces con otras aplicaciones
Operaciones paralelas
Funciones de auditoría
Funciones de control
Lenguaje(s) de programación
Protocolos de comunicación
Requisitos de habilidad
Criticidad de la aplicación
Consideraciones acerca de la seguridad
Suposiciones y Dependencias
Esta subsección de la ERS describir ‘a aquellos factores que, si
cambian, pueden afectar a los requisitos. Por ejemplo, los
requisitos pueden presuponer una cierta organización de ciertas
unidades de la empresa, o pueden presuponer que el sistema
correr ‘a sobre cierto sistema operativo. Si cambian dichos
detalles en la organización de la empresa, o si cambian ciertos
detalles técnicos, como el sistema operativo, puede ser
necesario revisar y cambiar los requisitos.Requisitos Futuros
Esta subsección esbozara´ futuras mejoras al sistema, que podrán analizarse e

implementarse en un futuro.
Requisitos Específicos
Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a
los diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo
de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no,
los requisitos. Todo requisito aquí especificado describir ‘a comportamientos externos del
sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la
sección más larga e importante de la ERS. Deberán aplicarse los siguientes principios:
El documento debería ser perfectamente legible por personas de muy distintas

formaciones e intereses.
Deberán referenciarse aquellos documentos relevantes que poseen alguna influencia

sobre los requisitos.
Todo requisito deberá ser unívocamente identificable mediante algún código o

sistema de numeración adecuado.
Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las
siguientes características:
• Corrección: La ERS es correcta si y sólo si todo requisito que figura aquí (y

que será implementado en el sistema) refleja alguna necesidad real. La
corrección de la ERS implica que el sistema implementado será´ el sistema
deseado.
• No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la

ambigüedad inherente a los requisitos expresados en lenguaje natural, se
deberán utilizar gráficos o notaciones formales. En el caso de utilizar términos
que, habitualmente, poseen más de una interpretación, se definirán con
precisión en el glosario.
• Completos: Todos los requisitos relevantes han sido incluidos en la ERS.
Conviene incluir todas las posibles respuestas del sistema a los datos de
entrada, tanto valido como no válido.
• Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de
requisitos contradictorio no es implementarle.
• Clasificados: Normalmente, no todos los requisitos son igual de importantes.

Los requisitos pueden clasificarse por importancia (esencial, condicional u
opcional) o por estabilidad (cambios que se espera que afecten al requisito).
Esto sirve, ante todo, para no emplear excesivos recursos en implementar
requisitos no esenciales.
• Verificables: La ERS es verificable si y solo si todos sus requisitos son

verificables. Un requisito es verificable (testearle) si existe un proceso finito y
no costoso para demostrar que el sistema cumple con el requisito. Un requisito
ambiguo no es, en general, verificable. Expresiones como a veces, bien,
adecuado, etc. introducen ambigüedad en los requisitos. Requisitos como “en
caso de accidente la nube tóxica no se extenderá´ más allá de 25Km” no es
verificable por el alto costo que conlleva.
• Modificables: La ERS es modificable si y sólo si se encuentra estructurada de

forma que los cambios a los requisitos pueden realizarse de forma fácil,
completa y consistente. La utilización de herramientas automáticas de gestión
de requisitos facilitan enormemente esta tarea.
• Trazables: La ERS es trazable si se conoce el origen de cada requisito y se

facilita la referencia de cada requisito a los componentes del diseño y de la
implementación. La trazabilidad hacia atrás indica el origen (documento,
persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R
indica que componentes del sistema son los que realizan el requisito R.
Interfaces Externas
Se describirán los requisitos que afecten a la interfaz de usuario, interfaz con otros
sistemas (hardware y software) e interfaces de comunicaciones.
Funciones
Esta subsección (quizá´ la más larga del documento) deberá´ especificar todas
aquellas acciones (funciones) que deberá´ llevar a cabo el software. Normalmente
(aunque no siempre), son aquellas acciones expresables como “el sistema deberá...”. Si
se considera necesario, podrán utilizarse notaciones gráficas y tablas, pero siempre
supeditadas al lenguaje natural, y no al revés.
Es importante tener en cuenta que, en 1983, el Estándar de IEEE 830 establecía que
las funciones deberían expresarse como una jerarquía funcional (en paralelo con los
Dedos propuestos por el análisis estructurado). Pero el Estándar de IEEE 830, en sus
últimas versiones, ya permite organizar esta subsección de múltiples formas, y sugiere,
entre otras, las siguientes:
Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase
de usuario que exista en la organización, se especificaran los requisitos funcionales
que le afecten o tengan mayor relación con sus tareas.
Por objetos: Los objetos son entidades del mundo real que serán reflejadas en el
sistema. Para cada objeto, se detallaran sus atributos y sus funciones. Los objetos
pueden agruparse en clases. Esta organización de la ERS no quiere decir que el
diseño del sistema siga el paradigma de Orientación a Objetos.
Por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que
requiere una determinada entrada para obtener su resultado. Para cada objetivo o
su objetivo que se persiga con el sistema, se detallaran las funciones que permitan
llevarlo a cabo.
Por estímulos: Se especificaran los posibles estímulos que recibe el sistema y las
funciones relacionadas con dicho estimulo.
Por jerarquía funcional: Si ninguna de las anteriores alternativas resulta de ayuda, la

funcionalidad del sistema se especificar ‘a como una jerarquía de funciones que
comparten entradas, salidas o datos internos. Se detallaran las funciones (entrada,
proceso, salida) y las subsunciones del sistema. Esto no implica que el diseño del
sistema deba realizarse según el paradigma de Diseño Estructurado.
Para organizar esta subsección de la ERS se elegir ‘a alguna de las anteriores

alternativas, o incluso alguna otra que se considere más conveniente.
Deberá, eso sí, justificarse el porqué de tal elección.
4 APENDICES
Requisitos de Rendimiento
Se detallaran los requisitos relacionados con la carga que se espera tenga que soportar el
sistema. Por ejemplo, el número de terminales, el número esperado de usuarios
simultáneamente conectados, número de transacciones por segundo que deberá soportar
el sistema, etc.
También, si es necesario, se especificaran lo requisitos de datos, es decir, aquellos
requisitos que afecten a la información que se guardara´ en la base de datos. Por
ejemplo, la frecuencia de uso, las capacidades de acceso y la cantidad de registros que
se espera almacenar (decenas, cientos, miles o millones).
Restricciones de Diseño
Todo aquello que restrinja las decisiones relativas al diseño de la aplicación: Restricciones
de otros estándares, limitaciones del hardware, etc.
Atributos del Sistema

Se detallarán los atributos de calidad (las “elites”) del sistema: Fiabilidad, mantenibilidad,
portabilidad, y, muy importante, la seguridad. Deberá´ especificarse que tipos de usuario
están autorizados, o no, a realizar ciertas tareas, y como se implementarán los
mecanismos de seguridad (por ejemplo, por medio de un login y una pastor).
Otros Requisitos
Cualquier otro requisito que no encaje en otra sección.
Apéndices
Pueden contener todo tipo de información relevante para la ERS pero que, propiamente,
no forme parte de la ERS. Por ejemplo:
1. Formatos de entrada/salida de datos, por pantalla o en listados.
2. Resultados de análisis de costes.
3. Restricciones acerca del lenguaje de programación.
CONCLUSION
 El estándar IEEE 830 es muy útil para la recolección de información de los

requisitos al momento de elaborar un sistema, debido a que contrario a
otros tiene un formato más reducido, específico y valedero. Por lo que se
vuelva en una buena herramienta a pesar de que no es obligatorio seguir
esta regla.
RECOMENDACIÓN
 Ver ejemplos de proyectos utilizando este tipo de estándar, pudiendo así
notar más cualquier falencia que el mismo contenga.
TAREA EXTRACLASE

ENVIO: ENTREGA:
TEMA: - Puntos de Fusión

OBJETIVO: - Determinar los puntos de Fusión del ejercicio “marketECUADOR”
PROBLEMA: - ¿Cómo determinar los puntos de fusión del ejercicio planteado?

de la profesión.
- Comprensión de sus responsabilidades profesionales y éticas.
- Comunicación Efectiva
(100%) (75%) (10%)
EN EXPOSICIONES

EN IMPRESOS
 Entrega documentación impresa y digital. (Siguiendo las normas y convenciones para la escritura
 Cumple con el formato, normas y estructura para la elaboración del documento .

USO DE RECURSOS:



TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA

Extraclase
- ERIKA TINOCO Investiga Investiga las normas del estándar.
- LUIS TOBAR Interpreta Interpreta la información y determina

resultado.
TÉCNICAS EMPLEADAS
Investigación, lectura, resumen.

DESARROLLO DE LA ACTIVIDAD
INTRODUCCION
Los puntos de fusión son un método de estimación contempla la aplicación a desarrollar
como una caja negra, es decir, no se interesa por las interioridades de la aplicación, sino que
se centra en lo que puede ver el usuario.
En el siguiente documento se determinan los puntos de fusión del ejercicio Marquet
Ecuador.
MARCO TEORICO
PUNTOS DE FUSION
FUNCIONES DE DATOS:
 Archivo Lógico Interno ILF – es un grupo de datos relacionados que el usuario

identifica, cuyo propósito principal es almacenar datos mantenidos a través de alguna
transacción que se está considerando en el conteo.
 Archivo de Interfaz Externo EIF - es un grupo de datos relacionados y referenciados

pero no mantenido por alguna transacción dentro del conteo.
A cada componente identificado se le asigna una complejidad (bajo, medio o alto)
considerando principalmente el número de datos.
FUNCIONES TRANSACCIONALES:
Este paso consiste en identificar y contar la capacidad de realizar operaciones Se distinguen

tres tipos de funciones transaccionales:
 Entrada Externa EI – es un proceso cuyo propósito principal es mantener uno más

archivos lógicos internos.
 Salida Externa EO – es un proceso cuyo propósito principal es presentar

información al usuario mediante un proceso lógico diferente al de sólo recuperar los
datos.
 Consulta Externa EQ – es un proceso cuyo propósito principal es presentar

información al usuario leída de uno o más grupos de datos.
METODOLOGIA
Las técnicas de investigación para el desarrollo del presente informe fueron: búsqueda de
información, análisis, resumen.
SOLUCIÓN
1. Se determina los ILF
CONTEOS DE PUNTOS DE FUNCION ARCHIVOS LOGICOS INTERNO

FICHEROS LÓGICOS NÚMERO NÚMERO
ERS INTERNOS
DET DE DET DE RET
COMPLEJIDAD
NumPedido FechaPedido
REQ-01.1 Ficha de Pedido CodigoProducto, Descripcion, Unidad, 7 2 BAJA
Cantidad, TotalItems
Id Producto, IdCategoria, Idproveedor,

Stock Actual, Nombres ,Unidad Medida,
REQ-01.5 Ficha de producto Precio Proveedor, Costo Iva, Precio 11 2 BAJA
Venta, Utilidad, Stock Mínimo
REQ-01.9 Ficha de Categoria IdCategoría, Nombre, detalle 3 1 BAJA

Id Proveedor, Código proveedor,
REQ-01.13 Ficha de Proveedor Nombres, Representante, Dirección, 8 2 BAJA
Ciudad, Departamento, Teléfono.
IdLocal, Dirección, Distrito, Teléfono,

Ficha de Local Fax 5 2 BAJA
REQ-01.17
IdGuia, IdLocal, IdTrans, IdProducto,
REQ-02.1 Ficha de Guia IdNumPedido, fechaSalida, PVP, 9 2 BAJA
Cantidad, Total de Items Despachados
Ficha de Idtrans, Cedtrans, Nombres, Dirección,

REQ-02.05 Teléfono. 5 1 BAJA
Transportista
IdOrden, IdProveedor, Fecha Ingreso,
Ficha de Orden
REQ-03.1 Fecha Emisión, IdProducto, Cantidad 8 2 BAJA
(Solicitud) Solicitada, Precio Proveedor
Ficha de Orden Cantidad Recibida, PrecioCompra,

REQ-04.1 Estado 3 1 BAJA
(Recepcion)
2. Se determina las EI
CONTEOS DE PUNTOS DE FUNCION ENTRADAS EXTERNAS

NÚMERO NÚMERO DE
ERS ENTRADAS EXTERNAS PESO COMPLEJIDAD
DE DET FTR
REQ-01.1 Insertar Pedido 8 1 3 BAJA
REQ-01.2 Modificar Pedido 8 1 3 BAJA
REQ-01.3 Eliminar Pedido 8 1 3 BAJA
REQ-01.5 Insertar Producto 12 1 3 BAJA
REQ-01.6 Modificar Producto 12 1 3 BAJA
REQ-01.7 Eliminar Producto 12 1 3 BAJA
REQ-01.9 Insertar Categoria 4 1 3 BAJA
REQ-
01.10
Modificar Categoria 4 1 3 BAJA
REQ-
01.11
Eliminar Categoria 4 1 3 BAJA
REQ-
01.13
Insertar Proveedor 9 1 3 BAJA
REQ-
01.14
Modificar Proveedor 9 1 3 BAJA
REQ-
01.15
Eliminar Proveedor 9 1 3 BAJA
REQ-
01.17
Insertar Local 6 1 3 BAJA
REQ-
01.18
Modificar Local 6 1 3 BAJA
REQ-
01.19
Eliminar Local 6 1 3 BAJA
REQ-02.1 Insertar Guia 9 1 3 BAJA
REQ-02.2 Modificar Proveedor 9 1 3 BAJA
REQ-02.3 Eliminar Proveedor 9 1 3 BAJA
REQ-02.5 Insertar Transportista 6 1 3 BAJA
REQ-02.6 Modificar Transportista 6 1 3 BAJA
REQ-02.7 Eliminar Transportista 6 1 3 BAJA
REQ-03.1 Insertar Orden Compra (Solicitud) 9 1 3 BAJA
REQ-03.2 Modificar Orden Compra (Solicitud) 9 1 3 BAJA
REQ-03.3 Eliminar Orden Compra (Solicitud) 9 1 3 BAJA
REQ-04.1 Modificar Orden Compra (Recepcion) 4 1 3 BAJA
REQ-04.2 Eliminar Orden Compra (Recepcion) 4 1 3 BAJA
3. Se determina los EO
CONTEOS DE PUNTOS DE FUNCION SALIDAS EXTERNAS

ERS SALIDAS EXTERNAS SOPORTE NÚMERO NÚMER APORTE COMPLEJIDAD
DE SALIDA DE DET O DE
Pantalla/
Req 01(1-2) Reporte de Pedido Impresora 7 2 5 MEDIA
Pantalla/
Req 01(5-6) Reporte de Producto Impresora 11 3 5 MEDIA
Pantalla/
Req 01(9-10) Reporte de Categoria Impresora 3 1 4 BAJA
Pantalla/
Req 01(13-14) Reporte Proveedor Impresora 8 1 4 BAJA
Pantalla/
Req 01(17-18) Reporte de Guia Impresora 9 5 7 ALTA
Pantalla/
Req 02(1-2) Reporte de Local Impresora 5 1 4 BAJA
Pantalla/
Reporte de
Req02 (5-6) Impresora 5 1 4 BAJA
Tranportista
Pantalla/
Reporte de orden
Req 03 (1) Impresora 8 3 5 MEDIA
solicitud
Pantalla/
Reporte de orden
Req 04(1-2) Impresora 3 1 4 BAJA
Recepcion
4. Se determina los EQ
CONTEOS DE PUNTOS DE FUNCION CONSULTAS EXTERNAS
SOPORTE NÚMERO NÚMERO
ERS SALIDAS EXTERNAS APORTE COMPLEJIDAD
DE SALIDA DE DET DE FTR
REQ-01.4 Encontrar Pedido (Entrada) Pantalla 2 2 3 BAJA
REQ-01.1 Encontrar Pedido (Salida) Pantalla 7 2 4 MEDIA
REQ-01.8 Encontrar Producto (Entrada) Pantalla 2 3 3 BAJA
REQ-01.5 Encontrar Producto (Salida) Pantalla 11 3 6 ALTA
REQ-01.12 Encontrar Categoria (Entrada) Pantalla 2 1 3 BAJA
REQ-01.9 Encontrar Categoria (Salida) Pantalla 3 1 3 BAJA
REQ-01.16 Encontrar Proveedor (Entrada) Pantalla 2 1 3 BAJA
REQ-01.13 Encontrar Proveedor (Salida) Pantalla 8 1 3 BAJA
REQ-01.20 Encontrar Local (Entrada) Pantalla 2 1 3 BAJA
REQ-01.17 Encontrar Local (Salida) Pantalla 5 1 3 BAJA
REQ-02.4 Encontrar Guia (Entrada) Pantalla 2 1 3 BAJA
REQ-02.1 Encontrar Guia (Salida) Pantalla 9 1 3 BAJA
Encontrar Transportista
REQ-02.08 Pantalla
(Entrada) 2 1 3 BAJA
REQ-02.05 Encontrar Transportista (Salida) Pantalla 5 1 3 BAJA
REQ-03.4 Encontrar Orden de Compra Pantalla
REQ-04.4 (Entrada) 2 1 3 BAJA
REQ-03.1 Encontrar Orden de Compra
Pantalla
REQ-04.1 (Salida) 10 1 3 BAJA
5. Determinamos los PUNTOS DE FUSIÓN
PARAMETR COMPLEJIDAD NUMERO X PESO Total

O
ALTA 0 X 15 0
ILF MEDIA 0 X 10 0
BAJA 9 X 7 63
ALTA 0 X 10 0
EIF MEDIA 0 X 7 0
BAJA 0 X 5 0
ALTA 0 X 6 0
EI MEDIA 0 X 4 0
BAJA 26 X 3 78
EO ALTA 1 7 7
MEDIA 3 X 5 15
BAJA 5 X 4 20
ALTA 1 X 6 6
EQ MEDIA 1 X 4 4
BAJA 14 X 3 42
Total 235
6. Determinamos el nivel de Influencia
Características generales del sistema Nivel de influencia

1- Comunicación de datos 4
2- Procesamiento distribuido 0
3- Perfomance (desempeño) 0
4-Configuración del equipamiento 1
5- Volumen de transacciones 1
6- Entrada de datos on-line 5
7- Interfase con el usuario 1
8- Actualización on-line 5
9- Procesamiento complejo 0
10- Reusabilidad 0
11-Facilidad de implementación 0
12- Facilidad de operación 0
13- Múltiples locales 0
14- Facilidad de cambios 0
Nivel de influencia 17
CONCLUSIONES Y RECOMENDACIONES
- Se concluye que al determinar los elementos de los puntos de fusión, la cantidad de
RETS y DETS dependerá de la perspectiva del analista
- Se recomienda analizar e identificar lo más aproximado en cuanto al nivel de influencia

se refiere.
TAREA EXTRACLASE

ENVIO: ENTREGA:
TEMA: - PUNTOS DE FUSION AJUSTADOS

UNIDAD N° 1:
- “DEL ANÁLISIS AL DISEÑO”
- Determinar los puntos de Fusión Ajustados del ejercicio
OBJETIVO:
“marketECUADOR”
- ¿Cómo determinar los puntos de fusión Ajustados del ejercicio

PROBLEMA:
planteado?
de la profesión.
(100%) (75%) (10%)
EN EXPOSICIONES

EN IMPRESOS

USO DE RECURSOS:



TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA

Extraclase

resultado.
TÉCNICAS EMPLEADAS

PUNTOS DE FUSION AJUSTADOS
Puntos de Fusión Sin Ajustar 235

Factor de Ajuste 0,82
Puntos de Fusión Ajustados 192,7
Esfuerzo Total = Tam App/Prod.Equip 1541,6
Calculo del Esfuerzo: (LOCS = PFA*LCPF) 3854
Duración 15
Costo Total de Proyecto (sueldo que
$ 10.791,20
percibe*número de personas*cuantos meses)
TAREA EXTRACLASE
ENVIO: ENTREGA:
TEMA: - CASOS DE USO

UNIDAD N° 2:
- “CASOS DE USO REALES Y DISEÑO DE LA INTERFAZ”
- Determinar el primer nivel de casos de uso del ejercicio “Marquet
OBJETIVO:
ECUADOR”
PROBLEMA: - ¿Cómo determinar los casos de uso del ejercicio planteado?

de la profesión.
(100%) (75%) (10%)
EN EXPOSICIONES

EN IMPRESOS

USO DE RECURSOS:



TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA

Extraclase

resultado.
TÉCNICAS EMPLEADAS

INTRODUCCION
En el proceso de desarrollo de un proyecto informático uno de los diagramas
dinámicos que conforman parte de los entregables es el Desgrama de Casos de
Uso. En el presente informe se presenta los casos de uso correspondiente al
primer novel del ejercicio que se ha venido desarrollando Marquet Ecuador.
MARCO TEORICO
Casos de Uso
¿Qué es?
Todo sistema tiene como mínimo un diagrama de caso de uso que es una representación
gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso).
Un diagrama de casos de uso muestra, los distintos requisitos funcionales que se esperan de
una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones).
METODOLOGIA
Las técnicas de investigación para el desarrollo del presente informe fueron: búsqueda de
información, análisis, resumen.
SOLUCIÓN
1. CASOS DE USO
1.1 DIAGRAMA DE CASO DE USO GENERAL (NIVEL 1)
DESCRIPCION DE LOS CASOS DE USO
1. REPOSICION DE MERCADERIA
Escenario que consiste en generar una orden de pedido al almacén central, el responsable de
realizar estas acciones es el Despachador de cada Local.
2. DESPACHO DE MERCADERIA
Consiste en recibir la solicitud de pedido, verificar el stock y realizar el despacho. Estas
acciones son realizadas por el bodeguero, en caso de los productos existentes genera la
guía.
3. SOLICITUD DE MERCADERIA
Permite la gestión de órdenes de compra. Estas acciones pueden ser realizadas por el
Bodeguero, en caso de que no haya tenido los productos solicitados, luego lo envía al jefe
de compras para que sea revisado y llegue a un acuerdo con el proveedor acerca de los
precios; el proveedor recibe la orden y llena los campos de cantidad y estado, luego los
envía al despacho de mercadería.
4. RECEPCION DE MERCADERIA
Consiste en que el almacén recibe la mercadería despachada por el proveedor. El encardo es
el bodeguero que procede a actualizar su stock.
DESCRIPCION DE ACTORES
Nombre de Actor: Administrador

Definición: Es el encargado de administrar el sistema. Tendrá los permisos de
libertad y movimiento por el sistema.
Notas: - El administrador es el encargado de manipular la información
contenida en el sistema.
- Tiene acceso a toda la información del sistema y es el único que
puede modificar todo lo que desee.
Nombre de Actor: Despachador

Definición: Es el encargado de generar una orden de pedido con los productos
que se necesitan reponer en el local y luego enviarlo al almacén
central para su despacho.
Notas: - El despachador puede gestionar nuevo pedidos y luego presentar
los datos de los mismos.
- El no despachador no le está permitido eliminar la orden de
pedido.
Nombre de Actor: Bodeguero

Definición: Es el encargado de recibir la orden de pedido, revisar su stock y
genera la guía de productos existentes, si no cuenta con algún
producto genera una orden de pedido al departamento de compras.
Notas: - Al bodeguero no le está permitido eliminar los pedidos.
- El bodeguero además debe recibir la orden de pedido enviada por
el proveedor y actualizar su stock.
Nombre de Actor: Jefe de compras

Definición: Es el encargado de recibir la orden de pedido, comunicarse con el
proveedor para negociar los precios, luego envía la orden; el
proveedor deberá llenar los campos de cantidad y estado de acuerdo a
su stock.
Notas: - El jefe de compras únicamente debe llenar campos de orden.
Nombre de Actor: Proveedor

Definición: Es el encargado de recibir la orden de pedido revisada por la jefa de
compras, y procede a llenar los campos de cantidad y estado de
acuerdo a su stock.
Notas: - El proveedor únicamente debe llenar campos de cantidad y
estado.
1.1.1 DIAGRAMA DE CASO DE USO GENERAL/REPOSICION DE

MERCADERIA
1.1.2 DIAGRAMA DE CASO DE USO GENERAL/DESPACHO DE

MERCADERIA
1.1.3 DIAGRAMA DE CASO DE USO GENERAL/SOLICITUD DE
MERCADERIA
1.1.4 DIAGRAMA DE CASO DE USO GENERAL/RECEPCION DE

MERCADERIA
TAREA EXTRACLASE

ENVIO: ENTREGA:
TEMA: - CASOS DE USO

UNIDAD N° 2:
- “CASOS DE USO REALES Y DISEÑO DE LA INTERFAZ”
- Determinar el segundo nivel y expandido de casos de uso del
OBJETIVO:
ejercicio “Marquet ECUADOR”
PROBLEMA: - ¿Cómo determinar los casos de uso del ejercicio planteado?

de la profesión.
(100%) (75%) (10%)
EN EXPOSICIONES

EN IMPRESOS

USO DE RECURSOS:



TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA

Extraclase

resultado.
TÉCNICAS EMPLEADAS

1.2 DIAGRAMA DE CASO DE USO A DETALLE Y CASOS DE USO EXPANDIDOS
REPOSICIÓN DE MERCADERÍA REQ-01
ADMINISTRAR PEDIDO (REQ-01.1 – REQ-01.2)
INSERTAR NUEVO PEDIDO - REQ-01.1
CASO DE USO: Insertar Nuevo Pedido
ACTORES: Administrador, bodeguero.
TIPO: Esencial primario.
Generar una orden de pedido con los productos que se

PROPÓSITO: necesitan reponer en el local y luego enviarlo al
almacén central para su despacho.
La interacción comienza cuando el responsable del

DESCRIPCIÓN inventario genera un pedido con los datos solicitados
GENERAL: en el REQ-01 y es enviado al almacén central para el
despacho de dicho pedido.
REFERENCIAS: Ninguno.
FLUJO PRINCIPAL
1. El actor selecciona en el menú nuevo pedido 2. Sistema limpia y activa los cuadros de
de reposición de mercadería. textos con la respectiva información
solicitada (número de pedido y fecha de
pedido) para permitir el ingreso de los
productos solicitados.
3. El actor busca e ingresa los productos 4. El sistema valida que no exista código
solicitados. de productos repetidos y permite el
ingreso de la cantidad solicitada.
Además va generando la cantidad de
5. El actor ingresa la cantidad requerida. ítems.
6. El sistema valida datos ingresados por

el actor y genera la nota de pedido.
7. El actor envía la nota de pedido al almacén
central y sale de la opción.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error productos repetidos.
R6: Imprimir nota de pedido si el actor lo requiere.
Insertar Nuevo Pedido

MODIFICAR PEDIDO - REQ-01.2
CASO DE USO: Modificación de Pedido
Modificar una orden de pedido con los productos que

PROPÓSITO: se fueron insertados para luego enviarlo al almacén
central para su despacho.

inventario desea realizar alguna modificación del
DESCRIPCIÓN pedido con los datos solicitados en el REQ-01.1 y es
GENERAL: enviado al almacén central para el despacho de dicho
pedido.
FLUJO PRINCIPAL
1. El actor selecciona el pedido y luego presiona en 2. Sistema limpia y activa los cuadros
el menú modificar pedido de reposición de de textos con la información respectiva
mercadería. del pedido para permitir la
modificación del mismo.
3. El actor realiza la modificación respectiva. 4. El sistema valida que no exista
código de productos repetidos y
permite la modificación del mismo.
5. El actor graba la modificación respectiva. 6. El sistema valida datos ingresados
por el actor y genera la nueva nota de
pedido.
7. El actor envía la nota de pedido al almacén
central y sale de la opción.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
Modificar Pedido
ELIMINAR PEDIDO - REQ-01.3
CASO DE USO: Eliminar Pedido
ACTORES: Administrador.
TIPO: Opcional.
PROPÓSITO: Eliminar una orden de pedido con los productos que se

fueron insertados.
DESCRIPCIÓN La interacción comienza cuando el responsable del

GENERAL: inventario desea eliminar algún pedido.
FLUJO PRINCIPAL
1. El actor selecciona el pedido y luego 2. Sistema presenta un mensaje de

presiona en el menú eliminar pedido de advertencia si está seguro de eliminar la
reposición de mercadería. orden de pedido.
3. El actor confirma la eliminación. 4. El sistema valida y elimina el pedido y
presenta un mensaje de proceso realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R2: Presentar mensaje de advertencia en caso de negar no realizar proceso.
R4: Verificar datos de productos antes de eliminar pedido.
Eliminar Pedido
CONSULTAR PEDIDO – REQ-01.4
CASO DE USO: Consultar Pedido
ACTORES: Administrador, Bodeguero
TIPO: Esencial secundario.
PROPÓSITO: Consultar una orden de pedido con los productos que se

fueron insertados.
DESCRIPCIÓN La interacción comienza cuando el administrador

GENERAL: desea consultar algún pedido.
FLUJO PRINCIPAL
1. El actor ingresa el número de pedido o la 2. Sistema presenta los resultados de la

fecha de pedido y selecciona la opción de búsqueda
búsqueda, luego presiona buscar pedido de
reposición de mercadería.
3. El actor selecciona el pedido que deseaba 4. Presenta datos de pedido

consultar.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R2: Presentar mensaje de advertencia en caso de que no haya resultados de la búsqueda.
R4: Verificar los datos ingresados antes de hacer la búsqueda antes de consultar pedido.
Consultar Pedido
ADMINISTRAR PRODUCTO (REQ-01.5 – REQ-01.8)
INSERTAR NUEVO PRODUCTO - REQ-01.5
CASO DE USO: Insertar producto
TIPO: Primario.
Inserta al producto con sus respectivos datos, para

PROPÓSITO: luego generar los documentos en que se requiera el ID
de producto.

DESCRIPCIÓN
inventario inserta un nuevo producto con los datos
GENERAL:
solicitados en el REQ-01.5.
REFERENCIAS: REQ-01.9.
FLUJO PRINCIPAL
1. El actor selecciona en el menú nuevo 2. Sistema limpia y activa los cuadros de

producto de reposición de mercadería. textos con la respectiva información
solicitada para permitir el ingreso de los
3. El actor ingresa los datos solicitados. datos de los productos solicitados.
4. El sistema valida que no exista código de
productos existentes y permite el ingreso de
5. El actor graba los nuevos datos. los datos solicitados.
6. El sistema valida datos ingresados por el

actor y graba los nuevos datos del producto.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error avisando en caso de que ya exista el producto con este
código.
Insertar Nuevo Producto

MODIFICAR PRODUCTO - REQ-01.6
CASO DE USO: Modificar Producto
TIPO: Primario.
PROPÓSITO: Modificar los datos del producto seleccionado.

inventario desea realizar alguna modificación de los
DESCRIPCIÓN
datos del producto con los datos
GENERAL:
solicitados en el REQ-01 y es enviado al almacén
central para el despacho de dicho pedido.
FLUJO PRINCIPAL
1. El actor selecciona el producto y luego presiona 2. Sistema limpia y activa los cuadros
en el menú modificar producto de reposición de de textos con la información respectiva
por el actores e ingresa los datos y
presenta mensaje de proceso realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R6: Su surgió algún error al guardar los datos, se presenta un mensaje de aviso.
Modificar Producto
ELIMINAR PRODUCTO - REQ-01.7

CASO DE USO: Eliminar reposición mercadería
TIPO: Opcional.
PROPÓSITO: Eliminar una orden de pedido con los productos que se

fueron insertados.

GENERAL: inventario desea eliminar algún pedido.
FLUJO PRINCIPAL
1. El actor selecciona el producto y luego presiona 2. Sistema presenta un mensaje de

en el menú eliminar producto de reposición de advertencia si está seguro de eliminar
mercadería. la orden de pedido.
4. El sistema valida y elimina el
3. El actor confirma la eliminación. pedido y presenta un mensaje de
proceso realizado.
5. El actor presionara confirmación.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar datos de productos antes de eliminar pedido.
Eliminar Producto
CONSULTAR PRODUCTO - REQ-01.8
CASO DE USO: Modificar Producto
TIPO: Primario.
PROPÓSITO: Modificar los datos del producto seleccionado.

inventario desea realizar alguna modificación de los
DESCRIPCIÓN
datos del producto con los datos
GENERAL:
solicitados en el REQ-01 y es enviado al almacén
central para el despacho de dicho pedido.
FLUJO PRINCIPAL
1. El actor ingresa el nombre de producto y 2. El sistema presente los resultados de

selecciona la opción de búsqueda, luego presiona la búsqueda.
buscar producto de reposición de mercadería.
3. El actor selecciona el producto que desea
consultar.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R6: Su surgió algún error al guardar los datos, se presenta un mensaje de aviso.
Consultar Producto
ADMINISTRAR CATEGORÍA (REQ-01.9 – REQ-01.12)

INSERTAR NUEVA CATEGORÍA - REQ-01.9
CASO DE USO: Insertar Categoría.
TIPO: Primario.
PROPÓSITO: Inserta los nuevos datos de la categoría que clasifica a

los productos.

DESCRIPCIÓN
inventario inserta una nueva categoría con los datos
GENERAL:
REFERENCIAS: Ninguna.
FLUJO PRINCIPAL
Acción del Actor Respuesta del Sistema

2. Sistema limpia y activa los cuadros de
1. El actor selecciona en el menú nueva textos con la respectiva información
categoría de la reposición de mercadería. solicitada (IdCategoria, se autogenera
incrementalmente) para permitir el ingreso
3. El actor ingresa los datos solicitados.
de los datos solicitados.
5. El actor guarda los datos ingresados. actor.
6. El sistema guarda los datos y envía
mensaje de proceso finalizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error en el ingreso de los datos.
Insertar Nueva Categoría
MODIFICAR CATEGORÍA - REQ-01.10
CASO DE USO: Modificar Categoría

TIPO: Primario.
PROPÓSITO: Modificar los datos de la categoría que fueron

insertados.

DESCRIPCIÓN
inventario desea realizar alguna modificación de la
GENERAL:
categoría con los datos solicitados en el REQ-01.9.
FLUJO PRINCIPAL

1. El actor selecciona la categoría y luego presiona 2. Sistema limpia y activa los cuadros
en el menú modificar categoría de reposición de de textos con la información respectiva
mercadería. de la categoría para permitir la
modificación de la misma.
código de categorías repetidos y
5. El actor graba la modificación respectiva.
6. El sistema valida datos ingresados
por el actor y presenta un mensaje de
proceso finalizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error categorías repetidas.
Modificar Categoría
ELIMINAR CATEGORÍA - REQ-01.11
CASO DE USO: Eliminar Categoría.
TIPO: Opcional.
PROPÓSITO: Eliminar una categoría especificada.
La interacción comienza cuando el administrador

DESCRIPCIÓN
desea dar de baja alguna categoría que no esté activa
GENERAL:
o siendo usada con ningún producto.
REFERENCIAS: REQ-01.9
FLUJO PRINCIPAL
1. El actor selecciona la categoría y luego presiona 2. Sistema presenta un mensaje de

en el menú eliminar categoría de reposición de advertencia si está seguro de eliminar
mercadería. la orden de pedido.
4. El sistema valida y elimina la
3. El actor confirma la eliminación. categoría y presenta un mensaje de
proceso realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar si el id de la categoría no está siendo usada por ningún producto activo, antes
de eliminar categoría.
Eliminar Categoría
CONSULTAR CATEGORÍA - REQ-01.11
CASO DE USO: Consultar Categoría
TIPO: Secundario.
PROPÓSITO: Consultar una categoría en específico.

GENERAL: desea consultar alguna categoría.
FLUJO PRINCIPAL

1. El actor ingresa el id o nombre de la 2. Sistema presenta los resultados de la
categoría a buscar y selecciona la opción de búsqueda.
búsqueda, luego presiona buscar categoría de
3. El actor selecciona la categoría que deseaba
consultar. 4. Muestra Datos
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R1: Verificar los datos ingresados para la consulta antes de consultar categoría.
Consultar Categoría
ADMINISTRAR PROVEEDOR (REQ-01.13 – REQ-01.16)
INSERTAR NUEVO PROVEEDOR - REQ-01.13
CASO DE USO: Insertar Proveedor.
TIPO: Primario.
PROPÓSITO: Insertar los nuevos datos del proveedor.

DESCRIPCIÓN
inventario inserta un nuevo proveedor con los datos
GENERAL:
FLUJO PRINCIPAL

proveedor de la reposición de mercadería. textos con la respectiva información
solicitada (IdProveedor, se autogenera
3. El actor ingresa los datos solicitados. incrementalmente) para permitir el
ingreso de los datos solicitados.
5. El actor guarda los datos ingresados. el actor.
6. El sistema guarda los datos y envía
mensaje de proceso finalizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error en el ingreso de los datos incorrectamente.

Insertar Nuevo Proveedor
MODIFICAR PROVEEDOR - REQ-01.14
CASO DE USO: Modificar Proveedor

TIPO: Primario.
PROPÓSITO: Modificar los datos del proveedor que fueron

insertados.

DESCRIPCIÓN
GENERAL:
proveedor con los datos solicitados en el REQ-01.13.
FLUJO PRINCIPAL
1. El actor selecciona el proveedor y luego presiona 2. Sistema limpia y activa los cuadros
en el menú modificar proveedor de reposición de de textos (excepto del ID) con la
mercadería. información respectiva del proveedor
para permitir la modificación del
3. El actor realiza la modificación respectiva. mismo.
4. El sistema valida que no exista
cedula de proveedor repetidos y

por el actor y presenta un mensaje de
proceso finalizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error proveedores con la misma cedula.
Modificar Categoría
ELIMINAR PROVEEDOR - REQ-01.15
CASO DE USO: Eliminar Proveedor.
TIPO: Opcional.
PROPÓSITO: Eliminar un proveedor especificado.

GENERAL: desea dar de baja algún proveedor.
FLUJO PRINCIPAL
1. El actor selecciona el proveedor y luego presiona 2. Sistema presenta un mensaje de

en el menú eliminar proveedor de reposición de advertencia si está seguro de eliminar
mercadería. al proveedor.
3. El actor confirma la eliminación. 4. El sistema valida y elimina el

proveedor y presenta un mensaje de
proceso realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar si el id de la proveedor no está siendo usada en ninguna de las ordenes de

pedido, antes de eliminar el proveedor.
Eliminar Proveedor
CONSULTAR PROVEEDOR - REQ-01.16
CASO DE USO: Consultar Proveedor.
TIPO: Secundario.
PROPÓSITO: Consultar un proveedor en específico.

GENERAL: desea consultar algún proveedor.
FLUJO PRINCIPAL
1. El actor ingresa el id, nombre o representante 2. Sistema presenta los resultados de la

del proveedor y selecciona la opción de búsqueda.
búsqueda, luego presiona buscar proveedor de
3. El actor selecciona el proveedor que deseaba

4. Muestra Datos de Proveedor
consultar.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R1: Verificar los datos ingresados para la consulta antes de consultar proveedor.
Consultar Proveedor
ADMINISTRAR LOCAL (REQ-01.17 – REQ-01.20)
INSERTAR NUEVO LOCAL - REQ-01.17
CASO DE USO: Insertar Local.
TIPO: Primario.
PROPÓSITO: Insertar los nuevos datos del local.

DESCRIPCIÓN
inventario inserta un nuevo local con los datos
GENERAL:
FLUJO PRINCIPAL

1. El actor selecciona en el menú nuevo local de 2. Sistema limpia y activa los cuadros de
la reposición de mercadería. textos con la respectiva información
solicitada (IdLocal, se autogenera
incrementalmente) para permitir el
3. El actor ingresa los datos solicitados. ingreso de los datos solicitados.
5. El actor guarda los datos ingresados. 4. El sistema valida datos ingresados por
el actor.
6. El sistema valida y guarda los datos y
envía mensaje de proceso finalizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error en el ingreso de los datos incorrectamente.

Insertar Nuevo Local
MODIFICAR LOCAL - REQ-01.18
CASO DE USO: Modificar Local
TIPO: Primario.
PROPÓSITO: Modificar los datos del local que fueron insertados.

DESCRIPCIÓN
GENERAL:
local con los datos solicitados en el REQ-01.17.
FLUJO PRINCIPAL
1. El actor selecciona el local y luego presiona en el 2. Sistema limpia y activa los cuadros
menú modificar local de reposición de mercadería. de textos (excepto del ID) con la
información respectiva del local para
3. El actor realiza la modificación respectiva. permitir la modificación del mismo.
4. El sistema valida los datos.
6. El sistema guarda los datos y
presenta un mensaje de proceso
finalizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error si existe error al ingresar los datos del local.
Modificar Local
ELIMINAR LOCAL - REQ-01.19
CASO DE USO: Eliminar Local.
TIPO: Opcional.
PROPÓSITO: Eliminar un local especificado.

GENERAL: desea dar de baja algún local.
FLUJO PRINCIPAL
1. El actor selecciona el local y luego presiona 2. Sistema presenta un mensaje de

en el menú eliminar local de reposición de advertencia si está seguro de eliminar al
mercadería. local.
4. El sistema valida y elimina el local y
3. El actor confirma la eliminación. presenta un mensaje de proceso realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar si el id de la local no está siendo usado en ningún otro proceso o información.
Eliminar Local
CONSULTAR LOCAL - REQ-01.20
CASO DE USO: Consultar Local.
ACTORES: Administrador
TIPO: Secundario.
PROPÓSITO: Consultar un local en específico.

GENERAL: desea consultar algún local.
FLUJO PRINCIPAL
1. El actor ingresa el id o ciudad del local y 2. Sistema presenta los resultados de

selecciona la opción de búsqueda, luego presiona la búsqueda
buscar local de reposición de mercadería.
3. El actor selecciona la local que deseaba consultar. 4. Mostrar Local.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R1: Verificar los datos ingresados para la consulta antes de consultar local.
Consultar Local
DESPACHO DE MERCADERÍA REQ-02
ADMINISTRAR GUÍA DE REMISIÓN (REQ-02.1 – REQ-02.4)
INSERTAR NUEVA GUÍA DE REMISIÓN - REQ-02.1
CASO DE USO: Insertar Guía de Remisión
Generar una Guía de Remisión con los productos de la

PROPÓSITO: orden de pedido que se tiene a su disposición en el
principal.

GENERAL: despacho de mercadería genera una Guía de
Remisión REQ-02.1 para luego despachar al local
respectivo los productos de la guía.
REFERENCIAS: REQ-01.17, REQ-02.5, REQ-01.5, REQ-01.1.
FLUJO PRINCIPAL
1. El actor selecciona en el menú nuevo Guía de 2. Sistema limpia y activa los cuadros de
Remisión de despacho de mercadería. textos con la respectiva información
solicitada (número de guía y fecha de
pedido) para permitir el ingreso de los
demás datos solicitados.
3. El actor busca e ingresa el Id del Local, Id del 4. El sistema valida que no exista código
Transportista, Id del Pedido, los productos de productos repetidos y permite el
solicitados, fecha de Salida. ingreso de la cantidad solicitada.
Además va generando la cantidad de
5. El actor ingresa la cantidad requerida, el PVP.
ítems.

el actor y genera la guía de remisión
para luego proceder al despacho.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R6: Imprimir guía de remisión si el actor lo requiere.
Insertar Nueva Guía de Remisión

MODIFICAR GUÍA DE REMISIÓN - REQ-02.2
CASO DE USO: Modificación de Guía de Remisión
Modificar una guía de remisión con los datos que han

PROPÓSITO: sido ingresados para luego proceder a despachar los
productos.

despacho desea realizar alguna modificación de la
DESCRIPCIÓN
guía con los datos solicitados en el REQ-02.1 y
GENERAL:
luego proceder al despacho de los productos que
contiene.
FLUJO PRINCIPAL
1. El actor selecciona la guía y luego presiona 2. Sistema limpia y activa los cuadros
modificar Guía de Remisión de despacho de de textos con la información respectiva
por el actor y genera la nueva guía de
remisión.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R6: Imprimir la guía de remisión si el actor lo requiere.
Modificar Guía de Remisión

ELIMINAR GUÍA DE REMISIÓN - REQ-02.3
CASO DE USO: Eliminar Guía de Remisión
TIPO: Opcional.
PROPÓSITO: Eliminar una Guía de Remisión con los productos que

se fueron insertados.

GENERAL: inventario desea eliminar alguna guía de remisión.
FLUJO PRINCIPAL
1. El actor selecciona el pedido y luego presiona en 2. Sistema presenta un mensaje de

el menú eliminar Guía de remisión de despacho de advertencia si está seguro de eliminar
mercadería. la guía de remisión.
4. El sistema valida y elimina la guía y
3. El actor confirma la eliminación. presenta un mensaje de proceso
realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar datos de productos antes de eliminar la guía.
Eliminar Guía de Remisión

CONSULTAR GUÍA DE REMISIÓN – REQ-02.4
CASO DE USO: Consultar Guía de Remisión
PROPÓSITO: Consultar una Guía de remisión con los productos que


GENERAL: desea consultar alguna guía de remisión.
FLUJO PRINCIPAL
1. El actor ingresa el número de pedido o el id de la 2. Sistema presenta los resultados de la

guía de remisión y selecciona la opción de búsqueda
búsqueda, luego presiona buscar guía de despacho
de mercadería.
3. El actor selecciona la guía que deseaba consultar. 4. Presentar Guía.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar los datos ingresados antes de consultar pedido.
Consultar Guía de Remisión
ADMINISTRAR TRASPOSTISTA (REQ-02.5 – REQ-02. 8)
INSERTAR TRASPOSTISTA - REQ-02.5

CASO DE USO: Insertar Transportista
PROPÓSITO: Insertar un nuevo Transportista, es decir los datos solicitados del

encargado de transportar los productos despachados hacia los
diferentes locales.
La interacción comienza cuando el responsable del despacho
de mercadería genera una Guía de Remisión REQ-02.1 y
DESCRIPCIÓN
requiere del código de transportista que se hará cargo de
GENERAL:
transportar los productos a despachar hacia el local
correspondiente.
FLUJO PRINCIPAL

Transportista de despacho de mercadería. textos con la respectiva información
solicitada (genera id de transportista)
para permitir el ingreso de los demás
datos solicitados.
3. El actor ingresa los datos solicitados. 4. El sistema valida los datos para que
no exista otra cedula con el mismo valor.
5. El guarda trasportista.
el actor y guarda en la Base de Datos,
presenta un mensaje de proceso
finalizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error en caso de que exista la cedula.

Insertar Transportista
MODIFICAR TRASPOSTISTA - REQ-02.6
CASO DE USO: Modificación de Transportista
Modificar los datos del transportista que han sido

PROPÓSITO: ingresados para luego proceder a usar el Id en las guías
de remisión.

DESCRIPCIÓN despacho desea realizar alguna modificación del
GENERAL: transportista con los datos ingresados en el REQ-
02.5
FLUJO PRINCIPAL
1. El actor selecciona el trasportista y luego 2. Sistema limpia y activa los cuadros

presiona modificar transportista de despacho de de textos con la información respectiva
mercadería. del transportista para permitir la
4. El sistema valida que no exista
cedula repetida y permite la
3. El actor realiza la modificación respectiva.

5. El actor graba la modificación respectiva. por el actor, guarda y presenta mensaje
de proceso finalizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Presentar mensaje de error cedula repetida.
Modificar Transportista
ELIMINAR TRASPOSTISTA - REQ-02.7

CASO DE USO: Eliminar Transportista
TIPO: Opcional.
PROPÓSITO: Eliminar una Transportista, es decir los datos que se fueron

insertados.

GENERAL: inventario desea eliminar algún transportista.
FLUJO PRINCIPAL
1. El actor selecciona el transportista y luego 2. Sistema presenta un mensaje de

presiona en el menú eliminar Transportista de advertencia si está seguro de eliminar
despacho de mercadería. el transportista.
4. El sistema valida y elimina al
3. El actor confirma la eliminación. transportista y presenta un mensaje de
proceso realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar datos de productos antes de eliminar el transportista.
Eliminar Transportista
CONSULTAR TRASPOSTISTA – REQ-02.8
CASO DE USO: Consultar Transportista
PROPÓSITO: Consultar un Transportista determinado.
DESCRIPCIÓN La interacción comienza cuando el administrador desea

GENERAL: consultar los datos de algún transportista.
FLUJO PRINCIPAL
1. El actor ingresa el id de transportista o la cedula 2. Sistema presenta los resultados de la

y selecciona la opción de búsqueda, luego presiona búsqueda.
buscar transportista de despacho de mercadería.
3. El actor selecciona el transportista que deseaba

consultar.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar los datos ingresados antes de hacer la búsqueda de Transportista.
Consultar Transportista
SOLICITUD DE MERCADERÍA REQ-03
ADMINISTRAR ORDEN DE COMPRA (REQ-03.1 – REQ-03.4)

INSERTAR NUEVA ORDEN DE COMPRA - REQ-03.1
CASO DE USO: Insertar Orden de Compra.
ACTORES: Administrador, bodeguero, jefe de compra.
Generar una Orden de Compra con los productos de la

PROPÓSITO: orden de pedido que no se tiene a su disposición en el
local principal.

DESCRIPCIÓN despacho de mercadería genera una Orden de
GENERAL: Compra REQ-03.1 para luego enviar al jefe de
compras y solicite la mercadería.
REFERENCIAS: REQ-01.13, REQ-01.5.
FLUJO PRINCIPAL
1. El actor selecciona en el menú nueva 2. Sistema limpia y activa los cuadros de

Orden de Compra. textos con la respectiva información
solicitada (número de orden de compra y
fecha de Orden de Compra) para permitir el
ingreso de los demás datos solicitados.
3. El actor busca e ingresa el Id proveedor; 4. El sistema valida que no exista código de
ingresa fecha de emisión, los productos a productos repetidos y permite el ingreso de
solicitar. la cantidad solicitada. Además va generando
la cantidad de ítems.
5. El actor ingresa la cantidad requerida, el
Precio de Proveedor. 6. El sistema valida datos ingresados por el
actor y genera la orden de compra.
7. El actor envía la orden de Compra al
departamento de compras.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R6: Imprimir la orden de compra si el actor lo requiere.
Insertar Nueva Orden De Compra

MODIFICAR ORDEN DE COMPRA - REQ-03.2
CASO DE USO: Modificación de Orden de Compra
ACTORES: Administrador, bodeguero, Jefe de Compras.
PROPÓSITO: Modificar una Orden de Compra con los datos que han sido
ingresados para luego enviar al jefe de compra.
La interacción comienza cuando el actor desea realizar

DESCRIPCIÓN alguna modificación de la Orden de Compra con los datos
GENERAL: solicitados en el REQ-03.1 y luego proceder a enviarla al jefe
de compras.
FLUJO PRINCIPAL
1. El actor selecciona la Orden de Compra y 2. Sistema limpia y activa los cuadros de

luego presiona modificar Orden de Compra. textos con la información respectiva de la
Orden de Compra para permitir la
3. El actor realiza la modificación respectiva. modificación de la misma.
4. El sistema valida que no exista código de
productos repetidos y permite la

actor y genera la nueva Orden de Compra.
7. El actor envía la orden de Compra al
departamento de compras.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R6: Imprimir la Orden de Compra si el actor lo requiere.
Modificar Orden de Compra

ELIMINAR ORDEN DE COMPRA - REQ-03.3
CASO DE USO: Eliminar Orden de Compra.
TIPO: Opcional.
PROPÓSITO: Eliminar una Orden de Compra con los productos que

DESCRIPCIÓN La interacción comienza cuando el actor desea

GENERAL: eliminar alguna Orden de Compra.
FLUJO PRINCIPAL
1. El actor selecciona la Orden de Compra y luego 2. Sistema presenta un mensaje de

presiona en el menú eliminar Orden de Compra. advertencia si está seguro de eliminar
la guía de remisión.
3. El actor confirma la eliminación. 4. El sistema valida y elimina la Orden
de Compra y presenta un mensaje de
proceso realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar datos de productos antes de Orden de Compra.
Eliminar Orden de Compra
CONSULTAR ORDEN DE COMPRA – REQ-03.4
CASO DE USO: Consultar Orden de Compra
ACTORES: Administrador, Bodeguero, Jefe de Compra
PROPÓSITO: Consultar una Orden de Compra con los productos que se

fueron insertados.
DESCRIPCIÓN La interacción comienza cuando el administrador desea

GENERAL: consultar alguna Orden de Compra.
FLUJO PRINCIPAL
1. El actor ingresa el Id de Orden o la fecha de 2. Sistema presenta los resultados de la

Orden y selecciona la opción de búsqueda, luego búsqueda
presiona buscar Orden de Compra.
4. Mostrar Orden de Compra.
3. El actor selecciona la Orden de Compra que
deseaba consultar.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar los datos ingresados antes de consultar Orden de Compra.
Consultar Orden de Compra
RECEPCIÓN DE MERCADERÍA REQ-03
ADMINISTRAR ORDEN DE COMPRA (REQ-03.1 – REQ-03.4)

MODIFICAR ORDEN DE COMPRA - REQ-03.2
CASO DE USO: Modificación de Orden de Compra
Administrador, bodeguero, Jefe de Compras,

ACTORES:
Proveedor.
Modificar una Orden de Compra con la información del

PROPÓSITO: proveedor, para luego el encargado del despacho de
mercadería realice la actualización del Stock.
La interacción comienza cuando el proveedor realiza

la modificación de la Orden de Compra con los datos
DESCRIPCIÓN
de los productos que tiene a su disposición y luego
GENERAL:
proceder a enviarla al despacho de mercadería para
que se realice la actualización del stock.
FLUJO PRINCIPAL
1. El actor selecciona la Orden de Compra y 2. Sistema limpia y activa los cuadros de

luego presiona modificar Orden de Compra. textos con la información respectiva de la
Orden de Compra para permitir la
modificación de la misma (solo en caso de
la cantidad recibida, precio compra,
3. El actor realiza la modificación respectiva. estado).
4. El sistema valida los datos.
7. El actor envía la orden de Compra al actor y guarda los datos ingresados.
despacho de mercadería.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R6: Imprimir la Orden de Compra si el actor lo requiere.
Modificar Orden de Compra
ELIMINAR ORDEN DE COMPRA - REQ-03.3
CASO DE USO: Eliminar Orden de Compra.
TIPO: Opcional.
PROPÓSITO: Eliminar una Orden de Compra con los productos que
DESCRIPCIÓN La interacción comienza cuando el actor desea

GENERAL: eliminar alguna Orden de Compra.
FLUJO PRINCIPAL
1. El actor selecciona la Orden de Compra y 2. Sistema presenta un mensaje de

luego presiona en el menú eliminar Orden de advertencia si está seguro de eliminar la guía
Compra. de remisión.
4. El sistema valida y elimina la Orden de
3. El actor confirma la eliminación. Compra y presenta un mensaje de proceso
realizado.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar datos de productos antes de Orden de Compra.
Eliminar Orden de Compra

CONSULTAR ORDEN DE COMPRA – REQ-03.4
CASO DE USO: Consultar Orden de Compra
ACTORES: Administrador, Bodeguero, Jefe de Compra
PROPÓSITO: Consultar una Orden de Compra con los productos que


GENERAL: desea consultar alguna Orden de Compra.
FLUJO PRINCIPAL
1. El actor ingresa el Id de Orden o la fecha de 2. Sistema presenta los resultados de la

Orden y selecciona la opción de búsqueda, luego búsqueda
presiona buscar Orden de Compra.
3. Presentar Orden de Compra.
3. El actor selecciona la Orden de Compra que
deseaba consultar.
FLUJO ALTERNO
Ninguno.
EXCEPCIONES
R4: Verificar los datos ingresados antes de consultar Orden de Compra.

ACTIVIDAD N°: FECHA 19/06/2014 FECHA 24/06/2014

ENVIO: ENTREGA:
10
TEMA: Diseño de Interfaces
UNIDAD N°2: Casos de Uso reales y Diseño de Interfaz
OBJETIVO: Investigar cómo realizar el diseño de interfaces
PROBLEMA:
 Desconocimiento de las fases o criterios para el diseño de
interfaces.
EVALUACION:
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□ Intraclase □ Individual □Taller □Práctica en laboratorio
□Síntesis, esquemas □Práctica en clase
□ Extraclase □ Grupal □Caso de estudio □Resolución de problemas,
CALIFICACIÓN □Informe de e
posición

Erika Paola Tinoco
Luis Fernando Tobar
INTRODUCCION
El diseño de interfaz es de vital importancia dentro del desarrollo de un sistema, la calidad

de la interfaz de usuario puede ser uno de los motivos que conduzca a un sistema al éxito
o al fracaso. En el presente documento estudiaremos los fundamentos básicos que nos
ayuden al desarrollo de una interfaz amigable y cada una de los elementos o fases que
intervienen en el proceso del mismo.
DESARROLLO
¿Qué es una Interfaz de Usuario?

Cuando uno usa una herramienta, o accede e
interactúa con un sistema, suele haber “algo”
entre uno mismo y el objeto de la interacción.
En un auto, ese “algo” son los pedales y el

tablero. En una puerta, es el picaporte. En una
máquina expendedora o un ascensor, los
botones. En una computadora (atención, que
no me refiero a un producto informático sino
una computadora), el teclado, el monitor, el
mouse, y otros periféricos.
Este “algo” nos informa qué acciones son posibles, el estado actual del objeto y los
cambios producidos, y nos permite actuar con o sobre el sistema o la herramienta.
Ese “algo”, que es a la vez un límite y un espacio común entre ambas partes, es
la interfaz.
Importancia
Si el software es muy difícil de usar, fuerza al usuario a cometer errores, o si frustra sus
esfuerzos para alcanzar las metas, entonces no le gustará, sin que importe el poder
computacional que tenga, el contenido que entregue o las funciones que ofrezca. La
interfaz tiene que estar bien hecha porque moldea la percepción que el usuario tiene del
software.
¿Cuál es el Costo de una Mala interfaz?

Una interfaz con problemas de usabilidad genera algunos costos. Algunos de ellos son
medibles y otros que no.
¿Cuánto vale un cliente insatisfecho? Es difícil medirlo en dinero, pero no es un costo que
ninguno de nosotros querría pagar.
¿Cuánto vale un error que enlentece 3 minutos diarios la operatoria de una persona? En
un área de 5 personas, es más de una semana/hombre de trabajo al fin del año.
Actualmente, hasta el 45% del código de una aplicación está dedicado a la interfaz. Más
de un tercio de los análisis, comparaciones y opiniones de la prensa está dedicada a la
facilidad de uso. Sin embargo, en otros países se dedica algo menos del 10% del
presupuesto global de un proyecto al desarrollo de la interfaz. En Argentina, esta inversión
es casi nula. ¿Cuál es la conclusión?
Aumentar los recursos destinados al desarrollo de la interfaz es una excelente
inversión, teniendo en cuenta la relación costo/beneficio medible y segura, aún sin tener
en cuenta los beneficios no medibles en dinero como el aumento de la satisfacción
¿Qué es el Diseño de Interfaces?

El diseño de interfaces es una disciplina que estudia y trata de poner en práctica procesos
orientados a construir la interfaz más usable posible, dadas ciertas condiciones de
entorno.
El entorno dentro del cual se inscribe el diseño de una
interfaz y la medida de su usabilidad, está dado por tres
factores:
1. Una persona.
2. Una tarea.
3. Un contexto.
Principios para el Diseño de Interfaces de Usuario

Existen principios relevantes para el diseño e implementación de IU, ya sea para las IU
gráficas, como para la Web.
 Anticipación
Las aplicaciones deberían intentar anticiparse a las necesidades del usuario
y no esperar a que el usuario tenga que buscar la información, recopilarla o
invocar las herramientas que va a utilizar.
 Autonomía
La computadora, la IU y el entorno de trabajo deben estar a disposición del
usuario. Se debe dar al usuario el ambiente flexible para que pueda
aprender rápidamente a usar la aplicación. Sin embargo, está comprobado
que el entorno de trabajo debe tener ciertas cotas, es decir, ser explorable
pero no azaroso.
 Percepción del Color
Aunque se utilicen convenciones de color en la IU, se deberían usar otros
mecanismos secundarios para proveer la información a aquellos usuarios
con problemas en la visualización de colores
 Valores por Defecto
No se debe utilizar la palabra "Defecto" en una aplicación o servicio. Puede
ser reemplazada por "Estándar" o "Definida por el Usuario", "Restaurar
Valores Iniciales" o algún otro término especifico que describa lo que está
sucediendo. Los valores por defecto deberían ser opciones inteligentes y
sensatas. Además, los mismos tienen que ser fáciles de modificar.
 Consistencia
Para lograr una mayor consistencia en la IU se requiere profundizar en
diferentes aspectos que están catalogados en niveles. Se realiza un
ordenamiento de mayor a menor consistencia:
Interpretación del comportamiento del usuario: la IU debe comprender
el significado que le atribuye un usuario a cada requerimiento. Ejemplo:
mantener el significado de las los comandos abreviados (shortcut-keys)
definidos por el usuario.
Estructuras invisibles: se requiere una definición clara de las mismas, ya que
sino el usuario nunca podría llegar a descubrir su uso. Ejemplo: la ampliación de
ventanas mediante la extensión de sus bordes.
Pequeñas estructuras visibles: se puede establecer un conjunto de objetos
visibles capaces de ser controlados por el usuario, que permitan ahorrar tiempo en
la ejecución de tareas específicas. Ejemplo: ícono y/o botón para impresión.
Una sola aplicación o servicio: la IU permite visualizar a la aplicación o servicio
utilizado como un componente único. Ejemplo: La IU despliega un único menú,
pudiendo además acceder al mismo mediante comandos abreviados.
Un conjunto de aplicaciones o servicios: la IU visualiza a la aplicación o servicio
utilizado como un conjunto de componentes. Ejemplo: La IU se presenta como un
conjunto de barras de comandos desplegadas en diferentes lugares de la pantalla,
pudiendo ser desactivadas en forma independiente.
Consistencia del ambiente: la IU se mantiene en concordancia con el ambiente
de trabajo. Ejemplo: La IU utiliza objetos de control como menúes, botones de
comandos de manera análoga a otras IU que se usen en el ambiente de trabajo.
Consistencia de la plataforma: La IU es concordante con la plataforma. Ejemplo:
La IU tiene un esquema basado en ventanas, el cual es acorde al manejo del
sistema operativo Windows.
 Eficiencia del Usuario

Se debe considerar la productividad del usuario antes que la productividad
de la máquina. Si el usuario debe esperar la respuesta del sistema por un
período prolongado, estas pérdidas de tiempo se pueden convertir en
pérdidas económicas para la organización. Los mensajes de ayuda deben
ser sencillos y proveer respuestas a los problemas. Los menúes y etiquetas
de botones deberían tener las palabras claves del proceso.
 Interfaces Explorables
Siempre que sea posible se debe permitir que el usuario pueda salir
ágilmente de la IU, dejando una marca del estado de avance de su trabajo,
para que pueda continuarlo en otra oportunidad.
Para aquellos usuarios que sean noveles en el uso de la aplicación, se deberá
proveer de guías para realizar tareas que no sean habituales.
Es conveniente que el usuario pueda incorporar elementos visuales estables que
permitan, no solamente un desplazamiento rápido a ciertos puntos del trabajo que
esté realizando, sino también un sentido de "casa" o punto de partida.
La IU debe poder realizar la inversa de cualquier acción que pueda llegar a ser de
riesgo, de esta forma se apoya al usuario a explorar el sistema sin temores.
Siempre se debe contar con un comando "Deshacer". Este suprimirá la necesidad
de tener que contar con diálogos de confirmación para cada acción que realice en
sistema.
El usuario debe sentirse seguro de poder salir del sistema cuando lo desee. Es por
ello que la IU debe tener un objeto fácil de accionar con el cual poder finalizar la
aplicación.
 Protección del Trabajo
Se debe poder asegurar que el usuario nunca pierda su trabajo, ya sea por
error de su parte, problemas de transmisión de datos, de energía, o alguna
otra razón inevitable.
 Auditoría del Sistema
La mayoría de los navegadores de Internet (browsers), no mantienen
información acerca de la situación del usuario en el entorno, pero para
cualquier aplicación es conveniente conocer un conjunto de características
tales como: hora de acceso al sistema, ubicación del usuario en el sistema
y lugares a los que ha accedido, entre otros. Además, el usuario debería
poder salir del sistema y al volver a ingresar continuar trabajando en lugar
dónde había dejado.
CONCLUSION
 La integración de los principios y prototipos de evaluación durante el
proceso de diseño de IU permite la creación de interfaces que satisfacen
las expectativas del Modelo del Usuario, el cual es el punto de vista más
importante para garantizar la aceptación de un sistema.
RECOMENDACIÓN
 Tomar en cuenta y aplicar cada uno de los principios y prototipos mostrados
en el documento para el desarrollo de una interfaz exitosa.
Bibliografía
Guía de Estudio del Módulo III "Metodología de Construcción de Sistemas de Software" de la
Maestría en Ingeniería del Software, Escuela de Posgrado, Instituto Tecnológico de Buenos
Aires.
http://www.slideshare.net/adrianazamora/diseo-de-interfaz-importancia-y-proceso-24058181
http://www.gaiasur.com.ar/infoteca/siggraph99/diseno-de-interfaces-y-usabilidad.html#4

ENVIO: ENTREGA:
TEMA: Diagramas de Secuencia y de Colaboración

UNIDAD N°3: DIAGRAMAS DE INTERACCION
Analizar qué es y cómo realizar el diseño de los diagramas de Secuencia y
OBJETIVO:
Colaboración
PROBLEMA: Desconocimiento de diagramas de Colaboración
EVALUACION:
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
xtraclase
□Informe de exp
CALIFICACIÓN sición

Erika Tinoco
Luis Tobar
INTRODUCCION
En el presente documento veremos que es un diagrama de secuencia y un diagrama de

colaboración, así como la forma correcta de diseñar los mismos. Un diagrama de
secuencia es donde vamos a plasmar la interacción entre los objetos que constan en
nuestro sistema y el diagrama de colaboración las relaciones entre los roles. Además de
ellos en su diseño deben constar todos los procesos, métodos y detalles que van a contar
en el código del programa.
DESARROLLO
Diagramas de Secuencia
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una

aplicación a través del tiempo y se modela para cada caso de uso. Mientras que
el diagrama de casos de uso permite el modelado de una vista business del escenario, el
diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los
objetos y clases que se usan para implementar el escenario y mensajes intercambiados
entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos

son necesarios para la implementación del escenario. Si se dispone de la descripción de
cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar
sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir
los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario
con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas
horizontales.
OBJETOS
Los diagramas de secuencia constan de objetos que se representan de modo usual:

rectángulo con nombre, mensajes entre los objetos representados por
líneas continuas con una punta de flecha y el tiempo representado
como una progresión vertical. Los objetos se colocan cerca de la parte
superior del diagrama de izquierda a derecha y se acomodan de
manera que simplifiquen el diagrama.
Línea de Vida
Una línea de vida representa un participante individual en un diagrama

de secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el
nombre del objeto. Si el nombre es self entonces eso indica que la línea de vida
representa el clasificador que posee el diagrama de secuencia.
Mensaje
Un mensaje que va de un objeto a otro pasa de la línea de vida de
un objeto al de otro. Un objeto puede enviarse un objeto a sí
mismo es decir de su línea de vida así propia línea de vida.
Un mensaje puede ser simple, síncrono y asíncrono

Mensaje simple: es la transferencia del control de un objeto a otro.
Mensaje síncrono: es cuando el objeto espera la respuesta a ese mensaje antes de
continuar con su trabajo.
Mensaje asíncrono: es cuando el objeto no espera la respuesta a ese mensaje antes de
continuar.
Tiempo
El diagrama representa el tiempo en

dirección vertical. El tiempo se inicia en la
parte superior y avanza hacia la parte
inferior. Un mensaje que esté más cerca de
la parte superior ocurrirá antes que uno que
esté cerca de la parte inferior.
Con ellos el diagrama de secuencia tiene 2

dimensiones: la dimensión horizontal (es la disposición de los objetos) y la dimensión
vertical (muestra el paso del tiempo).
Recursividad
En ocasiones un objeto posee una operación que se invoca a sí

misma. A esto se le conoce como recursividad y es una
característica fundamental de varios lenguajes de programación.
Ejemplo
El detalle del diagrama depende de la fase en la que estemos, lo

que pretendamos contar con el diagrama y a quién. En una primera
fase de diseño podemos poner clases grandes y ficticias, que representen un
paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a
la vez, incluso clases que representen un ejecutable.
Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien
atados los detalles entre dos programadores, que cada uno va a programar una de las
clases o módulos que participan, entonces debemos posiblemente ir al nivel de clase real
de codificación y método, con parámetros y todo, de forma que los programadores tengan
claro que métodos van a implementar, qué deben llamar de la clase o módulo del otro,
etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de
secuencia en el que sólo salga el actor "jugador" y una única clase "juego ajedrez" que
representa nuestro programa completo, de forma que el cliente vea qué datos y en qué
orden los tiene que meter en el programa y vea qué salidas y resultados le va a dar el
programa. El siguiente puede ser un diagrama de secuencia del ejemplo del ajedrez a un
nivel de diseño muy preliminar.
Aquí ya se ha decidido que se van a desarrollar tres librerías/paquetes/módulos, una para

la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos
válidos y demás) y otra para el algoritmo de juego del ordenador. En el ejemplo se ha
utilizado una clase representando cada uno de los paquetes y se ha representado el caso
de uso "mover pieza".
En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos,

jaques, etc.) puesto que poner todos los detalles puede dar lugar a un diagrama que no se
entiende o difícil de leer. El diagrama puede acompañarse con un texto en el que se
detallen todas estas situaciones erróneas y particularidades.
Diagramas de Colaboración
Es un diagrama que muestra interacciones organizadas alrededor de los roles. A

diferencia de los diagramas de secuencia, los diagramas de colaboración, también
llamados diagramas de comunicación, muestran explícitamente las relaciones de los
roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una
dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto
la secuencia de mensajes como los hilos concurrentes.
 Muestra cómo las instancias específicas de las clases trabajan juntas para
conseguir un objetivo común.
 Implementa las asociaciones del diagrama de clases mediante el paso de

mensajes de un objeto a otro. Dicha implementación es llamada "enlace".
Un diagrama de comunicación es también un diagrama de clases que contiene roles de

clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles
de clasificador y los de asociación describen la configuración de los objetos y de los
enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando
se instancia una comunicación, los objetos están ligados a los roles de clasificador y los
enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios
tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales
del procedimiento. Los símbolos de enlace pueden llevar estereotipos para
indicar enlaces temporales.
Elementos del diagrama de Colaboración
 Objetos y Mesajes
 Creación de Objetos.
 Asociaciones
 Recursión
 Condicionales
 Iteración
Ejemplo:
Caso de Uso: Pago por servicios.
Actores: Administrador, Agente, Huésped (inicia).
Propósito: Controlar que el huésped cancele su estadía y los servicios solicitados.
Tipo: Primario y esencial.
Descripción: El agente designado en administración controla que el huésped cancele su estadía
en el hotel y los servicios solicitados.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR RESPUESTA DEL SISTMA

1.- Se inicia cuando el huésped desea retirarse
del hotel.
2.- El agente revisa que no exista daños ni
pérdidas durante la estadía del huésped.
3.- El administrador calcula el saldo que debe 5.- El sistema actualiza el pago del huésped
cancelar, y pide la cancelación total al huésped
4.- El huésped cancela al administrador y este
le proporciona una factura.
6.- El administrador recibe las llaves de la
habitación.
7.- El huésped se retira.
Conclusiones
 El diagrama de Secuencia, muestra gráficamente los eventos que
originan los actores dentro de un sistema y cómo se comunican
(interactúan) entre sí a lo largo del tiempo, en cambio los de
Colaboración solo se centran en las responsabilidades de cada objeto.
Recomendaciones
 Dar ejemplos prácticos en clase sobre este tipo de diagramas, para un
mejor entendimiento y ahondar más en los procesos que se deben
tomar en cuenta.
Bibliografía
http://jams001.blogspot.com/2012/09/diagrama-de-secuencia-y-colaboracion.html
http://webdocs.cs.ualberta.ca/~pfiguero/soo/uml/colaboracion01.html
http://es.slideshare.net/miriam1785/diagramas-de-secuencia-y-colaboracion

ACTIVIDAD N°: 12 FECHA 07/08/2014
ENVIO:
FECHA
ENTREGA:
11/08/2014
TEMA: Diagramas de Componentes y Despliegue
UNIDAD N°3: DIAGRAMAS DE INTERACCION
Analizar qué es y cómo realizar el diseño de los diagramas de

OBJETIVO: Componentes y de Despliegue
PROBLEMA: Desconocimiento de diagramas de Componentes
EVALUACION:
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
xtraclase
CALIFICACIÓN

Erika Tinoco Investigadora
DIAGRAMA DE COMPONENTES
Un diagrama de componentes permite visualizar con más facilidad la estructura general

del sistema y el comportamiento del servicio que estos componentes proporcionan y
utilizan a través de las interfaces. Puede usar un diagrama de componentes para describir
un diseño que se implemente en cualquier lenguaje o estilo. Solo es necesario identificar
los elementos del diseño que interactúan con otros elementos del diseño a través de un
conjunto restringido de entradas y salidas. Los componentes pueden tener cualquier
escala y pueden estar interconectados de cualquier manera.
Elementos de un Diagrama de Componentes
Normalmente este tipo de Diagramas contiene los siguientes elementos:
 Componentes
 Interfaces
 Relaciones de dependencia, generalización, asociación y realización
 Paquetes o subsistemas.
Componentes
Un componente es una parte física de un sistema (modulo, base de datos, programa
ejecutable, etc.). Se puede decir que un componente es la materialización de una o más
clases, porque una abstracción con atributos y métodos pueden ser implementados en los
componentes.
Los componentes se pueden agrupar en paquetes así como los objetos en clases,
además pueden haber entre ellos relaciones de dependencia como:
• generalización
• asociación
• agregación
• realización
Estereotipo de Componentes
UML define cinco estereotipos estándar que se aplican en los componentes
• Executable, componente que se puede ejecutar
• Library, biblioteca de objetos estática o dinámica
• Table, Componentes que representa una tabla de base de datos
• File, componente que representa un documento que contiene código fuente o

datos
• Document, Comp. Que representa un documento.
Interfaces
Es el lazo de unión entre varios componentes.
Ejemplo de Diagrama de Componentes

Ejemplo2: Cómo diseñar el portal de la facultad
Tecnológica de manera que permita visualizar la
información completa acerca de ella e interactuar
eficazmente con los usuarios para que ellos puedan acceder
a los diferentes servicios web?
DIAGRAMA DE DESPLIEGUE
Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un sistema.

Esto muestra la configuración de los elementos de hardware (nodos) y muestra cómo los
elementos y artefactos del software se trazan en esos nodos.
Componentes de Diagrama de Despliegue
Nodo
Un Nodo es un elemento de hardware o software. Esto se muestra con la forma de una

caja en tres dimensiones, como a continuación.
Instancia de Nodo
Una instancia de nodo se puede mostrar en un diagrama. Una instancia se puede

distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos
puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de
los dos puntos. El siguiente diagrama muestra una instancia nombrada de una
computadora.
Estereotipo de Nodo
Un número de estereotipos estándar se proveen para los nodos, nombrados «cdrom»,

«cd-rom», «computer», «disk array», «pc», «pc client», «pc server», «secure», «server»,
«storage», «unix server», «user pc». Estos mostrarán un icono apropiado en la esquina
derecha arriba del símbolo nodo.
Artefacto
Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los
modelos del proceso (e.g. modelos de Casos de Uso, modelos de Diseño, etc.), archivos
fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de
usuario y más.
Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el

estereotipo «artifact» y un icono de documento, como a continuación.
Asociación
En el contexto del diagrama de despliegue, una asociación representa una ruta de

comunicación entre los nodos. El siguiente diagrama muestra un diagrama de despliegue
para una red, mostrando los protocolos de red como estereotipos y también mostrando
multiplicidades en los extremos de la asociación.
Nodo como contenedor
Un nodo puede contener otros elementos,

como componentes o artefactos.
El siguiente diagrama muestra un
diagrama de despliegue para una parte del sistema embebido y muestra un artefacto
ejecutable como contenido por el nodo madre (motherboard).
Ejemplo de Diagrama de Despliegue
¿Cómo diseñar el portal de la facultad Tecnológica de manera que permita visualizar la

información completa acerca de ella e interactuar eficazmente con los usuarios para que
ellos puedan acceder a los diferentes servicios web?
EVALUACIONES PARCIALES
PROYECTO FINAL

Portafolio de Diseño Hidraúlico, Quinto Semestre UTMACH

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Portafolio de Diseño Hidraúlico, Quinto Semestre UTMACH

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD TÉCNICA DE MACHALA

FACULTAD DE INGENIERÍA CIVIL

DISEÑO ORIENTADO A OBJETOS

5TO. SEMESTRE PARALELO “A”

ERIKA PAOLA TINOCO

ING. JOFFRE CARTUCHE

MACHALA – EL ORO – ECUADOR

Fecha de Inicio: Fecha de Finalización:

El Diseño de Sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en

 Realizar el diagrama de casos de uso para modelar el sistema mediante la heramienta

 Definir la estructura e interfaz del sistema a desarrollarse, aplicando conocimientos

 Usar Patrones de acuerdo al Proyecto.

 Representar clases y relaciones para el mapeo del programador de acuerdo a UML.

Por ello el Diseño es una etapa imprescindible para el desarrollo de proyectos.

3. OPERACIONALIZACION DE LA ASIGNATURA CON RESPECTO A LAS

3.1. Objeto de estudio de la asignatura

3.2. Competencia de la asignatura

3.3. Relación de la asignatura con los resultados de aprendizaje

media Integrar y dirigir equipos de trabajo, liderando

e) Resuelve problemas de Ingeniería de Expresar aspectos del diseño a través del

media Determinar los atributos visibles de acuerdo a

k) Utilización de técnicas e instrumentos alta Utilizar herramientas privativas y libres para

l) Capacidad para liderar, gestionar o media Tener la capacidad de formar grupos de

3.4. Proyecto o producto de la asignatura:

4.1. Estructura de la asignatura por unidades:

UNIDAD COMPETENCIAS RESULTADOS DE APRENDIZAJE

1.Determina la Arquitectura del Sistema

UNIDAD I: DEL ANÁLISIS AL DISEÑO

UNIDAD II: CASOS DE USO REALES Y DISEÑO DE LA INTERFAZ

UNIDAD III: DIAGRAMAS DE INTERACCIÓN

UNIDAD IV: PATRONES GRASP

UNIDAD V: DIAGRAMA DE CLASES DEL DISEÑO

TOTAL DE HORAS DE UNIDAD VI 20

UNIDAD VII: ALGUNOS ASPECTOS DEL DISEÑO

08/09/14 – EXAMEN FIN DE

5. METODOLOGIA: (ENFOQUE METODOLOGICO)

La metodología de enseñanza en las clases y las actividades académicas se aplicará de

5.1. Métodos de enseñanza

a) Clases magistrales, donde se expondrán los temas de manera teórica, mostrando y

3. Trabajos de campo, realizados grupalmente como encuestas, o censos.

e) Medios tecnológicos que se utilizaran para la enseñanza:

 Pizarrón para tiza líquida y marcadoresde varios colores.

6. COMPONENTE INVESTIGATIVO DE LA ASIGNATURA:

 Investigación Formativa.- Referida al aprendizaje por descubrimiento y construcción

8.2. Parámetros de Evaluación:

PARAMETROS DE EVALUACION PORCENTAJES

9.1. Bibliografía Básica:

 WEITZENDFELD, Alfredo (2005), Ingeniería de software Orientada a Objetos

9.2. Bibliografía Complementaría:

 PRESSMAN, Roger, 2010. Ingeniería de Software Un enfoque Práctico.

10. DATOS DEL O LOS DOCENTES:

12. FECHA DE PRESENTACION:

Machala, Abril del 2014

MI nombre es Erika Tinoco, soy estudiante de la asignatura de Diseño

UNIVERSIDAD TÉCNICA DE MACHALA

Datos del Padre

Datos del cónyuge (en caso de tenerlo)

Datos del Trabajo: (en caso de tenerlo)

UNIVERSIDAD TÉCNICA DE MACHALA

La Universidad Técnica de Machala es una Institución reconocida en su área de influencia

formadora de profesionales, con capacidades científico-técnicas, ética, solidaria, con identidad

nacional, que aporta, creativamente, a través de la docencia, investigación, vinculación y

gestión, a la solución de los problemas del desarrollo sostenible y sustentable.