Tema 01 Introduccion A La Asignatura-Fusionado

Introducción a la Asignatura.
Conceptos básicos, aspectos generales y medios para

Obtención de Información
Doc. Ing. Rosa Almaraz

Contenido.
Introducción.
Metodología para desarrollo de Sistemas o software.
Que es
Tipos de Metodologías.
Estructurado vs Orientado a Objetos.
Fases en el desarrollo de un Software.
Orientación a Objetos.
Ventajas de la Orientación a Objetos.
Conceptos Básicos de la Orientación a Objetos.
Conceptos Generales.
Usuario.
Ing. De Sistemas.
La Organización como un Sistema.
Cultura Organizacional
Análisis.
Diseño.
Medios para obtención de Información.
Entrevista.
Cuestionarios.
Otros medios.
Tarea.

Introducción
Objetivo del Tema:
Este tema tiene como objetivo, introducir a los estudiantes en la Asignatura. Se estudian algunos
conceptos básicos necesarios que sientan la base para el estudio de toda lo que se verá en el
semestre.
Forma de trabajar en la asignatura:
Se pasarán cuatro horas semanales. De ellas, dos horas son teóricas y otras dos horas serán
practicas o de laboratorio.
Las clases teóricas y su contenido estarán subidas en el e-campus de la Universidad.
La orientación de las practicas o laboratorios que se realizaran, están subidas en el e-campus de la
Universidad. El estudiante deberá asistir al laboratorio o practica con la misma ya avanzada, de
forma tal, que en el aula pueda realizar la presentación u exposición de la misma para su evaluación.
Aspectos a considerar:
Se estudian aspectos relacionados al desarrollo de un sistema informático para una organización o

empresa, un sistema de gestión empresarial. Diseñando, ya sea para desktop, Tablet o dispositivo
móvil.

Metodología.
¿Qué significa Metodología?
En cualquier proyecto de desarrollo de software, es necesaria la colaboración de muchas personas.

Las mismas deberán tener diversos perfiles, para su éxito. Por lo que esto traerá dos problemas
fundamentales:
1.- La especialización de cada rol o perfil dentro del equipo de trabajo trae consigo un problema de
comunicación entre ellos.
2.- El proyecto se deberá descomponer o dividir en Fases o etapas, para tratarlo de una forma más
simple.
Para solucionar los problemas enunciados anteriormente, surge el Concepto de Metodología. Que
no es más que: Un conjunto de Herramientas, modelos y Técnicas que permiten definir
las fases de un proceso de desarrollo y las reglas para pasar de una fase a otra.
Tipos de Metodologías
Se tiene diversas metodologías, desde el Análisis y diseño Estructurado hasta la Metodología

Orientada a Objetos.

Estructurado vs Orientado a Objetos.
Si bien la metodología estructurada ha sido ampliamente utilizada, actualmente se ha impuesto con

gran fuerza la metodología Orientada a Objetos, entre otras causas, el empuje de los lenguajes de
Programación Orientado a Objetos. La adaptación de las Bases de Datos relacionales a este tipo de
metodología ha impulsado también la llegada de las Bases de Datos Orientadas a Objeto puras.
Surgiendo modelos tales como, el objeto-relacional.
La unificación de los métodos, ha permitido también el auge de la Metodología Orientada a Objetos.
Hasta hace pocos años, prácticamente, cada autor proponía su propia metodología, provocando lo
que se llamó guerra de los métodos. Los más conocidos fueron: Booch, OMT y OOSE. Debido a esto
las principales empresas se unieron, para construir una herramienta CASE que se basara en las
características principales de ellos tres y así obtener las ventajas de cada uno de ellos. Racional
Software Co. fue la empresa que promovió esto, apoyada por Microsoft Hewlett-Packard, Oracle e
IBM, quien encargo a los gurús Grady Booch, Ivar Jacobson, y Jim Runbaugh, la construcción de
una metodología que se basara en lo mejor de los tres modelos, surgiendo así UML, siglas de
Lenguaje Unificado de Modelado.

Fases en el Proceso de Desarrollo de un Software
Todo software cuenta con dos fases importantes:

Análisis: Se centra en el que. Proceso donde se definen requisitos, necesidades, funcionalidades.
Diseño: Se centra en la solución. En el cómo se satisfacen esas necesidades y requisitos.
Tanto la metodología estructurada como la orientada a objetos, deberían satisfacer esta división de
pasos, pues se puede especificar y abordar el proceso de forma más simple.
ANALISIS de un sistema.
El análisis de un sistema es el proceso de clasificación e interpretación de hechos, diagnósticos de
problemas y empleo de la información para recomendar mejoras al sistema. En esta etapa los
analistas se encargan de analizar los requerimientos del sistema.
Su propósito es la obtención de una especificación detallada del sistema de información que
satisfaga las necesidades de los usuarios. Por lo que centra la atención principalmente, en la
interacción con los usuarios.
DISEÑO de un sistema
Se realiza el diseño del sistema a partir de la información recolectada anteriormente. El analista
diseña la captura de datos, salidas del sistema, tratamiento de errores, la interfaz del sistema, las
bases de datos, etc.

Orientación a Objetos
La programación estructurada tradicional se basa fundamentalmente en la ecuación de Wirth:
Algoritmos + Estructuras de Datos = Programas
Que significa, que, en la programación estructurada u orientada a los procedimientos, los datos y el
código se tratan por separado. Lo único que se realiza son funciones o procedimientos que tratan
esos datos y los van pasando de unos a otros hasta que se obtiene el resultado que se desea.
La programación orientada a objetos, POO (OOP, Object Oriented Programming, en inglés), tiene
como soporte principal el objeto. Un objeto es una extensión de un tipo abstracto de Datos (TAD),
concepto ampliamente utilizado desde los setenta. Un TAD es un tipo de dato definido por el
usuario, que encapsula un conjunto de datos y sus procedimientos sobre estos datos.

Ventajas de la Orientación a Objetos
Las ventajas más importantes son:
Mantenibilidad: Facilidad de Mantenimiento. Los programas que se diseñan utilizando el

concepto de orientación a objetos, son más fáciles de leer, comprender.
Modificabilidad: Facilidad de Modificar los programas. Es fácil realizar añadidos o supresiones al

programa, solamente añadiendo, suprimiendo o modificando los objetos.
Reusabilidad: si se han diseñado correctamente los objetos, pueden ser utilizados numerosas
veces y en distintos proyectos.
Fiabilidad: los programas que utilizan el concepto de orientado a objetos, suelen ser más fiables,
debió a que se utilizan objetos, ya definidos ampliamente testados.
Todas ellas son aplicables a cualquiera de las fases del ciclo de vida de un proyecto de software.

Conceptos Básicos de la Orientación a Objetos
• Abstracción.
Es un Proceso mental por el que se evitan los detalles, para centrarnos en las cosas más
genéricas. Es aquella característica que nos permite identificar un objeto a través de sus
aspectos conceptuales. Las características de los objetos pueden ser tan diferentes que
puede costarnos reconocer que pertenecen a una misma clase, sin embargo, nosotros
reconocemos a que clase pertenecen, gracias a la Abstracción.
• Clase:
Es una descripción de un conjunto de objetos similares. Por ejemplo, la clase carro.
• Objeto:
Es una cosa. Extraída del vocabulario del espacio del problema o de la solución. Todo objeto
tiene un nombre (se le puede identificar), un estado (generalmente hay unos datos
asociados a él), y un comportamiento (se le pueden hacer cosas al objeto y él puede hacer
cosas a otros objetos). Ejemplo, un objeto de la clase carro puede ser un Ford Fiesta
• Atributos:
Característica concreta de una clase. Ejemplo, los atributos de la clase carro pueden ser:
Color, Numero de Puertas, etc.
• Método:
Una operación concreta de una clase. Ejemplo, la clase carro puede tener el método
Arrancar (pone en marcha al carro), acelerar (hace que sea más veloz el carro), etc.
• Instancia:
Manifestación Concreta de una clase (un objeto con valores concretos). Ejemplo un carro,
Ford fiesta de color plateado con cinco puertas.
• Herencia:
Mecanismo a partir del cual se pueden crear nuevas clases a partir de otra ya existente.
• Polimorfismo:
Es la posibilidad que dos métodos implementen distintas acciones, aun cuando ambos
tengan el mismo nombre.

Conceptos Básicos Generales.
Datos.
Son las características propias de cualquier entidad. Por ejemplo: los datos de una persona como su
edad, fecha de nacimiento, domicilio, número de teléfono, etc.
Información
Es el conocimiento relevante producido como resultado del procesamiento de datos y adquirido por
la gente para realzar el entendimiento y cumplir ciertos propósitos.
Importancia de la información.
La información es un recurso más de cualquier organización o empresa. Ella no es sólo producto de
la conducción de una empresa sino que también, alimenta a los negocios y puede ser el factor crítico
para el éxito o fracaso de cualquier empresa o proyecto acometido.
Formas del Manejo de Información.

▪ Como recurso.
Se debe Manejar como se maneja cualquier otro recurso de la empresa tales como materias
primas, tiene costos asociados a ella. Tales como la distribución, la producción, seguridad
almacenamiento y recuperación. Sirve para posicionar la competitividad de un negocio.
▪ Información generada por Computadora.
La computadora es esencial en el manejo de información, su utilización también implica
costos, por lo general hay mayor información en ellas que manualmente.

Sistema.
Un sistema es un conjunto de componentes que interaccionan entre sí para lograr un objetivo
común.
▪ Ejemplo de Sistemas:
o El Sistema nervioso es un sistema y está compuesto por los siguientes elementos:
Cerebro / Medula espinal/ Los nervios/ Las células sensoriales.
o El lenguaje es un sistema y está compuesto por:
Palabras/Símbolos
o Otros sistemas.
▪ Sistema económico, Sistema legislativo, Sistema de encendido de un
automóvil.
o Organización como Sistema
Una organización es un sistema, sus componentes trabajan juntos para crear utilidades
que beneficien tanto a los empleados como a la compañía.
Está compuesto de diversos departamentos, donde trabajan diversas personas, con un
objetivo común, mejorar y crecer a esta organización; tales como: Mercadotecnia,
Manufactura, Ventas, Investigación, Embarques, Contabilidad, Persona, etc.l
Cada uno de estos componentes es a su vez un sistema que también se compone de
elementos para lograr un objetivo común. Estos elementos se relacionan a través del
Sistema de Información.
Sistema de Información.
▪ Que es un Sistema de Información?

Toda organización depende en mayor o menor medida de una entidad abstracta
denominada Sistema de Información. Es el medio por el cual fluyen los datos, de una
persona o departamento a otro, y puede ser cualquier cosa desde la comunicación interna
entre los diferentes componentes del sistema hasta sistemas de cómputo que generan
reportes periódicos para varios usuarios.
Formada por un conjunto de elementos, que interactúan entre sí para procesar los datos y la
información, para distribuirla de la manera más adecuada posible, en una determinada
organización en función de sus objetivos.
Puede estar basado en el uso de computadoras.

▪ Finalidad de un Sistema de Información.
La función principal de los sistemas de información es proporcionar servicios a todos los
demás sistemas de la organización y enlazar todos sus componentes en forma tal que estos
trabajen con eficiencia para alcanzar el mismo objetivo.
Los sistemas de información procesan entradas, mantienen actualizados archivos de datos,
producen información, reportes y otras salidas.
Aplicación.
Conjunto particular de subsistemas utilizados, equipo específico, programas, archivos y
procedimientos, están formados por subsistemas que incluyen Hardware, Software y
Medios de almacenamiento.
Elementos de un Sistema de Información.

Personas.
Datos.
Actividades.
Recursos Materiales.
Características de los Sistemas.

Todos los sistemas tienen características similares que son las siguientes:
▪ Todo sistema interactúa con un medio.

Para alcanzar objetivos el sistema interactúa con su medio ambiente.
Por ejemplo: La universidad interactúa con varias organizaciones teles como la alcaldía,
impuestos, la fábrica Fancesa, etc.

Medio ambiente: Está formado por todos los objetos que se encuentran fuera de la frontera del
sistema.
Sistemas abiertos: Aquellos sistemas que interactúan con su medio ambiente.
Sistemas cerrados: Aquellos que no interactúan con el medio ambiente.
▪ Los Sistemas tienen Niveles Aceptables de Desempeño.

Cuando los niveles son aceptables entonces decimos que está bajo control.
Ejemplo1:
Una fiebre alta trae consigo un cambio drástico en las funciones del cuerpo, por lo que el
sistema deja de funcionar y permanece inactivo hasta que se corrija su condición. Si no se
corrige esta condición, las consecuencias pueden ser fatales para el sistema.
Ejemplo2: Para que la universidad funciones por ejemplo, es necesario que hayan 50000
estudiantes, 2000 docentes, 10 000 asientos y 40 por aulas, un presupuesto anual de 100
000000, como muestra la siguiente figura.
De esto se desprende que todo sistema tiene un modelo de control básico que se explica a
continuación:
➢ Un estándar para medir el desempeño actual.
➢ Un método para medir el desempeño actual.
➢ Un medio para comparar el desempeño actual contra el estándar.
➢ Un método de retroalimentación.

▪ Los sistemas pueden estar formados por varios niveles de sistemas y subsistemas
Ejemplo1:
Cuerpo humano, puede estar formado por los siguientes Subsistemas:
o Sistema nervioso.
o Sistema respiratorio.
o Sistema circulatorio.
o Etc.
Ejemplo2:
Las organizaciones están formadas por muchos sistemas, cada una con las características
propias de un sistema general, por ejemplo, la universidad puede estar formada por los
siguientes subsistemas y otros:
Ciclo de vida de un Sistema
¿Qué es el ciclo de vida de un Sistema?

La actividad de desarrollar un sistema se debe organizar, es por eso que se han establecidos
ciclos o fases por las que debe pasar un sistema antes de llegar a término. Es el período de
tiempo que "vive" un sistema informático desde que es pensado hasta que es desechado.
El ciclo de vida de desarrollo de sistemas informáticos puede dividirse en actividades o fases
A continuación, se muestran estos pasos o fases clásicas.

1. Identificación de problemas y oportunidades.
En esta parte el analista debe identificar si existen problemas y cuáles son, a partir de esto
se establecen objetivos para poder lograr la resolución de estor problemas; a través de la
redistribución de componentes y/o la posibilidad de un sistema automatizado que resuelvan
todos esos problemas. Las posibilidades son situaciones que el analista considera que
puedan ser mejoradas con un sistema de información computarizado. Al identificar
objetivos usted estará descifrando que es lo que intenta hacer el negocio, e identificará que
aspectos en un sistema de información ayudará al negocio alcanzar los objetivos. Se realizan
entrevistas para obtener más información se evalúa el alcance del proyecto, y se
documentan los resultados. Intervienen usuarios, analistas, administradores de sistemas
que coordinan el proyecto la salida de esta fase es un estudio de factibilidad que contiene la
definición del problema para que los administradores analicen si continúan el proyecto o
no.
2. Determinación de los Requerimientos de Información.

Se obtiene los requerimientos de información para los usuarios involucrados. Se utilizan
entrevistas cuestionarios, observación; se pueden elaborar prototipos, etc. El analista debe
comprender que información necesitan los usuarios para realizar su trabajo. Se interactúa
bastante con los usuarios. Interviene los usuarios y los analistas. Los administradores de las
operaciones y los trabajadores de las operaciones. El analista necesita saber los detalles de
las funciones actuales del sistema, que actividades realiza, donde las realiza, y cómo las
realiza. Debe preguntar porque utiliza el sistema actual que deben ser consideradas al
diseñar el nuevo sistema y debe saber que aspectos les gustaría más o que cosas no les
gustan.
3. Análisis de las Necesidades del Sistema.

Analiza que es lo que debe tener el sistema. Utiliza diagramas de flujos de datos,
diccionarios de datos, para describir todos estos aspectos. Analiza las decisiones estructuras
que se toman, acciones y reglas de acción. También se analizan las decisiones
semiestructuradas (decisiones bajo riesgo). Que son analizadas en función del grado de
habilidad del tomador de decisiones, el grado de complejidad del sistema y la cantidad de
criterios considerados cuando se toma la decisión. En esta fase el analista propone que debe
ser hecho y plantea alternativas y análisis de costos y beneficios. No existe una sola solución
para cada problema, la solución depende del grado de experiencia y habilidades que tenga el
analista de sistemas.

4. Diseño del Sistema.
Se realiza el diseño del sistema a partir de la información recolectada anteriormente. El
analista diseña la captura de datos, salidas del sistema, tratamiento de errores, la interfaz
del sistema, las bases de datos, etc.
5. Desarrollo y Documentación del Sistema

El analista trabaja con los programadores, para desarrollar software que se necesita.
6. Pruebas.
Se prueba el sistema desarrollado utilizando los diferentes tipos de pruebas, aspecto que se
estudiará más adelante.
7. Implantación y evaluación del sistema

Se pone en ejecución el nuevo sistema.
Objetivos del Análisis de Sistemas:
Especificar un Sistema de Información que ayude a conseguir los Fines de la Organización.

Dotar a la Organización de un Sistema Informático que satisfaga las necesidades de los usuarios.
Mejorar la productividad de los diferentes departamentos de la Organización.
Facilitar la Comunicación y Entendimiento entre los distintos participantes, teniendo en cuenta su
papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
Usuarios
• ¿Quiénes Son los Usuarios?

Los usuarios son las personas que solicitan la realización de un sistema de información o mejora
de este.
• Importancia de los Usuarios.

Involucrar a los usuarios en el proyecto es esencial; su participación puede asegurar o no el
éxito del sistema una vez terminado. Son un componente esencial en el desarrollo de un
sistema.

▪ Tipos de Usuarios.
Usuario Final directo: Opera el sistema. Interactúa directamente con el mismo
Usuario final indirecto: Emplea los reportes y otro tipo de información, pero no opera el
sistema.
Administradores: Supervisa la inversión en el desarrollo o uso del sistema. Tiene la
responsabilidad ante la organización de controlar las actividades del sistema.
Directivos: Incorpora los usos estratégicos y competitivos de los sistemas de información en
los planes y estrategias de la organización. Evalúa los riesgos, a los que se expone la
organización originados por fallas en los sistemas de información.
¿Quién es el Analista de Sistemas?

Es el que realiza el análisis de sistemas, analiza una situación y llega a conclusiones sobre la misma
y plantea soluciones.
Responsabilidades del Analista.
▪ Debe comprender los detalles de una situación y decidir si es fiable o no la automatización.

▪ No sólo busca procesos manuales para llevarlos a la computadora, estudia un proceso y lo
evalúa, y determina si son necesarios cambios, estos deben ser resultados no un intento.
▪ No debe ir detrás de ideas atractivas a menos que estas mejoren la organización.
▪ Los analistas tienen la responsabilidad de identificar las características importantes y necesarias
que deben tener los nuevos sistemas.
▪ El analista especifica la forma en que va a operar el sistema y sus subsistemas, las entradas
requeridas, las salidas que debe producir y los trabajos que se producirán tanto por las
computadoras como de forma manual.
▪ Describir los elementos de control tales como estándares o métodos para evaluar el desempeño
también es su responsabilidad.

