Codificación de los módulos del sistema de Información

MAURICIO ALEJANDRO GONZÁLEZ FERIA CC: 1.069.174.552

MIGUEL MARIANO RUBIDE MOSQUERA CC: 1078116858
VÍCTOR AUGUSTO REGINO CONDE CC: 1064309129

ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓN - ADSI

FICHA 1565035 - SENA VIRTUAL
ABRIL 2019
MÓDULO DE SISTEMAS DE INFORMACIÓN

1.1 SISTEMAS DE INFORMACIÓN EN LOS NEGOCIOS ACTUALES

Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y

administración de datos e información, organizados y listos para su uso posterior,
generados para cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna
de las siguientes categorías:

• Personas
• Datos
• Hardware
• Software
• Procedimientos

Todos estos elementos interactúan para procesar los datos y dan lugar a información más
elaborada, que se distribuye de la manera más adecuada posible en una determinada
organización, en función de sus objetivos.
Segun wikipedia dice que “Sistema de información se entiende como el conjunto de tecnologías,
procesos, aplicaciones de negocios y software disponibles para las personas dentro de una
organización. Es un conjunto de elementos que interactúan entre sí con un fin común; que
permite que la información esté disponible para satisfacer las necesidades en una organización.
Los sistemas de información, permiten incrementar el crecimiento económico.

Un Sistema de Información realiza cuatro actividades básicas:

● Entrada de información: proceso en el cual el sistema toma los datos que requiere.
● Almacenamiento de información: puede hacerse por computadora o archivos físicos para
conservar la información.
● Procesamiento de la información: permite la transformación de los datos fuente en
información que puede ser utilizada para la toma de decisiones
● Salida de información: es la capacidad del sistema para producir la información procesada o
sacar los datos de entrada al exterior.”

1.2 NEGOCIOS GLOBALES: CÓMO UTILIZAN LAS EMPRESAS LOS

SISTEMAS DE INFORMACIÓN

Las empresas han incorporado dentro de sus procesos los sistemas de información, estos son
de gran relevancia que permiten a estas desarrollar sus actividades de trabajo, con
información y conocimiento, al mismo tiempo ha permitido un aumento en la eficiencia de
los procesos y la automatización de muchos otros procesos para competir a niveles más
globales. Los sistemas de información se pueden establecer desde dos perspectivas: la
funcional, en la que se encuentran sistemas de ventas y marketing, de manufactura y
producción, financieros y contables, de recursos humanos., que fortalecen las tomas de
decisiones de la empresa.
Los sistemas de información se han ido convirtiendo con el tiempo, en otra área funcional de
la empresa, tal como la de contabilidad, finanzas, mercadeo, o producción. En la actualidad
toda organización exitosa se ha concientizado de la importancia del manejo de las tecnologías
de información (TI) como elemento que brinda ventajas comparativas con respecto a la
competencia.

Es importante tener en cuenta que un sistema de información necesita justificar su

implementación desde el punto de vista - costo / beneficio -, partiendo de la concepción del
valor que se le otorgue a la información dentro de una organización.

Los beneficios se pueden medir a nivel intangible y tangible de acuerdo a la organización,

pues es diferente hacer el análisis desde el punto de vista de una empresa comercial a una de
tipo académico que pretende prestar un servicio social como lo es la salud o educación
pública.

Los beneficios que se pueden obtener usando sistemas de información son los siguientes:

❖ Acceso rápido a la información y por ende mejora en la atención a los usuarios.

❖ Mayor motivación en los mandos medios para anticipar los requerimientos de las
directivas.
❖ Generación de informes e indicadores, que permiten corregir fallas difíciles de
detectar y controlar con un sistema manual.
❖ Posibilidad de planear y generar proyectos institucionales soportados en sistemas de
información que presentan elementos claros y sustentados.
❖ Evitar pérdida de tiempo recopilando información que ya está almacenada en bases de
datos que se pueden compartir.
❖ Impulso a la creación de grupos de trabajo e investigación debido a la facilidad para
encontrar y manipular la información.
❖ Soluciona el problema de falta de comunicación entre las diferentes instancias. A
nivel directivo se hace más efectiva la comunicación
❖ Organización en el manejo de archivos e información clasificada por temas de interés
general y particular.
❖ Generación de nuevas dinámicas, utilizando medios informáticos como el correo
electrónico, multimedia, teleconferencia, acceso directo a bases de datos y redes
nacionales e internacionales.
❖ Acceso a programas y convenios e intercambios institucionales.
❖ Aumento de la productividad gracias a la liberación de tiempos en búsqueda y
generación de información repetida.
1.3 SISTEMAS DE INFORMACIÓN Y ORGANIZACIÓN ESTRATEGIA

La interacción entre la tecnología de información y las organizaciones es muy compleja y

recibe la influencia de muchos factores mediadores, como la estructura, los procesos de
negocios, las políticas, la cultura, el entorno y las decisiones administrativas. Algunos de
los cambios que ocurren en las empresas a causa de las nuevas inversiones en tecnología de
información no pueden verse y sus resultados podrían o no satisfacer sus expectativas. Una
organización es una estructura social formal, estable, que toma recursos del entorno y los
procesa para producir bienes y servicios. También son estructuras sociales porque
constituyen un conjunto de elementos sociales, de manera parecida a la estructura de una
máquina.

1.4 ASPECTOS ÉTICOS Y SOCIALES DE LOS SISTEMAS DE INFORMACIÓN

La ética se refiere a los principios del bien y el mal, actuando como agentes de libre moral;
los sistemas de información generan nuevas cuestiones éticas, y junto con la tecnología de
la información producirá beneficios éticos para muchos y costos para las directivas. La
ética nos señala los principios de lo correcto e incorrecto que formen nuestra conducta y
que como seres libres optamos para la toma de nuestras decisiones. Los sistemas de
información (Internet, comercio electrónico, etc.) se pueden utilizar y aprovechar para
realizar cosas muy beneficiosas como el progreso social y no para cometer delitos y
amenazar los valores más preciados.
2.1 INFRAESTRUCTURA DE TI Y TECNOLOGÍAS EMERGENTES

Una buena infraestructura de IT es indispensable para apoyar las operaciones cotidianas

basadas en el flujo continuo de información del entorno de la organización y dentro de la
organización misma, dicha infraestructura sirve como plataforma para poner en práctica la
estrategia de negocio, enfrentar los cambios del entorno y proporcionar un nuevo conjunto
de habilidades y procesos a sus administradores.

ELEMENTOS DE LA NUEVA INFRAESTRUCTURA DE TI.

Hay cuatro principales infraestructuras de sistemas: sistemas antiguos, cliente/servidor,

Internet/Intranet y comunicaciones inalámbricas/celulares. Una gran parte de la computación
corporativa se sigue basando en una arquitectura cliente/servidor que llega a los escritorios,
respaldada por aplicaciones y bases de datos de microcomputadoras del sistema antiguo. Esta
infraestructura tradicional ahora debe integrarse con Internet pública y con las Intranets
corporativas, además una nueva forma de trabajo móvil está usando dispositivos portátiles de
PC que deben tener casi el ​mismo acceso a los datos corporativos.
2.2 FUNDAMENTOS DE INTELIGENCIA DE NEGOCIOS: ADMINISTRACIÓN
DE LA BASE DE DATOS E INFORMACIÓN

Trabajar con bases de datos es fácil cuando tienes los conocimientos necesarios, finalmente
son herramientas esenciales para construir sitios rápido, dinámicos y modernos.
Esencialmente las bases de datos son estructuras para almacenar información. Todos
usamos bases de datos, sólo que no tenemos conciencia de que eso es lo que son. Por
ejemplo, una agenda con direcciones es una base de datos, allí guardas nombres, fonos o
direcciones. Es decir, la agenda almacena información, la puedes tener ordenada
alfabéticamente para facilitar la búsqueda y de vez en cuando debes actualizarla.

En una versión electrónica una base de datos tiene las siguientes características:

● Almacena información, cualquiera que necesites guardar.

● Esta información se encuentra indexada y se mantienen los datos almacenados en un
orden tal que permita su búsqueda rápida.
● Además incluye un sistema de recuperación rápida, esta recuperación se llama
“Consulta”. Tú haces la consulta y el computador hará la parte difícil de buscar lo que
estás necesitando.
● Cada cierto tiempo tu base de datos necesitará una limpieza, tal como la agenda de la
que hablábamos. En el caso de la base de datos, esta se desordena con borrones o
cambios, por lo que te será necesario hacerle una rápida y fácil limpieza.

Las bases de datos pueden almacenar prácticamente cualquier información que quieras, al
menos mientras las tengas correctamente instaladas. Esa información se indexará para una
búsqueda rápida. En una base de datos, puedes guardar información de clientes o registros
de ventas, pero una de las cosas más útiles de una base de datos es la posibilidad que
entrega de hacer sitios web dinámicos, pues a través de ellas podrás cambiar contenido
fácilmente. Dentro de los tipos de sistemas de administración de bases de datos, el
relacional es el más utilizado, esto porque es más sencillo y comprensible por los usuarios
finales y los profesionales de tecnologías de información; además puede progresar, ya que
las relaciones entre los datos no necesitan estar predefinidas.
2.3 PROTECCIÓN DE LOS SISTEMAS DE INFORMACIÓN

La s​ eguridad de la información es el conjunto de medidas preventivas y reactivas de

las organizaciones y de los sistemas tecnológicos que permiten resguardar y
proteger la información buscando mantener la confidencialidad, la disponibilidad e
integridad de datos y de la misma. El concepto de seguridad de la información no
debe ser confundido con el de ​seguridad informática​, ya que este último sólo se
encarga de la seguridad en el medio informático, pero la información puede
encontrarse en diferentes medios o formas, y no solo en medios informáticos.

Para el hombre como individuo, la seguridad de la información tiene un efecto