Cualidades del Analista.
Un analista exitoso deberá poseer un gran número de cualidades. Entre ellas podemos citar:
• Solucionador de problemas: Es una persona que disfruta de retos y busca las mejores
soluciones para todos.
• Buen comunicador: Al realizar el análisis debe interactuar con muchos usuarios por lo que
deberá saber comunicarse con todos y poder capturar para todos sus expectativas.
• Saber programar y tener experiencia: Para el desarrollo de un sistema automatizado el
analista deberá conocer y seleccionar técnicas; establecer las pautas de programación para
dar las mejores soluciones.
• Autodisciplinado y automotivado: Debe poder establecerse metas y lograrlas; esto no podría
ser sin disciplina; que solamente será controlada por el mismo: Además para lograr esto se
debe motivar constantemente.
• Entre otras cualidades debe ser capaz de dirigir a otras gente, manejar recursos, activo,
creativo, paciente, educado, sociable, amable, No egoísta, servicial y en constante
superación.
Papel del Analista
▪ Como consultor: Puede ser contratado para que se encargue de los asuntos de los sistemas de
información en una empresa. Pueden ser consultores internos o externos.
▪ Como experto de soporte: El analista se apoya en su experiencia relacionada con el hardware y
software y su experiencia en el negocio. Por lo general no es un proyecto de sistemas completo
sino solamente algunas modificaciones en un departamento específico.
▪ Como agente de cambio: Es el papel de mayor responsabilidad, el analista desarrolla planes de
cambios y trabaja con otros para llevar a cabo estos cambios. Debe buscar siempre mejoras y no
realizar cambios porque si ó se le antoje. Debe interactuar constantemente con todas las
personas que se encuentran involucradas en el proyecto para lograr éxito. Además, debe tomar
en cuenta la capacitación de las personas que se involucrarán en el proyecto una vez realizados
los cambios.

¿Quién es el Ingeniero en Sistemas?
▪ El ingeniero de Sistemas estará a cargo de las diversas tareas incluyendo el Análisis de Sistemas.
▪ Por lo general Trabajará en una organización o empresa.
▪ Tomará en cuenta el uso de la computadora para realizar mejoras a la empresa.
Trabajo del Ingeniero de Sistemas.

El ingeniero en sistemas puede realizar los siguientes trabajos.
▪ Análisis de Sistemas.
La única responsabilidad es conducir estudios de sistemas para detectar hechos relevantes
relacionados con la empresa. Su función más importante es reunir información y
determinar los requerimientos.
▪ Análisis y Diseño de Sistemas.
Además de llevar a cabo el análisis tiene la responsabilidad adicional de diseñar el nuevo
Sistema.
▪ Análisis, Diseño y Programación de Sistemas.
Conduce el análisis, el diseño y la programación (analista programador)
En empresas pequeñas tiene más funciones que en empresas grandes.
Podrá desempeñarse con éxito como creadores de software, consultores independientes,
líderes de proyectos o gerentes de sistemas.
 Podrá insertarse en el mercado regional e internacional, en cualquier ámbito donde la
computación sea un factor de competitividad.
 Adaptarse al constante cambio en la industria informática e integrarse a equipos
multidisciplinarios de investigación en el desarrollo de nuevas tecnologías.
 Diseñar y desarrollar sistemas informáticos de gran porte y complejidad en áreas tan
diversas como la gestión en tiempo real, información geográfica, videojuegos, control
industrial y Sistemas de Información Gerencial.
Resultados del análisis

 Se obtiene un modelo de lo que se quiere construir.
 Modelo: Simplificación de la realidad que describe un sistema desde una perspectiva dada.
 El modelo se crea a partir de los requerimientos del usuario.
 Para resolver los problemas en la entidad objeto de estudio

Modelado de Datos.
Corresponde a la documentación del diseño de un sistema, en el se especifican de manera formal
sus componentes y sus funciones. Se usan para representar las necesidades relacionadas con los
datos de un proceso de negocio. En este modelo se muestran los aspectos estáticos como las
entidades, los objetos, sus propiedades, y las relaciones entre ellos. También los aspectos dinámicos
como las operaciones que realizan.
Tipos de modelados de Datos:

• Modelo Conceptual.
• Modelo lógico.
• Modelo físico
Modelo Conceptual: Representa una visión general del Sistema

Modelo lógico: Visión Completa de la Organización, incluyendo todos los detalles de los datos
Modelo Físico: Esquema que muestra la implementación de los datos en una aplicación de bases de
Datos.
Los modelos utilizables son:

• Seguros: Describen correctamente el sistema a ser construido.
• Consistentes: Las diferentes vistas no expresan cosas que estén en conflictos con otras.
• Fáciles de comunicar a otros.
• Fáciles de cambiar.
• Comprensibles: Tan simple como sea posible, pero no los más simples.
La organización
La organización es un sistema, que comprende un sistema de información a su vez. Una empresa,
una institución, son organizaciones, que juegan un rol importante en la sociedad.
Están compuestas de diversos departamentos, donde trabajan diversas personas, con un objetivo
común, mejorar y crecer a esta organización.
Estos elementos se relacionan a través del Sistema de Información y conforman un Sistema con
todas sus características que ya se han estudiado.
Está compuestos por subsistemas interrelacionados que cumplen funciones especializadas.
Convenio Sistemático entre personas para lograr algún propósito específico.
Son Sistemas Sociales.

Ambientes Organizacionales
 Ambiente Externo.
❑ Son instituciones o fuerzas fuera de la organización, relevantes para sus
operaciones, afectando el rendimiento de la organización.
 Ambiente Interno.
❑ Llamado Clima Organizacional
❑ Grupos o Elementos de Interés Interno, que ejercen influencia directa en las
actividades de la organización, y caen dentro del ámbito y responsabilidad de un
director y/o sus gerentes.
❑ Además, esto hace más amena la influencia del orden y organización.
La Empresa
Es una Organización.
Toma las decisiones sobre la utilización de factores de la producción para obtener bienes y servicios
que se ofrecen en el mercado.
La actividad productiva consiste en la transformación de bienes intermedios (materias primas y
productos semielaborados) en bienes finales, mediante el empleo de factores productivos
(básicamente trabajo y capital).
Para poder desarrollar su actividad necesita disponer de una tecnología que especifique que tipo de
factores productivos precisa y como se combinan.
Es el instrumento universalmente empleado para producir y poner en manos del público la mayor
parte de los bienes y servicios existentes en la economía.
Engloba una amplia gama de personas e intereses ligados entre sí mediante relaciones contractuales
que reflejan una promesa de colaboración.
La empresa debe adoptar una organización y forma jurídica que le permita realizar contratos, captar
recursos financieros, si no dispone de ellos, y ejerce sus derechos sobre los bienes que produce.
El Empresario.
El empresario es la persona que aporta el capital y realiza al mismo tiempo las funciones propias de
la dirección:
 Organizar.
 Planificar.
 Controlar.
Desde esta perspectiva, la figura del empresario aparece como una pieza básica, pues es el elemento
conciliador de distintos intereses en la empresa.

Las Instituciones
Las instituciones son mecanismos de orden social y cooperación que gobiernan el comportamiento
de un grupo de individuos (que puede ser reducido o coincidir con una sociedad entera) mediante la
elaboración e implantación de reglas.
El término institución se aplica comúnmente a las normas de conducta y costumbres consideradas
importantes para una sociedad, como las particulares organizaciones formales de gobierno y
servicio público.
Derivado del origen etimológico de institutio (en latín educación), una institución es un
establecimiento u organismo que realiza una labor social de tipo educativo y cultural, como los
institutos de enseñanza o investigación o los museos. Del mismo origen vienen instrucción,
instructor e institutriz.
El término institución no tiene por qué ser un lugar físico. Una institución es, por ejemplo, el
conducir un automóvil por la derecha en ciertos países. Por ejemplo: La Universidad, La Corte
Suprema, Superior, Etc.
Una Organización es un Sistema.

 Están formado por varios niveles de sistemas y subsistemas, cada una con las características
propias de un Sistema.
 Para realizar el Análisis se toman en cuenta algunas características como son:
❑ Canales Formales.
❑ Interdependencias.
❑ Personas y Funciones Claves.
❑ Enlaces Críticos de Comunicación.
Canales Formales.
¿Qué interacciones existen entre las personas y los departamentos que no aparecen descritos en el
Organigrama?
Ejemplo:
Secretaria, recibe la solicitud de acta que entrega al Gerente, para que autorice la entrega del acta
al solicitante.

Interdependencias.
¿De qué otros departamentos y componentes de la organización depende un elemento en

particular?
Ejemplo:
El departamento de Planillas ubicado en la central necesita que la facultad le envíe la

información necesaria para elaborar las planillas de sueldo.
Personas y Funciones Claves.
¿Cuáles son las personas y elementos más importantes en el sistema para que éste tenga éxito?
Ejemplo:
El director del departamento de Informática es clave en la toma de decisiones relacionadas con la

compra de equipos y nuevas tecnologías.
Enlaces Críticos de Comunicación.
¿Cuál es el flujo de información e instrucciones entre los distintos componentes de la organización?,

¿Cómo se comunican las áreas entre sí?
Ejemplo:
Cada dirección envía mensualmente el informe de asistencia de sus empleados a la gerencia general,
que se encarga de enviar al departamento de planillas de la institución, para elaborar los sueldos de
los empleados que podrán cobrar en el banco.
Niveles de Administración
• Administración de Operaciones.
• Administración Media.
• Administración Estratégica.
Administración de Operaciones:
Forma el nivel inferior de la administración. Los administradores de operaciones toman
decisiones usando reglas predeterminadas que tienen resultados predecibles cuando son
implementadas correctamente. Su trabajo es claro, tiene un alto grado de certeza al tomar
decisiones. Aseguran que se logren las actividades básicas en una organización en tiempo y de
acuerdo con las restricciones organizacionales.

Sus decisiones están relacionadas con la calendarización del trabajo, control de inventario,
envío, recepción y control de procesos tales como la producción. Las decisiones tomadas
tienden a ser repetitivas. Las decisiones que toma son fáciles de enumerar. Es fácil identificar
los problemas.
Administración Media
Forman el segundo nivel de administración ó nivel intermedio. Realiza decisiones de planeación
y control a corto plazo sobre la manera en que son organizados los recursos. Experimenta muy
poca certeza en su ambiente de toma de decisiones. Sus decisiones van desde la predicción de
requerimientos futuros de recursos hasta la resolución de problemas de personal que amenacen
la productividad.
Administración Estratégica.
Comprende el tercer nivel de administración. Van fuera de la organización hacia el futuro.
Toman decisiones que guiarán a los medios y operacionales en los meses y años por venir.
Trabajan con alta incertidumbre. Se dedican a decidir sobre si se desarrollan nuevas líneas de
productos, renuncia a empresas no rentables, adquiere o no otras compañías compatibles, o si
ella misma será vendida. Tienen múltiples objetivos de decisión, es difícil la identificación de
problemas.
Cultura Organizacional
Una organización incluye diferentes subculturas.
Identificación de subculturas:
Usted debe identificar las subculturas, esto lo puede realizar guiándose por los siguientes
criterios:
• Simbolismo verbal: incluye las frases, el lenguaje compartido, humor, visiones, etc.
• Simbolismo no verbal: incluye la vestimenta, la decoración, artefactos, ritos, y
ceremonias compartidas.
Tipo de Subculturas:
• Subcultura Oficial: La cultura oficial impone la forma de vestir, como dirigirse a
sus superiores y compañeros, formas de tratar con el público externo.
• Otra Subculturas: Existen, pero no son predominantes, puede haber varias.

Características de las Subculturas.
• Las subculturas coexisten dentro de una organización. Es decir, hay varias y buscan
la forma de existir sin problemas entre ellas.
• Los miembros de una organización pueden pertenecer a varias subculturas.
• Las subculturas ejercen influencia sobre el comportamiento de los miembros en una
organización.
• Las subculturas pueden también ser competitivas; pueden estar en conflicto
tratando de ganar adeptos a su visión de lo que debe ser la organización.
Importancia de la Identificación de Subculturas.

La comprensión de las subculturas puede ayudar al analista venza la resistencia al cambio.

Medios para obtención de Información
Para comenzar el desarrollo de un sistema, se debe conocer primero el objeto de estudio, y a los
usuarios. Es importante conocer cómo funciona, cuales son interacciones, conocer el sistema de
información y las necesidades nuevas que existen. Es por ello que para esta búsqueda usted requiere
estudiar los medios que le permitirán hacer esto. Entre esos medios se encuentran las entrevistas,
cuestionarios, y otras técnicas. En este tema, comprenderá a profundidad en qué consisten las
entrevistas y los cuestionarios. Aprenderá como realizarlos y cuando. Para encontrar la información
relacionada a los siguientes elementos:
• Hechos: Que indicará que actividades se realizan en el negocio.
• Información Financiera: Esto brindará ayuda de cómo se manejan los recursos y si existe o
no disponibilidad para desarrollar el sistema.
• Contextos Organizacionales: Conocer las relaciones del negocio con otros establecerá
también pautas para la toma de las mejores decisiones para la organización y su entorno.
• Tipos de documentos: El analista debe comprender para quienes y para qué son realizados
estos documentos en el negocio.
• Problemas: El conocimiento de los problemas que puede haber son indicadores de
oportunidades para realizar mejoras al negocio.
En este tema, tiene asociado un documento que incluye un resumen de preguntas que usted puede
usar para hacer sus entrevistas. Deberá redactarlas en función del trabajo que este realizando.

Entrevistas
Que es una Entrevista

Se entiende por Entrevista, a la comunicación entre, un analista o miembro del grupo de trabajo de
desarrollo de un sistema y un usuario portador de información importante para el trabajo que se
desarrolla con un propósito bien definido. Las entrevistas se basan en un formato de preguntas y
respuestas.
Información Buscada en la Entrevista.

Entre la información que se busca se encuentran:
1.- Opinión del Entrevistado
2.-Sentimientos Acerca del Sistema Actual.
3.- Objetivos de la organización y Personales.
4.-Procedimientos informales.
1. Opinión del entrevistado. (Veamos el siguiente fragmento de una entrevista)
Ana María dueña de una fábrica de lácteos, es entrevistada por José,

analista de sistemas del equipo de desarrollo de software y le pregunta:
José: - ¿Cuantas devoluciones de productos recibe por día?
Ana María: - 20 a 30 devoluciones.
Cuando José termina la entrevista y revisa los documentos de devoluciones, descubre

que solamente son unas 10 devoluciones por semana. Ana María, había estado
exagerando.
Hubiera sido mejor preguntarle a Ana María cuáles son sus preocupaciones principales a
lo que hubiera respondido la cantidad diaria de devoluciones, aspecto que el analista
hubiera tomado de otra forma. Para Ana María es muy importante y un grave problema
las devoluciones, ella está sumamente preocupada.
De ahí que la opinión del entrevistado es sumamente importante que se conozca. En

muchas ocasiones nos permitirán determinar los problemas reales que existen en la
entidad objeto de estudio.

2. Sentimientos acerca del Sistema Actual.
Ayuda a capturar las emociones y actitudes. También ayuda a comprender la cultura de la

organización. Los sentimientos se capturan solamente mediante preguntas que la respuesta
deba expresarlos. Una respuesta “Me siento bien que usted esté realizando estos
cambios”; es síntoma de que el sistema y su desarrollo marchará bien.
3. Objetivos de la organización y personales.
Los objetivos proyectan el futuro de una organización. Conocerlos le dará pautas de cuáles
serían las propuestas de sistemas más acorde con dichos objetivos. Pero no solo los de la
organización, conocer los interese personales de los usuarios para poder ayudarles a
conseguirlos es importante también. Recuerde que todo ser humano tiene intereses de algún
tipo y estos deben ser también logrados, además usted debe vender un sistema.
4. Procedimientos informales.
Deberá conocer la forma de trabajo de las personas con el sistema, que actividades realizan y
con qué objetivo. Esto le ayudará obviamente a desarrollar un sistema para los usuarios.
Importancia de las Entrevistas.

Es una de las fuentes más valiosas para la obtención de información. La razón principal para hacerla
es buscar información. Tome en cuenta que debe desarrollar un sistema, y para ellos si no realiza
una investigación sobre que va a hacer, no podrá crear un sistema.
En la misma el entrevistador debe explicar su trabajo, así como también recopilar información
creando de esta forma un clima favorable para la realización del nuevo sistema.
Pasos de las Entrevistas.

El desarrollo de una Entrevista se divide en tres pasos:
1. Preparación.
2. Realización.
3. Resumen.

1.- Preparación
La entrevista debe ser previamente preparada cuidadosamente, nunca se debe improvisar y de antemano se
debe ir sabiendo que se espera de ella. Primero se debe examinar que es lo que se quiere conocer para luego
seleccionar la persona o personas necesarias para este objetivo. Para esto es importante conocer las
características del usuario, pues de esta forma las relaciones con el mismo se pueden mejorar.
Aspectos a desarrollar en la preparación:

1. Lectura de material de fondo: Lea y comprenda a fondo tanto material, revistas, artículos, etc. Sobre el
entrevistado y la organización. Sensibilícese con el lenguaje particular que utilizan, construya un
vocabulario común con los miembros del equipo, con esto logrará escribir preguntas mejores y conectar
más rápidamente con el entrevistado, además le ahorrará tiempo haciendo preguntas generales sin
importancia que ya conoce con la lectura.
2. Establecer los objetivos de la entrevista: Deberá seleccionar las áreas sobre las cuales deberá buscar
información, basado en su propia experiencia y en lo que ha aprendido de la empresa.
3. Decidir a quién entrevistar: Decida quién será la persona que podrá darle la información que requiere, el
contacto en la organización también podrá orientarle sobre a quién entrevistar.
4. Preparar al entrevistado: Para realizar la entrevista debe hablar primero con el entrevistado y fijar fecha y
hora en que le puede atender y darle la información que requiere.
5. Decidir sobre tipos de preguntas y estructuras: Redacte las preguntas tomando en cuenta las
características del usuario para la selección de la estructura y tipos de preguntas a realizar.
Preguntas:
Son la base de una entrevista. Las preguntas deben redactarse con cuidado, previendo que cumplan el
objetivo de la entrevista.

Tipos de Preguntas
❖ Abiertas: Aquellas cuyas respuestas lo mismo ❖ Cerradas: Limitan la respuesta del
pueden ser de dos palabras o dos párrafos, según entrevistado, a un número finito tal
el entrevistado. como uno ó ninguno, limita la
¿Qué piensa usted del sistema actual? respuesta del entrevistado.
¿Cuál es su opinión acerca del sistema automatizado ¿Cuántos reportes genera por día?
que utiliza? ¿Desde cuándo trabaja aquí?
¿Qué problemas experimenta con el funcionamiento ¿Quién recibe esta salida?
del sistema? Ventajas:
Ventajas Se ahorra tiempo.
Proporciona mayor nivel de detalle. Se mantiene el control de la
Se conoce mejor el vocabulario del entrevistado entrevista.
Muestra información que no se había tomado en Son fáciles de resumir.
cuenta. Desventajas
Permite elaborar nuevas preguntas. Pueden ser aburridas.
Desventajas No permite conocer mejor al
Puede perderse el hilo de la entrevista. entrevistado.
Puede que se den detalles irrelevantes. Se pueden perder ideas que no se
Lleva más tiempo tomar las notas. han tomado en cuenta.
Lleva más tiempo el resumen.
Averiguaciones: El objetivo de este tipo de pregunta es ir más allá.
Ejemplos:
¿Por qué?
¿Puede darme un ejemplo?
¿Me podría hablar más de esto?
Errores en las Preguntas

• Tendenciosas: Obligarlo a dar una • Dobles: se realizan dos preguntas a la
respuesta ¿está de acuerdo en ____ vez ¿Qué es ...? Y ¿por qué?
cómo los otros gerentes?
Orden Lógico en las Preguntas

Las formas de razonamiento humano son • Inductivo.
inductivo y deductivo. Lo mismo se aplica para • Deductivo.
la redacción de preguntas. Combinar el inductivo y deductivo.

Estructura de las entrevistas
• Pirámide • Embudo • Diamante
• Se comienza con • Se comienza con preguntas abiertas y • Combina las dos

preguntas luego preguntas cerradas. anteriores.
cerradas y luego • Una entrevista sin comprometerla. • Requiere más tiempo.
preguntas • Cuando el entrevistado está
abiertas. comprometido sentimentalmente con
• Para encadenar el tópico.
preguntas para
llegar al final.
Entrevistas no estructuradas o sin estructura: Son entrevistas que se realizan sin tomar
ninguna estructura estudiada anteriormente.
Comparación de las entrevistas estructuradas y no estructuradas