significativo respecto a su ​privacidad​, la que puede cobrar distintas dimensiones
dependiendo de la cultura del mismo. El campo de la seguridad de la información
ha crecido y evolucionado considerablemente a partir de la Segunda Guerra
Mundial, convirtiéndose en una carrera acreditada a nivel mundial. Este campo
ofrece muchas áreas de especialización, incluidos la auditoría de sistemas de
información, planificación de la continuidad del negocio, ciencia forense digital y
administración de sistemas de gestión de seguridad, entre otros.
Concepción de la seguridad de la información
En la seguridad de la información es importante señalar que su manejo está basado en la
tecnología y debemos de saber que puede ser confidencial: la información está centralizada
y puede tener un alto valor. Puede ser divulgada, mal utilizada, ser robada, borrada o
saboteada. Esto afecta su disponibilidad y la pone en riesgo. La información es poder, y
según las posibilidades estratégicas que ofrece tener acceso a cierta información, ésta se
clasifica como:

❏ Crítica​: Es indispensable para la operación de la empresa.

❏ Valiosa​: Es un activo de la empresa y muy valioso.
❏ Sensible​: Debe de ser conocida por las personas autorizadas.
❏ Existen dos palabras muy importantes que son riesgo y seguridad:
❏ Riesgo​: Es la materialización de vulnerabilidades identificadas, asociadas con su
probabilidad de ocurrencia, amenazas expuestas, así como el impacto negativo que
ocasione a las operaciones de negocio.

La seguridad de la información comprende diversos aspectos entre ellos la disponibilidad,

comunicación, identificación de problemas, análisis de riesgos, la integridad,
confidencialidad, recuperación de los riesgos. Precisamente la reducción o eliminación de
riesgos asociado a una cierta información es el objeto de la seguridad de la información y la
seguridad informática. Más concretamente, la ​seguridad de la información tiene como
objeto los sistemas el acceso, uso, divulgación, interrupción o destrucción no autorizada de
información.​2​​ Los términos seguridad de la información, ​seguridad informática y ​garantía
de la información son usados frecuentemente como sinónimos porque todos ellos persiguen
una misma finalidad al proteger la ​confidencialidad​, ​integridad y ​disponibilidad de la
información. Sin embargo, no son exactamente lo mismo existiendo algunas diferencias
sutiles. Estas diferencias radican principalmente en el enfoque, las metodologías utilizadas,
y las zonas de concentración. Además, la seguridad de la información involucra la
implementación de estrategias que cubran los procesos en donde la información es el activo
primordial. Estas estrategias deben tener como punto primordial el establecimiento de
políticas, controles de seguridad, tecnologías y procedimientos para detectar amenazas que
puedan explotar vulnerabilidades y que pongan en riesgo dicho activo, es decir, que ayuden
a proteger y salvaguardar tanto información como los sistemas que la almacenan y
administran. La seguridad de la información incumbe a gobiernos, entidades militares,
instituciones financieras, los hospitales y las empresas privadas con información
confidencial sobre sus empleados, clientes, productos, investigación y su situación
financiera.
3.1 EL ROL DE ANALISTA DE SISTEMAS

El a​ nalista de sistemas es un ​profesional especializado del área de la ​informática​,

encargado del desarrollo de aplicaciones en lo que respecta a su diseño y obtención de
los ​algoritmos​, así como de analizar las posibles utilidades y modificaciones necesarias
de los ​sistemas operativos para una mayor eficacia de un ​sistema informático​. Otra
misión de estas personas es dar apoyo técnico a los usuarios.

Las funciones más relevantes que se incorporan son:

● Dirección (de proyectos), para dirigir los recursos hacia el resultado deseado.
● Deducción de requisitos, para determinar el comportamiento que se espera del software.
● Garantía de calidad, para garantizar las expectativas del cliente.
● Diseño, para que exista una mínima certeza de que el software es viable y eficaz
con la tecnología existente.
● Gestión de configuración, para controlar el caos a medida que el software crece.

Estas funciones han sido adoptadas en muchos casos por analistas, pero no son materia
específica de esta profesión. En algunas organizaciones (y en algunos países) la profesión ya
no existe, siendo sustituida por otras figuras (pero siempre bajo el perfil de analista de
sistemas ya que no se puede desvincular la necesidad de la captura de requerimientos y
niveles de abstracción con los cuales el profesional puede plasmar la necesidad del cliente en
los documentos correspondientes y realizar posteriormente el diseño del sistema) tales como
el ingeniero de software, el jefe de proyecto, el modelador de software, o el
analista-programador. Esta última figura es muy popular ya que resuelve los típicos
problemas de ​comunicación que existían entre analistas y programadores. Estos problemas
se deben a la extrema idealización de la especialización de funciones.

Lo que no se escapa a la realidad es la necesidad de un rol que posea tanto conocimientos

técnicos como de análisis ya que siempre se necesitará un intérprete entre el cliente y los
programadores involucrados en los proyectos; y no existen carreras como la de jefe de
proyecto o modelador de software.Es deseable también que el analista de sistemas tenga
conocimientos -al menos básicos- de usabilidad. Ya que cualquier sistema que no esté al
servicio de los usuarios o diseñado pensando en el usuario, no tiene mucho sentido.
3.2 ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE
INFORMACIÓN.

Los analistas de sistemas para poder analizar y diseñar un sistema de información deben
visualizar las organizaciones en las que laboran como sistemas formados por las
interacciones de tres fuerzas principales como lo son:

Los niveles de administración, el diseño de las organizaciones y las culturas de dichas

organizaciones.

Las organizaciones pueden ser sistemas complejos que a su vez se puede componer de
subsistemas que interconecten o sean independientes. Estos subsistemas se caracterizan por
su entorno que va de un continuo abierto y cerrado. Por lo general es sistema abierto
permite el libre tránsito de recursos (gente información material) al contrario de los
sistemas cerrados o permiten que la información fluya de manera libre no existe entradas ni
salidas.

Los analistas usan los diagramas de entidad-relación para comprender las entidades y sus
relaciones, las cuales conforma el sistema organizacional. Estos diagramas son los que
conforman el sistema organizacional ya que pueden describir relaciones uno a uno, uno a
muchos y muchos a muchos.

Hay tres niveles de control administrativo:

* El operativo
* El nivel medio
* El estratégico

El tiempo para la toma de decisiones es distinto en cada nivel.

Culturas y subculturas dentro de las organizaciones son factores importantes determinan la

manera de cómo la gente utiliza la información así como los sistemas de información.

3.3 DETERMINACIÓN DE LA VIABILIDAD Y ADMINISTRACIÓN DE LAS

ACTIVIDADES DE ANÁLISIS Y DISEÑO.

Los proyectos pueden ser solicitados por diversas personas de la organización o por los
mismos analistas de sistemas. La selección de un proyecto es una decisión difícil, ya
que se solicitarán más proyectos de los que se pueden realizar. Cinco criterios
importantes para la selección de un proyecto son:
1.- El proyecto solicitado debe tener el respaldo de los directivos de la organización
2.- Que cuente con un periodo adecuado de compromiso para la terminación del proyecto
3.- Que impulse a la organización hacia la consecución de sus metas
4.- Que tenga factibilidad
5.- Que tenga la importancia suficiente para darle mayor prioridad que a otros proyectos.

Entre muchas de las capacidades fundamentales que debe dominar un analista de sistemas
se incluye la iniciación de proyectos, la determinación de la viabilidad de un proyecto, la
programación de proyectos, y la planeación y administración de las actividades y los
miembros de un equipo para optimizar la productividad. Estas capacidades se consideran
aspectos fundamentales de un proyecto.

4.2 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS

Entre los muchos tipos de recolección de la información para un sistema, la más usada es la
entrevista donde resaltan dos clases de preguntas, las abiertas y las cerradas; las preguntas
abiertas permiten al entrevistado usar todas las opciones de respuestas, en las preguntas
cerradas se limitan las opiniones posibles. Los sondeos o preguntas de seguimiento pueden
ser abiertos o cerrados, pero piden al encuestado una respuesta más detallada. Las
preguntas pueden estructurarse de tres maneras básicas: pirámide, embudo y diamante. Las
estructuras de pirámide empiezan con preguntas cerradas y detalladas y finalizan con
preguntas más amplias y generales. Las estructuras de embudo empiezan con pregunta
abierta y general y a continuación pasan a preguntas cerradas más específicas. La
estructuras con forma de diamante combinan la fortaleza de las otras dos estructuras, pero
 toma mucho más tiempo para realizarse. Hay ventajas y desventajas involucradas en la
decisión de cuan estructuradas hacer las preguntas de la entrevista y la secuencia de
preguntas.

4.3 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS NO INTRUSIVOS.

Los métodos que se verán a continuación son el muestreo, la investigación, y la observación del
comportamiento y el entorno físico donde se desempeña la labor del tomador de decisiones.

Muestreo

El muestreo en si se trata de tomar elementos que represente parte de una población en

particular. Se dice que el analista de sistema tiene que tomar encuestas 2 puntos muy
importantes a realizar este método, el primero se tiene que tomar encuesta todos los
documentos y sitios web que los miembros de la organización han realizado, tiene que checar
cuál de ellos le sirve y cual hay que rechazar. El segundo tiene que ver quiénes serán más
afectados con la implementación del sistema que se desarrollara.

Existen muchas razones por la cual es necesario el muestreo, ya que el analista tiene que
seleccionar una parte representativa de dato o personas que tiene que analizar, ya sea por
medio de entrevistas para el caso de las persona. Hay cuatro razones importantes:

1. Reducir costos: Ya que es muy costoso para el analista, andar examinando documento
por documento, más los sitios web. Con el muestro el analista puede ahorrarse mucho
trabajo, ya solo puede recopilar información de un lugar con todos los datos de la
población.

2. Acelerar la recopilación de datos: Ayuda a mejorar la efectividad si se puede obtener

información más precisa.

3. Mejorar efectividad: Hablar con menos empleados, hace que analista tenga tiempo de
verificar que no haya perdido los datos.

4. Reducir la parcialidad: En este punto el analista entrevista al ejecutivo que está más
involucrado con el sistema.
Diseño del muestreo

Para tener un buen muestreo el analista tiene que seguir los siguientes 4 pasos:

1) Determinar qué datos van a ser recopilados o descritos

2) Determinar qué población se van a tomar muestra
3) Escoger el tipo de muestra
4) Decidir el tamaño de la muestra

Investigación

La investigación es la acción de descubrir y analizar los datos. El analista de sistemas necesita

examinar cada punto importante dentro de la organización, mediante la examinación de datos
reales.los datos y formulación dan a entender a dónde ha estado la organización y hasta donde
se cree que se dirige. Para ello hay que analizar todos los documentos que sean de carácter
cuantitativo y cualitativo. En el documento cuantitativo, se incluyen informes usados en la
toma de decisiones, informes de desempeño, registros y una variedad de formularios. En el
documento cualitativo se incluyen mensajes de correos, memorandos, carteles en los tableros
de anuncios y en las áreas de trabajo entre otros documentos. Estos documentos son muy
detallados.

Observación

La observación es una de los métodos más sencillos en el se observan muchas cosas

importante,ya que este nos da una mejor idea de lo que realmente se hace en la organización,
o sea que ve cómo se realizan todos y cada uno de los procesos que se realizan. En ello se
identifican los actores principales en la toma de decisiones, utilizando un guión del analista.
Otro punto importante dentro del método de la observación es la estructura del entorno del
tomador de decisiones, llamado STROBE.

Se pueden observar e interpretar algunos elementos concretos en el entorno del tomador de

decisiones. Estos elementos incluyen:

(1) la ubicación de la oficina.

(2) la colocación del escritorio del tomador de decisiones;
(3) el equipo fijo de oficina
(4) los accesorios como las computadoras de bolsillo y las PCs
(5) las fuentes externas de información como las revistas especializadas y el uso de la Web
(6) la iluminación y el color de la oficina
(7) La vestimenta de los tomadores de decisiones.
4.3 ELABORACIÓN DE PROTOTIPOS DE RAD Y PROGRAMACIÓN EXTREMA.

C​omo analista de sistemas que presenta un prototipo del sistema información, usted está
bastante interesado en las reacciones de los usuarios y los directivos de la organización
hacia el prototipo .Usted desea saber detalladamente cómo reaccionarán al trabajar con el
prototipo y que también satisfarán sus necesidades la características del sistema a partir de
las cuales se elaboró el prototipo. Las reacciones se recopilan a través de la observación, las
entrevistas y las hojas de retroalimentación (posiblemente los cuestionarios) diseñados para
obtener la opinión de cada persona sobre el prototipo después que interactúan con él.

La información recopilada en la fase de elaboración de prototipos permite al analista

establecer las prioridades y cambiar el rumbo de los planes a bajo costo, con un mínimo de
molestias. Debido a esta característica, la elaboración de prototipos y la planeación van de
la mano.

Clases de prototipos

La palabra prototipo se usa de muchas formas diferentes. En lugar de sintetizar todos estos
usos en una sola definición o de tratar de convenir en un enfoque correcto al tema un tanto
polémico de la elaboración de prototipos, ilustramos la manera en que cada una de varias
concepciones de la elaboración de prototipos se puede aplicar convenientemente en una
situación particular.

Prototipo corregido La primera clase de elaboración de prototipos tiene que ver con la
construcción de un sistema que funciona pero se corrige simultáneamente. En la ingeniería
a este enfoque se le llama elaboración de una tabla experimental: la creación, en una tableta
de pruebas, de un modelo funcional de un circuito.

PROGRAMACIÓN EXTREMA

La programación extrema (XP) es un enfoque de desarrollo de software (tratando el capítulo

3) que adopta lo que generalmente designamos como práctica de desarrollo de software
aceptable y las lleva al extremo. Por ejemplo, la retroalimentación es importante para los
programadores, analistas, diseñadores, usuarios y computadoras (como verán en el
capítulo 14). Así que la programación extrema usa ciclo de retroalimentación cada vez más
rápido e intenso, que proporcionan más información.

La administración de proyecto es importante, de tal manera que la programación extrema

intenta definir rápidamente un plan global del sistema, desarrollar y liberar rápidamente el
software y posteriormente revisarlo continuamente para incorporarles características
 adicionales. Los programadores, analistas y diseñadores ordinarios que trabajan
independientemente y luego integran su trabajo logran resultados sólidos; los
programadores extremos que trabajan en parejas pueden ser excelentes. Pero la
programación extrema no solo se basa en los resultados. Se basa en los valores principios y
prácticas.

5.1 USO DE DIAGRAMA DE FLUJO DE DATOS.

Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación
gráfica para la maceta del "flujo" de datos a través de un sistema de información. Un
diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento
de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un
contexto a nivel de DFD que primero muestra la interacción entre el sistema y las
entidades externas. Este contexto a nivel de DFD se "explotó" para mostrar más detalles
del sistema que se está modelando.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador
original del diseño estructurado, basado en el modelo de computación de Martin y Estrin:
"flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres
perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método
SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados
y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo
de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el
sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de
 diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de
diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un
sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para
proporcionar al usuario final una idea física de cómo resultarán los datos a última
instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en
que cualquier sistema es desarrollado, puede determinarse a través de un diagrama de
flujo de datos. Modelo de datos tiene 3 niveles, los cuales son:

· Nivel 0: Diagrama de contexto.

· Nivel 1: Diagrama de nivel superior.
· Nivel 2: Diagrama de detalle o expansión

5.2 ANÁLISIS DE SISTEMAS MEDIANTE DICCIONARIO DE DATOS.

Un ​diccionario de datos​, o repositorio de ​metadatos​, como lo define el ​IBM Dictionary of

Computing,​ un repositorio centralizado de información sobre datos tales como significado,
relación con otros datos, origen, uso y formato. ​En un diccionario de datos se encuentra la
lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los
elementos más importantes son flujos de datos, almacenes de datos y procesos. El
diccionario guarda los detalles y descripciones de todos estos elementos.

Si los analistas desean conocer cuántos caracteres abarca un determinado dato o qué otros
nombres recibe en distintas partes del sistema, o dónde se utiliza, encontrarán las
respuestas en un diccionario de datos desarrollado en forma apropiada. El diccionario se
desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la
determinación de los requerimientos de sistemas.

NECESIDAD DE ENTENDER EL DICCIONARIO DE DATOS

Muchos sistemas de administración de base de datos están equipados con un diccionario ​de datos
automatizado. Estos diccionarios pueden ser complejos o sencillos. Algunos diccionarios de datos
computarizados catalogan automáticamente los elementos de datos ​cuando se hace la
programación; otros simplemente proporcionan una plantilla para motivar a la persona que
llene el diccionario a que lo haga de una manera uniforme para cada entrada.

ESTRUCTURAS DE DATOS LÓGICAS Y FÍSICAS

Cuando las estructuras de datos se definen primero, sólo se incluyen los elementos de datos
que el usuario vería, tal como un nombre, dirección y saldo a pagar. Esta fase es el diseño
lógico, el cual muestra qué datos necesita el negocio para sus operaciones diarias.

ALMACENES DE DATOS

Todos los elementos base se deben almacenar en el sistema. También los elementos
derivados se podrían almacenar en el sistema, tal como, para un empleado, el sueldo bruto
acumulado a la fecha. Los almacenes de datos se crean para cada entidad de datos
diferente que se almacenará. Es decir, cuando los elementos base de un flujo de datos se
agrupan para formar un registro estructural, se crea un almacén de datos para cada registro
estructural único.

CREACIÓN DEL DICCIONARIO DE DATOS

Las entradas del diccionario de datos se podrían crear después de completar el diagrama de flujo
de datos, o se podrían construir conforme se desarrolle el diagrama de flujo de datos.

El uso de notación algebraica y registros estructurales permite al analista desarrollar el

diccionario de datos y los diagramas de flujo de datos mediante un enfoque jerárquico de
arriba hacia abajo.

Por ejemplo, el analista podría crear un flujo de datos de un Diagrama 0 después de las
primeras entrevistas y, al mismo tiempo, hacer las entradas preliminares del diccionario
de datos. Típicamente, estas entradas consisten en los nombres de los flujos de datos
encontrados en el diagrama de flujo de datos y sus estructuras de datos correspondientes.

USO DEL DICCIONARIO DE DATOS

El diccionario de datos ideal es automatizado, interactivo, en línea y evolutivo. Conforme el

analista de sistemas descubre cosas nuevas de los sistemas de la organización, se agregan
elementos de datos al diccionario de datos. Por otro lado, el diccionario de datos no es un
fin en sí mismo y nunca debe serlo. Para evitar desviarse del propósito principal con la
construcción de un diccionario de datos completo, el analista de sistemas debe verlo como
una actividad paralela al análisis y diseño de sistemas.

5.3 DESCRIPCIÓN DE LAS ESPECIFICACIONES DE PROCESOS Y

DECISIONES ESTRUCTURADAS.

Los tres objetivos de la especificación de proceso son: reducir la ambigüedad de los procesos,
obtener una descripción precisa de lo que se logra y validar el diseño de sistema. Una gran
parte del trabajo del analista de sistemas involucrará decisiones estructuradas, Para lograr esto,
 el analista necesita definir cuatro variables en la decisión que está siendo examinada:
condiciones, alternativas de condición, acciones y reglas de acción. El lenguaje estructurado
usa palabras reservadas aceptadas, tales como SI, entonces, sino, hacer, hacer ​mientras y
hacer hasta para describir la lógica usada y usa sangrías para indicar la estructura
jerárquica del proceso de decisión. Las tablas de decisión proporcionan otra forma para
examinar, describir y documentar decisiones.