Criterios de comparación No Estructurad Estructurada
Evaluación Difícil Fácil
Cantidad tiempo Mucho Poco
Entrenamiento Mucho Limitado
Espontaneidad Mucho Poco
Permite conocer entrevistado Mucho Poco
Flexibilidad Gran Poco
Control de la entrevista Bajo Alto
Precisión Baja Alta
Confiabilidad Baja Alta

2.- Realización
En la realización de la entrevista, se puede definir que, existen tres puntos clave:
• El inicio.
• La realización como tal.
• La conclusión o finalización de la entrevista.
Inicio:
El inicio corresponde al momento en que se comienza la entrevista donde el entrevistador debe identificarse y
explicar los objetivos.
La realización como tal de la entrevista
Durante este paso, el entrevistador debe lograr un clima de confianza con el entrevistado, para esto debe
escuchar con interés, no hacer críticas, no discutir, resolver las contradicciones, adaptar sus preguntas al nivel
del entrevistado, empleando una terminología adecuada. El entrevistador debe tomar nota o utilizar
grabadora si el entrevistado lo permite. Durante la realización de la misma se deben recopilar también
documentos que puedan ser útiles.
Medios usados:
Uso de grabadora: Se debe preguntar la opinión al entrevistado sobre el uso de la grabadora. Si está de
acuerdo se puede usar sino no.
Toma de notas: Se utiliza papel y lápiz.
Solución de problemas durante la entrevista.

• Percibir que la autoestima se encuentra amenazada: Cambiar la forma de la pregunta.
• Reacciones emotivas a temas conflictivos: dar el tema por terminado e ir a otro punto.
• Malentendidos. Hacer estudio de antecedentes, si ocurren, señalar las discrepancias y observar la
reacción si persiste entonces hacer investigación posteriormente.
• Apego a formas tradicionales. (sexos, machismo, feminismo, etc.) aclarar con franqueza y honestidad y
que no incomoda ninguna respuesta.
• Equívocos al inferir sobre lo observado: cuando el entrevistado infiere alguna observación que no ha sido
así.
• Competencia por el tiempo: reprogramar la entrevista.
• Olvido de hechos importantes: corroborar los hechos con otros entrevistados o observación o archivos.
• Mentir para ocultar hechos importantes. Crear una atmósfera favorable.
Conclusión o Finalización de la Entrevista
Al terminar la entrevista el entrevistador se debe despedir, mostrar agradecimiento al entrevistado, si se cree
necesaria otra entrevista se debe dejar abierta la posibilidad de otra entrevista.

3.- Resumen
Después de terminada la entrevista el entrevistador debe revisar las notas obtenidas. Estas deben ordenarse y
organizarse por tema, clasificarse, comprobar si no hay contradicciones entre esa entrevista y otras realizadas
anteriormente, de existir, se hará una investigación para resolverlas. El resumen debe capturar la esencia de
la entrevista, se debe realizar tan pronto termine la entrevista para asegurar la calidad de los datos obtenidos
en ella.
Pasos
Resumen Inicial Resumen con mayor detalle.
Importancia del Resumen

Le permite obtener los datos más importantes de la entrevista realizada
Le ayuda a planear las próximas entrevistas
Formato Sugerido para el Resumen

Entrevistado Fecha
Entrevistador Tema
Objetivos de la entrevista
Se lograron los objetivos:
Puntos Principales de la entrevista Opinión del Entrevistador

Cuestionarios
Que es un cuestionario.
El cuestionario es otro instrumento de recopilación de información, está destinado a obtener las
respuestas de preguntas que vienen impresas en un documento que debe ser llenado por la persona
que responde.
Información que se busca cuando se utiliza cuestionarios.

Actitudes, creencias, comportamientos y características de varias personas de la organización que
pueden ser afectadas por el sistema actual y propuesto.
Actitudes: Es lo que la gente dice que quiere.
Creencias: Es lo que la gente piensa.
Comportamientos: Es lo que hace la gente en la organización.
Características: Son las propiedades de las personas o cosas de la organización.
Cuando utilizar.
Los cuestionarios deben ser utilizados para obtener:
❖ Información de numerosas personas en un corto tiempo.
❖ Respuestas de personas dispersas geográficamente.
❖ Información que pueda consolidarse en tablas analíticas, ya sea por medios manuales o
automatizados.
❖ Para cuantificar lo que ha encontrado en las entrevistas.
❖ Para determinar que tan amplio ó limitado es un sentimiento expresado en una entrevista
❖ Para tratar de encontrar problemas antes que las entrevistas se hayan realizado.
Formas de realizarlos
❖ Realizar primero los cuestionarios y en función de lo detectado hacer entrevistas.
❖ Realizar entrevistas y después cuestionarios.
La forma de realizarlo, será decisión del analista, en función de su propia experiencia, de igual
manera, podrá utilizar las dos formas si así lo requiere.

Pasos para realizar el cuestionario
1. Preparar el cuestionario:
La preparación del cuestionario debe tomarse en serio.
• Se establecen los objetivos; debe establecerse la información que se quiere obtener de
él.
• Decidir quien recibirá el cuestionario.
• Debe Comenzar con una introducción corta y clara explicando el objetivo del
cuestionario.
• Se podrán establecer preguntas filtro, para saber si el encuestado, tiene las
características necesarias para participar de la encuesta.
• Se formulan las preguntas del cuestionario que nos darán la información buscada.
Tomando en cuenta los siguientes criterios:
i. Deben ser muy claras.
ii. El flujo de preguntas debe ser muy coherente.
iii. Las preguntas del interlocutor deben ser anticipadas.
iv. Planeadas a detalle.
2. Realizar la Encuesta
• Determinar la forma de hacer el cuestionario.
i. Reunir a todos los involucrados en un lugar a la vez.
ii. Entregar a los involucrados el cuestionario en blanco y que depositen o lleven a
un lugar específico con un límite de tiempo una vez que lo hayan llenado.
iii. Enviar por correo y especificar una fecha límite para volver a reenviar.
iv. Utilizar medios electrónicos, tales como Internet.
Cada uno de estos métodos tiene ventajas y desventajas, el analista analizará cual será el
método mejor a aplicar.
• Realizar el cuestionario.
Aplicación del cuestionario.
• Cierre del Cuestionario.
Se debe agradecer y despedir. También podría ser el mejor momento para pedir
información de contacto y el nombre.
3. Recapitular
Se llega a conclusiones sobre los objetivos propuestos.

Preguntas en Cuestionarios
Preguntas cerradas.
Ya estudiadas anteriormente.
Pueden ser cuantificadas.
Cuando usar.
Cuando el analista de sistemas sea capaz de listar efectivamente todas las respuestas
posibles a la pregunta.
Cuando todas las respuestas posibles sean mutuamente excluyentes (la selección de una
impide la selección de las demás).
Por ejemplo:
23. A continuación se muestran los paquetes de software disponibles en el centro de

información. Marque el paquete que usted utiliza con más frecuencia.
___WORD ___EXCEL
___WORPAD ___POWER PAINT
___PAINT ___ACCES
24. El paquete actualmente funciona bien

____ De Acuerdo _______ En desacuerdo
25. Si está en desacuerdo, los problemas se presentan

Rara vez A veces Frecuentemente Siempre
1 2 3 4

Preguntas Abiertas
Ya estudiadas anteriormente son analizadas e interpretadas de otra forma, por ejemplo:
40.- ¿Cuáles son los problemas más frecuentes con los que se enfrenta en las salidas de la
computadora?
A___________________________________________________________
_______________________________________________________________
__________________________________________________________
_______________________________________________________________
41.- De los problemas enumerados arriba. ¿Cuál de ellos es más grave?
_______________________________________________________________
___________________________________________________________
42.- ¿Por qué?
_____________________________________________________________
_____________________________________________________________
Comparación de Preguntas Cerradas y Preguntas Abiertas.
Criterios de comparación: Abiertas Cerradas

Velocidad de conclusión Lenta Rápida
Naturaleza exploratoria Alta Poca
Amplitud y profundidad Alta Poca
Facilidad de preparación Fácil Difícil
Facilidad de análisis Difícil Fácil

Diseño de un Cuestionario de Calidad.
• Lograr el objetivo para el cual se diseño.

• Adaptarse al nivel jerárquico y cultural del que responder.
• No inducir a responderlo de una manera determinada.
• Tener un ordenamiento funcional, clasificándolo por temáticas, bien impreso y con
instrucciones claras y precisas.
• Prever la forma en que será procesada la información y su objetivo.
• Simplificar al máximo el trabajo del que responde, utilizando alternativas en las que haya
que marcar SI o NO, una cruz (X), etc.
• Use preguntas cortas
• Evite el uso de lenguaje corriente.
• No suponga un conocimiento muy profundo.
• Asegúrese de que las preguntas sean técnicamente precisas, antes de incluirlas.
• Dejar suficiente espacio en blanco.
• Disponer del espacio adecuado para las preguntas.
• Las preguntas de mayor importancia deben ir primero.
• Agrupar las preguntas por temas.
• Los temas más conflictivos o controversiales deben ir en último lugar.
• Use el lenguaje del interlocutor.
• Mantenga simple la redacción.
Utilización de Escalas en Cuestionarios

Escalar es el proceso de asignar símbolos a un atributo o característica con el fin de poder medirlo.
Se utilizan para
• Medir las actitudes o características de la gente que contesta un cuestionario. Ejemplo
algunos no querrán modificar los informes impresos, otros querrán informes más claros,
otros querrán elementos adicionales.
• Contar con un elemento de juicio sobre los temas de un cuestionario. ejemplo cuando se
necesita saber cómo se evalúa algo, los consultados actuarán como jueces.

Mediciones
Formas de escala de medición:
Formas de Escalas de Medición:
Nominal: Se utilizan para clasificar Ordinal: Permite la clasificación y además
objetos. implica un ordenamiento de rango.
Son la forma de medición más débil Una clase es mayor o menor que otra clase.
Por lo general sólo obtienen totales. La diferencia entre las selecciones no tiene
Ejemplo: que ser la misma. Por ejemplo:
¿Qué tipo de programa utiliza más? El personal del centro de información es:
1. Procesador de texto 1. Extremadamente útil
2. Hoja de cálculo 2. Muy útil
3. Base de Datos. 3. Moderadamente útil
4. No muy útil
5. Nada útil.
De intervalo: Permite la clasificación, ordenamiento por rango, pero con un período de
intervalo de igual tamaño.
Dado que los intervalos son los mismos, se pueden realizar operaciones matemáticas sobre
los datos del cuestionario, permitiendo un mejor análisis. Por Ejemplo:
Escalas de Celsius y Fahrenheit para medir temperaturas.
El personal del centro de información es:
Extremadamente nada
útil útil.
1 2 3 4 5
Proporcional:
Muy parecidas a las de intervalo, pero implica un cero absoluto. El intervalo entre números
es el mismo. Por Ejemplo:
Distancias en una regla.
Cuántas horas dedica en la computadora
0 2 4 6 8
Mediciones de desempeño en la construcción de escalas

Validez en las escalas: Es cuando la pregunta mide lo que el analista trata de medir.
Confiabilidad: Si el cuestionario fue suministrado una vez y otra vez bajo las mismas
condiciones y se obtuvieron los mismos resultados. Mide la consistencia del cuestionario y sus
escalas.

Problemas al Construir Escalas
Indulgencia
El interlocutor califica a la ligera. Califica todo como excelente ó la máxima evaluación.
Por Ejemplo:
El centro de información es
Nada Útil Un poco Útil Muy útil
1 2 3
Se mejoraría poniendo más escalas:

El centro de información es
Un poco Muy Extremadamente
Útil útil indispensable
1 2 3 4 5
Tendencia Central
Sucede cuando el interlocutor evalúa todo promedio.
Por Ejemplo:
Los reportes son
Nunca Útiles Ocasionalmente Útiles Siempre útiles
1 2 3
Se mejoraría poniendo más escalas:

Los reportes son
Nunca Útiles Ocasionalmente Siempre
Útiles Útiles útiles
1 2 3 4 5 6 7
Efecto de Halo.
Es cuando la impresión formada en una pregunta se lleva a la siguiente pregunta.
Ejemplo:
Los reportes mensuales de desempeño son fáciles de leer
Nunca Ocasionalmente Siempre
1 2 3 4 5

Los reportes mensuales de desempeño son precisos
1 2 3 4 5
Los reportes mensuales de desempeño son esenciales
1 2 3 4 5
Solución:
La solución sería no poner preguntas sobre una misma cosa todas juntas, puede ser que a
esta persona le encanten los reportes de un tipo y llevará la misma respuesta a todas las
demás preguntas.
Los reportes mensuales de desempeño son fáciles de leer
1 2 3 4 5
Las gráficas comparativas regionales son fáciles de leer

1 2 3 4 5
Los reportes nuevos de presupuesto son fáciles de leer

1 2 3 4 5
Material para realizar Encuestas
A continuación, se muestran algunas páginas, donde puede realizar encuestas.
• Google Forms
• Encuesta.com
• surveymonkey.com

Otros Medios
Observación
Que es la Observación.
La observación es una técnica mediante la que se lleva a efecto la percepción de la realidad objetiva,
a partir de un procedimiento determinado, el cual permite obtener cierta información acerca de lo
observado. En la observación se distinguen: el sujeto, el objeto y los instrumentos. El primero hace
la observación, el segundo la recibe y los terceros aumentan la capacidad del sujeto para observar al
objeto.
Qué se observa
Al tomador de decisiones: para obtener información del tomador de decisiones.
El ambiente físico: para obtener información del ambiente físico donde trabaja el tomador de
decisión.
Para que se observa

Para obtener información del tomador de decisiones.
Para obtener información del ambiente físico donde trabaja el tomador de decisiones.
Para afirmar ó negar e invertir, lo que ha sido encontrado por medio de las entrevistas,
cuestionarios y otros métodos.
Pasos para la Observación.

1. Decidir que observar
2. Crear escalas para la observación.
3. Decidir el momento de la observación.
4. Ejecutar la observación.

Reglas a seguir para Observar.
• Debe ser estructurada
• Sistemática
• El analista, debe saber qué está observando
• El analista debe saber cuándo, donde, como y porque observa.
Observación del tomador de decisión
Que se busca al observarlo

Busca obtener una percepción de lo que realmente se hace y no sólo de lo documentado ó
explicado.
Se busca ver la relación entre él y sus subordinados.
Qué se observa del tomador de decisiones.

1.-Observación de sus actividades
• Decidirá qué actividades observar.
Ejemplos;
Observará si el gerente (u objeto de observación), comparte libremente información
con los subordinados.
Observará si el gerente (u objeto de observación), controla personalmente la
solución de los problemas.
Observará si el gerente (u objeto de observación), envía una copia del informe de
desempeño a sus subordinados.
i. Creará categorías que capturen adecuadamente las actividades principales.
• Preparará escalas, listas de verificación y otros materiales adecuados para la
observación.
• Decidirá cuando observar.
• Ejecutará la observación.
2.-Observación del lenguaje corporal.

La observación del lenguaje corporal permite que el analista comprenda mejor los
requerimientos de información del tomador de decisiones, añadiendo dimensión a lo que
está diciendo. La interpretación de esto es poco precisa y varía entre culturas.
• Observación del contacto visual.
• Observación de la postura del tomador de decisión.
• Observación del movimiento de los brazos y piernas del tomador de decisión.
• Observación del uso de las manos.

Registro del comportamiento
Para registrar lo observado del tomador de decisiones se utilizan tres técnicas.

• Parejas de adjetivos
• Categorías
• Escalas.
Pareja de adjetivos:
Puede utilizar el siguiente formato tentativo:
Nombre del observador
Nombre del tomador de decisiones Fecha de observación
Hora inicio observación Hora final observación
De cada par encierra en un círculo el adjetivo que describa mejor al tomador de decisiones
1. Enérgico/no enérgico
2. Calmado/ excitado
3. Asertivo/ no asertivo
4. Creíble/no creíble
5. Extrovertido/introvertido
6. Platicador/callado
7. Congruente/incongruente
8. Autoritario/indiferente
9. Con iniciativa/desmotivado
10. Orientado a objetivos/sin orientación
11. Solucionador de problemas/creador de problemas.

Por categorías de Conducta.
Nombre del observador
Nombre del tomador de decisiones Fecha de observación
Hora inicio observación Hora final observación
Cada vez que vea que el tomador de decisiones se involucra nuevamente en el

comportamiento listado, ponga un uno en el cuadro de al lado, de la categoría adecuada.
Comportamiento Cantidad de veces que Total Porcentaje
ocurre el comportamiento total
Instruye a subordinados.
Instruye a sus colegas.
Instruye a sus superiores.
Consulta a subordinados.
Consulta a sus colegas.
Consulta a sus superiores.
Regaña a subordinados.
Regaña a sus colegas.
Regaña a sus colegas.
Abre la correspondencia.
Responde al teléfono.
Hace llamadas telefónicas.
Lee información externa.
Lee información interna.
Procesa la propia información.
Pide a otros que procesen información.
Escalas
Crear escalas para medir el comportamiento del tomador de decisiones
Nada Autoritario Autoritario

1 2 3 4 5
Indeciso Decidido
1 2 3 4 5
etc.

Guion del analista
Se utiliza también para registrar el comportamiento de lo observado. El actor es el tomador
de decisiones.
El actor es listado en la columna izquierda y sus acciones en la columna derecha.
Es un enfoque organizado y sistemático.
Tomador de decisiones Actividad relacionada con la información

(Actor) (Guión)
Gerente de control de Calidad Pide al supervisor del piso que traiga el reporte
de producción del día
Supervisor piso Imprime el reporte de producción diario. Y trata
problemas con control de calidad
Gerente de control de Calidad Lee el reporte de producción.
Etc….
Observación del Ambiente Físico.
Método de observación del Ambiente Físico

El método de observación del ambiente físico se llama STROBE.
Que se busca al observarlo.

Se busca el significado simbólico del contexto de trabajo de los tomadores de decisiones.
Busca la influencia sobre el comportamiento del mismo.
Observando su vestimenta, lenguaje corporal, el analista trabaja para ver que mensajes
envía.
El analista trabaja para comprender la influencia del tomador de decisiones sobre los demás
en la organización.
Que características físicas se Observan

Ubicación de la oficina.
Ubicación del escritorio.
Equipo fijo de oficina.
Artículos personales.
Revistas, periódicos.
Iluminación y color de la oficina.

Vestimenta del tomador de decisiones.
Opciones de Aplicación.
• Análisis de fotografías.
• Enfoque de lista de verificación/escala de Likert: Se realizan escalas con las
características del ambiente.
Escalas para la observación del ambiente físico

1. La iluminación, paredes, pinturas y gráficos están con tonos cálidos, creando
un escenario informal para el intercambio de información.
Paredes con colores Paredes con colores
Fríos, sin decoración cálidos, decoración agradable
1 2 3 4 5
2. La oficina contiene diversas formas de información llevadas desde el exterior

de la organización, incluyendo revistas del negocio, cartas de asociaciones y
periódicos de negocio.
No hay fuentes de información externa Muchas fuentes de información externa
1 2 3 4 5
3. Se encuentran presentes en la oficinas ayudas para el procesamiento de

información y son fácilmente accesibles.
No hay calculadoras o monitores visibles La calculadora o monitor son muy
accesibles sin levantarse del asiento
1 2 3 4 5
4. En la oficina se encuentran muchas piezas para almacenar la información.

No hay archiveros en la oficina Hay cuatro o más archiveros o estantes
1 2 3 4 5
5. El escritorio está dispuesto para maximizar el territorio para el administrador

y limitar el espacio del visitante
El escritorio está puesto contra la pared El escritorio está puesto como una barrera con
poco espacio para el visitante
1 2 3 4 5
6. Usa trajes de negocio convenientes en vez de ropa casual o deportiva.

Usa ropa casual o deportiva Usa ropa de negocio conservadora
1 2 3 4 5
7. La oficina del administrador es fácilmente accesible.
La oficina está situada en un piso La oficina está situada en el mismo
Diferente al de los subordinados piso de los subordinados
1 2 3 4 5
• Listas anecdóticas (con uso de símbolos).

Se utilizan símbolos significativos para avalar una descripción o no.
Narración: Características a analizar
Se pone en forma de tabla y símbolos
Símbolos ó códigos:
Confirma la narración
Niega la narración X
Nota para mirar más allá
Modificar la narrativa
Complementar la narrativa
Ejemplo:
Narrativa dicha por los Ubicación de Iluminación, Vestimenta
miembros de la organización la Oficina y Color y
el equipo Gráficos
La Información está fluyendo X
Libremente en todos los niveles
Juan dice Me imagino los X
Porcentajes yo mismo
Carla dice me gusta leer todas
Estas cosas

Recuperación
La recuperación incluye aquellas técnicas que permiten obtener la información de lugares,

documentos, libros, manuales, etc. en los que se encuentra archivada y clasificada de alguna forma
determinada.
Diagramas de Organización
Un Diagrama de Organización u Organigrama se utilizan para representar gráficamente una

organización, empresa o institución.
En el diagrama se dibujan las unidades de organización, las direcciones, las relaciones y
dependencias entre ellos.
.
• Aspectos a tener en cuenta para la confección de un Organigrama:
• Las unidades más importantes se presentan en la parte superior del gráfico y se añaden
hacia abajo otras unidades de mayor importancia a menor importancia.
• Las unidades que dependen de un jefe común se colocan en un mismo nivel y se vinculan
con éste por líneas continuas.
• Las unidades funcionales aparecen en un plano superior al de las ejecutivas, cuando ambas
pertenecen a un mismo jefe.
• En algunos casos se indica por debajo de cada unidad, sus principales objetivos o tareas.

Técnicas de Trabajo Creativo en Grupo.
Que son
Las técnicas de trabajo creativo en grupos son un conjunto de métodos de trabajo que permiten
obtener la experiencia y conocimientos de un grupo de personas (expertos) dentro de un ambiente
de franqueza, no sujeto a restricciones ni censuras de ningún tipo.
Objetivo
Obtener la opinión de los expertos en la esfera del problema a resolver, a través de extraer o exponer
sus intuiciones y experiencias utilizando las capacidades asociativas y clasificadoras del cerebro
humano.
Importancia
La importante de estas técnicas es que se llega a conclusiones, decisiones, valoraciones, etc., en
conjunto, de forma colectiva, lo que brinda un grado mayor de confiabilidad y objetividad, además,
los usuarios sienten un mayor nivel de compromiso con las soluciones planteadas al tomar parte en
su elaboración.
Cuando utilizar
Cuando los grupos de usuarios estén impacientes y quieren algo nuevo rápidamente.
La cultura organizacional da soporte a los comportamientos de la solución de problemas en
conjunto entre varios niveles de empleados.
Los analistas predicen que la cantidad de ideas generadas por medio de entrevistas persona a
persona no será tan abundante como la cantidad de ideas generada por medios de ideas generadas
de un grupo amplio.
El flujo de trabajo organizacional permite la ausencia de personas importantes durante un tiempo.
Quienes participan
Los expertos generalmente son los usuarios y otras personas con experiencia en dicho campo de
acción.
El líder de la sección no debe ser un analista o diseñador siempre, puede ser una persona con
excelentes habilidades de comunicación para facilitar las interacciones.

Reglas generales que se siguen.
Se debe crear un ambiente de confianza y receptividad a las opiniones que se emitan.
Se debe garantizar libertad de opiniones individuales sobre los fenómenos que se están evaluando.
Se debe brindar tiempo suficiente para pensar y responder.
Se elaboran de juicios colectivos de los aspectos evaluados.
Se debe publicar de forma escrita las conclusiones y deberán ser leídas por los participantes.
Beneficios
Ahorro de tiempo de las entrevistas uno a uno.
El tiempo de desarrollo del sistema se disminuirá.
El usuario se sentirá más involucrado y por lo tanto más comprometido con el desarrollo del
sistema.
Aumenta la posibilidad de que el diseño sea más creativo.
Desventajas
Los participantes deben dedicar mucho tiempo extra aparte de su trabajo lo que puede provocar
incomodidad y rechazo, por lo que deben estar realmente interesados en el proyecto.
Requisitos:
Una mesa donde estén cómodamente sentados los participantes.
Lápiz y papel frente a cada participante para que escriba sus ideas.
Una pizarra ó cualquier medio donde se escriban las ideas para ser vistas por todos.
Conductores de proceso:
Facilitador: Persona que facilita el proceso de exposición y elaboración de ideas
1. Hace que todos participen
2. Debe brindar la confianza que se requiere.
3. Protege al que expresa una idea de los ataques de los que no coinciden
4. No evalúa ni sustenta ninguna de las ideas planteadas por los participantes
5. Actúa como policía de tráfico, permite el flujo adecuado de ideas.
6. No dirige.
El Registrador: Anota y registra las ideas que van surgiendo en el proceso por parte de los
participantes.
1. Para el registro de ideas utiliza el medio previsto para el respecto.
2. Utiliza las propias palabras de los participantes.

Técnicas de Trabajo Creativo en Grupo.
• Método brainstorming (Torbellino de cerebro o torbellino de ideas).
Objetivo:
Obtener ideas de forma rápida, sin importar la calidad de ellas, lo que interesa es la cantidad.
Procedimiento:
1. Se plantea el objetivo de la reunión. Se da a conocer la problemática y los objetivos que
se desean.
2. Los participantes pensarán sobre el tema y anotarán las ideas que tenga.
3. Cada participante expondrá sus ideas sin justificarlas ni argumentarlas.
4. Una vez recogida todas las ideas se determinará cuáles ideas se tomarán y cuáles no,
cosa que harán los analistas y usuarios principales.
Método de los Grupos Nominales.
Objetivo:
Obtener una idea que sea consensuada entre todos los participantes.
Es un proceso de preguntas, de respuestas y retroalimentación con nuevas preguntas donde
después de varias iteraciones se alcanza el consenso de los expertos.
Procedimiento:
Primer Paso: Inicio de las preguntas.
Segundo Paso: Se solicita al grupo que redacte sus respuestas de forma silenciosa e
independiente.
Tercer Paso: Se lleva a la pizarra las ideas del grupo.
Cuarto Paso: Se aclaran las diversas ideas
Quinto Paso: Votación.
• Método del Mapa de Color.
Objetivo:
Colorear cada área de la empresa, organización, institución, etc., con un lápiz de determinado
color, según lo que se ha determinado en cuanto a colores.

Requisitos:
Tres lápices de colores diferentes: rojo, azul y negro.
Un plano con una vista aérea de la organización, empresa u organización que se está estudiando.
Procedimiento:
Cada color tiene su significado: por ejemplo, rojo para funcionamiento bueno, azul para
funcionamiento regular y negro para funcionamiento malo. Se coloreará según el criterio del
participante. Esto por ejemplo puede permitir a los analistas conocer los departamentos de una
entidad por los que se debe comenzar el desarrollo del sistema.

Tarea

Tarea
I. Lea el Tema Completo.
II. Ponga tres ejemplos donde se manifieste la importancia de la Información.
III. Seleccione un trabajo a realizar durante el semestre (Este trabajo será propuesto por la
docente), a través de dicho trabajo seleccionado, deberá aplicar lo que vaya avanzando
durante el semestre. Explique el tema seleccionado, como desarrollara la aplicación, con
que lenguaje se desarrollara.
IV.Para el trabajo práctico seleccionado:

a) Identifique los diferentes departamentos y personas en la organización.
b) Identifique las Características de Sistemas que se ponen de manifiesto. Justifique cada
una.
c) Qué papel como analista usted deberá realizar, si se le asigna la tarea de crear un
Sistema automatizado. Justifique cada uno de los papeles.
d) Qué estrategias para el desarrollo de Sistemas, usted seguiría. Justifique.
e) Describa el sistema de información.
f) Lea el tema Tipo de sistema, explique cuales tipos de sistemas podría desarrollar.
Justifique cada uno.
g) Identifique las subculturas encontradas. Justifique.
V. En el documento del contenido del tema, se especificó algunas páginas donde puede realizar
encuestas, entre ellas Google Forms y encuestas.com. Para cada una de ellas, elabore un tutorial
en Word, donde muestre el funcionamiento de ambas.
VI. Para el trabajo practico que va a desarrollar, realice una entrevista y un cuestionario utilizando
Google Forms. En ambos casos, deberá desarrollar todas las etapas y pasos, que especificará en un
documento que deberá subir al ecampus, en el caso del cuestionario, deberá adjuntar el enlace a su
encuesta.

Metodología de Desarrollo de
Sistemas.
UML
Docente: Ing. Rosa Almaraz

Contenido.
Introducción.
Metodología.
Explicación de las fases de la Metodología.
UML.
Proceso Unificado.

Objetivo
Este tema tiene como objetivo, comenzar el aprendizaje de cómo realizar el análisis de un sistema,
además de la obtención y especificación de los requisitos del Sistema. Para ello, se estudiará UML y
las herramientas que se utilizan para la realización de esta etapa, utilizando una metodología.

Introducción
Un proyecto de desarrollo de software no puede ser abordado de forma directa. Requiere de una
metodología, que nos permita definir los contenidos de cada fase para el desarrollo de un software y
como pasar de una etapa a otra. En este tema comenzamos el estudio de la metodología definida
por Craig Larman, unido al estudio de UML. Misma que establece una serie de actividades que
pueden desarrollarse en cada fase, las cuales pueden adaptarse a las condiciones del proyecto
software que se desea desarrollar.

Metodología
Como ya estudiamos anteriormente, una metodología no es más que: Un conjunto de

Herramientas, modelos y Técnicas que permiten definir las fases de un proceso de
desarrollo y las reglas para pasar de una fase a otra.
Metodología de Craig Larman
Esta metodología, nace a partir del modelo de procesos descrito en RUP (Rational Unified Process).
Es un método de desarrollo de software iterativo, incremental y dirigido por casos de uso que
permite desarrollar completamente un sistema software partiendo de un prototipo funcional inicial
cuyas funcionalidades se van extendiendo hasta culminar con el desarrollo del sistema. (González,
2017)
La metodología RUP es un proceso muy abierto, adaptativo e incremental dirigido por casos de uso
(en función de las características del proyecto se podía utilizar un ciclo de vida u otro), en el cual se
pueden seguir muchos caminos distintos para desarrollar el software.
Actividades que define la Metodología
1. Planificación y Especificación de Requisitos.

2. Construcción.
3. Instalación.
Cada una de estas actividades, serán explicadas en los próximos temas a estudiar.

Ventajas del uso de esta metodología
✓ No define una metodología estricta

✓ Adopta un enfoque práctico
✓ Incluye los últimos avances en la ingeniería del software.
✓ Aporta soluciones a problemas que anteriores métodos no han podido solucionar.
✓ Modelo iterativo e incremental, es decir, el producto contempla una serie de
funcionalidades, para las cuales se realiza el proceso de desarrollo completo, que se irán
incrementando en sucesivas versiones o iteraciones.
✓ Las iteraciones son como mini proyectos, en cada una de ellas se repite un proceso de
trabajo similar, cada requisito se debe completar en una única iteración incluyendo pruebas
y documentación.
✓ En cada iteración se hace una entrega, a partir de los resultados obtenidos anteriormente, y
se añaden nuevos requisitos y/o se mejoran los que ya fueron completados
Descripción de las etapas de la metodología
1.- Planificación y Especificación de Requisitos
Consiste en realizar el análisis de los requisitos que presenta el usuario las necesidades que debe
satisfacer el producto que se quiere construir.
Pasos a seguir:
1. Definición del Plan Borrador.
2. Informe de Investigación Preliminar.
3. Definir los requisitos.
4. Registrar Términos en el Glosario.
5. Casos de Uso.
6. Arquitectura del Sistema.

2.- Construcción
✓ En esta fase, se construye el sistema.

✓ Etapas a seguir:
1.- Análisis.
2.- Diseño.
3.- Implementación.
4.- Pruebas.
✓ Actividades que se desarrollan

Definir casos de uso esenciales en formato expandido
Definir el Modelo conceptual y refinar el glosario
Definir los Diagramas de Secuencia.
Definir los contratos.
Definir los casos de uso reales.
Definir los diagramas de Colaboración.
Definir los diagramas de Interacción.
Definir el diagrama de Clases de Diseño.
3.- Instalación
En esta fase se instalará el sistema, el usuario dará el visto bueno y se comenzará una nueva
iteración del producto con las funciones añadidas por éste.

UML, El Lenguaje Unificado de Modelado.
Por mucho tiempo se habló en la industria del software sobre la llamada crisis del software. Las
discusiones de la crisis se basaban a los siguientes aspectos:
1.- Muchos proyectos de software fallan en producir sistemas que cumplen con los requerimientos y
las necesidades de los usuarios.
2.- Los proyectos de desarrollo de software terminan excediendo los presupuestos y los horarios de
tiempo.
3.- Los sistemas se han vuelto cada vez más grandes y distribuidos a través de muchas
computadoras, utilizando la arquitectura Cliente/Servidor.
4.- La necesidad de integrar sistemas complejos en un ambiente distribuido requiere que los
sistemas tengan algunos modelos comunes.
El avance de la programación orientada a objetos, la programación visual y los ambientes de

desarrollo avanzados han ayudado a incrementar la productividad. El costo perpetuo de usar y
soportar muchos lenguajes de modelaje motivó a muchas compañías que producen o usan
tecnología orientada a objetos a endorsar y soportar el desarrollo del Lenguaje de Modelaje
Unificado.
Que es UML
UML es un lenguaje estándar que sirve para escribir los planos de software, con el mismo se puede,
visualizar, especificar construir y documentar todas las partes que componen un sistema con gran
cantidad de software.
El Lenguaje de Modelaje Unificado (el UML) ha sido un intento para resolver algunos de los
problemas descritos anteriormente.
UML es el estándar formal y puede ser también el estándar de facto para construir los modelos
utilizables:
• Seguros: Describen correctamente el sistema a ser construido.
• Consistentes: Las diferentes vistas no expresan cosas que estén en conflictos con otras.
• Fáciles de comunicar a otros.
• Fáciles de cambiar.

• Comprensibles: Tan simple como sea posible, pero no los más simples.
Sigue el enfoque iterativo e incremental, es decir, el producto contempla una serie de

funcionalidades, para las cuales se realiza el proceso de desarrollo completo, que se irán
incrementando en sucesivas versiones o iteraciones.
Surgimiento de UML
Oficialmente surge en Octubre de 1994 al unirse Rumbaugh y Booch en Rational.
Tuvo como objetivo crear un nuevo método, el "Método Unificado," para unir el método de Booch y
el método OMT.
Por el 1995, Ivar Jacobson responsable del método OOSE y Objectory, se unió, y UML fue
expandido para incorporar OOSE.
El trabajo se dirigió fundamentalmente a la creación de un lenguaje de modelaje estándar, que le
llamaron "Lenguaje de Modelaje Unificado.", que pudiera ser utilizado por todos.
Uso de UML
UML puede usarse para modelar desde sistemas de información hasta aplicaciones distribuidas
basadas en WEB, pasando por sistemas empotrados de tiempo real.
Características de UML
Es un lenguaje, porque proporciona un vocabulario y las reglas para utilizarlo, por lo que es sólo una
parte de un método de desarrollo de software.
Es independiente del proceso, aunque para que sea óptimo debe usarse en un proceso dirigido por
casos de uso, centrado en la arquitectura, iterativo e incremental.
Es un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la
representación conceptual y física del sistema.
Es un lenguaje que nos ayuda a interpretar grandes sistemas, mediante gráficos o mediante texto,
obteniendo modelos explícitos que ayudan a la comunicación durante el desarrollo, ya que, al ser
estándar, los modelos podrán ser interpretados por personas que no participaron en su diseño (e
incluso por herramientas) sin ninguna ambigüedad.
Sirve para especificar modelos concretos, no ambiguos y completos.
No es un lenguaje de programación. A pesar de ello, se puede conectar de manera directa a
lenguajes de programación, tales como Java, C++, o Visual Basic, esto permite lo que se denomina
ingeniería directa (obtener el código fuente partiendo de los modelos) también, es posible
reconstruir un modelo en UML partiendo de la implementación, o sea, ingeniería inversa.

Permite modelar actividades de planificación de proyectos y de sus versiones, expresar requisitos y
las pruebas sobre el sistema, representar todos sus detalles, así como la propia arquitectura.
Mediante estas capacidades se obtiene una documentación que es válida durante todo el ciclo de
vida de un proyecto.
Es un lenguaje estándar “abierto-cerrado”, es posible extender el lenguaje de manera controlada.
UML es un lenguaje para:

 Visualizar.
 Especificar.
 Construir.
 Documentar
Los artefactos de un sistema con gran cantidad de software.
Tiene la capacidad de que permite modelar actividades de planificación, especificar requisitos y las
pruebas del sistema, permite representar todos los detalles y la propia arquitectura. Obteniéndose
también, la documentación. (documentar).
Elementos Básicos de UML

Estructurales
Elementos: Abstracciones de Primer nivel De Comportamiento
De Agrupación
De Notación
1.- Los bloques de construcción De Dependencia

De Asociación
Relaciones: Unen los elementos entre si De Generalización
De Realización
Diagramas: Agrupaciones de Elementos
ELEMENTOS
Son los conceptos utilizados en los diagramas.
Un elemento del modelo es definido con una semántica, una definición formal del elemento
o el significado exacto de lo que representa en un enunciado no ambiguo.
Un elemento del modelo también tiene un elemento de vista correspondiente, el cual es una
representación gráfica del elemento o el símbolo gráfico utilizado para representar al
elemento en los diagramas.
Un elemento puede existir en varios tipos diferentes de diagramas, pero hay reglas para las
cuales los elementos pueden ser mostrados en cada tipo de diagrama.

En la siguiente figura se muestran algunos ejemplos de elementos del modelo tales como
clase, objeto, estado, caso de uso, nodo, interfaz, paquete, nota, componente, actor, señal, y
estados inicial, final e historia.
RELACIONES:
Las relaciones son también elementos del modelo, y son utilizadas para interconectar
otros elementos del modelo unos a otros. Algunas relaciones diferentes son:
• Asociación: Conecta elementos y enlaza instancias.
• Generalización: También llamada herencia, esto significa que un elemento puede ser la
especialización de otro elemento.
• Dependencia: Muestra que un elemento depende de alguna manera de otro
elemento.
• Agregación: Es una forma de asociación en la cual un elemento contiene otros
elementos.
• Refinamiento: Es una forma de generalización entre un elemento a mayor nivel de detalle
que otro pero que representan lo mismo.
DIAGRAMAS
Que son los diagramas

1. Son gráficos que describen los contenidos de las vistas.
2. Es una parte específica de una vista.
3. Un diagrama puede ser parte de diferentes vistas.
4. Un diagrama en una vista debe ser suficientemente simple para poder ser comunicado.
5. Contiene símbolos gráficos que representan los elementos del modelo del sistema.
Tipos de Diagramas
❖ Diagramas de Casos de Uso:
❖ Son una vista gráfica de algunos o todos los actores, casos de usos, interacciones del
sistema.
❖ Tipos de Diagramas de Casos de Usos:
❖ Diagrama de CU Principal: Es la imagen de la frontera (actores principales)
y la funcionalidad principal del Sistema.
❖ Un diagrama que muestre todos los CU para un actor determinado.
❖ Un Diag. De CU que muestre todos los CU implementados en una iteración.
❖ Un diag. Que muestre un caso de uso y sus relaciones.