Cuatro cuadrantes:

1.- Describir las condiciones.

2.- Identificar alternativas de decisión posibles (tales como S o N).
3.- Indicar cuáles acciones deben ser ejecutadas.
4.- Describir las acciones.

El tercer método para el análisis de decisiones es el árbol de decisión que consiste de nodos
(un cuadrado para acciones y un círculo para condiciones) y ramas. Los árboles de decisión
son adecuados cuando se deben realizar acciones en una secuencia determinada.

5.4 PREPARACIÓN DE LA PROPUESTA DE SISTEMAS.

El analista de sistemas necesita trabajar con los usuarios para determinar qué hardware se
necesitará. Las determinaciones del hardware sólo se pueden realizar de manera
conjunta con la determinación de los requerimientos de información.

CÓMO INVENTARIAR EL HARDWARE DE CÓMPUTO

Empiece por inventariar el hardware de cómputo que ya existe en la organización. Como

podrá observar, algunas de las opciones de hardware involucran la ampliación o el
reciclaje del hardware actual, de modo que es importante saber con qué se cuenta.

CÁLCULO DE LAS CARGAS DE TRABAJO

El próximo paso en la determinación de las necesidades de hardware es calcular las

cargas de trabajo. Así, los analistas de sistemas establecen cifras que representan las
cargas de trabajo actuales y proyectadas para el sistema con el fin de que cualquier
hardware que se adquiera cuente con la capacidad para manejar las cargas de trabajo
actuales y futuras.
EVALUACIÓN DEL HARDWARE DE CÓMPUTO

La evaluación del hardware de cómputo es una responsabilidad compartida de los

directivos, usuarios y analistas de sistemas. Aunque los fabricantes proporcionarán
detalles acerca de los productos que ofrezcan, los analistas necesitan supervisar
personalmente el proceso de evaluación porque ellos se preocuparán por los mejores
intereses del negocio. Además, tal vez los analistas de sistemas tengan que enseñar a
los usuarios y a los directivos las ventajas y desventajas generales del hardware para
que puedan evaluarlo de manera eficaz.

TAMAÑO Y USO DE LA COMPUTADORA

El rápido avance de la tecnología obliga a los analistas de sistemas a investigar qué tipos
de computadoras están disponibles en el momento específico en que se escribe la
propuesta de sistemas. El tamaño de las computadoras va desde las pequeñas
computadoras Palm que caben en una mano hasta las supercomputadoras que podrían
ocupar toda una sala. Evaluación del soporte técnico del fabricante para el hardware de
cómputo Diversas áreas importantes se deben evaluar al analizar los servicios de
soporte técnico que los fabricantes ponen a disposición de las empresas. La mayoría de
los fabricantes ofrece una prueba de hardware en la entrega y una garantía de 90 días
que cubre cualquier defecto de fabricación, pero usted debe averiguar qué más ofrece
el fabricante. Los fabricantes de calidad comparable frecuentemente se distinguen de
otros por la gama de servicios de soporte técnico que ofrecen.

CÓMO IDENTIFICAR Y PRONOSTICAR LOS COSTOS Y BENEFICIOS

Siempre se deben considerar en conjunto los costos y beneficios del sistema de cómputo
propuesto, debido a que con frecuencia están vinculados y dependen uno del otro.

CÓMO PRONOSTICAR LOS COSTOS Y BENEFICIOS

Se necesita que los analistas de sistemas pronostiquen ciertas variables importantes antes
de enviar la propuesta al cliente. Hasta cierto punto, un analista de sistemas se apoyará
en un análisis de “qué pasa si”, tal como, “¿Qué pasa si los costos de mano de obra
suben sólo 5 por ciento por año durante los próximos tres años, en lugar de 10 por
ciento?” Sin embargo, el analista de sistemas debe entender que él o ella no se pueden
apoyar únicamente en un análisis del tipo “qué pasa si” si quieren que la propuesta sea
creíble, significativa y valiosa.
ANÁLISIS DE FLUJO DE EFECTIVO

El análisis de flujo de efectivo examina la dirección, tamaño y modelo del flujo de

efectivo que se asocia con el sistema de información propuesto.

5.5 DISEÑO DE UNA SALIDA Y ENTRADA EFICAZ.

La información que se entrega a los usuarios a través del sistema de información utilizando
intranets, extranets o la World Wide Web. Algunos datos requieren un gran cantidad de
procesamiento antes de transformarse en la salida apropiada; otros se almacenan, y cuando
se recuperan, se consideran como salida con poco o ningún procesamiento. La salida puede
tomar muchas formas: los informes impresos tradicionales y los informes presentados de
manera transitoria, como el caso de las pantallas de computadora, las micro formas y la
salida de audio. Los usuarios dependen de la salida para realizar sus tareas y con frecuencia
juzgan el valor de un sistema solo por su salida. Para crear la salida más útil posible, el
analista de sistemas debe trabajar cerca con el usuario en un proceso interactivo hasta que
el resultado se considera satisfactorio.

DISEÑO DE UNA SALIDA EFICAZ

La salida es la información que se entrega al usuario por medio del sistema de información
utilizando intranets, extranet o la WWW, debido a que esta salida están relevante para la
aceptación de un SI, estos son algún objetivos claros a la hora de crear dicho sistema.

● Diseñar la salida para satisfacer un propósito específico.

● Hacer significativa la salida para el usuario.
● Entregar la cantidad adecuada de salida.
 ● Proporcionar una distribución adecuada de la salida.
● Proporcionar la salida a tiempo.
● Elegir el método de salida más efectivo
● Diseño de la salida para satisfacer un propósito específico

Toda salida de información debe tener un propósito, el analista debe averiguar qué
propósito debe satisfacer. Para esto se tiene en cuenta que si la salida no es funcional, no
debe crearse, porque toda salida representa costos de tiempo y recursos.

DISEÑO DE SALIDA PARA SATISFACER UN USUARIO

En un sistema de información grande que atiende a muchos usuarios con muchos propósitos
diferentes, a menudo es difícil personalizar la salida. Con base en las entrevistas, las
observaciones, los costos y tal vez los prototipos, será posible diseñar una salida que
satisfaga lo que muchos usuarios, si no es que todos, necesitan y prefieren. En términos
generales, es más práctico crear salida específica para el usuario, o que él pueda
personalizar, cuando ésta se diseña para un sistema de apoyo a la toma de decisiones u
otras aplicaciones sumamente interactivas, como las que se desarrollan para la Web. Sin
embargo, aun así es posible diseñar salidas que satisfagan una función del usuario en la
organización, lo cual nos lleva al siguiente objetivo.

5.6 DISEÑO DE LA BASE DE DATOS

Una base de datos correctamente diseñada permite obtener acceso a información exacta y
actualizada. Puesto que un diseño correcto es esencial para lograr los objetivos fijados para la
base de datos, parece lógico emplear el tiempo que sea necesario en aprender los principios de
un buen diseño ya que, en ese caso, es mucho más probable que la base de datos termine
adaptándose a sus necesidades y pueda modificarse fácilmente.En este artículo se
proporcionan instrucciones para preparar una base de datos. Aprenderá a decidir qué
información necesita, a dividir la información en las tablas y columnas adecuadas y a
relacionar las tablas entre sí. Debe leer este artículo antes de crear la primera base de datos.

QUE ES UN BUEN DISEÑO DE LA BASE DE DATOS

El proceso de diseño de una base de datos se guía por algunos principios. El primero de ellos es
que se debe evitar la información duplicada o, lo que es lo mismo, los datos redundantes,
porque malgastan el espacio y aumentan la probabilidad de que se produzcan errores e
incoherencias. El segundo principio es que es importante que la información sea correcta y
completa. Si la base de datos contiene información incorrecta, los informes que recogen
información de la base de datos contendrán también información incorrecta y, por tanto, las
decisiones que tome a partir de esos informes estarán mal fundamentadas.
Un buen diseño de base de datos es, por tanto, aquél que:

❖ Divide la información en tablas basadas en temas para reducir los datos redundantes.
❖ Proporciona a Access la información necesaria para reunir la información de las
tablas cuando así se precise.
❖ Ayuda a garantizar la exactitud e integridad de la información.
❖ Satisface las necesidades de procesamiento de los datos y de generación de
informes.

5.7 DISEÑO DE INTERFAZ DE USUARIO

El diseño de interfaz de usuario o ingeniería de la interfaz es el resultado de definir la

forma, función, usabilidad, ergonomía, imagen de marca y otros aspectos que afectan a la
apariencia externa de las interfaces de usuario en sistemas de todo tipo (computadoras de
uso general, sistemas de control, dispositivos de comunicación móviles, software de
sistemas, software de aplicaciones, sitios web, etc). El diseño de la interfaz de usuario es
una disciplina asociada al diseño industrial (aparece como tal recogido en la Clasificación
de Locarno en el apartado 14-04) y se enfoca en maximizar la usabilidad y la experiencia
de usuario. El objetivo final del diseño de la interfaz de usuario es hacer que la
interacción entre el usuario y el sistema del que es interfaz sea tan simple y eficiente
como sea posible, en términos de cumplimiento de los objetivos del usuario. Sigue por
ello una filosofía de diseño centrado en el usuario.

Un buen diseño de la interfaz de usuario facilita la compleción de tareas a realizar sin que el
usuario vea atraída su atención hacia la forma. El diseño gráfico y la tipografía se
combinan para ofrecer usabilidad, influyendo en cómo el usuario realiza ciertas
interacciones y mejorando la apariencia estética del diseño; la estética del diseño puede
mejorar o dificultar la capacidad de los usuarios para utilizar las funciones de la
interfaz.1​ El proceso de diseño debe balancear la funcionalidad técnica y los elementos
visuales (es decir, el modelo mental) para crear un sistema que no solo sea operativo,
sino también usable y adaptable a la evolución de las necesidades del usuario.