❖ Diagramas de Clases.
1. Es un tipo de modelo estático, Describe la estática del sistema.
2. Tiene similitud con el DER, Definen la base para otros diagramas (estados,
colaboración).
3. Son creados para mostrar una imagen o vista de las clases de una vista.
4. Usos típicos:
5. Vista de todas las clases de implementación de un paquete.
6. Vista de la estructura y comportamiento de una o más clases.
7. Vista de una jerarquía de herencia.
8. También pueden ser creados en los casos de uso, contienen una
vista de las clases que participan en el caso de uso.
❖ Diagramas de Objetos.
o Parecido al Diagrama de clases.
o Muestra una serie de objetos, en vez de clases actuales.
o Muestra las instancias de una clase.
o Utiliza la misma notación excepto que los nombres están subrayados, y son
mostradas todas las instancias en una notación.
❖ Diagramas de Secuencia.
1. Muestra una Colaboración Dinámica entre una serie de objetos.
2. Muestra una secuencia de mensajes enviados entre objetos, algo que
sucederá en un punto específico de la ejecución de un sistema.
3. Consiste en una serie de objetos.
4. Para enfatizar la secuencia.
❖ Diagramas de Actividades.
▪ Muestra el flujo secuencial de las actividades.
▪ Puede ser utilizado para describir las actividades realizadas en una
operación.
▪ Puede usarse para describir otros diagramas:
▪ Casos de usos.
▪ Iteración.
▪ Estados.
❖ Diagramas de Colaboración.
5. Muestra una Colaboración Dinámica.
6. Muestra los Objetos y sus Relaciones.

7. Para Enfatizar el Contexto.
❖ Diagramas de Estado.
➢ Muestra todos los estados posibles que los objetos de la clase pueden tener.
➢ Muestra qué eventos causan un cambio de estado.
➢ No son dibujados para todas las clases, sólo aquellas que tienen estados
bien definidos.
➢ Pueden ser dibujados para el sistema en su totalidad.
➢ Complementan la descripción de una clase.
❖ Diagramas de Componentes.
❖ Diagramas de Implementación.
2.- Las reglas: Dictan pautas para la realización de asociaciones entre objetos, son reglas
semánticas, que afectan a los nombres, a la visibilidad, a la integridad y a la ejecución.
3.- Mecanismos: Proporcionan comentarios extra, información o semántica acerca de un elemento

del modelo. Se utilizan en los diagramas.
Mecanismos comunes: Sirven para que cada persona o entidad adapte el lenguaje a sus
necesidades, dentro del marco ordenado y siguiente las reglas para que no se pierda la semántica
propia de UML. Entre estos mecanismos se tienen:
Especificaciones: Una explicación textual de la sintaxis y semántica de los bloques de
construcción. Los elementos del modelo tienen propiedades que guardan datos sobre el
elemento. Una propiedad es definida con un nombre y un valor llamado valor agregado, el
cual es de un tipo especificado, por ejemplo integer o string. Hay una serie de funciones
predefinidas tales como Documentación, Responsabilidad, Persistencia, y Concurrencia.
Las propiedades son utilizadas para agregar especificaciones sobre instancias de elementos
que son normalmente mostrados en el diagrama. Una clase típicamente es descrita de
manera informal listando las responsabilidades y capacidades de la clase. Este tipo de
especificación no es normalmente mostrada en el diagrama por sí mismo, pero está
disponible en una herramienta usualmente accesada haciendo doble click sobre el elemento
que despliega una ventana con todas las propiedades.
✓ Adornos: Son elementos secundarios que proporcionan más nivel de detalle. Sirven para
dotar a los modelos de más semántica.
o Los adornos gráficos pueden ser incorporados a los elementos del modelo en los
diagramas. Un ejemplo de adorno es la técnica utilizada para separar tipo de una

instancia.
o Cuando un elemento representa un tipo, su nombre es mostrado en negrillas.
Cuando el mismo elemento representa una instancia del tipo, su nombre es
subrayado y puede especificar el nombre de la instancia, así como el nombre del
tipo. Un rectángulo de clase, con el nombre en negrillas representa una clase, y el
mismo nombre subrayado representa un objeto.
o Lo mismo se aplica a los nodos, donde el símbolo del nodo puede ser un tipo, en
negrillas, tal como Impresora, o bien, una instancia del tipo, tal como Impresora
HP SMP. Otros adornos son la especificación de la multiplicidad de las relaciones,
donde la multiplicidad es un número o un rango que indica cuántas instancias de
tipos conectados pueden contenerse en la relación. Los adornos son escritos cerca
del elemento a los cuales agregan información. Todos los adornos son descritos en
conjunción con la descripción del elemento que ellos afectan.
✓ Notas: No todo puede ser definido en un lenguaje de modelaje, no importa cuán extenso
sea el lenguaje. Para permitir agregar información al modelo que de otra manera no puede
ser representada, UML proporciona las notas. Una nota puede ser puesta en cualquier lugar
del diagrama, y puede contener cualquier tipo de información. Su tipo de información es
una cadena que no puede ser interpretada por el UML. La nota es agregada típicamente a
algún elemento en el diagrama con alguna línea punteada que especifica cuál elemento está
siendo explicado o detallado, junto con la información en la nota.
o Una nota contiene cualquier información adicional, tales como comentarios simples
o Una nota contiene a menudo comentarios y preguntas del modelador como un
recordatorio para resolver un dilema más tarde.
o Las notas pueden tener también estereotipos que describen el tipo de nota.
✓ Las divisiones comunes: Permiten dividir los modelos en al menos un par de formas
diferentes, para facilitar la comprensión desde distintos puntos de vistas.
o División entre clases y objeto, (clase es una abstracción y objeto es una
manifestación de esa abstracción).
o División interfaz /implementación; la interfaz presenta un contrato (algo que se va a
cumplir de una determinada manera) mientras que la implementación es la manera
en que se cumple dicho contrato.

Mecanismos de extensibilidad: Sirven para evitar posibles problemas que pueden surgir debido
a la necesidad de poder representar ciertos matices, por esta razón UML incluye los estereotipos,
para poder extender el vocabulario con nuevos bloques de construcción, los valores etiquetados,
para extender las propiedades de bloque y las restricciones, para extender la semántica.
VISTAS:
Que son las vistas.

▪ Muestran diferentes aspectos de los sistemas modelados.
▪ No es un gráfico, es una abstracción que está formada por diferentes diagramas.
▪ Definiendo una serie de vistas, cada una representando un aspecto particular se puede
construir un sistema completo.
▪ Cada vista es descrita en una serie de diagramas.
▪ Los mismos contienen información que enfatiza un aspecto particular del sistema.
▪ Un diagrama puede ser parte de más vistas (traslape).
Tipos de Vistas:
 Vista de Caso de Uso: Muestra la funcionalidad de un sistema como es percibida por los
actores externos.
 Vista Lógica: Muestra cómo es diseñada la funcionalidad del sistema en términos de
estructuras estáticas del sistema y su comportamiento dinámico.
 Vista de Componente: Muestra la organización de los componentes del código.
 Vista de procesos: Muestra la concurrencia en el sistema, resolviendo problemas de
comunicación y sincronización que están presentes en un sistema concurrentes.
 Vista de Despliegue: Muestra el despliegue de un sistema dentro de una arquitectura
física con computadoras y dispositivos llamados nodos.
Donde utilizar UML

• Sistemas de información de empresas
• Bancos y servicios financieros
• Telecomunicaciones
• Trasporte
• Defensa/industria Inter espacial.
• Comercio
• Electrónica médica

• Ámbito científico
• Servicios distribuidos basados en RED
Diferentes Tipos de sistemas

El objetivo es describir cualquier tipo de sistema, en términos de diagramas orientados a objetos.
Naturalmente, el uso más común es crear modelos de sistemas de software, también es utilizado
para describir sistemas mecánicos sin ningún software o la organización de un negocio. Aquí hay
algunos tipos diferentes de sistemas y sus características más comunes.
• Sistemas de Información: Almacenan, recuperan, transforman y presentan información a los

usuarios. Manejan grandes cantidades de datos con relaciones complejas, los cuales son
almacenados en bases de datos relacionales o de objetos.
• Sistemas Técnicos: Mantienen y controlan equipo técnico tal como procesos de

telecomunicaciones, procesos de sistemas militares o procesos industriales. Deben mantener
las interfaces especiales del equipo y tienen menos software que los sistemas de información.
Los sistemas técnicos son a menudo sistemas de tiempo real.
• Sistemas de Tiempo Real Empotrados: Se ejecutan en un hardware simple empotrado en

cualquier otro equipo tal como un teléfono móvil, un carro, un utensilio del hogar, etc. Esto es
llevado a cabo a través de programación de bajo nivel que requiere soporte de tiempo real.
Estos sistemas a menudo carecen de dispositivos tales como pantalla, disco duro, etc.
• Sistemas Distribuidos: Distribuidos en una serie de máquinas donde los datos son
transferidos fácilmente de una máquina a otra. Requieren de mecanismos de comunicación
sincronizada para asegurar la integridad de los datos y son construidos a menudo sobre
mecanismos de objetos tales como CORBA, COM/DCOM, o Java Beans/ RMI.
• Software de Sistemas: Definen la infraestructura técnica que utiliza otro software. Los
sistemas operativos, bases de datos, e interfaces de usuario realizan operaciones de bajo nivel
en el hardware, mientras presentan interfaces genéricas para ser utilizadas por otro software.
• Sistemas de Negocios: Describen los objetivos, los recursos (humanos, computadoras, etc.),
las reglas (leyes, estrategias del negocio, políticas, etc.), y el trabajo actual en el negocio
(procesos del negocio).

Es importante enfatizar que la mayoría de los sistemas no encajan limpiamente en una de
estas categorías, pero pertenecen a más de uno de los tipos de sistemas o como una
combinación. Por ejemplo, muchos de los sistemas de información de hoy tienen
requerimientos distribuidos y de tiempo real.
Proceso Unificado
Que es el Proceso Unificado.

Es un proceso de ingeniería de software.
Proporciona una aproximación disciplinada para asignar tareas y responsabilidades dentro de una
organización de desarrollo
Meta: asegurar software de alta calidad, dentro de un tiempo y presupuesto predecible.
Fases del Proceso

Inicio
Elaboración
Construcción
Transición
Características del proceso

Tecnología de Objetos.
Desarrollo conducido por Casos de Usos.
Desarrollo Iterativo Controlado.
Administración de Requerimientos.
Fuerte énfasis en la Arquitectura.
Desarrollo basado en componentes.
Configurabilidad del proceso.

Descripción de las Fases de Proceso Unificado
Inicio:
• Objetivos:
• Razón del negocio
• Alcance del proyecto.
• Que se hace:
• Costos.
• Beneficios.
• Definición de los Casos de Uso del negocio.
• Se determina si se sigue o no con el proyecto.
Elaboración:
▪ Analizar el dominio del problema:
▪ ¿Qué es lo que se va a construir?
▪ ¿Cómo se va a construir?
▪ ¿Qué tecnología se va a utilizar?
▪ Establecer una fundición arquitectónica sólida.
▪ Deben ser tomadas con un entendimiento completo del sistema.
▪ Debe describir la mayor cantidad de casos de usos.
▪ Tomar en cuenta algunas restricciones: requerimientos no
funcionales.
▪ Para verificar la arquitectura: debe implementar un sistema que
demuestre las opciones arquitectónicas y ejecute casos de usos
significativos.
▪ Eliminar los elementos de más alto riesgo del proyecto
▪ Riesgos de requerimientos / Riesgos tecnológicos
▪ Riesgos de habilidades / Riesgos Políticos
1. Que se hace:
2. Se obtienen requerimientos más detallados.
3. Se hace análisis y diseño para de alto nivel, para obtener la arquitectura
base.
4. Se crea el plan para la construcción.
5. Cuando Termina:
6. Cuando se conoce cuanto tiempo demora en realizar cada caso de uso

7. Cuando ya se han identificado los riesgos significativos.
Construcción
❖ Muchas iteraciones.
❖ En cada iteración se construye software de calidad, probado e integrado.
❖ En cada iteración se hace Análisis, Diseño, Implementación y Pruebas.
❖ Iterativo.
❖ Incremental.
❖ Se desarrolla un producto completamente listo.
❖ Cada iteración es un mini proyecto(Análisis,Diseño, codificación, pruebas e integración)
para los casos de usos asignados a cada iteración.
❖ Dentro de cada iteración puede haber una planificación más detallada.
Transición.
 Pruebas beta.
 Optimización del rendimiento.
 Capacitación del usuario.
Otros conceptos
Ciclo.
• El ciclo de vida de software está dividido en ciclos
• Cada ciclo trabaja en una nueva generación del producto.
• Un ciclo está compuesto por fases:
• Inicio
• Preparación
• Construcción
• Transición.
Hitos.
• Cada fase está construida por hitos, bien definidos.
• Hito: un punto en el tiempo donde ciertas decisiones críticas deben tomarse.
• Cada fase tiene un propósito.

Modelos del Proceso Unificado.
• Modelo de Casos de Usos
• Modelo de Diseño
• Modelo de Implementación
• Modelo de Prueba

Planeación y Especificación
del Sistemas (01)

Contenido.
Introducción
1.-Definir el Plan borrador
2.- Informe de Investigación Preliminar.
3.- Definir los requisitos
4.- Registrar términos en el glosario.
Orientación de la Tarea.

Introducción
En este tema, comenzaremos a desarrollar las fases de la metodología explicada en el tema anterior.
Mismas que consisten en:
1. Planificación y Especificación de Requisitos.
2. Construcción.
3. Instalación.
Aquí no enfocamos en la Planificación y Especificación de Requisitos. Como se especificó
anteriormente, esta etapa consta de otras fases, mismas que se irán explicando a continuación. Esta
fase, es una etapa preliminar al proceso de desarrollo que consta de varias actividades que se deben
completar para conseguir abordar la siguiente fase de forma óptima.
Comenzaremos aprendiendo, cómo realizar la obtención y especificación de los requisitos del
Sistema. utilizando una metodología.
En la anterior clase, identificamos los siguientes pasos de esta fase, mismos que se estudiaran a lo
largo de este tema.
1. Definición del Plan Borrador.
2. Informe de Investigación Preliminar.
3. Definir los requisitos.
4. Registrar Términos en el Glosario.
5. Casos de Uso.
6. Arquitectura del Sistema.

1.- Definir el Plan Borrador.
Incluye:
Estudio de viabilidad, que determinara si el sistema es factible.
Costos y plazos estimativos en términos de orden y amplitud, no requiere un informe detallado
porque sería un esfuerzo en vano si el proyecto no es abordable.
Una definición de roles del equipo de desarrollo que va a participar en el proyecto.
Un plan acerca de cómo se va a desarrollar el sistema, incluyendo estimación de plazos, revisiones
por parte del usuario, validación de requisitos, etc.
Las fases que se contemplan en la definición de este plan son las siguientes:
Es una planificación estimada de las fases por las que va a pasar el

proyecto.
✓ Definición del Programa Sirve para controlar si el proyecto transcurre dentro de lo estimado y
establecer acciones para corregir lo contrario.
Se determinan los recursos del proyecto.

Se establecen los roles que participaran en cada una de sus etapas,
entre ellos se tienen (no tienen que ser todos, pueden ser otros más)
✓ Definición de Recursos Responsable de proyecto: Responsable de la coordinación del mismo.
Responsable de calidad: Responsable de que el proyecto cumpla con
las normas de calidad establecidas.
Responsable de soporte: Encargado de cumplir con la gestión de
configuración, control de versiones, mantenimiento de la línea base del
proyecto, etc.
Analista: Encargado de realizar el análisis y diseño.
Programador: Encargado de la programación.

Documento contractual donde se establece la
relación entre el cliente que ha encargado el sistema
a construir y la empresa que se encarga de la
construcción.
Debe contemplar:
✓ Elaboración de Presupuesto Funciones básicas que debe hacer la aplicación,
junto con la estimación de plazos y costos.
Debe contar con la aprobación de todas las partes
que participan en el desarrollo del sistema.
Un riesgo es todo evento que puede hacer fracasar o

retrasar el desarrollo de un proyecto.
Aquí se elabora un plan de gestión de riesgos,
donde se debe establecer la relación entre la
✓ Determinación de Riesgos
posibilidad de ocurrencia de dicho riesgo y la
pérdida que ocasiona.
Ejemplo: si la posibilidad de que ocurra un
incendio que provoque una pérdida de los datos es
baja, pero el incendio produce un perjuicio alto, no
tiene tanto riesgo como si la probabilidad de que se
caiga el servidor es alta, aunque no produzca tanto
perjuicio.

2.- Crear un informe de Investigación Preliminar.
.
Se realiza una investigación donde:
1.- Se analizan y se establecen los motivos que han llevado a la empresa a realizar el proyecto, las
alternativas de desarrollo, las necesidades de la empresa, tanto a nivel de recursos como de material
(HW,SW, comunicaciones).
2.- Se elabora un Plan de Trabajo. Una vez que se haya dado la conformidad al proyecto, se debe
crear un plan de trabajo que rija la metodología a utilizar, el ciclo de desarrollo que tendrá la
aplicación, definir puntos de control, etc. Utilizar un plan evolutivo, que vaya incrementando la
funcionalidad en cada iteración. Las ventajas de esta metodología son las siguientes:
La experiencia muestra los errores corregidos y la forma de corregirlos.
Una evolución permite la adaptación de los usuarios, los cuales por otro lado suelen poner bastantes
dificultades al cambio de un sistema y por otro lado facilitan la formación.
Se obtienen resultados en menos plazos.
3.- Metodología. Definir la metodología que se va a usar para implementar el sistema. Puede ser
metodología estructurada u orientada a objetos. Habrá que hacer un estudio para determinar la
metodología más adecuada a la semántica de la aplicación, debido a que un tipo de aplicación es
más conveniente abordarla con una metodología que con otra. En nuestro caso , la metodología que
vamos a estudiar es la orientada a objetos y el planteamiento a seguir es utilizar este estándar en
todas las fases de desarrollo(planificación , análisis, diseño e implementación)
3.- Definición de Recursos. Se determinan los recursos necesarios de software, hardware. No es

igual implementar una aplicación en un sistema operativo Windows o similar, a otro que sea de tipo
empotrado, como por ejemplo el software de las máquinas de refrescos.
Por ese motivo habrá que especificar con qué tipo de plataforma contamos, cuál va a ser el uso que
se haga de la aplicación, el nivel de eficiencia que se precisa, si va a utilizar una base de datos, etc.
Así mismo habrá que especificar la infraestructura de comunicaciones que debe contar el sistema
según las necesidades del usuario.

3.- Definir los Requisitos.
¿Qué se hace?
Se determinan las necesidades respecto al proyecto.
¿Qué se obtiene?
Se obtienen un documento de especificación de requisitos que se realiza en dos pasos
✓ Especificación de requisito de usuario, para definir las necesidades del usuario de manera
informal.
✓ Especificación de requisitos de sistema; que incluye propósito, ámbito del sistema y
funciones del sistema.
¿Que son los requisitos?

Los requisitos son las funcionalidades que debe cumplir el sistema.
Importancia de la Ingeniería de Requisitos,
 La necesidad de una ingeniería de requisitos es imprescindible para obtener productos de

calidad, que no se puede implementar en las etapas finales de desarrollo, sino que es una
característica intrínseca al propio producto, iniciándose en las especificaciones de los
productos.
 Por lo que la calidad en la ingeniería de requisitos son la base para el aseguramiento de la
calidad del proyecto.
 Que podrán terminarse con éxito, ser cancelados, o ser modificados.
Tipos de Proyectos, según.
Proyecto Exitoso
Son aquellos que cumplen con el alcance definido, son terminados en tiempo y con el coste, de los
datos con los que fueron planificados.
Proyecto Cancelado
Son aquellos que no llegaron a terminarse.

Proyecto Modificado
Son aquellos que fueron modificados en alguno de estos parámetros: alcance inicial, tiempo
estimado y/o coste planificado
Factores para que un proyecto tenga éxito.
 Apoyo de la dirección.
 Usuarios involucrado.
 Experiencia en la dirección del proyecto.
 Objetivos de negocio claros.
 Alcance realista.
 Requisitos acordados.
 Estimaciones fiables.
 Entre otros.
Requisito
 Se define el término como una especificación de lo que debe ser implementado.

 Son descripciones de cómo el sistema se debe comportar, o las propiedades o atributos que
el sistema debe contener.
 Los requisitos deben ser una restricción en el proceso de desarrollo del sistema.
 Los Requisitos son las Funcionalidades que debe cumplir el Sistema.
Especificación de Requisitos.
Los Requisitos son las Funcionalidades que debe cumplir el sistema.

Es una de las fases más críticas del proceso de desarrollo software., según se derivan de diversos
estudios.
Una buena especificación de requisitos va a producir un software robusto y sin errores.
No detectar errores en los requisitos incrementa los costos del proyecto.
Cuanto más avanzada sea la fase en que se encuentre el proyecto, más elevado serán los costos

Forma de Especificar los requisitos
1. Utilizar el Lenguaje Natural.
2. Especificar en un Documento.
3. Este documento debe ser abierto tanto al analista como a los usuarios.
4. Utilizar frases tales como “el sistema hará..”.
5. Ejemplos de Requisitos pueden ser los siguientes:
▪ Requisitos que definen efectos: El sistema mantendrá la temperatura entre 40
y 100 grados C.
▪ Requisitos Funcionales: El sistema permitirá a los usuarios realizar una
búsqueda de pacientes por CI, Apellidos o nombres.
▪ Requisitos de Implementación: El sistema podrá ejecutarse en entorno WEB.
▪ Requisitos de Rendimiento: El sistema deberá soportar 20 transacciones por
segundo.
▪ Requisitos de Usabilidad: El sistema permitirá a los usuarios familiarizarse en
un período de 45 minutos.
Características de los Requisitos.

 Ser medibles.
 Ser Comprobables.
 No tiene que ser ambigüos.
 No mostrar contradicciones.
Pasos para la especificación de requisitos.
1. Obtención de Requisitos.
2. Análisis y Negociación de Requisitos
3. Documentación de los Requisitos
4. Validación y Aceptación de Requisitos.
1.- Obtención de los Requisitos.

• Es la captura de los requisitos.

• Se necesita un cierto conocimiento del dominio del problema. Por ejemplo, si lo que se
desea hacer es un sistema de contabilidad, se necesita conocer algunos aspectos
relacionados con la contabilidad.
• La obtención de requisitos debe centrarse en los aspectos relacionados al dominio no a
la implementación ni al diseño.
Herramientas para la obtención de Requisitos

 Entrevistas
 Cuestionarios
 Otros medios estudiados.
 Prototipos.
 Casos de usos
 Modelo Conceptual.
Problemas en la Obtención de Requisitos.

1. Muchas veces puede ocurrir que a los mismos usuarios les cuesta describir las tareas
aún cuando las sepan realizar, por ejemplo, un ciclista no puede decir cómo montar una
bicicleta sin caerse
2. Puede ocurrir que la información importante no se llegue a verbalizar, ya que muchas
de las tareas se dan por hecho o que se conocen.
3. Se puede dar que muchas veces haya que inventarse los requisitos.
Problemas relacionados con las personas involucradas

 Los usuarios no tiene claro lo que desean.
 Los usuarios no se involucran en la elaboración de requisitos escritos.
 Los usuarios insisten en nuevos requisitos después de que el coste y la programación se
hayan fijado.
 La comunicación con los usuarios es lenta.
 Los usuarios no participan en revisiones o son incapaces de hacerlo.
 Los usuarios no comprenden los problemas técnicos.
 Los usuarios no entienden el proceso del desarrollo.
Esto puede conducir a la situación donde las exigencias del consumidor cambian, incluso
cuando el desarrollo del producto ya está en marcha

Problemas con los analistas
 En su redacción hay que evitar:
 Uso de terminología ambigua en la redacción de los documentos de requisitos
 Sobre Especificación de los requisitos.
 Escritura poco legible, voz pasiva, abuso de negaciones.
 Uso de verbos en condicional, expresiones subjetivas.
 Ausencia de términos y verbos del dominio de la aplicación.
Problemas con los desarrolladores

 El personal técnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar
a creer incorrectamente que están de acuerdo, no dándose cuenta del desacuerdo hasta que
se provee el producto final.
 Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de
desarrollar un sistema adaptado a las necesidades del cliente.
 El análisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en
vez de personal con las habilidades de relación con la gente y el conocimiento apropiados
para entender las necesidades de un cliente correctamente.
Soluciones a aplicar
 Una solución aplicada en los problemas de comunicaciones ha sido emplear a especialistas
en análisis del negocio o del sistema.
 Las técnicas introducidas en los años 90 tienden al uso de prototipos, UML, casos de uso.
 Pizarras electrónicas para bosquejar los algoritmos y para probar alternativas
 Capacidad de capturar la lógica del negocio y los datos necesarios
 Capacidad de generar los prototipos que imitan fielmente el producto final
 Interactividad
 La capacidad para agregar requisitos contextuales y otro comentarios
 Capacidad para que usuarios remotos y distribuidos operen con el prototipo
 Por último, se requieren herramientas que permitan medir, de forma objetiva, la calidad de
una especificación de requisitos.
2.- Análisis y Negociación de los Requisitos.

 Detectar conflictos entre requisitos y resolverlos y negociar aquellos que sean más
conflictivos, es decir, es preferible ponerse de acuerdo acerca de cómo hacer algo a
imponerlo al usuario.
 La modelización conceptual puede servir de ayuda si el sistema es complejo e impide una
correcta descripción de los objetivos.

 Cómo veremos mas adelante, pueden utilizarse casos de uso para describir los requisitos o
también herramientas estructuradas.
3.- Documentación de Requisitos-
Los requisitos deben especificarse en un documento, llamado especificación de requisitos,

que deberá ser aprobado por el usuario.
Se sugiere que contenga la siguiente información:
▪ Información referente al problema.
▪ Propiedades y comportamiento del sistema.
▪ Restricciones.
▪ Descripción acerca de cómo el sistema ayudará a usuarios a realizar tareas.
Aspectos a considerar al crear el documento:

1. Debe ser claro: Especificar claramente los requisitos y cada una de las restricciones
que debe satisfacer.
Debe ser completo y correcto: Debe describir todo el sistema respondiendo a las
necesidades del usuario.
2. Utilizar un lenguaje comprensible tanto para analista como para usuarios, para que
pueda ser entendido y poderse verificar e interpretar correctamente.
3. Puede ser modificable: Si alguna de las partes encuentra un error en la
especificación, debe cambiarse.
4. Debe ser independiente de aspectos del diseño e implementación: Sólo se limita al
modelo conceptual.
Elementos del estándar IEEE830.

El estándar es un documento que especifica los requisitos y se divide en las siguientes
partes:
1. Introducción.
a) Propósito y Alcance
b) Definiciones.
c) Referencias.
d) Visión General.
2. Descripción.
a) Perspectiva.

b) Funciones.
c) Características de los usuarios.
d) Restricciones.
e) Suposiciones.
3. Requisitos específicos.
Propósito y Alcance
 Propósito:
▪ Se especifica el propósito del documento y a quien va dirigido este
documento.
 Alcance:
✓ Identifique el producto (s) del software para ser diseñado por el nombre .
✓ Explique que hará y que no hará el producto
Definiciones
 Se definen todos los términos utilizados en el documento de especificación de requisitos
 Debe proporcionar las definiciones de todas las condiciones, las siglas, y abreviaciones
que exigen interpretar el SRS propiamente.
Referencias
 Se especificarán todas las referencias a las que se hace lugar en el documento.
 Proporcione una lista completa de todas las referencias de los documentos en otra parte
en el SRS;
 Identifique cada documento por el título, número del reporte (si es aplicable), fecha, y
publicación de la organización;
 Especifique las fuentes de las referencias de donde se obtuvieron.
Visión General
 Describe de forma general de que trata el documento.
 Explica cómo está organizado este documento.
Perspectiva del Producto

 Debe relacionar el futuro producto software con otros productos, o si es totalmente
independiente de otros productos.

Funciones
 Proporcionar un resumen de las funciones mayores que el software realizará.
Características de los Usuarios
 Esta subdivisión debe describir esas características generales de los usuarios
intencionales del producto que incluye nivel educativo, experiencia, y la especialización
técnica.
Restricciones.
 Proporcionar una descripción general de cualquier otro punto que limitará las opciones
de los diseñadores.
 Las políticas reguladoras.
 Las limitaciones del Hardware;
 Las Interfaces a otras aplicaciones;
 El funcionamiento Paralelo;
 Las funciones de la Auditoría;
 Las funciones de Control;
 Los requisitos de lenguaje;
 Los requisitos de Fiabilidad;
 Credibilidad de la aplicación;
 La Seguridad y consideraciones de seguridad.
Suposiciones y Dependencias.
 Debe listar cada uno de los factores que afectan los requisitos Declarados.
 Estos factores no son las restricciones del diseño en el software pero son, más bien,
cualquier cambio a ellos eso puede afectar.
 Por ejemplo, una suposición puede ser que un sistema operativo específico estará
disponible en el hardware designado para el producto del software. Si, de hecho, el
sistema operativo no está disponible, los requisitos tendrían que cambiar de acuerdo
con eso entonces.
Requisitos Específicos
 Debe contener todos los requisitos del software a un nivel de detalle suficiente para
permitirles a los diseñadores diseñar un sistema para satisfacer esos requisitos, y a los
auditores a probar que el sistema satisface esos requisitos.

 A lo largo de esta sección, cada requisito declarado debe ser externamente perceptible
por los usuarios, operadores u otros sistemas externos.
4.- Validación y Aceptación de Requisitos.
En qué consiste esta fase:
1. En esta fase se aprueba o no el Documento de Requisitos.

2. Tiene como objetivo principal encontrar errores en los requisitos, que tendrán que
corregirse lo más rápido posible, para volver a realizar después y nuevamente este paso
de validación.
3. Se Revisa también la calidad del documento y la adhesión a estándares.
Forma de validar la Especificación de Requisitos
4. La forma más utilizada es a través de listas de comprobación o chechList ( conjunto de

preguntas que deberán satisfacerse para aprobar el documento), por eejmplo:
¿Están todos los requisitos convenientemente enumerados?
¿El mismo servicio es solicitado en distintos requisitos?
¿Existen contradicciones entre ellos?
¿Son fácilmente comprensibles? ¿Por todo tipo de lector?
¿Los requisitos relacionados se encuentran agrupados en el documento?
¿Son correctos?
Ejemplos de Requisitos
✓ Requisitos que definen efectos: El sistema mantendrá la temperatura entre 70 y 80 grados C
✓ Requisitos funcionales: El sistema permitirá a los usuarios realizar una búsqueda de libros
por títulos, autor o ISBN.
✓ Requisitos de Implementación: El sistema podrá ejecutarse en entorno WEB.
✓ Requisitos de Rendimiento: El sistema deberá soportar 20 transacciones por segundo.

✓ Requisitos de Usabilidad: El sistema permitirá a los usuarios familiarizarse en un período
de 30 minutos.
4.- Registrar Terminos en el Glosario.
El glosario es una especie de diccionario, donde se especifican los conceptos que pueden dar
lugar a dudas. Ira creciendo en la medida que avanzamos en el análisis del sistema.
Ejemplo:
Nombre Descripción
Cliente Persona que ingresa a realizar una compra
Proveedor Persona que provee los productos para la
venta
Orientación de la Tarea.
Para el trabajo practico que está desarrollando, haga:

Plan Borrador.
Informe de Investigación Preliminar.
Definir los requisitos.
Glosario de términos.

Planeación y Especificación
del Sistemas (02).

Contenido.
5.- Casos de Uso

6.- Arquitectura del Sistema
Orientación para la Practica

5.- Definir Casos de Uso.
Introducción.
Los sistemas, no se encuentra aislados, ellos, interactúa con personas u objetos mecánicos con algún
objetivo y que esperan que el sistema funcione de una forma determinada.
Es por ello, que es importante identificar las fronteras de un sistema, y con quienes se interactúa,
además de conocer cuáles serían los procesos que se toman en cuenta para esta interacción.
Conceptos Básicos.
Qué es el modelo de casos de uso.

• El Modelo de Casos de usos proporciona la funcionalidad del sistema.
• Ilustra:
• Funciones del Sistema.
• Su entorno (Actores).
• Relaciones entre los casos de uso y actores. (Diagrama de Casos de Uso).
Importancia del Modelo de Casos de Uso.

• A través de él se comunican los Usuarios y los Desarrolladores.
• Decidir y describir los requerimientos funcionales del sistema.
• Dar una descripción concisa y consistente de lo que el sistema debe hacer.
• Proporciona las bases para las pruebas del sistema.
• Proporciona la habilidad de trazar los requerimientos funcionales en clases y operaciones
del sistema.
• Nos ayuda a comprender mejor los requisitos que debe tener un sistema, las necesidades
del usuario.
En qué momento se realizan.

▪ El modelo de casos de uso, comienza en la fase de inicio.
▪ (identificación de actores y casos de usos).
▪ Madura en la fase de Elaboración (se detallan más, se añaden más en la medida que se
necesiten).

Que representa
▪ Representa la Vista del Modelo de Casos de Usos.
▪ Que afecta las otras Vistas del Sistema.
▪ Las Funciones Especificadas en esta vista son implementadas en las otras Vistas.
▪ No sólo es utilizado para capturar requerimientos nuevos, sino también para desarrollar
nuevas generaciones de sistemas, añadiéndole nuevas funcionalidades a las ya existentes.
Que incluye:
 Diagramas de Casos de Uso.
 Descripción de los Casos de Uso.
Frontera del Sistema
 Como parte del modelaje se identifican las fronteras del Sistema.

 Aspectos a tener en cuenta para realizar la definición:
 Es difícil establecer la frontera.
 No se conoce que deberá ser automatizado y que no.
 Lo mejor es tomar la funcionalidad básica.
 Se debe obtener un catálogo de conceptos centrales, este no es un modelo del dominio,
sino un intento de describir la terminología del sistema.
 El sistema puede ser descrito como una caja, el nombre aparece arriba o dentro de la caja.
Actores
1. No son parte del Sistema.

2. Representan algo o alguien que debe interactuar con el Sistema.
3. El actor puede:
a) Solamente introducir datos.
b) Solamente recibir datos del sistema.
c) Introducir o recibir información desde / hacia el sistema.
4. Se comunican con el sistema enviando o recibiendo mensajes.
5. Un caso de uso es iniciado siempre por un actor, a menudo llamado estímulo.
6. El caso de uso es realizado para enviar mensajes a uno o más actores.
7. Un actor es una clase, no una instancia.
8. El actor representa un rol no un usuario individual del sistema.
9. Un actor tiene un nombre que representa el rol que realiza.

• Pueden tener rango:
• Actor primario: utilizan las funciones principales del sistema.
• Actor secundario: utilizan las funciones secundarias(mantenimiento del sistema,
respaldo, comunicación, etc).
• No tiene que ser un usuario directo.
• No tiene que ser humano siempre.
• Notación para actor:
▪ Identificación de Actores:
• Son encontrados en conversación con los clientes y los expertos del
dominio.
• Preguntas para encontrarlos:
• ¿Quién usará la funcionalidad Principal del Sistema?
• ¿Quién está interesado en cierto requerimiento?
• ¿Dónde en la organización será utilizado el Sistema?
• ¿Quién se beneficiará con el uso del Sistema?
• ¿Quién administrará, soportará y mantendrá al Sistema?
▪ Pueden tener relaciones pues son clases.
▪ Se muestran estas a través de generalización / especialización.
▪ Los actores especializados heredan el comportamiento de su superclase.

▪ Documentación de los actores
• Para cada actor se realizará una descripción.
• Esta descripción será el rol que juega.
• Ejemplo:
• Un cliente es aquella persona que adquiere un producto de
la compañía.
▪ Ejemplo:
• EL Caso de uso: Procesamiento de préstamos.
• Involucra necesariamente a los actores: cliente, responsable de
préstamos.

Casos de Uso
Que son?
 Modelan un diálogo entre una actor y el sistema.
 Representan la funcionalidad mostrada por el sistema.
 La colección de casos de usos representan todas las formas definidas en que un sistema será
utilizado.
 Representa una funcionalidad completa, tal y como será percibida por un autor.
 Caso de uso: es una secuencia de acciones, realizadas por el sistema que proporciona un
resultado observable de valor para un actor en particular.
 Notación:
• Un caso de uso especifica el comportamiento de un sistema o de una parte del mismo.

• Se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener
que especificar como se implementa ese comportamiento.
• Proporcionan un medio para que los desarrolladores los usuarios finales del sistema y los
expertos del dominio lleguen a una comprensión común del sistema.
• Puede tener varias variantes, se pueden tener casos de uso que son versiones especializadas
de otros casos de uso, casos de uso incluidos como parte de otros y casos de usos que se
extienden el comportamiento de otros casos de uso básicos.
1. Es siempre iniciado por un actor.
2. Proporciona valor a un actor.
3. Es completo.
4. Es una clase, no una instancia.
5. Un caso de uso puede tener instancias: Ejemplo de instanciación.
6. Caso de uso: Firmando Póliza de Seguro
7. Juan conecta el sistema por teléfono y firma una póliza de seguro para el tollota que
acaba de comprar.

8. Identificación de actores
• A partir de los Actores.
• ¿Cuáles son las tareas que necesita hacer?
• ¿Qué funciones requiere el actor del sistema?
• ¿necesitará el actor informar de algo al sistema?
• ¿Necesitará el actor ser informado de lago?
• Otras preguntas que no involucran a los Actores.
• ¿Qué casos de uso soportará y mantendrá el sistema?
• ¿Qué casos de uso creará, mantendrá o requerirá el
sistema?
• ¿Qué entrada, salidas recibirá/generará el sistema y
hacia7desde dónde?
1. Es una Vista Gráfica de algunos o todos los actores, casos de usos, interacciones del sistema.
2. Diagramas de Casos de Usos:
3. Diagrama de CU Principal: Es la imagen de la frontera (actores principales) y la
funcionalidades principales del Sistema.
4. Un diagrama que muestre todos los CU para un actor determinado.
5. Un Diag. De CU que muestre todos los CU implementados en una iteración.
6. Un diag. Que muestre un caso de uso y sus relaciones.
Ejemplo:

Como se describen los casos de Usos.
 Existen varias formas de hacer esto:
 Casos de uso de alto nivel. (En esta fase o etapa se describen en formato de alto
nivel) y es el que vamos a ver en este apartado.
 Formato Expandido.

Casos de uso de Alto Nivel.
a) Son más generales.
b) Son independientes del diseño.
c) Se deben especificar:
d) Nombre
e) Tipo
f) Actores
g) Descripción breve de lo que hace el caso de uso.
h) Pueden ser:
i) Primario (muy importante u ocurre con mayor frecuencia),
j) Secundario (menos importante),
k) Opcional (puede realizarse o no).
Formato a utilizar:
Nombre:
Tipo:
Actores:
Descripción:
Por Ejemplo:
Nombre: Comprar productos en el Supermercado
Tipo: Principal
Actores: Cajero, Cliente
Descripción: Cuando un cliente llega a la caja a pagar los productos que

se quiere llevar, el cajero va introduciendo cada código del
producto, cuando finaliza, el cajero indica le dice el total
que ha de pagar al cliente, el cliente paga y se va con los
productos comprados.

6.- Definir la Arquitectura del Sistema.
La Arquitectura del Sistema es una representación a alto nivel de los módulos que forman el
sistema, sus interfaces, conexiones, e interacciones.
La Arquitectura se representa mediante paquetes. Que gráficamente se pueden representar de la

siguiente forma.
Un paquete puede mostrar un grupo de subsistemas. Se denotan por carpetas. Es cualquier tipo de
elementos de UML. (clases, diagramas de casos de usos). Pueden tener otros paquetes subordinados
en si interior.

Arquitectura de tres niveles
La Arquitectura de tres niveles, divide el sistema en tres partes.

Presentación: La forma en que se presentan los datos.
Lógica del dominio: La comunicación entre la presentación y los datos
Almacenamiento: Gestión de las bases de Datos.
A continuación, se muestra un diagrama de la arquitectura del sistema, de tres niveles.