Normalmente el diseño de interfaces de usuario es una actividad multidisciplinar que

involucra a varias ramas tales como el diseño gráfico, el diseño industrial, el diseño web,
el diseño de software y la ergonomía; y puede aparecer como actividad en un amplio
rango de proyectos, desde el desarrollo de sistemas informáticos hasta el desarrollo de
aviones comerciales. En este sentido las disciplinas del diseño industrial y diseño gráfico
se encargan de que la actividad a desarrollar se comunique y aprenda lo más
rápidamente, a través de recursos como los gráficos, los pictogramas, los estereotipos y la
simbología, todo sin afectar un funcionamiento técnico eficiente.
El diseño de la interfaz de usuario requiere de una buena comprensión de las necesidades
del usuario. Hay varias fases y procesos en el diseño de una interfaz de usuario, algunos
de los cuales son más demandados que otros, dependiendo del proyecto.2​ Nota: en lo que
resta de sección, la palabra sistema se utilizará para referirse a cualquier tipo de proyecto,
ya sea éste para el desarrollo de una web, una aplicación o dispositivo.

La ingeniería de requisitos - elaboración de una lista de los elementos funcionales

requeridos por el sistema para que cumpla los objetivos del proyecto y las necesidades
potenciales de los usuarios. El análisis del perfil de los usuarios y las tareas - un tipo de
trabajo de campo que consiste en la actividad de análisis de los usuarios potenciales del
sistema, estudio de la forma en la que realizan las tareas que el diseño debe permitir, y
realización de las entrevistas que permitirán determinar sus objetivos.3​ Con preguntas
habituales como:

¿Qué querría el usuario que haga el sistema?

¿Cómo encajaría el sistema en el flujo de trabajo o las actividades diarias?
¿Cuán competente es el usuario técnicamente y qué sistemas parecidos ya utiliza?
¿Qué estilos de aspecto y comportamiento son los preferidos del usuario?

Arquitectura de la información - desarrolla un flujo de información y/o procesos del sistema

(por ejemplo, en un sistema de desvío automático de llamadas, podría ser diagrama de
flujo en forma de árbol de opciones, o en un sitio web la jerarquía de páginas que muestra
el uso del sitio). Prototipado - desarrollo de un esquema de página, ya sea en forma de
prototipo en papel o de pantallas interactivas simples. En estos prototipos se evita la
utilización de los elementos de estilo, aspecto y comportamiento, así como la mayor parte
del contenido de forma que el analista pueda concentrarse en la interfaz.
Inspección de la usabilidad - permitir que un evaluador inspeccione la interfaz de usuario.
Este método se considera que es normalmente más fácil de implementar que las pruebas
de usabilidad (véase el siguiente proceso), y puede utilizarse en las etapas tempranas del
proceso de desarrollo de la interfaz de usuario ya que puede utilizarse para evaluar tanto
prototipos como especificaciones del sistema que habitualmente no pueden ser evaluados
con los usuarios finales. Algunos de los métodos comunes de inspección de la usabilidad
incluyen el recorrido cognitivo, que se enfoca en la simplicidad del sistema para los
nuevos usuarios, la evaluación heurística, en la que se utilizan un conjunto de heurísticas
para identificar problemas de usabilidad en el diseño de la interfaz de usuario, y la
revisión participativa del diseño, en la que se selecciona un grupo de gente para recorrer
el sistema en un escenario típico de uso y discutir los problemas de usabilidad.

Pruebas de usabilidad - prueba de uno o varios prototipos con un usuario real—con

frecuencia utilizando una técnica denominada "protocolo de pensar en alto", en el que se
pide al usuario que exprese en voz alta lo que piensa mientras experimenta la interacción
con el sistema. Las pruebas de usabilidad del diseño de una interfaz permiten que el
 diseñador entienda cómo es percibido el sistema desde la perspectiva del usuario, y así
facilita la obtención de aplicaciones exitosas.

Diseño de la interfaz gráfica de usuario - realización del diseño final con sus elementos de
estilo, aspecto y comportamiento de la interfaz gráfica de usuario (GUI). Puede basarse
en los elementos desarrollados en fases anteriores, una vez éstos han sido refinados para
resolver los problemas de usabilidad encontrados durante la fase de pruebas de
usabilidad.4​ Dependiendo de la interfaz que se esté creando, este proceso típicamente
implica algo de programación informática orientada a validar formularios, establecer
enlaces o realizar una acción requerida.

Mantenimiento de software - Después del despliegue de una nueva interfaz, puede que sea
necesario ocasionalmente mantener el software que la implementa para resolver bugs,
adaptar características o actualizar completamente un sistema. Una vez se decide
actualizar la interfaz, el sistema heredado volverá a requerir de un nuevo proceso de
diseño, y será necesario repetir las distintas fases del ciclo de vida de la interfaz

Principios y requisitos de diseño de una interfaz de usuario

Las características dinámicas de un sistema se describen en términos de requisitos diálogo

que aparecen definidos en los siete principios de diálogo del capítulo 10 del estándar ISO
9241 sobre ergonomía de la interacción persona-sistema.7​ Este estándar establece una
serie de conceptos y elementos básicos de ergonomía que suponen un punto de partida
para facilitar el diálogo entre los sistemas y las personas que usan dichos sistemas, con
definiciones de alto nivel, aplicaciones ilustrativas y ejemplos de los principios definidos.
Los principios aplicables representan los aspectos dinámicos de la interfaz y pueden
considerarse, de forma general, como la "sensación" que produce la interfaz.

Los siete principios son los siguientes:

1. Adecuación a la tarea: el diálogo es adecuado a la tarea cuando asiste al usuario en

la compleción eficaz y eficiente de la tarea.
2. Carácter autodescriptivo: el diálogo es autodescriptivo cuando cada paso del diálogo
es inmediatamente comprensible ya sea mediante la información devuelta por el
propio sistema o por una explicación a solicitud del usuario.
3. Conformidad con las expectativas del usuario: el diálogo es conforme con las
expectativas del usuario cuando es consistente y se ajusta a las características del
usuario, tales como conocimiento de la tarea, educación, experiencia, y otros
convenios comunmente aceptados.
4. Adecuación al aprendizaje: el diálogo es adecuado al aprendizaje cuando ofrece
soporte y guía para que el usuario aprenda a utilizar el sistema.
5. Controlabilidad: el diálogo es controlable cuando el usuario es capaz de iniciar y
controlar la dirección y ritmo de la interacción hasta el punto en el que la tarea ha
sido completada.
 6. Tolerancia a errores: el diálogo es tolerante a errores si, con independencia de que
haya errores de la entrada, el resultado pretendido puede ser alcanzado sin acción
necesaria por parte del usuario, o con una acción mínima.
7. Personalizable: el diálogo es personalizable cuando la interfaz de software puede ser
modificada para ajustarse a las necesidades de la tarea, preferencias individuales, y
habilidades del usuario.

El concepto de usabilidad es definido en el estándar a partir de la eficacia, eficiencia de la

interfaz, así como de la satisfacción del usuario. El capítulo 11 del estándar ofrece la
siguiente definición de usabilidad:

"La usabilidad es la medida con la que un producto se puede usar por usuarios determinados
para conseguir objetivos específicos con eficacia, eficiencia y satisfacción en un contexto
de uso concreto."

● La eficacia o efectividad mide la extensión (exactitud e integridad) con la que se

alcanzan globalmente los objetivos de uso del sistema.
● La eficiencia mide los recursos que deben utilizarse para alcanzar los objetivos
pretendidos.
● La satisfacción es un factor subjetivo que mide hasta donde el usuario encuentra
globalmente al sistema aceptable.

La eficacia, la eficiencia y la satisfacción se pueden considerar como factores de calidad de

la usabilidad. La evaluación de estos factores necesita de una descomposición adicional
en subfactores y, finalmente, en métricas de usabilidad.

La presentación de la información se describe en el capítulo 12 del estándar, con cuestiones

que afectan a la organización de la información (disposición, alineado, agrupado,
etiquetas, localización), a la visualización de objetos gráficos, y a la codificación de la
información (abreviaturas, color, tamaño, forma, claves visuales) mediante siete
atributos. Los "atributos de la información presentada" representan los aspectos estáticos
de la interfaz y pueden ser generalmente considerados como la "apariencia" de la
interfaz. Los atributos se detallan en las recomendaciones ofrecidas por el estándar. Cada
una de las recomendaciones se enlaza con uno de esos siete atributos.

Los siete atributos de presentación son los siguientes:

● Claridad: el contenido de la información es presentado de forma rápida y precisa.

● Discriminabilidad: la información visualizada puede ser distinguida de forma
precisa.
● Concisión: los usuarios no son sobrecargados con información irrelevante.
● Consistencia: el diseño es único y conforme a las expectativas del usuario.
● Detectabilidad: la atención del usuario es dirigida hacia la información necesaria.
● Legibilidad: la información es fácil de leer.
● Comprensibilidad: el significado es claramente inteligible, no ambiguo, interpretable
y reconocible.
5.8 DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS

La calidad de datos es una medida de qué tan consistentemente correctos, dentro de ciertos
límites prefijados, están los datos. Los datos codificados eficazmente facilitan la entrada de
datos precisa al reducir la cantidad necesaria de datos y, con ello, el tiempo requerido para
introducir la información.

CODIFICACIÓN EFECTIVA