Arquitectura multinivel
La arquitectura multinivel, consiste en dividir en varios subniveles, un nivel.
Ventajas:
Reusabilidad: Un modulo bien construido se puede reutilizar en otros sistemas
Flexibilidad: Se pueden asignar distintos niveles a distintos equipos de desarrollo
Concurrencia: Distintos procesos pueden estar asignados a distintos procesos que se ejecuten en
varias máquinas.
Desventajas:
Aumento de la complejidad
Cada uno de los subniveles, puede a su vez tener varias particiones.
A continuación, se muestra un diagrama de la arquitectura del sistema multinivel.

Identificación de paquetes:
Se deben agrupar en un paquete los elementos que se refieren a un servicio en común, con un alto
nivel de colaboración y acoplamientos.
El paquete debe ser altamente cohesivo, incluir solamente aquellos elementos que se refieren a un
servicio con responsabilidades relacionadas
Entre los elementos de los paquetes, debe haber poco acoplamiento para evitar llamadas de unos
elementos a otros.
Orientación Tarea.
En esta parte, presentará un trabajo práctico, que deberá defender.
• Realice para su trabajo practico, todas las partes y la documentación que se genera en
esta fase.

Teoría del Color.

Contenido.
Que es el color
Colores primarios, secundarios, intermedios, terciarios
Circulo cromático.
Formas de combinar los colores
Elección de un esquema de color.
Colores fríos.
Colores cálidos.
Significado de los colores
Conclusiones.
(Imágenes: Material Recompilado de Internet)

El Color
Que es el color
 Color es la sensación resultante de la estimulación de la retina del ojo por ondas lumínicas.
 Están presentes en la naturaleza, en las formas, en los objetos.
 Brindan volumen, profundidad y personalidad.
 La forma de elegir un color, de mezclarlo, de combinarlo o contrastarlo para conseguir el
mejor efecto influye sobre el resultado final.
Colores Primarios:
Son aquellos colores que no se pueden obtener de la mezcla de ningún otro color, se dice que son
originales, y a partir de ella se pueden obtener junto con el blanco y el negro, cualquier otro color.
Estos colores son:
• Amarillo.
• Rojo.
• Azul.
Colores Secundarios:
Los colores secundarios son aquellos que se obtienen al mezclar los primarios.
Estos colores son:
• Violeta (rojo + azul).
• Naranja (rojo + amarillo).
• Verde (azul + amarillo).
Colores Intermedios:
Los colores intermedios son los que se obtienen mezclando los colores primarios con los
secundarios.
Colores Terciarios:
Mezclando dos colores secundarios se obtienen los terciarios. Y mezclando dos terciarios obtenemos
aun un color cuaternario.

Circulo Cromatico
1. El círculo cromático, es utilizado para obtener las formas clásicas de combinación de

colores.
2. No hay reglas que gobiernen la selección de un esquema de color.
3. Pero hay algunas combinaciones armónicas inspiradas en el círculo cromático.

Combinación de Colores.
Formas Clásicas de Combinar los colores.
1. Combinaciones Monocromáticas.
2. Combinaciones por Analogía.
3. Combinaciones de Complementarios.
4. Combinaciones por Complementarios Divididos.
5. Combinación Triaxal.
Combinaciones Monocromáticas.
Se utiliza un solo color, y sus diferentes matices.
Ejemplos:

Combinaciones por Analogía
Consiste en utilizar colores adyacentes en el círculo cromático (uno al lado del otro). Todos los
colores tienen un color base igual.
Ejemplo Nro1: azul y violeta

Ejemplo Nro1: Naranja y Amarillo

Combinaciones de Complementarios
Se combinan colores opuestos en el círculo cromático.
Por ejemplo, el rojo y el verde; el azul y el naranja.
Se debe tratar que un color domine, y el otro que se utilice para contraste
Por Ejemplo:

Combinaciones de Complementarios Divididos:
• Se consigue utilizando un color y los adyacentes de su complementario.

• Por ejemplo: Verde, Rojo, Morado.

Combinación Triaxal.
▪ Tomando como punto de partida cualquier color, podemos trazar un

triángulo equilátero en el círculo cromático, que nos dará, en sus
vértices, los otros dos colores restantes que forman el trío armónico.
▪ Por lo tanto, el trío armónico está formado por los tres colores que
quedan en los vértices si trazamos un triángulo equilátero en el círculo
cromático.
▪ De esta manera los primarios forman un trío armónico entre sí, igual
que los secundarios. Por tratarse de una combinación demasiado
violenta (colores que "chocan" entre sí), se utilizan relativamente poco y
con mucho cuidado.

Ejemplo: Combinación de los colores Morado, Verde, Naranja.
Ejemplo: Combinación de los colores Azul, Amarillo, Rojo.

Elección de un esquema de Color.
➢ El color comunica información, no es sólo decorativo (Por ejemplo se puede utilizar para
reforzar el mensaje de error).
➢ Debe utilizar combinaciones adecuadas (por ejemplo, las paletas proporcionadas por los
sistemas operativos) o también, se puede usar una de las combinaciones de armonía y
contraste estudiadas anteriormente.
➢ El color debe atraer la atención, pero no cansar después de un rato de trabajo.
➢ Es especialmente importante seguir las líneas de diseño existentes. Principio básico: diseñar
primero en blanco y negro, y luego añadir el color.
➢ Si utiliza algún esquema de color, se puede empezar estudiando en profundidad un color

que resulte particularmente agradable.

Colores cálidos y Colores fríos.
➢
Colores Cálidos.
▪ Son los colores asociados al sol y al fuego.
▪ Cuanto más próximos en intensidad esté un color a un primario cálido (sea rojo o amarillo)
más cálido será.
▪ Los colores cálidos son vibrantes, estimulantes y activos.
▪ La calidez se presenta de muchas maneras; el terracota es sofisticado, mientras que el tono

de las hojas secas es rústico, el amapola (rojo) es estimulante, mientras que el albaricoque
(amarillo) es apacible.
▪ Puede ser abrumador grandes cantidades de colores cálidos fuertes, por lo que es mas
prudente elegir sus vecinos (análogos) más suaves y reservar los fuertes para algunos
toques.

Colores Fríos.
• Los colores azules son colores fríos.
• Los colores del agua transparente, de extensos prados y de bosques sombríos tienden a ser
colores fríos.
• Pueden dar sensaciones de tranquilidad y frescura, son colores sedantes.
• Otro de los colores fríos es el verde, que es el favorito de la naturaleza.

Significado de los colores.
AMARILLO
Representa luz, vida, Acción y Poder.
 Sobre aspectos psicológicos es considerado el color de la ira, la antipatía, el atrevimiento,

los impulsos y la falsedad.
 Paradójicamente, puede ser relacionado con el sol, significa alegría, y buen humor. En
algunos casos es considerado liberador e intelectual.
 En grandes cantidades puede molestar debido a la intensa irradiación de luz.
 Es sagrado en China, simbolizando el oro.
NARANJA
Representa la prosperidad, la abundancia de frutos, y el sol. Posee la luminosidad del amarillo y la
excitación del rojo.
 Se relaciona bien con el ardor y el entusiasmo, lo que lo vuelve popular.
 Es altamente empleado para la señalización en las industrias, identificando o advirtiendo
sobre áreas con maquinaria peligrosa.
 Cuando se adiciona al negro, es inmediatamente destituido de todos sus aspectos positivos.
Pasa a representar los deseos reprimidos y la intolerancia. Pierde su pureza emotiva.
ROJO
Es un color llamativo, con gran poder de atracción
 Rojo es calor.
 Debe aparecer en áreas de pequeña.
 Color ligado al erotismo.
 No beneficia la actividad mental pero estimula.
 Aumenta la tensión muscular, activa la respiración, estimula la presión arterial.
 Es indicado para estimular a personas retraídas.

AZUL
Esencialmente atmosférico. Es frío por naturaleza.
 Puede ser utilizado en grandes superficies sin volverse cansador.

 Es tranquilizante.
 Está ligado a la mente. Reduce la presión sanguínea.
 En tono violeta simboliza verdad y sabiduría.
 Debe ser equilibrado armónicamente con otros colores para evitar un clima de tristeza y
monotonía.
VERDE
Equilibra las emociones. Es el color que menos fatiga la vista. Es el equilibrio entre el calor y el
movimiento del amarillo, y la estática y la frialdad del azul.
 En la industria es ampliamente empleado para combatir la fatiga visual y consecuentemente
el cansancio físico.
 Es el color más representativo de las Iglesias Cristianas, simbolizando resurrección y
bautismo.
 Se encuentra en la naturaleza, en un sinfín de tonalidades.
Trae claridad y alegría cuando es usado como complemento.

 Es asociado a prestigio, economía, distinción, silencio, ligereza, tranquilidad y limpieza.
 Un cuerpo blanco refleja, teóricamente, la totalidad de los rayos luminosos que inciden
sobre él.
NEGRO
Leves toques de negro dan un cierto aspecto agradable a un diseño. Modifica el efecto de los
colores, realzando sus tonos. Intensifica los valores altos y reduce la intensidad de los bajos. Es el
color que refleja menos luz.

Otros ejemplos del uso del Color(Material recompilado).

Tema 5 Construcción.
1
Contenido.
 Construcción.
 Actividades a desarrollar.
 Casos de uso en formato expandido.
 Modelo Conceptual.
 Casos de uso reales
 Diagramas de Secuencia.
 Contratos de Operación del Sistema.
 Diagramas de Colaboración.
 Bibliografía: Material recompilado.
2
Construcción.
 Análisis: Se analiza el problema a resolver desde la perspectiva
del usuario y de las entidades externas que van a interactuar.
 Diseño: Se especifican las funciones de la aplicación
describiendo como va a funcionar internamente y para cubrir los
requisitos indicados en el análisis.
 Implementación: Se lleva lo especificado en el diseño a un
lenguaje de programación.
 Pruebas: Se prueba el sistema para verificar que funciona según
lo especificado en las anteriores fases.
3
Actividades que se desarrollan
 En esta fase las actividades a desarrollar son:
❑Definir casos de uso esenciales en formato expandido.
❑Definir el Modelo conceptual y refinar el glosario.
❑Definir los Diagramas de Secuencia.
❑Definir los Contratos.
❑Definir los Casos de uso reales.
❑Definir los Diagramas de Colaboración.
❑Definir los Diagramas de Interacción.
❑Definir el Diagrama de Clases de Diseño.
4
Continuamos con casos de usos
 En la Fase de Análisis se escogen los casos de uso mas
importantes y se describen con mayor nivel de detalle,
utilizando el formato expandido
 En la fase de diseño: Se describen los casos de uso en formato
real.
5
Casos de uso de Alto Nivel.
 Son más generales.
 Son independientes del diseño.
 Se debe especificar:
▪ Nombre
▪ Tipo
▪ Actores
▪ Descripción breve de lo que hace el caso de uso.
▪ Pueden ser:
 Primario (muy importante, ocurre con mayor frecuencia),
 Secundario (menos importante)
 Opcional (puede realizarse o no).
6
Formato.
Nombre:
Tipo:
Actores:
Descripción:
7
Ejemplo de un Caso de Uso de Alto Nivel.
Nombre: Compra de Productos en el supermercado

Tipo: Principal
Actores: Cliente, Cajero.
Descripción: Un cliente llega a la caja con los productos que quiere comprar, el cajero ira
introduciendo cada producto, cuando finaliza, el cajero indica el total que ha
de pagar el cliente, el cliente paga y se va con los productos comprados.
8
Casos de uso en formato expandido
9
Casos de uso en Formato Expandido.
 Se toman los casos de uso mas importantes y se describen con más
detalle.
 Se deben especificar:
❑Nombre.
❑Actores.
❑Propósito.
❑Visión General.
❑Tipo (Primario, Secundario, General)
❑Referencia a los requisitos.
❑Curso Típico de Eventos.
❑Curso Alternativo de Eventos.
10
Formato
Nombre:
Actores:
Propósito:
Visión
General:
Tipo:
Referencias:
Curso Típico de Eventos
Curso Alternativo de Eventos
11
Ejemplo.
Actores Cliente (iniciador), cajero
Propósito Capturar una venta y su pago
Visión General Un cliente llega a la caja con los productos que quiere llevar, el
cajero va introduciendo cada producto, cuando finaliza, el
cajero indica el total que ha de pagar el cliente, el cliente paga
y se va con los productos comprados.
Tipo Principal
Referencias R1
cliente Sistema Cajero
12
1.- El caso de uso 3.- El sistema determina el precio de 2.- El cajero registra cada producto, si
se inicia cuando el cada producto, calcula el total y lo va hay mas de uno de un producto
cliente llega a la acumulando. determinado, el cajero puede
caja con los 5.- El sistema calcula el total de la registrar la cantidad.
productos a pagar. venta. 4.- cuando el cajero termina de
7.- El cliente 9.- Calcula y muestra el cambio a capturar la venta, le indica al sistema
entrega dinero en devolver e imprime la factura. que ha terminado.
efectivo al cajero 11.- Registra la venta completada. 6.- El cajero le dice al cliente el
en una suma igual importe total.
o mayor al 8.- Registra la cantidad entregada por
importe de la el cliente.
compra. 10.- Deposita el dinero en la caja, le
12.- El cliente entrega el cambio y factura al cliente
toma el cambio y
se va.
13
Línea 2 Se registra un producto incorrecto, se indica el error.
Línea 7 El cliente no tiene dinero suficiente, se cancela la transacción ó:
Cliente Sistema Cajero
7.- El cliente le 9.- El sistema descuenta el importe 8.- El cajero le indica al sistema que
dice al cajero que total de los productos devueltos va a descontar productos, y va
no tiene dinero 11.- El sistema calcula el importe registrando los que va devolviendo.
suficiente y que le total. 10.- Indica al sistema que ya no va a
va a devolver devolver más.
varios productos
14
 Se pueden utilizar también sesiones, por ejemplo, el pago puede
hacerse al contado o con tarjeta, quedando de la siguiente forma:
Visión General Un cliente llega a la caja con los productos que quiere llevar, el
cajero va introduciendo cada producto, cuando finaliza, el cajero
indica el total que ha de pagar el cliente, el cliente paga y se va
con los productos comprados.
Tipo Principal
Referencias R1
15
1.- El caso de uso 3.- El sistema determina el precio de 2.- El cajero registra cada producto, si
se inicia cuando el cada producto, calcula el total y lo va hay mas de uno de un producto
cliente llega a la acumulando. determinado, el cajero puede
caja con los 5.- El sistema calcula el total de la registrar la cantidad.
productos a pagar. venta. 4.- cuando el cajero termina de
7.- El cliente elige 8.- Imprime la factura. capturar la venta, le indica al sistema
el tipo de pago 9.- Registra la venta completada. que ha terminado.
a) Si escoge 6.- El cajero le dice al cliente el
Pago en importe total.
efectivo ir a
sesión pago
en efectivo.
b) Si escoge
Pago con
tarjeta de
crédito ir a
sesión pago
con tarjeta
11.- El cliente se
16
va
Sesión Pago en Efectivo
1.- Entrega el 3.- Obtiene el cambio 2.- Registra la cantidad entregada por
importe. el cliente.
4.- Entrega el cambio al cliente
Sesión Pago con tarjeta
cliente Sistema Autorización de Tarjeta
1.- Entrega la 2.- Autoriza la tarjeta
tarjeta 3.- Adeuda la compra a la cuenta del
cliente.
17
Modelo Conceptual.
Un caso de uso no es la mejor herramienta para

definir el dominio de la Aplicación.
Para ello utilizamos el Modelo Conceptual.
18
Modelo Conceptual
 Se identifican los conceptos, características y relaciones.
 Se le llama también Diagrama de Estructura Estática.
 Debe satisfacer los requisitos expresados en los casos de uso.
 Permite describir el dominio en un grado de abstracción
alto, libre de decisiones de diseño.
 A través de él, se describen los conceptos del dominio,
utilizando conceptos, asociaciones y atributos.
 Es Estático.
 Es Cíclico (Existe un modelo conceptual por cada ciclo).
 Es Evolutivo.
19
Pasos para obtener el Modelo
Conceptual.
Se parte de los requisitos descritos en los casos de uso y del
conocimiento del dominio.
1.- Se especifican nombres, Conceptos y Atributos
2.- Realizar una lista de asociaciones típicas relevantes entre distintos
conceptos.
3.- Diagrama de estructura estática.
20
1.- Especificar nombres, Conceptos y Atributos.
 Se realizar una lista de conceptos comunes:
 Objetos físicos, por ejemplo: terminal de punto de venta, buzón de voz, etc.
 Especificaciones o descripciones de objetos.
 Lugares : aeropuerto, tienda.
 Transacciones: reserva, venta.
 Línea de una transacción: venta de un producto, tramo en una reserva de viaje.
 Roles : azafata, cajero.
 Contenedores : hangar, estantería.
 Sistemas o dispositivos externos: servicio autorización de cheques
 Conceptos abstractos: satisfacción, pobreza
 Organizaciones: Línea aérea.
 Miembros de una organización: piloto, técnico, analista.
 Eventos : despegue, aterrizar.
 Reglas o políticas: normativa de exámenes, criterio de calificación.
 Catálogos : catálogo de productos.
 Documentos financieros legales: cheque, contrato de trabajo.
 Manuales, libros, documentos: manual de procedimiento.
21
2.- Realizar una lista de asociaciones típicas relevantes entre
distintos conceptos,
 Las asociaciones que se pueden tener son:
 A es parte física de B: manos/dedos
 A es parte lógica de B: tramo/viaje
 A está físicamente dentro de B : pasajero/avión
 A está lógicamente dentro de B : descripción de producto/catálogo
 A es una descripción de B : descripción de ítem/ítem
 A es un elemento de una transacción de B: compra de ítem/compra
 A es registrado, capturado o archivado en B : conexión/Terminal
 A es miembro de B : piloto / línea aérea
 A es subunidad organizativa de B :sucursal/banco
 A esta relacionado con una transacción B :pasajero/reserva
 A es una transacción relacionada con otra transacción B : compra/cambio
 A esta junto a B : finger/finger
 A usa o gestiona B : piloto / avión
 A comunica con B : cliente/cajero
 A posee a B : línea aérea / avión
22
Formas de Identificar Conceptos.
1.- Lista de categorías Visto anteriormente
Consiste en transformar los
2.- A partir de frases nominales. sustantivos que aparecen en el
requisito en conceptos o atributos.
 Por ejemplo, del Requisito:

 El cliente llega al Cliente
punto de venta con Punto de ventas
productos para Productos.
comprar.
23
Ejemplo: A partir del siguiente requisito
construiremos un diagrama de
Estructura Estática:
El centro comercial tiene empleados, que trabajan como cajeros, uno
de los empleados hace la función de gerente.
24
Solución
1.- Identificar Conceptos.
 Una organización centro comercial
 dos roles, cajero y gerente.
2.- Identificar atributos.
nombre nombre
centro comercial cajero y gerente.
dirección. salario.
3.- Identificar asociaciones

 cajero se relaciona con el centro comercial mediante la asociación trabaja
 el gerente es encargado de la dirección del centro comercial
25
Elementos del Diagrama de Estructura
Estática
 Conceptos. Se representan en un Cuadrado.
Contienen el nombre de los Atributos.
Característica de los conceptos.
Sus valores suelen pertenecer a tipos simples
 Atributos. Si son tipos estructurados, pueden considerarse como un concepto
aparte.
Se colocan dentro del cuadrado que describe el concepto.
Representan relaciones entre dos conceptos.

Se puede incluir una flecha en la asociación, para indicar el sentido de
la lectura.
 Asociaciones. Se puede especificar multiplicidad (el número de conceptos que se
relaciona con cada uno de ellos) Multiplicidad: Cuantas instancias de
un concepto se relacionan con una instancia del concepto que
26 relacionan.
Para nuestro Ejemplo.
 Tenemos el concepto centro
comercial, se representa con
un cuadrado, en el cual se
colocan los atributos del
mismo, nombre y dirección
y los conceptos cajero y
gerente, representados
ambos en cuadrados, dentro de
los cuales se especifican sus
atributos, nombre y sueldo.
27
Especificación de multiplicidad (hay varias
formas de especificar la multiplicidad:
❑ En un centro comercial trabajan
muchos cajeros y como mínimo
uno.
❑ Un numero exacto. En un
centro comercial tiene 5
cajeros. Se indica poniendo un
5 en el extremo
correspondiente a cajero.
❑ Un número indeterminado de
instancias. En un centro
comercial trabajan varios
cajeros. Se indica con un * en el
extremo correspondiente a
28
cajero.
Especificación de multiplicidad (hay varias
formas de especificar la multiplicidad:
❑ Se debe especificar la
multiplicidad en dos
sentidos, por ejemplo, en un
centro comercial trabajan
muchos cajeros y un cajero
trabaja en el centro comercial
❑ Un centro comercial tiene un

gerente que a su vez puede
serlo de 0 o 1 centro.
29
Obtenemos el Diagrama de Estructura Estática
siguiente:
30
Otras relaciones y asociaciones:
Relación Reflexiva
Asociaciones:
Generalización / Especialización
Agregación
Composición
Asociación
31
Relación Reflexiva.
 Relación entre el mismo concepto.
 Por ejemplo:
 El concepto persona se relaciona puede
relacionar con el mismo, una persona es
jefe de varias personas, a su vez es
dirigida por una persona.
 Habrá que especificar el rol o papel que
desempeña, en una dirección será jefe
mientras que en la opuesta subordinado.
32
Tipos de Asociaciones
 Generalización-Especialización.
 Agregación
 Composición.
 Asociación.
33
Generalización-Especialización
 Aumento del grado de abstracción
de un concepto.
 Al padre se le dice supertipo y a
los hijos subtipos.
 Para denotar esta relación se
coloca un triángulo apuntando al
supertipo, del que cuelgan los
hijos o subtipos.
34
Agregación
 Se refiere a conceptos que forman parte de otros conceptos.
 Se representa con un rombo como se muestra a continuación:
 Por ejemplo: Si se tiene un equipo deportivo, mismo que está

compuesto por varios alumnos y un alumno puede pertenecer a
varios equipos.
 Si cada alumno solo puede pertenecer a un equipo entonces la

relación es de composición, ya no de agregación. Aspecto que
se trata a continuación.
35
Composición
 Similar a la relación de agregación, difiere, en que un elemento
sólo puede pertenecer a un contenedor.
 La notación es igual, es decir, se utiliza un rombo. pero estará
pintado o relleno de negro.
 Por ejemplo: una mano está compuesta de cinco dedos, cada
dedo es de una mano. A continuación se muestra la
representación de esta composición.
36
Relaciones Asociativas.
 Son las asociaciones entre conceptos,
donde la relación tienen atributos propios.
 La notación, es una entidad que cuelga de
la asociación con una línea discontinua.
 Por ejemplo:
 Un socio de un video club puede alquilar varias películas y una película
puede ser alquilada por un socio; la forma de representar esto, es con
dos conceptos, socio y película, relacionado entre sí mediante una
asociación.
 Sin embargo, la fecha de devolución, no es un atributo de socio ni de
pelicual, sino de la relación entre ellos, es decir, la asociación. Por lo
tanto, se colocara como atributo de la asociación.
37
Casos de uso en Formato Real
38
Casos de Uso en Formato Real
 Los Casos de Uso Reales, se obtienen en el diseño.
 Detallan el funcionamiento de una pantalla.
 Detallan la interfaz con el usuario.
 Detallan la funcionalidad que ofrecen los eventos.
 Se utilizan para especificar la funcionalidad que debe cumplir
un caso de uso en un nivel de abstracción bajo.
 A cada uno de ellos, se asocia una pantalla.
Casos de Uso Real.
Nombre: Compra de Productos en supermercado en efectivo
Visión Un cliente llega a la caja con los productos que quiere llevar,
General el cajero va introduciendo cada producto, cuando finaliza, el
cajero indica el total que ha de pagar el cliente, el cliente paga
y se va con los productos comprados.
Tipo Principal, real
Referencias R1
40
Curso típico de eventos.
1.- El caso de uso 3.- El sistema determina el precio de 2.- El cajero introduce en la caja de
se inicia cuando el cada ítems, muestra el precio y texto el código o identificador
cliente llega a caja descripción, y va acumulando al de cada producto, si no conoce el
con productos a importe total de la venta. identificador del producto podrá
pagar. 5.- El sistema calcula el total de la pulsar el botón Buscar. Aparecerá
7.- El cliente venta y muestra en una caja de una lista de los productos. Si hay mas
entrega dinero en texto, el importe total de la venta. de uno producto de uno determinado,
efectivo al cajero 9.- Calcula y muestra el cambio a el cajero puede registrar la cantidad.
en una suma igual devolver en la etiqueta, e imprime 4.- Cuando el cajero termina de
o mayor al el recibo. capturar toda la venta, le indica al
importe total de la 11.- Registra la venta completada. sistema que ha terminado,
compra. cliqueando el botón Terminar.
12.- El cliente 6.- El cajero le dice al cliente el
toma el cambio y importe total.
se va. 8.- Registra la cantidad entregada por
el cliente en la caja de edición.
10.- Deposita el dinero en la caja y le
entrega el cambio y recibo al cliente
41
Línea 2 Se registra un producto incorrecto, indicar el error.
Línea 7 El cliente no tiene dinero suficiente, se cancela la transacción ó:
7.- El cliente le 9.- El sistema descuenta el importe 8.- El cajero indica al sistema que va a
dice al cajero que total de los productos devueltos descontar productos, va registrando
ya no tiene dinero 11.- El sistema calcula el importe los productos a devolver.
y le va a devolver total. 10.- Indica al sistema que ya no va a
algunos productos. devolver más.
42
Para el caso de uso de pedidos en una
Churrasqueria , seria de esta forma
Nombre: Pedidos en una Churasqueria
Actores Cliente (iniciador), mesero
Propósito Capturar un pedido
Visión Un cliente llega a la churrasquería y solicita productos del

General menú para su consumo, el mesero, va seleccionado cada item
y asignando la cantidad, cuando finaliza, el mesero envia el
pedido a cocina para su procesamiento.
Tipo Principal, real
Referencias R
43
Cliente Sistema Mesero
1.- Este Caso de uso 3.- Determina el precio de 2.- El mesero, introduce
comienza cuando el cada ítem registrado, cada ítem, haciendo clic en
cliente solicita pedir muestra el precio y va la casilla de verificación
productos a consumir del acumulando el importe asociada, con su respectiva
menú total de todo el pedido. cantidad.
5.- Envía el pedido a cocina 4.- Una vez terminado el
para su procesamiento cajero le dice al sistema que
ha terminado, haciendo clic
en el botón terminar

Línea 2 Se registra un item que no se esta ofertando, se muestra un error
44
Diagrama de Secuencia.
Diagrama de Secuencia
Pasos.
Ejemplo.
45
Diagrama de Secuencia.
Que es?.
Cuando se utiliza.
Notación.
46
Que es el Diagrama de Secuencia
 Es un diagrama
 Donde se muestra el comportamiento del sistema.
 Muestra una visión dinámica del sistema.
 Complementa al Modelo Conceptual.
 Ilustra:
 Actores
 Sistemas.
 Eventos.
 Es secuencial.
 No representa alternativas ni iteraciones.
47
Cuando se utiliza y a partir de que
 Cuando se utiliza
 En el Diseño de alto nivel.
 A partir de que se obtiene

 A partir de los casos de uso en formato expandido.
48
Notación.
 Eventos: Se utiliza una flecha horizontal, donde se escribe el

nombre del evento, pueden tener parámetros, el nombre debe
comenzar con un verbo. Sólo se representan los eventos q
parten del actor, no los q hace el sistema para responder a este
evento.
Nombre del evento(lista de parámetros)
49
Notación.
 Actor: Notación utilizada para un actor.
 Sistema : Un rectángulo, con el nombre, utilizando : antes

del nombre y subrayado.
 Tiempo: Se utiliza un rectángulo, para indicar el tiempo en

que no se puede ejecutar otro evento.
50
Pasos para elaborar el diagrama
de Secuencia.
1.- Dibujar un rectángulo que represente el sistema.
2.-Identificar los actores y dibujarlos, uno a continuación del otro en línea
horizontal.
3.- Trazar una línea vertical para cada actor.
4.- Dibujar un rectángulo con el nombre del sistema en la línea horizontal.
5.- Identificar los eventos para cada actor y dibujarlo, utilizando una flecha
horizontal con el nombre del evento.
51
Ejemplo
Para el caso de uso en formato expandido estudiado de Compra de

productos en el Supermercado, se mostrara el Diagrama de secuencias.
52
Diagrama de Secuencia para compra de
Productos con tarjeta
53
Compra de Productos en efectivo
54
Devolución del Producto
55
Contrato de Operación del Sistema.
Es una herramienta que permite definir las

operaciones que debe cumplir el sistema.
A través de los contratos se describen el
comportamiento de sistema asignando
responsabilidades a las operaciones.
56
Componentes.
 Nombre de la Operación.
 Responsabilidades
 Referencias a los requisitos y casos de uso.
 Notas y sugerencias para el diseño.
 Excepciones
 Salidas fuera de la interfaz
 Precondiciones: Condiciones para que se pueda ejecutar con éxito.
 Postcondiciones: De que manera se transforma el estado del
sistema, que puede ser:
o Destrucción o creación de instancias.
o Establecimiento o rupturas de asociaciones entre conceptos.
o Modificación de valores o atributos.
57
Pasos para elaborar los contratos.
 Identificar las operaciones utilizando los diagramas de
Secuencia.
 Elaborar un contrato para cada operación del Diagrama.
 Redactar las responsabilidades y describir el propósito.
 Identificar las postcondiciones, a través de las siguientes
categorías:
o Destrucción o creación de instancias.
o Establecimiento o rupturas de asociaciones entre
conceptos.
o Modificación de valores o atributos.
58
59
Nombre registraVentaItem(cod: entero,cant:entero)
Responsabilidades: Registrar la venta de un producto y añadirlo a la venta en
curso, mostrar el precio del producto y la descripción del
producto
Referencias: R1, R5, R7
Casos de uso: Comprar productos en el supermercado
Excepciones: Si el código es incorrecto, muestra un mensaje de error
Precondicones: Que el código sea conocido por el sistema
Postcondiciones: Si es una venta nueva, se crea una instancia de compra y se
crea una asociación con TPV.
Se creo una instancia de compra de producto, y se asocio con
la compra actual y con la descripción del producto.
Nombre Compra de un item.cantidad toma valor cant.
finalizaVenta
Responsabilidades: Finalizar la venta en curso y mostrar el total de la compra.
Casos de uso: Comprar productos en el Supermercado.
Excepciones: Si no hay una venta, devuelve error
Precondicones: Que al menos haya un producto en la venta.
60 Postcondiciones:
Análisis de Sistemas Si asigna a venta.terminada el valor verdadero.
Nombre realizaPagoTarjeta(numero: entero)
Responsabilidades: Realiza el pago con tarjeta.
Casos de uso: Comprar productos
Excepciones: Que haya una venta en curso.
Precondicones: Que el atributo venta terminada sea verdadero
Postcondiciones: Si asocio a venta.pago el valor con tarjeta.
Nombre Autorizapago(resp)
Responsabilidades: Comprueba si la tarjeta es valida y resta la cantidad de la
cuenta del cliente
Casos de uso: Comprar productos
Excepciones: Que haya una venta en curso.
Precondicones: Que el atributo venta.terminada sea verdadero
Que el atributo venta.pago sea con_tarjeta
Postcondiciones: Si asocia el atributo venta.pagada con valor verdadero.
61
Diagramas de Colaboración.
Son una representación de como

colaboran distintos conceptos
para conseguir una determinada
funcionalidad.
62
 Cada uno de esos conceptos estarán representados por clases
o objetos (instancias de ellas)
 Ellos interactuaran para llevar a cabo la realización de un
evento. (representado en los diagramas de secuencias)
 Por tanto, se realizara un diagrama de colaboración por cada
evento representado en los diagramas de secuencia.
 Un evento se ejecutara como un método de una de las clases del
sistema.
 Que a su vez, disparara otros eventos, mismos que pueden
ejecutarse en otros objetos, para poder conseguir la funcionalidad
que este realiza.
63
Pasos para realizar el Diagrama de
Colaboración.
 Se toma un diagrama de secuencia.
 Por cada evento se hace un diagrama de colaboración.
 Se toma como entrada un evento. Que será un método que
va a ejecutar una clase del sistema.
 Se determina, cual será la clase encargada de ejecutar dicho
método, que se puede obtener del modelo conceptual.
 El modelo conceptual, tiene las clases, sin embargo, en este
momento pueden surgir algunas otras que no habíamos
tomado en cuenta.
64
Como hacer el Diagrama de
Colaboración.
 Se determinan las clases según las responsabilidades que tiene
ese evento. Que clases son las que participan en ese evento.
 Se enumeran los eventos, según el orden de ejecución que se
realizaran.
 Se pone primero el evento para el cual se esta construyendo el
diagrama de colaboración. Este evento no se enumera, no lleva
asociado un numero, no tiene clase origen.
 A continuación se enumeran todos los eventos que deben
ejecutarse en orden secuencial, enumerándolos a partir se 1, 2,
etc.
65
66
67
Condiciones e iteraciones en el
Diagrama de Colaboración.
 En ocasiones se pueden necesitar poner condiciones, en ese caso se
utilizara la palabra 1a:[cond]metodo1() y por el otro lado
1b:[nocond]metodo2().
 El caso de condiciones se da, cuando se puede ir por una rama u otra.
Para indicar que son diferentes ramas se utiliza a,b,c , etc, diferentes
letras.
 Se puede necesitar que un metodo se ejecute varias veces, en ese caso,
se coloca un asterisco * despues del numero:
 Ejemplo: 1*: lin=siguientelineaproductos()
 Si es un numero de iteraciones determinado, puede utilizarce un
rango de valores, para indicar las veces que se repite el metodo.
Ejemplo: 1: [i=1..20]=siguientelineaproductos()
68
Visibilidad en el Diagrama de Colaboracion
 Para que un objeto pueda enviar un mensaje a otro deben ser
visibles entre si.
 La visibilidad es la capacidad que tiene un objeto para referenciar a
otro.
 Tipos de visibilidad:
❑Visibilidad de atributos o asociacion: un atributo es visible a objeto que
lo contienen.
❑Visibilidad de parametros: un parametro de un mensaje es visible al
objeto que lo llama.
❑Visibilidad local: un objeto local declarado en un mensaje de un objeto
es visible a dicho objeto.
❑Visibilidad global: un objeto es visible globalmente.
69
❑NotacionVisibilidad de asociacion:
Cuando B es un atributo de A
❑Notacion visibilidad de parametros:

B es un parametro del metodo A
❑Visibilidad local:
Cuando se declara B como un objeto
local dentro de un metodo de A,
❑Visibilidad global:
B es global para A
70
Diagrama de Interacción
Es una forma de representar el Diagrama de Colaboración con distinta
notación.
Es un diagrama parecido al diagrama de secuencia
Se utiliza para representar la secuencia de ejecución de los métodos que
interactúan entre las clases que forman el evento
La diferencia principal con el diagrama de secuencia es que en este se
muestran todos los métodos que parten del sistema
71
Diagrama de Interaccion para
Registrar Venta
72
Diagrama de Interaccion para
Realizar Pago
73
Diagrama de Clases de Diseño
Es una herramienta que se utiliza para definir el comportamiento del
Sistema.
Definir clases, los atributos y los métodos que se van a implementar en el
diseño de bajo nivel.
Se realizan como una ampliación del modelo conceptual, tomando en cuanta
los diagramas de secuencia, operaciones y contratos definidos en el diseño de
alto nivel.
Se parte del diagrama de secuencia y se añaden las nuevas clase obtenidas en
74los diagramas de colaboración.
Pasos
 Identificar clases en los diagramas de interacción.
 Se dibujan en el diagrama de clases.
 Se colocan los atributos del modelo conceptual
 Colocar los métodos del diagrama de interacción.
 Incorporar los tipos de los atributos y métodos.
 Agregar asociaciones y dependencias.
75
Conclusiones.
76
Conclusiones.
 Formato Expandido. Para la descripción de los casos de uso
 También el modelo conceptual y como realizar un diagrama de
estructura estática.
 Casos de uso reales, mismos que llevan asociado una pantalla.
 Diagramas de Secuencia.
 Contrato de operaciones
 Diagramas de colaboración
 Diagramas de interacción
 Diagramas de clases.
77
Practica
78
Trabajo Práctico.
➢Describa los casos de uso en formato expandido.
➢Realice el modelo conceptual. Diagrama de
estructura estática.
➢Casos de uso reales.
➢Diagrama de secuencias.
➢Contrato de Operaciones.
➢Diagrama de colaboración.
➢Diagramas de interacción
➢Diagrama clases.
79

Tema 01 Introduccion A La Asignatura-Fusionado

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 01 Introduccion A La Asignatura-Fusionado

Cargado por

Copyright:

Formatos disponibles

Introducción a la Asignatura.

Conceptos básicos, aspectos generales y medios para

Doc. Ing. Rosa Almaraz

Doc. Ing. Rosa Almaraz

Objetivo del Tema:

Forma de trabajar en la asignatura:

Se estudian aspectos relacionados al desarrollo de un sistema informático para una organización o

Doc. Ing. Rosa Almaraz

¿Qué significa Metodología?

En cualquier proyecto de desarrollo de software, es necesaria la colaboración de muchas personas.

Se tiene diversas metodologías, desde el Análisis y diseño Estructurado hasta la Metodología

Doc. Ing. Rosa Almaraz

Si bien la metodología estructurada ha sido ampliamente utilizada, actualmente se ha impuesto con

Doc. Ing. Rosa Almaraz

Todo software cuenta con dos fases importantes:

Doc. Ing. Rosa Almaraz

La programación estructurada tradicional se basa fundamentalmente en la ecuación de Wirth:

Algoritmos + Estructuras de Datos = Programas

Doc. Ing. Rosa Almaraz

Las ventajas más importantes son:

Mantenibilidad: Facilidad de Mantenimiento. Los programas que se diseñan utilizando el

Modificabilidad: Facilidad de Modificar los programas. Es fácil realizar añadidos o supresiones al

Doc. Ing. Rosa Almaraz

Doc. Ing. Rosa Almaraz

Formas del Manejo de Información.

Doc. Ing. Rosa Almaraz

▪ Que es un Sistema de Información?

Doc. Ing. Rosa Almaraz

Elementos de un Sistema de Información.

Características de los Sistemas.

▪ Todo sistema interactúa con un medio.

Doc. Ing. Rosa Almaraz

▪ Los Sistemas tienen Niveles Aceptables de Desempeño.

Doc. Ing. Rosa Almaraz

Ciclo de vida de un Sistema

¿Qué es el ciclo de vida de un Sistema?

Doc. Ing. Rosa Almaraz

2. Determinación de los Requerimientos de Información.

3. Análisis de las Necesidades del Sistema.

Doc. Ing. Rosa Almaraz

5. Desarrollo y Documentación del Sistema

7. Implantación y evaluación del sistema

Objetivos del Análisis de Sistemas:

Especificar un Sistema de Información que ayude a conseguir los Fines de la Organización.

• ¿Quiénes Son los Usuarios?

• Importancia de los Usuarios.

Doc. Ing. Rosa Almaraz

¿Quién es el Analista de Sistemas?

Responsabilidades del Analista.

▪ Debe comprender los detalles de una situación y decidir si es fiable o no la automatización.

Doc. Ing. Rosa Almaraz

Papel del Analista

Doc. Ing. Rosa Almaraz

Trabajo del Ingeniero de Sistemas.

Resultados del análisis

Doc. Ing. Rosa Almaraz

Tipos de modelados de Datos:

Modelo Conceptual: Representa una visión general del Sistema

Los modelos utilizables son:

Doc. Ing. Rosa Almaraz

Doc. Ing. Rosa Almaraz

Una Organización es un Sistema.

Doc. Ing. Rosa Almaraz