Una de las formas en que los datos pueden ser introducidos de manera más precisa y
eficiente es mediante el empleo inteligente de varios códigos. El proceso de poner
datos ambiguos o demasiado largos en unos cuantos dígitos o letras que se puedan
introducir fácilmente se conoce como codificación (que no se debe confundir con la
codificación de programas.

para codificar incluyen lo siguiente:

1. Llevar registro de algo.

2. Clasificar la información.
3. Ocultar la información.
4. Revelar la información.
5. Solicitar la acción apropiada.

El código de derivación alfabética es un método que se usa comúnmente para identificar un

número de cuenta. El ejemplo de la figura 15.2 proviene de una etiqueta de correo para una
revista. El código se convierte en el número de cuenta. Los primeros cinco dígitos conforman
los primeros cinco dígitos del código postal del suscriptor, los siguientes tres son las primeras
tres consonantes del nombre del suscriptor, los siguientes cuatro números son de la calle y los
últimos tres constituyen el código para la revista. El propósito principal de este código es
identificar una cuenta.

Un ejemplo de codificación de clasificación es la forma en que podría agrupar los

elementos deducibles de impuesto con el propósito de completar sus impuestos
sobre la renta.
6.1 ASEGURAMIENTO DE LA CALIDAD MEDIANTE LA INGENIERÍA DE
SOFTWARE.

Las normas ISO 9000 establecen que el aseguramiento de la calidad son todas las acciones
sistemáticas y planificadas, necesarias para proporcionar una confianza adecuada de que
un producto o servicio satisfaga los requisitos dados de calidad. Para conseguir,
mantener y mejorar la calidad, las organizaciones desarrollan y utilizan su Sistema de
Calidad. Estos sistemas de calidad deben diseñarse de acuerdo con ISO 9004 y evaluarse
de acuerdo con la norma apropiada, que en el caso del software es ISO 9001.

Los productos no pueden cumplir los estándares ISO 9001, las organizaciones si, y eso es
lo que se pretende: garantizar el uso de un sistema de calidad por el cual se asegura que
el proceso de fabricación del software cumple los requisitos establecidos por la calidad.

Los sistemas de calidad pueden establecer la necesidad de confeccionar y cumplir el

sistema de calidad del proyecto, de modo que cada uno en particular se regirá por las
normas establecidas en el propio sistema del proyecto. Básicamente un sistema de
calidad se compone de:

​El programa de garantía de calidad: Documentación en el que se establece la política

de aseguramiento de la calidad, de acuerdo con las direcciones y estrategias de la
organización.

​Manuales de normas y procedimientos: Comprenden el manual de organización, los

manuales de administración, producción, etc., los cuales regulan las actividades que
afectan a la calidad de los productos, asignando responsabilidades y describiendo las
técnicas aplicables.

Estos dos componentes básicos del sistema (programa y manual) se complementan para
facilitar su integración con las actividades propias del desarrollo del proyecto.

PROPUESTA DE ASEGURAMIENTO DE LA CALIDAD

El método de ACS que se propone en este trabajo, permitirá a cualquier proyecto de

desarrollo de software, proporcionar calidad al producto final. Este enfoque práctico está
diseñado, para adaptarse o acoplarse a cualquier Metodología de Desarrollo y de esta
manera administrar la calidad en desarrollo de un proyecto. Esta propuesta está basada
en los conceptos y referencias que según Pressman 8​ deberían incluir un Aseguramiento
de la Calidad del software: 1) un proceso de ACS, 2) tareas específicas de aseguramiento
de la calidad y control de la calidad, 3) prácticas eficientes de ingeniera de software
(métodos y herramientas), 4) control de todos los productos del trabajo de software y de
 los cambios que sufren, 5) un procedimiento para garantizar el cumplimiento de los
estándares del desarrollo de software, y 6) mecanismos de medición y reporte.

Por lo tanto, tomado en consideración lo que plantea Pressman, se desarrolla y propone un

método de ACS. Esta propuesta está compuesta por Esencia y Herramientas el que será
medido por Métricas, que buscan no solo una forma de trabajar y administrar la calidad,
sino también la posibilidad de mejorar los procesos de desarrollo a través de la
recolección y análisis de errores.

Método de ACS

Como se mencionó anteriormente y puede verse en la figura, esta Propuesta Metodológica

de Aseguramiento de la Calidad, se puede adaptar o acoplar a cualquier Metodología de
Desarrollo que se esté utilizando, sin tener la necesidad de agregar un miembro más o un
equipo paralelo de ACS.

A continuación pasaremos a describir cada una de las tres actividades o tareas que
componen la metodología. Es importante destacar que estos tres componentes se
relacionan entre sí, entendiendo que una de las herramientas, puede ser una forma de
medir o que a su vez, una herramienta tenga el concepto o la filosofía PDCA.

Esencia

Esta actividad en el método de ACS, hace referencia a la manera de cómo se debe

comprender, por el grupo de trabajo, la forma de trabajar, en base a un objetivo que es
proporcionar calidad al producto de software. Si todo el equipo de trabajo, desde el líder
de equipo, pasando por todos los roles del grupo, trabajarán entendiendo que la calidad
es fundamental en el desarrollo de un producto y su objetivo es satisfacer las necesidades
 del cliente, la administración de la calidad no sería un problema, ya que todos estarían
trabajando en función de ese objetivo.

Mejoramiento Continuo

La filosofía de mejora continua es una herramienta ideal, para que el equipo de trabajo
entienda y busque la calidad en el desarrollo del producto. El proceso de mejora continua
es una constante refinación de las normas para responder de una forma dinámica a las
exigencias del cliente y las oportunidades de mejora de los procesos. Para que esto
suceda, la administración debe establecer primero el estándar o la base en los procesos o
actividades, para que, posteriormente, el ciclo PDCA desempeñe su función reguladora,
mejorando los estándares establecidos. De esta manera, el ciclo PDCA permite el
aprendizaje organizacional y el logro de mejores estándares.

● Plan (Planificar o Planear), énfasis a la planificación del proyecto.

● Do (Hacer), corresponde a realizar, fabricar o trabajar el producto planificado.
● Check (Revisar o Comprobar), para confirmar si el cliente está satisfecho o el
proceso está según especificaciones.
● Act (Actuar), si se presenta algún reclamo, se actúa sobre el problema sin tener que
esperar que finalice el proceso, luego se vuelve a la fase de planificación, volviendo
al ciclo PDCA, para obtener un mejoramiento.

Herramientas

Las herramientas, en la propuesta metodológica de ACS, son un conjunto de técnicas y

artefactos que ayudarán a mantener el control y a la vez administrar la calidad en el
desarrollo desde el inicio hasta el final, de un producto de software. A continuación se
describirán y mostrarán las herramientas que propone este método de ACS.

Tabla de Control de Riesgo

La figura muestra la tabla de Control de Riesgo, que tiene como objetivo identificar,
controlar y eliminar las fuentes de riesgo antes de que empiecen a afectar el
cumplimiento de los objetivos del proyecto. De esta manera se pueden evaluar y estimar
el impacto de los riesgos posibles y a su vez establecer un plan de contingencia para
mitigarlos en el caso de que el problema se presente, teniendo como objetivo la pro
actividad. Por lo tanto: 1) se inicia antes del trabajo técnico, 2) se categoriza o clasifica
según su impacto, 3) identifica los riesgos potenciales, valorando su probabilidad de
impacto y 4) establecer un plan.
Historial de Cambio

La figura muestra el Documento Historial de Cambio, que permite al equipo de trabajo

llevar un registro de los cambios o mejoras solicitadas en el Documento de Petición de
Mejora, junto con ello también admite llevar un control de los documentos o entregables,
tanto sus versiones como alguna modificación en ellos.

Documento de Petición de Mejora

Este documento llamado Petición de Mejora, que se puede observar en la figura, tiene
como objetivo priorizar y mostrar las modificaciones que proponen o recomiendan los
Stakeholders o Clientes. De esta manera, se podrán analizar dichos cambios o propuestas
e implementarlas en el proyecto, controlando de modo ordenado los cambios en el
desarrollo del sistema. Cabe destacar que este documento sirve para gestionar cambios o
 mejoras ya sea en los requisitos del sistema, entregables, artefactos o documentación del
proyecto, luego de ser testeada o implementado.

Adecuación de requisitos (Repertory Grid)

Uno de los problemas fundamentales en el desarrollo de software es la mala calidad de la

educación de los requisitos del sistema, provocando costos importantes en los proyectos.
Por lo tanto, para evitar los problemas anteriores y desarrollar productos que satisfagan
al cliente, se propone utilizar el emparrillado (Repertory Grid) planteada en la ​Tabla 1
muestra un ejemplo de Repertory Grid, la cual permite determinar el valor de adecuación
de dichos requisitos a las necesidades del usuario, a mayor adecuación, mayor calidad.

Tabla 1 Ejemplo de Aplicación de Repertory Grid.

Tal como lo plantea Meléndez, por un lado el polo nominal o de semejanza de los
constructos dicotómicos a utilizar, se estructura de la siguiente forma:

● • ​Correcto,​ si, y sólo si, cada requisito declarado se encuentra en el producto.

● • I​ nequívoco, si, o solo si, cada requisito declarado tiene una sola interpretación. Debe
ser inequívoco para aquellos que lo crean y para aquellos que lo usen.
● • ​Completo, si, y sólo si, están relacionados con la funcionalidad, el desarrollo, las
restricciones de diseño, los atributos y las interfaces externas.
● • ​Consistente, si, y sólo si, ningún subconjunto de requisitos individuales generó
conflictos en él.
● • ​Importante, si, y sólo si, él tiene un identificador para indicar la importancia que lo
relaciona al producto.
● • ​Estable, si, y sólo si, el número de cambios realizados, o que se espera realizar, es
mínimo.
● • ​Comprobable, si, y sólo si, existe algún proceso rentable finito con que una persona o
la máquina pueda verificar que el producto reúne el requisito.
● • ​Modificable, si, y sólo si, su estructura y estilo son tales que pueden hacer cualquier
cambio fácilmente, completamente y de forma consistente conservando la estructura y
estilo.
● • ​Identificable, si, y sólo si, su origen está claro y facilita su referencia en el desarrollo
futuro o documentación del mismo, debiendo ser tanto identificable dirigido hacia tras,
como identificable dirigido hacia adelante.

Por el otro lado, el polo de contraste está compuesto por, Incorrecto, Ambiguo, Incompleto,
Débil, Intrascendente, Inestable, No Comprobable, No Cambiable, No Reconocible.

Al igual que en la propuesta de Meléndez, los constructos a utilizar serán del tipo
multivaluados (1-9) en donde 9 es la máxima aproximación al polo nominal y 1 su
homólogo al polo de contraste. De esta manera, se obtendrán los niveles de adecuación
que posee cada una de los requisitos elicitados: Verde (7-9), Naranja (4-6), y rojo (1-3).
Trazabilidad (Codificación IR-Kanban)

El no tener un control de trazabilidad, asociado a identificar los diferentes documentos o

artefactos en un desarrollo de software, podrían causar problemas y por lo tanto
perjudicar en la calidad del producto.

Para esto se propone a IR-Kanban, que es un sistema de codificación del cual se puede
obtener un correcto control de la documentación asociada al proyecto como: SRS,
Diagramas de flujos, casos de uso, entre otros. Ayudando a identificar diferentes
aspectos a través de los sub códigos que lo componen. En la ​imagen, se observa la
estructura de IR-Kanban donde el código resultante, estará conformado por segmentos
de información, agrupados de forma similar a las MAC.

La​ ​Tabla 2​, describe la estructura del sistema IR-Kanbas.

Control de Versiones

El código fuente es el elemento primordial en un desarrollo de un producto de software y

poder administrarlo de forma eficiente, siendo fundamental a la hora de proporcionar
calidad al proyecto de software. Una de las herramientas propuestas del método ACS, es
el sistema de control de versiones (SCV). Los SCV son una herramienta esencial para
manejar proyectos de software. Proporcionan una serie de funcionalidades claves para el
desarrollo de proyectos como es el control de cambios en el código, la reversibilidad de
dichos cambios, y la posibilidad de colaborar en el desarrollo del código.

Los principales beneficios de esta herramienta según O'Sullivan​ ​son:

1) cualquier revisión almacenada de un archivo puede ser recuperada para visualizarse o

modificarse
2) pueden desplegarse las diferencias entre distintas versiones
3) las correcciones pueden ser creadas automáticamente
4) múltiples desarrolladores pueden trabajar simultáneamente en el mismo proyecto o
archivo sin pérdida de datos
5) los proyectos pueden ser divididos para permitir el desarrollo simultáneo en varias
versiones (estas divisiones pueden ser fusionadas para alcanzar el objetivo principal del
desarrollo)
6) el desarrollo distribuido, es soportado a través de las redes de datos con diferentes
mecanismos de autentificación. Uno de los más utilizados es Git, inicialmente
desarrollado para Linux. Git permite a varios programadores trabajar paralelamente con
sus propias copias de trabajo obtenidas de un repositorio, como lo efectúan todos los
SCV distribuidos

Métricas

La única manera de mejorar es medir cómo se está haciendo algo. Para ello, este modelo
propone una herramienta de ACS estadístico que reúne y clasifica errores para luego
analizarlos y poder mejorar sustancial a la calidad, en el desarrollo de proyectos futuros.

Según Pressman los errores se pueden clasificar en las siguientes causas:

a. • Especificaciones erróneas o incompletas (EEI).

b. • Mala interpretación de la comunicación con el cliente (MCC).
c. • Desviación intencional de las especificaciones (DIE).
d. • Violación de los estándares de programación (VEP).
e. • Errores en la representación de los datos (ERD).
f. • Interfaz componente inconsistente (ICI).
g. • Error en el diseño lógico (EDL).
h. • Prueba incompleta o errónea (PIE).
i. • Documentación inexacta o incompleta (DII).
j. • Errores en la traducción del lenguaje de programación del diseño (LPD).
 k. • Interfaz humano/computadora ambigua o inconsistente (IHC).
l. • Varios (V).

Para aplicar el ACS estadísticos se elabora una tabla, como se observa en la ​Tabla 3​, que
contiene todas las posibles causas de errores, clasificadas en: Serio, Moderado y Menos.
De esta manera se puede observar e identificar los errores más críticos o vitales, se puede
dar comienzo a sus acciones correctivas.

Tabla 3 Colección de Datos para ACS Estadístico.

Es importante destacar que acciones correctivas se centran sobre las pocas causas vitales.
En tanto estas se corrigen, nuevas candidatas se van a la cumbre de la pila.

6.2 IMPLEMENTACIÓN EXITOSA DEL SISTEMA DE INFORMACIÓN

El concepto de sistemas distribuidos se usa de muchas formas diferentes.Aquí se tomará en

un sentido amplio para que incluya estaciones de trabajo que se pueden comunicar entre sí
y con los procesadores centrales, así como también diferentes configuraciones
arquitectónicas jerárquicas de procesadores de datos que se comunican entre sí y que tiene
diferentes capacidades de almacenamiento de datos. Uno de los aspectos costosos de
implementar una LAN es que cada vez que se mueve, se debe cambiar la instalación
eléctrica. Algunas organizaciones están afrontando esto al establecer una red inalámbrica
de área local (WLAN) de alta velocidad.

Ventajas de los sistemas distribuidos Los sistemas distribuidos permiten el almacenamiento

de datos en lugares donde no estorben a las transacciones de tiempo real en línea. Por
ejemplo, el tiempo de respuesta en las consultas se podría mejorar si no todos los registros
necesitan ser investigados antes de que se dé una respuesta.
Desventajas de los sistemas distribuidos Los sistemas distribuidos presentan algunos problemas
únicos que los sistemas de cómputo centralizados no poseen. El analista necesita pensar estos
problemas contra las ventajas presentadas y plantearlos también con el negocio interesado.

El primer problema es la confiabilidad de la red. Para hacer de una red un recurso en lugar
de una carga, debe ser posible transmitir, recibir, procesar y almacenar datos de forma
confiable. Si hay demasiados problemas con la confiabilidad del sistema, éste se
abandonará.

ESTRATEGIAS DE CAPACITACIÓN

Personas que capacitan a los usuarios para un proyecto grande, se podrían usar muchos ​instructores
diferentes dependiendo de cuántos usuarios se deben capacitar y quiénes son.

Las posibles fuentes de capacitación incluyen lo siguiente:

1. Vendedores.
2. Analistas de sistemas.
3. Instructores externos.
4. Instructores internos.
5. Otros usuarios del sistema.

LINEAMIENTOS PARA LA CAPACITACIÓN

1.-Objetivos de la capacitación
2.-Métodos de capacitación
3.-Sitios de capacitación
4.-Materiales de capacitación

ESTRATEGIAS DE CONVERSIÓN

1. Conversión directa.
2. Conversión paralela.
3. Conversión gradual o por fases.
4. Conversión de prototipo modular.
5. Conversión distribuida.

SEGURIDAD LÓGICA

La seguridad lógica se refiere a los controles lógicos en el software. Los controles lógicos
son familiares para la mayoría de los usuarios como contraseñas o códigos de
autorización de alguna clase. Cuando se usan, permiten al usuario entrar al sistema o a
una parte particular de una base de datos con una contraseña correcta.
6.3 ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADO A OBJETOS USANDO EL
LENGUAJE UNIFICADO UML.

El análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software

que modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoque
representa un domino absoluto en términos de conceptos compuestos por verbos y
sustantivos, clasificados de acuerdo a su dependencia funcional. Todo sistema de
información requiere de artefactos o componentes (clases) para llevar a cabo tareas, es de
gran importancia dentro de la ingeniería de software tener un buen "análisis y diseño" para
un mejor desarrollo, que conlleva a que tan "escalable" sea un sistema de información.

En este método de análisis y diseño se crea un conjunto de modelos utilizando una notación
acordada como, por ejemplo, el lenguaje unificado de modelado (UML).

ADOO aplica técnicas de modelado de objetos para analizar los requerimientos para un
contexto (por ejemplo, un sistema de negocio, un conjunto de módulos de software) y para
diseñar una solución para mejorar los procesos involucrados.

No está restringido al diseño de programas de computadora, sino que cubre sistemas enteros
de distinto tipo. Las metodologías de análisis y diseño más modernas son "casos de uso"
guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en

análisis y diseño orientado a objetos.

Una exigencia de la gran mayoría de instituciones dentro de su Plan Informático estratégico,

es que los desarrollos de software bajo una arquitectura en​ ​Capas​, se formalicen con un
lenguaje estándar y unificado. Es decir, se requiere que cada una de las partes que
comprende el desarrollo de todo software de diseño orientado a objetos, se visualice,
especifique y documente con lenguaje común. Se necesitaba un lenguaje que fuese
gráfico, a fin de especificar y documentar un sistema de software, de un modo estándar
incluyendo aspectos conceptuales tales como procesos de negocios y funciones del
sistema.

Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual
cuenta con una notación estándar y semánticas esenciales, para el modelado de un sistema
orientado a objetos. Así mismo, aquellos que deseen enmarcar conceptualmente desde su
génesis UML, recomiendo comprender los ​Fundamentos de los Lenguajes Estructurados​.
El UML unido a un gestión de calidad, evita malos entendidos y entrega ciertas
precauciones en la evolución y mantención de programas. Especialmente en lo referente a
los requerimientos asociados al levantamiento y diseño funcional de un sistema. En
efecto, por ejemplo con los ​Clientes Dilema​, quienes no podrán hacer pensar que el
 cambio que están solicitando es pequeño, cuando detrás de la petición existe una enorme
cantidad de tareas relacionadas al requerimiento. Cabe preguntarse​ ​¿Cuáles son las
características que debe tener una herramienta UML?.

¿Qué es UML?

El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de

una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los
80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los
métodos consisten de ambos de un lenguaje de modelado y de un proceso.

El UML , fusiona los conceptos de la orientación a objetos aportados por Booch, OMT y
OOSE (Booch, G. et al., 1999).

UML incrementa la capacidad de lo que se puede hacer con otros métodos de análisis y
diseño orientados a objetos. Los autores de UML apuntaron también al modelado de
sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente
estos dominios.

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para
expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un
diseño. La estandarización de un lenguaje de modelado es invaluable, ya que es la parte
principal del proceso de comunicación que requieren todos los agentes involucrados en un
proyecto informático. Si se quiere discutir un diseño con alguien más, ambos deben
conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.

Ver RobotDocIRS​ y ¿Cuáles son las características que debe tener una
herramienta UML?
Semántica y Notación

Una de la metas principales de UML es avanzar en el estado de la integración institucional

proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin
embargo para lograr un intercambio exitoso de modelos de información entre
herramientas, se requirió definir a UML una semántica y una notación.

La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje
de modelado. Por ejemplo, la notación del diagrama de clases define como se representan
los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y
qué significa exactamente una asociación o multiplicidad en una clase?. Un metamodelo
es la manera de definir esto (un diagrama, usualmente de clases, que define la notación).

Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la
notación. Una herramienta de UML debe mantener la consistencia entre los diagramas en
un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede
cumplir con la notación de UML. El lenguaje está dotado de múltiples herramientas para
lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma
simplificada sobre:

● Modelamiento de Clases
● Casos de Uso
● Diagrama de Interacción
● Los diagramas de clases de UML forman la vista lógica.
● Los diagramas de interacción de UML constituyen la vista de proceso.
● La vista de desarrollo captura el software en su entorno de desarrollo.
● Los diagramas de despliegue integran la vista física .
● Los escenarios: el modelo de casos de uso.
Modelamiento de Clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.
Un diagrama de clases está compuesto por los siguientes elementos:

● Clase: atributos, métodos y visibilidad.

● Relaciones: Herencia, Composición, Agregación, Asociación y Us​o.

Elementos

● Clase
● Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una
instancia de una clase). A través de ella podemos modelar el entorno en estudio (una
Casa, un Auto, una Cuenta Corriente, etc.).
● En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

● Superior​: Contiene el nombre de la Clase

● Intermedio​: Contiene los atributos (o variables de instancia) que caracterizan a la Clase
(pueden ser private, protected o public).
● Inferior​: Contiene los métodos u operaciones, los cuales son la forma como interactúa el
objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:
Una Cuenta Corriente que posee como característica:

● Balance

Puede realizar las operaciones de:

● Depositar
● Girar
● y Balance
El diseño asociado es:

Atributos y Métodos​:

Atributos:

● Los atributos o características de una Clase pueden ser de tres tipos, los que definen el
grado de comunicación y visibilidad de ellos con el entorno, estos son:
○
○ public​ (+): Indica que el atributo será visible tanto dentro como fuera de la clase,
es decir, es accsesible desde todos lados.
○
○ private​ (-): Indica que el atributo sólo será accesible desde dentro de la clase
(sólo sus métodos lo pueden accesar).
○
○ protected​ (#): Indica que el atributo no será accesible desde fuera de la clase,
pero si podrá ser accesado por métodos de la clase además de las subclases que se
deriven (ver herencia).

Métodos:

● Los métodos u operaciones de una clase son la forma en como ésta interactúa con su
entorno, éstos pueden tener las características:
○ public​ (+): Indica que el método será visible tanto dentro como fuera de la clase,
es decir, es accsesible desde todos lados.
○ private​ (-): Indica que el método sólo será accesible desde dentro de la clase (sólo
otros métodos de la clase lo pueden accesar).
○ protected​ (#): Indica que el método no será accesible desde fuera de la clase, pero
si podrá ser accesado por métodos de la clase además de métodos de las subclases
que se deriven (ver herencia).
Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden

interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada
extremo de la relación y éstas pueden ser:

● uno o muchos​: 1..* (1..n)

● 0 o muchos​: 0..* (0..n)
● número fijo​: m (m denota el número).

i. Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase,
por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las
características y atributos visibles de la Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las
Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es
Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio,
VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo único "visible" es el método Características
aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición pública, en
cambio atributos como Descapotable no son visibles por ser privados.

Agregación​:

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer
objetos que son instancias de clases definidas por el desarrollador de la aplicación,
tenemos dos posibilidades:

● Por Valor​: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido
está condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es
comúnmente llamada ​Composición​ (el Objeto base se construye a partir del
objeto incluido, es decir, es "parte/todo").
● Por Referencia​: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto
incluido es independiente del que lo incluye. Este tipo de relación es
comúnmente llamada ​Agregación​ (el objeto base utiliza al incluido para su
funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

● Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).
● Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.
● La composición (por Valor) se destaca por un rombo relleno.
● La agregación (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no
existe este tipo de particularidad la flecha se elimina.
Asociación​:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran
entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un
objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas órdenes de Compra, en cambio una orden de
compra solo puede tener asociado un cliente.

Dependencia o Instanciación (uso)​:

Representa un tipo de relación muy particular, en la que una clase es instanciada (su
instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso más particular de este tipo de relación es para denotar la dependencia que tiene una
clase de otra, como por ejemplo una aplicación gráfica que instancia una ventana (la
creación del Objeto Ventana está condicionado a la instanciación proveniente desde el
objeto Aplicación):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro
del objeto que lo crea (en este caso la Aplicación).

Casos Particulares​:

● Clase Abstracta​:
Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica".
Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos
(aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es
definiendo subclases, que implementan los métodos abstractos definidos.

Clase parametrizada​:

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en

donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda
ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o
palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser
genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o
bien de alguna estructura predefinida (especialización a través de clases).
En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependen
exclusivamente de la implementación que se le quiera dar.

Ejemplo​:

Supongamos que tenemos tenemos un el caso del Diccionario implementado mediante un

árbol binario, en donde cada nodo posee:

● key: Variable por la cual se realiza la búsqueda, puede ser genérica.

 ● ítem: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo también puede
ser genérico.

Para este caso particular hemos definido un Diccionario para almacenar String y Personas,
las cuales pueden funcionar como llaves o como ítem, solo se mostrarán las relaciones
para la implementación del Diccionario:

Casos de Uso (Use Case)

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el
sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan
(operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:

● Actor.
● Casos de Uso​.
● Relaciones de Uso, Herencia y Comunicación​.
Elementos

● Actor​:

Una definición previa, es que un ​Actor es un rol que un usuario juega con respecto al
sistema. Es importante destacar el uso de la palabra ​rol​, pues con esto se especifica que un
Actor no necesariamente representa a una persona en particular, sino más bien la labor
que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol
de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el
Jefe de Local.

● Caso de Uso​:

●
● Es una operación/tarea específica que se realiza tras una orden de algún agente externo,
sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

● Relaciones​:

Asociación​

○ Es el tipo de relación más básica que indica la invocación desde un actor o caso
de uso a otra operación (caso de uso). Dicha relación se denota con una flecha
simple.

Dependencia o Instanciación​

○ Es una forma muy particular de relación entre clases, en la cual una clase depende
de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha
punteada.
 Generalización​

○ Este tipo de relación es uno de los más utilizados, cumple una doble función
dependiendo de su estereotipo, que puede ser de ​Uso (<<uses>>) o de ​Herencia
(<<extends>>).
○ Este tipo de relación esta orientado exclusivamente para casos de uso (y no para
actores).
○ extends​: Se recomienda utilizar cuando un caso de uso es similar a otro
(características).
○ uses​: Se recomienda utilizar cuando se tiene un conjunto de características que
son similares en más de un caso de uso y no se desea mantener copiada la
descripción de la característica.
○ De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y
modelamiento de clases, en donde esta la duda clásica de ​usar​ o ​heredar​.

Ejemplo:

Como ejemplo está el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema
debe controlar y/o aceptar:

● Registrar el número de ítems ingresados.

● Imprimir un recibo cuando el usuario lo solicita:
1. Describe lo depositado
2. El valor de cada ítem
3. Total
● El usuario/cliente presiona el botón de comienzo
● Existe un operador que desea saber lo siguiente:
1. Cuantos ítemes han sido retornados en el día.
2. Al final de cada día el operador solicita un resumen de todo lo depositado en el
día.
● El operador debe además poder cambiar:
1. Información asociada a ítemes.
2. Dar una alarma en el caso de que:
1. Ítem se atora.
2. No hay más papel.

Como una primera aproximación identificamos a los actores que interactúan con el sistema:
Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede cambiar la
información de un Ítem o bien puede Imprimir un informe:

Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar
algún item por un cliente o bien puede ser realizada a petición de un operador.
Entonces, el diseño completo del diagrama Use Case es:
Diagrama de Interacción

Introducción

El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos

(Clases) se comunican entre sí en petición a un evento. Esto implica recorrer toda la
secuencia de llamadas, de donde se obtienen las responsabilidades claramente. Dicho
diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de
Casos de Uso (son diferentes).

Los componentes de un diagrama de interacción son:

● Un Objeto o Actor​.
● Mensaje de un objeto a otro objeto​.
● Mensaje de un objeto a sí mismo​.

Elementos

● Objeto/Actor​:

●
● El rectángulo representa una instancia de un Objeto en particular, y la línea punteada
representa las llamadas a métodos del objeto.

Mensaje a Otro Objeto​:

● Se representa por una flecha entre un objeto y otro, representa la llamada de un método
(operación) de un objeto en particular.
 Mensaje al Mismo Objeto​:

●
● No solo llamadas a métodos de objetos externos pueden realizarse, también es posible
visualizar llamadas a métodos desde el mismo objeto en estudio.

Ejemplo

En el presente ejemplo, tenemos el diagrama de interacción proveniente del siguiente

modelo estático:
Aquí se representa una aplicación que posee una Ventana gráfica, y ésta a su vez posee
internamente un botón.

Entonces el diagrama de interacción para dicho modelo es:

En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos) y la llamada a
Paint() por el objeto Botón.