Metodologia de Proyectos de Grado en Ingenieria de Sistemas - 2020 PDF

UNIVERSIDAD AUTONOMA DE COLOMBIA
VICE RECTORIA ACADEMICA

FACULTAD DE INGENIERIA
PROGRAMA INGENIERÍA DE SISTEMAS
METODOLOGIA DE PROYECTOS DE GRADO
MARIO DUSTANO CONTRERAS CASTRO

PROFESOR DOCENTE CATEDRA
BOGOTA, MARZO 2020

INTRODUCCION
El Desarrollo de un Proyecto Informático exige al proponente responder y establecer:

Como es el objeto de estudio (Sistema de Información)
Como se realiza un diagnóstico de un sistema informático
Como se realiza un pronóstico de un sistema informático
Como se selecciona una solución acorde con el perfil profesional
Como el proceso de investigación es aplicado hacia el interior de un proyecto tecnológico
Como escribir el Objetivo General acorde a la solución planteada
Como escribir objetivos específicos acorde las etapas de desarrollo del objetivo general
Como escribir objetivos específicos que sean medibles y observables, como también, claros y precisos
Como estimar el tiempo a realizar cada objetivo específico de acuerdo a actividades y producto entregable
La importancia de una justificación acorde a lo que se quiere hacer, beneficios a obtener
Desarrollo de un Marco teórico y conceptual acorde con el proyecto tecnológico
La importancia de:
• Redactar una conclusión como resultado de comparar resultados obtenidos versus resultados esperados
• Apropiarse (adoptar, adaptar e implantar) de tecnologías de la información (TI) cuando estas cumplan con
las necesidades o requerimientos de la organización o contexto
• Desarrollar innovaciones en servicios o productos informáticos cuando sean una novedad o transformación
necesaria dentro de una organización o contexto
• Interdisciplinariedad para mejorar procesos como actividades en una organización apoyándose tanto en las
TI como en sus conocimientos teóricos y prácticos adquiridos en su formación profesional
• Práctica de valores sobre la administración de la información o fuente de información
• Evidenciar habilidades de negociación
• Predisposición para adaptarse a los cambios
•Evidenciar autodisciplina en el trabajo y capacidad de autoaprendizaje
TITULO
El objetivo de la definición del titulo es enunciar la intención del proponente de realizar un trabajo de grado
bajo un nombre que debe reunir las siguientes características:
 Breve
 Conciso
 Explicativo
 Sintético
 Pertinente al perfil profesional
PLANTEAMIENTO DE UN PROBLEMA
El planteamiento del problema debe responder ¿Qué se quiere hacer? ante una situación o un problema a
resolver.
Problema
Definiciones
Algunas definiciones de problema:
 Problema es un procedimiento dialéctico que tiende a la elección o al rechazo o también a la verdad y
al conocimiento (Aristóteles).
 El Problema o la proposición problemática es una proposición principal que enuncia que algo puede
ser hecho, demostrado o encontrado (Jungius).
 Problema es una proposición práctica demostrativa por la cual se afirma que algo puede o debe ser
hecho (Wolff).
 Problemas son proposiciones demostrativas que necesitan pruebas o son tales como para expresar
una acción cuyo modo de realización no es inmediatamente cierto (Kant).
 Un problema es una situación que implica un no saber y por consiguiente una necesidad para hallar la
solución
 Un problema es la definición de los estados de incertidumbre funcionales, operativos y o
administrativos propios de situaciones y eventos.
 Todo problema aparece a raíz de una dificultad; ésta se origina a partir de una necesidad, en la cual
aparecen dificultades sin resolver.
Tipos de problemas
Teóricos. Cuyo propósito es reflexionar sobre un tema o conocimiento.
Prácticos. Con objetivos destinados al progreso e innovación.
Teórico-prácticos. Para obtener información desconocida en la solución de problemas de la práctica
¿Qué es una Situación problémica?
La situación problémica es la presencia o ausencia de un hecho, desarrollo o no de una actividad y prestación
o no de un servicio que afecta el logro de los objetivos de un sistema y organización
Esta presencia o ausencia de un hecho, desarrollo o no de una actividad y prestación o no de un servicio se
puede o debe diagnosticar o pronosticar como una deficiencia (debilidad) o necesidad (requisito).
Deficiencia: Dificultad o no se posee los recursos, servicios, métodos para cumplir con el objetivo propuesto
Necesidad: Puede ser Anticipada (En el caso que se va a implantar un nuevo producto, recurso o servicio) o
por Demanda (el sistema u organización considera indispensable en su desarrollo social, económico,
tecnológico).
Presentación del Sistema y Organización
Concepto de Sistema y Organización:
―Un conjunto de elementos relacionados entre si y armónicamente conjugados". (Ferrater Mora, José.)
―Un sistema es un todo coherente de partes". (Herbert G. Heneman)
―Un conjunto complejo de elementos o componentes directa o indirectamente relacionados en una red causal".
(Walter Buckley)
Finalmente, según C. West Churchman todos los que definen el termino "sistema", están de acuerdo en que
se trata de un conjunto de partes coordinadas para lograr un conjunto de metas.
Una vez conocido el concepto de sistema, se puede definir la organización como " un sistema diseñado para
lograr metas y objetivos predeterminados por medio de la gente y otros recursos que emplean" (Kendall &
Kendall).
Las Organizaciones son sistemas grandes compuestos de subsistemas interrelacionados, en donde las
culturas y subculturas organizacionales influencian la manera en que se interrelaciona los intereses, los
objetivos, recursos y gentes en los diferentes subsistemas. Es por tanto, de primordial importancia considerar
a la organización como un todo para definir de manera adecuada los requerimientos de información para su
correcto funcionamiento.
Enunciado del Sistema y Organización
Se describe el departamento, sección, empresa en donde se realizara las actividades de desarrollo del
proyecto.
Si, es posible se enuncia:
- Nombre
- Ciudad
- Domicilio
- Estructura Organizativa
- Breve Descripción de: Actividades y Servicios
Diagnóstico
El punto de partida para llevar a cabo cualquier tipo de cambio en una organización. Es ―una fotografía‖,
―radiografía‖ o ―un mapa‖ que nos señala lo que hay en el sistema y organización, que proporciona datos e
información.
Es un insumo fundamental para, con base en él, definir y emprender futuras acciones.
Objetivo del Diagnóstico
Aportar un parámetro válido, para conocer la situación que guarda una organización en su conjunto o
cualquiera de las áreas que la conforman sobre una o varias deficiencias o necesidades, a fin de
entenderlos, asimilarlos y ubicarlos en la realidad que viven –o guardan- en ese momento.
Las fuentes de Diagnóstico
Las fuentes de consulta para llevar a cabo el levantamiento de un Diagnóstico son las siguientes:
- Leyes, reglamentos y normatividad existente que impacta directamente al organismo o área que se desea
diagnosticar.
–Funciones básicas y generales.
–Principales sistemas y procedimientos de operación y de seguimiento, evaluación y control (manuales de
procedimiento).
–Organigrama (manuales de organización).
–Líderes formales e informales, personal operativo ―clave‖
–Principales productos y/o servicios
–Interconexión e interacción directa con su medio ambiente externo (clientes y proveedores) y entre áreas o
departamentos internos
Las Actividades para configurar o determinar un Diagnóstico
Para llevar a cabo el levantamiento de diagnóstico es necesario considerar las siguientes actividades:
- Recopilación de datos;
- Análisis y validación los datos obtenidos;
- Clasificación los datos;
- Definición de reglas de los datos/negocio;
- Enunciado del Diagnóstico: Necesidad o Deficiencia
- Enunciado del Pronóstico: Sobre lo que es probable que ocurra en el futuro, basándose en el
diagnóstico y en consideraciones de juicio
Las herramientas del Diagnóstico
Las herramientas que pueden ser utilizadas para la obtención del diagnóstico se enumeran a continuación; es
importante destacar que es conveniente usar todas ellas o la gran mayoría, a fin de contar con datos que
cubran diferentes vistas del mismo sistema y organización, estas son:
- Observación;
- Análisis de documentos;
- Entrevistas verbales libres, semidirigidas y dirigidas;
- Cuestionarios;
- Metodología de análisis estructurado o Metodología de análisis orientada a objetos
¿Qué es una Situación problémica?
La situación problémica es la presencia o ausencia de un hecho, desarrollo o no de una actividad y prestación
o no de un servicio que afecta el logro de los objetivos de un sistema y organización
Esta presencia o ausencia de un hecho, desarrollo o no de una actividad y prestación o no de un servicio se
puede o debe diagnosticar o pronosticar como una deficiencia (debilidad) o necesidad (requisito).
Deficiencia: Dificultad o no se posee los recursos, servicios, métodos para cumplir con el objetivo propuesto
Necesidad: Puede ser Anticipada (En el caso que se va a implantar un nuevo producto, recurso o servicio) o
por Demanda (el sistema u organización considera indispensable en su desarrollo social, económico,
tecnológico).
En el caso de la Ingeniería de Sistemas, la situación problémica es la presencia o ausencia de un objeto de
estudio de investigación (sistema software, sistema telemático, desarrollo de la buenas prácticas de TI) que
afecta el logro de los objetivos de un sistema y organización.
Requisitos para elegir la situación problemica
Sin duda existe un gran número de situaciones problemicas que inquietan al proponente, pero quizá la mayor
parte de ellos no están al alcance de él.
Los requisitos para elegir una situación problemica son:
- Experiencia en el tema.
- Importancia de la situación problemica
- Conocimientos para su manejo.
- Relevancia social
- Relevancia contemporánea.
- Pertinencia con el saber profesional
Definición con claridad la situación problemica
El proyectante plantea la existencia de un problema informático que le ha llamado la atención y que –a su
juicio— requiere ser analizada (diagnóstico y pronostico) para pasar a algún tipo de acción posterior como es
la solución sistemica y tecnologica (modelamiento, prototipos, documentación, software).
Al definir la situación problemica, es necesario relacionar al menos dos elementos, que pueden ser: posibles
causas de la situación y efectos de la misma.
Delimitación la Situación Problemica

La situación problemica se delimita por: el ambiente (organización, sistema), conocimientos se tienen sobre la
situación problemica (Diagnóstico o Pronóstico), las necesidades a satisfacer o deficiencias a mejorar
Tomando el ejemplo de un colegio se puede decir entonces:
La no-relación de los procesos académicos con los administrativos genera:
- Demoras en Matriculas porque no se sabe sí un alumno está a paz y salvo
- La no existencia de alumnos en lista pese a que están matriculados
- No hay consistencia en el informe de los estudiantes que esta mora de pago
Descripción del Problema Informático
Se hace uso del modelo de negocio para obtener una sintomatología tanto del uso como de los procesos
de la información digital hacia el interior de una organización.
Con el empleo de herramientas de análisis y diseño de sistemas informáticos se puede obtener:
- Diagrama de actividades
- Modelo de procesos del negocio
- Modelos de Datos, como también, estructuras de información
- Modelos de interfaces para la captura de información
- Interfaces para captura y validación de la información
- Procesos de uso de la información (diagramas de pasada, HIPO)
- Consultas requeridas o empleadas
- Modelos de salidas de información (formularios o reportes)
Enunciado del Diagnóstico debe proporcionar la necesidad o deficiencia de un sistema informático.
Enunciado del Pronóstico: Sobre lo que es probable que ocurra en el futuro, basándose en el diagnóstico
y en consideraciones de juicio
Antecedente. Planteamiento de un Problema Informático
El proyectante plantea la existencia de un problema informático que le ha llamado la atención y que –a su
juicio— requiere ser analizada (diagnóstico y pronostico) para pasar a algún tipo de acción posterior como es
la solución sistemica y tecnologica (modelamiento, prototipos, documentación, software).
Entonces, el proponente plantea la deficiencia de un sistema informático desde:
El Mantenimiento del sistema informático; como consecuencia de una omisión realizada en la etapa del diseño
del sistema e involucra solucionar fallas menores del sistema, que obligará a la realización de cambios en el
sistema. La Modificación del sistema; involucra cambios en la estructura como en la funcionalidad del sistema
Y la necesidad de:
El Mejoramiento del sistema; es el agregado de capacidades que no formaron parte del sistema informático
original; por ejemplo cuando en una división se implementó un sistema de inventarios, este sistema no incluía
un módulo para calcular la futura demanda de bienes y partes. La inclusión de este sofisticado módulo de
cálculo es considerado un mejoramiento del sistema.
El Reemplazo del sistema; ocurre cuando los sistemas informáticos (sistema software, sistema telemático,
sistema de servicios) se tornan físicamente, tecnológicamente o competitivamente obsoletos.
Herramientas para el Planteamiento de un Problema
Tabla de Méndez
Como herramienta para realizar la descripción de un problema de investigación Carlos Eduardo Méndez
Álvarez sugiere la construcción del ―cuadro diagnóstico para el planteamiento del problema‖, el cual, está
conformado por cuatro elementos que ayudan a caracterizar una situación problemática. Es de aclarar que en
el cuadro Diagnóstico no se narra plenamente el problema sino que se cita puntualmente los aspectos de
cada uno de los elementos. Posteriormente, dichos puntos serán la base para la escritura del documento.
Tabla 1. Cuadro diagnóstico para el planteamiento del problema
Síntomas Causas Pronóstico Control al pronóstico
Hechos o Hechos o Situaciones que Acciones por las
situaciones que se situaciones que pueden generarse cuales el
observan al producen la si se siguen investigador
analizar el objeto existencia de los presentando los puede anticiparse
de estudio de la Síntomas síntomas y y controlar las
Investigación. Identificados. causas acciones
Identificadas. identificadas, en
los síntomas,
causas y
Pronostico.
Entonces, para plantear un problema es necesario:
1. Expresar la existencia de una situación problemica (Manejar dos variables como mínimo).
2. Definir con claridad la situación problemica
Los referentes empíricos y el manejo de dos variables como mínimo, permiten plantear el problema con
precisión de detalles. Los términos utilizados para plantear un problema deben ser lo bastante claros para
permitir que cualquier persona, con sólo leer, se ubique en lo que se pretende estudiar o analizar.
Tabla Tomada de Proyecto: Diseño, desarrollo e implementación de un software para la eficiencia de las
operaciones contables de la asociación Asofutuglua del municipio de la Macarena, Meta. Estudiante: Diana
Patricia Sandoval Quimbaya, CAU: Villavicencio
El Diagrama de Ishikawa o Diagrama de Causa Efecto o Espina de pescado
El Diagrama de Ishikawa o Diagrama de Causa Efecto (conocido también como Diagrama de Espina de
Pescado dada su estructura) consiste en una representación gráfica que permite visualizar las causas que
explican un determinado problema
Figura. Aplicación de Espina de Pescado en Planteamiento de un Problema

Fuente Proyecto de Grado Oscar Andrés Betancourt Beltrán
Antecedente. Listado de Soluciones
El proyectante debe enunciar de manera clara y sin ambigüedades varias soluciones al planteamiento del
problema; teniendo en cuenta:
- Interés o motivación personal y profesional sobre la solución
- Pertinencia profesional sobre la solución
- Se dispone de recursos para cumplir con la solución
- Debe ser verificada
- En correlación con la descripción y delimitación del planteamiento del problema
El proponente decide cual es la mejor solución a partir de la capacidad de; comparar y contrastar, decidir a
favor o en contra, establecer relación causa – efecto.
Desde el punto de vista proyecto software la solución debe ser dado mediante el Modelo de Requisitos:
- Modelo de Dominio: Pictogramas, Actividades del sistemas, Entidades del sistema, diagrama de
actividades
- Modelos de casos del negocio
Antecedente. Formulación del Problema del Proyecto

La solución del problema sistemico y tecnologico se toma como el problema del proyecto sistemico y
tecnologico. Entonces, se formula:
Como Afirmación. Un problema es una frase, oración o proposición expresada en términos positivos.
Ejemplo: El Sistema Software Fisioterapéutico permite realizar operaciones…. acordes con el modelo del
negocio.
Como Pregunta. Un problema es una frase, oración o proposición expresada en forma de pregunta o
interrogación.
Ejemplo: ¿Cómo ofrecer servicios de Cartera, Matriculación, Pago de Pensiones eficaces a partir de la
relación de los procesos académicos y Administrativos?
Figura 1. Planteamiento de un Problema

Fuente Metodología de la Investigación - Sampieri (6ta edición)
OBJETIVOS
El proyecto de grado es evaluado por el logro de los objetivos mediante un proceso sistemático, los cuales
deben haber sido previamente señalados y seleccionados en la propuesta del proyecto.
.
Los Requisitos para plantear los objetivos:
1. Señalar que es lo que se quiere alcanzar con el proyecto
2. Enfocarse a la solución del problema.
3. Ser realistas.
4. Ser medibles.
5. Ser congruentes.
6. Ser importantes.
7. Redactarse evitando palabras subjetivas.
8. Precisar los factores existentes que lleva el proyecto
9. Enfatizar la importancia de mejorar la organización.
10. Ser práctico, correcto, definido y verificable, debe guiar y soportar los pasos del proyecto de grado,
es decir, implica tácitamente el por qué, y el cómo del proyecto.
11. Como resultados o los fines que se pretenden lograr con el proyecto de grado.
Deben por tanto ser enunciados con claridad y precisión determinado de antemano la eficacia, eficiencia y
efectividad de la formación de los mismos con respecto al problema planteado.
Se recomienda formular dos tipos de objetivos:
Objetivo General
Es el enunciado en que se expresa la acción general (total) de lo que se pretende realizar en el proyecto.
El objetivo general debe tener una correlación con el problema planteado..
¿Cómo se redactan los Objetivos Generales?
Un Objetivo es un enunciado en que se expresa una acción a llevar a cabo. Por lo tanto debe estar iniciado
por verbos fuertes, que indican acciones, a continuación se indica el objeto o instrumento que se emplea para
la solución del problema. Y por último se establecen el resultado esperado o resultados esperados en
correlación con la formulación del problema.
A continuación se muestra una tabla sintagmática que puede ayudar a construir los objetivos del proyecto
Tabla 2. Tabla Sintagmática para Construir Objetivos
Verbo Objeto/ Instrumento Finalidad del Correlación del
Objetivo formulación del
problema con
resultados esperados
Mejorar
Establecer
1.Sistema Software Renovar
Averiguar
2. Funciones Sugerir
Identificar
3. Buenas Prácticas Innovar
Recopilar
4. Metodologías Agiles Resolver
Indagar
5. Estadísticas Satisfacer
Proponer
6. Integración Continua Controlar
Implementar
Administrar
Diseñar
Esquematizar
Desarrollar
Desplegar
Ejemplo: Implementar la Integración Continua para los proyectos de software desarrollados con la suite
webMethods en la compañía xxx (Proyecto Implementación de la Integración Continua en la Suite
Webmethods del estudiante Javier Hernando Mesa Losada).
Objetivos Específicos
Informan los resultados intermedios que se pretende realizar en cada una de las etapas del proyecto. Un
objetivo bien formulado es aquel que transmite en forma precisa los logros del proyecto.
En los objetivos específicos se responde la pregunta ¿a dónde queremos llegar? Y por consiguiente son
indicadores de resultados esperados, metas y productos También, indican los propósitos que se pretenden
alcanzar en forma inmediata o mediata.
En lo posible cada objetivo específico debe estar relacionado con un solo logro
Entonces, El Objetivo General, para ser llevado a cabo, usualmente puede y tiene que ser desglosado en una
serie de acciones o actividades particulares menores, sustancialmente diferentes unas de otras. En el
ejemplo de un colegio, se tendrá que investigar el funcionamiento académico, por un lado y el funcionamiento
administrativo y tecnológico, por lo tanto, dando tres acciones independientes. Estos son los Objetivos
Específicos. Son como las dos, tres o cuatro partes básicas en que se divide el proyecto.
Por lo tanto el desarrollo del proyecto a lo largo de la metodología empleada no es otra cosa que la forma en
que se van resolviendo los objetivos específicos.
Ejemplo tomado del Proyecto Implementación de la Integración Continua:
- Instalar y configurar las herramientas de Integración Continua en el servidor adecuado y destinado
para ello.
- Realizar conexión de webMethods con las herramientas de Integración Continua.
- Documentar todos los procesos de instalación y configuración de las herramientas de Integración
Continua.
- Capacitar un grupo de diez (10) ingenieros de la empresa xxx para el uso de las herramientas de la
Integración Continua en sus labores diarias.
Tabla Verbos para Objetivos Generales y Objetivos Especificos
JUSTIFICACIÓN
Tiene que ver con la motivación, importancia, pertinencia, beneficios, impactos, relevancia social, relevancia
administrativa, financiera y tecnológica del proyecto en el contexto administrativo e informático.
Deben responder ¿Cuál es su importancia? ¿Qué se va a proyectar y por que? ¿Por qué se quiere
hacer? También, mencionar ¿Cuáles son los beneficios a obtener? ¿Quién recibirá los beneficios?
LIMITACIÓN
Tiene que ver con la precisión de los alcances y limites del proyecto. Se debe relacionar en términos tangibles
lo que se espera obtener y hasta donde llega el proyecto.
Se delimita con relación al espacio, tiempo, temática, ambiente y tecnología.
1. En relación con espacio, indica el área, sección, departamento, organización y población afectada o
beneficiada por la presentación, desarrollo o implantación del proyecto
2. En relación con el tiempo, se ubica el proyecto en que momento sucede o puede suceder la presentación,
desarrollo o implantación del proyecto
3. En relación con la temática, se debe conocer el área del conocimiento a la pertenece el proyecto.
4. En relación con el ambiente, se debe determinar el impacto sobre el ambiente, por ej., la contaminación
5. En relación con la tecnología, se debe establecer herramientas, servidores, versiones, etc.
Ejemplo:
Tiempo: 12 Meses
Espacio: Empresa Los Colores, Sección Facturación
Temática: Buenas Prácticas
Tecnológica: Ejemplo tomado del Proyecto Implementación de la Integración Continua
ALCANCES
Los alcances indican con precisión qué se puede esperar o cuales aspectos alcanzaremos en el proyecto.
Figura 2. Representación Metodológica. Fuente Propia
ESTUDIO DE VIABILIDAD
Es preciso estudiar un mínimo de tres viabilidades que condicionarán el éxito o fracaso del proyecto: la
viabilidad técnica, la legal y la económica. Otras viabilidades son las de gestión, la política y la ambiental.
Figura 3. Estudio de Viabilidad.
La viabilidad técnica determina si es posible física o materialmente hacer un proyecto. Puede incluso llegar a
evaluar la capacidad técnica y motivación del personal del sistema y organización involucrado.
La viabilidad legal determina la existencia de trabas legales para la instalación y operación normal del
proyecto, incluyendo las normas internas de la empresa.
La viabilidad económica determina la rentabilidad de la inversión en un proyecto.
La viabilidad de gestión determina si existen las capacidades gerenciales internas del sistema y organización
para lograr la correcta implementación y eficiente administración del proyecto.
La viabilidad ambiental determina el impacto sobre el ambiente, por ej., la contaminación.
La viabilidad política corresponde a la intencionalidad de quienes deben decidir si quieren o no implementar un
proyecto, independientemente de su rentabilidad. Por ej., al elegir entre dos proyectos, el criterio tradicional es
elegir el de mayor valor actual neto (VAN), aunque los responsables políticos pueden decidir a favor del
proyecto con un menor punto de equilibrio en ventas, o a favor del proyecto más flexible en cuanto a la caída
de ventas.
CRONOGRAMA DE ACTIVIDADES
Las actividades del proyecto se presentan gráficamente a través de un diagrama con una coherencia y
ordenamiento espacio-temporal.
El proyectante puede representar el cronograma a partir del diagrama Gantt (
Diagrama que sirve para relacionar actividades con el tiempo) adicionando la columna de Objetivos
específicos, para asociar así, con las actividades como también el resultado esperado.
Ejemplo tomado del Proyecto Seguimiento Actividades Especialistas de TI Estudiante Pablo Emilio Gil Puertas
Figura 4. Cronograma de Actividades. Fuente Propia

ESTUDIANTE: DIEGO ALEJANDRO HUERTAS URREA
PROYECTO DE GRADO
UNIVERSIDAD AUTONOMA 1 2020
12.1 Diagrama de Gantt
Figura 2. Diagrama de Gantt y actividades

12. Cronograma
Figura. Cronograma de fases y actividades

MARCO DE REFERENCIA
Su objetivo es suministrar información sobre resultados obtenidos en proyectos anteriores (antecedentes),

teorías de referencia (marco teórico), conceptos principales (marco conceptual), procedimientos
implementados en el proyecto (marco metodológico), normas y leyes que regulan el proyecto (marco legal o
normativo), y si es posible describir aspectos que se llevan a cabo en el proyecto a través de marco
demográficos, geográficos e históricos
.
Antecedentes
Se describe la evolución del problema formulado. Esta evolución se enuncia como el desarrollo o
transformación del problema formulado en sus etapas a través del tiempo hasta la actualidad.
Corresponde el resumen de los resultados de estudios realizados sobre temas afines al problema formulado,
en sistemas y organizaciones.
Marco Teórico
Un marco teórico es el grupo central de teorías que se utilizan para formular y desarrollar un proyecto.
También, se define como la base teórica a la solución del problema del proyecto.
Permite ampliar la descripción de la solución del problema del proyecto.
Consiste en ubicar, abordar, encasillar, enfocar la solución del problema del proyecto dentro de un área de
conocimiento teórico existente.
Marco conceptual
Proviene del término concepto. Cada concepto se delimita considerando sus atributos primordiales que lo
diferencia de otros conceptos.
Hay muchos modos de definir un marco conceptual, algunas definiciones son las siguientes:
- Una serie de ideas o conceptos coherentes organizados de tal manera que sean fáciles de comunicar a
los demás.
- Definición y Delimitación de los conceptos propios del proyecto.
- Una visión de conjunto de las ideas, conceptos y las prácticas que conforman el modo en que se lleva a
cabo el trabajo de un proyecto.
- Una serie de suposiciones, valores, y conceptos que el proponente adopta para el proyecto.
Normatividad a Cumplir con los conceptos
- El número de conceptos corresponde al criterio del proponente.

- Cuando se define un concepto quiere decir que se debe interpretar de esta manera y no en otra forma
general.
- Se necesita hacer precisión para que no se desvié el sentido del proyecto.
- No manejar conceptos que den lugar a interpretaciones equivocas
- No se debe confundir con un glosario o con una lista de definiciones tipo diccionario
Ejemplo:
- Entidad. Toda Cosa ó Persona del que / quien se puede decir algo.
- Información. El Atributo o Característica de la Entidad
- Dato. El valor asociado a la Información.
Marco Metodológico
El marco metodológico es la explicación de los mecanismos utilizados para el análisis del problema del
proyecto. Por lo general, es el resultado de la aplicación, sistemática y lógica, del área de conocimiento
teórico existente, como también, la serie de ideas, conceptos y prácticas expuestos en el marco teórico y
marco conceptual. Es importante comprender que la metodología de la investigación es progresiva, por lo
tanto, no es posible realizar el marco metodológico sin las fundamentaciones teóricas.
En el marco metodológico se debe incluir las siguientes secciones:
Nivel de Investigación
El nivel de investigación se refiere al grado de profundidad con que se aborda un objeto o fenómeno. Aquí se
indicará si se trata de una investigación exploratoria, descriptiva o explicativa. En cualquiera de los casos es
recomendable justificar el nivel adoptado.
Investigación Exploratoria: es aquella que se efectúa sobre un tema u objeto poco conocido o estudiado, por
lo que sus resultados constituyen una visión aproximada de dicho objeto
Investigación Descriptiva: consiste en la caracterización de un hecho, fenómeno o supo con establecer su
estructura o comportamiento. Los estudios descriptivos miden de forma independiente las variables, y aun
cuando no se formulen hipótesis, las primeras aparecerán enunciadas en los objetivos del proyecto.
Investigación Explicativa: se encarga de buscar el porqué de los hechos mediante el establecimiento de
relaciones causa-efecto.
Ejemplo tomado del Proyecto Control de Aplicaciones y Registro de Novedades:
Diseño de la Investigación
El diseño de la investigación es la estrategia que adopta el proponente para responder al problema del
proyecto.
Los diseños de investigación son:
Investigación Documental: es aquella que se basa en la obtención y análisis de datos provenientes de
materiales impresos u otros tipos de documentos.
Investigación de Campo: consiste en la recolección de datos directamente de la realidad donde ocurren los
hechos, sin manipular o controlar variable alguna.
Investigación Experimental: proceso que consiste en someter a un objeto o grupo de individuos a
determinadas condiciones o estímulos (variable independiente), para observar los efectos que se producen
(variable dependiente).
Población y Muestra
La población (personas, organizaciones o instituciones) involucradas en el proyecto informático para el cual
serán válidas las conclusiones.
Se describe la población, así como el tamaño y forma de selección de la muestra, es decir, el tipo de
muestreo, en el caso de que exista.
En el caso de investigación bibliográfica el universo equivale al tema de estudio.
Por otra parte, los estudios de caso se concentran en uno o pocos elementos que se asumen, no como un
conjunto sino como una sola unidad.
Variables
Una variable es una cualidad susceptible de sufrir cambios. Un sistema de variables consiste, por lo tanto, en
una serie de características por estudiar, definidas de manera operacional, es decir, en función de sus
indicadores o unidades de medida.
Un sistema de variables puede ser desarrollado mediante un cuadro, donde además de las variables, se
especifiquen sus dimensiones e indicadores, y su nivel de medición.
Tabla 4. Descripcion de Variables
Fuente http://www.smo.edu.mx/colegiados/apoyos/proyecto-investigacion.pdf

BIBLIOGRAFÍA
En la bibliografía se registran las obras que tratan del tema, implícita o explícitamente, no es recomendable
citar obras de cultura general, como enciclopedias, diccionarios, etc.
La lista bibliográfica o referencia bibliográfica puede subdividirse en dos partes:
Fuentes bibliográficas consultadas (Normas a Consultar: APA, Icontec)
Fuentes bibliográficas para consultar.
QUE ES UN PROYECTO SISTEMICO Y TECNOLOGICO
En un entorno de proyecto tecnológico, la decisión de iniciar un proyecto sistémico y tecnologico viene dado
por las necesidades de: mantenimiento, modificación, mejoramiento, reemplazo o capacidad; encuadrándose
así, el proyecto sistémico y tecnológico, dentro de una categoría de complejidad mostrada en la siguiente
figura:
Figura 5. Proyecto Informático. Fuente Propia
El Mantenimiento de un sistema software; es una consecuencia de una omisión realizada en la etapa del
diseño del sistema e involucra solucionar fallas menores del sistema, que obligará a la realización de cambios
en el programa; como por ejemplo el descuido de no considerar que puedan ocurrir en el sistema, ciertas
condiciones extraordinarias; como sería el caso de un aumento no previsto del 60 %, en la emisión de órdenes
de compra. Las fallas también pueden provenir de otros factores, como ser en el caso de que existan cambios
en las expectativas de los usuarios.
La Modificación de un sistema software; involucra algo más que un simple cambio en el código; involucra un
cambio estructural de una entidad. Por ejemplo, un cambio en el número de dígitos del código postal, o en el
código de zona telefónica. La diferencia con el Mantenimiento es el grado de importancia
El Mejoramiento del sistema software; es el agregado de capacidades que no formaron parte del sistema de
información original; por ejemplo cuando en una división se implementó un sistema de inventarios, este
sistema no incluía un módulo para calcular la futura demanda de bienes y partes. La inclusión de este
sofisticado módulo de cálculo es considerado un mejoramiento del sistema.
El Reemplazo de un sistema software; ocurre cuando los sistemas de información se tornan físicamente,
tecnológicamente o competitivamente obsoletos. Como es el caso de la utilización del láser, en el
reconocimiento óptico de caracteres para la lectura del código de barras, remplazando a la entrada por
teclado.
FASES DE UN PROYECTO DE GRADO (PROYECTO SOFTWARE)
Figura 6. Fases de un Proyecto Informático. Fuente Propia

PROPUESTA DEL TEMA (FORMULACION DEL PROYECTO)
El aval de la propuesta del tema por parte del comité de grados contempla que el proponente debe tener en
cuenta los siguientes requerimientos del documento para su entrega oficial:
1. Titulo Provisional.
2. Nombre de Proponente
3. Nombre de Asesor Propuesto
4. Planteamiento del Problema
Presentación del Sistema y Organización
Descripción de la Situación Problemica del Sistema y Organización
Delimitación de la Situación Problemica del Sistema y Organización
Formulación del Problema
5. Modelado del Negocio/Modelo del Negocio
Figura 7. Modelado del Negocio. Fuente Propia

DOCUMENTO ANTEPROYECTO
Este anteproyecto debe partir de una situación real, de manera que los datos sean factibles.
1. DATOS GENERALES DEL PROYECTO DE GRADO (PROYECTO SOFTWARE)
1. Título descriptivo del proyecto.
2. Planteamiento del problema
Planteamiento del Problema Informático
Formulación del Problema del Proyecto Informático
3. Objetivos.
General
Específicos
4. Justificación.
5. Alcances y Limitaciones
2. MARCO DE REFERENCIA.
1. Antecedentes.
2. Marco Teórico
3. Marco Conceptual.
4. Marco Metodológico
Figura 8. Marco de Referencia. Fuente Propia
3. ASPECTOS ADMINISTRATIVOS.
1. Estudio de Viabilidad
2. Cronograma.
4. INGENIERIA DEL ANTEPROYECTO
Modelado del Negocio/Modelo del Negocio
BIBLIOGRAFIA
DOCUMENTO DEL PROYECTO (PROYECTO SOFTWARE ORIENTADO A OBJETOS)
Este proyecto debe partir de una situación real, de manera que los datos sean factibles
1. DATOS GENERALES DEL PROYECTO DE GRADO
3. Objetivos.
General
Específicos
4. Justificación.
1. Antecedentes.
2. Marco Teórico
2. Cronograma.
4. INGENIERIA DEL PROYECTO

1. Modelado del Negocio
Modelo del Negocio
Modelo de Requisitos
2. Metodología de Análisis
Diagrama de Secuencia del Sistema
Diagrama de Contrato
Diagrama de Colaboración
Diagrama de Clases
3. Metodología de Diseño
Modelo Arquitectónico.
Diseño de Clase y Datos (ORM)
Diseño de Interfaces
Diseño de Paquetes
Figura 9. Ingeniería del Proyecto. Fuente Propia

5. MODELO DE DESARROLLO.
Acorde con: Factoría de Software, Ingeniería de requerimientos, Modelos de Buenas Prácticas,
Metodologías Agiles.
Figura 10. Ejemplo de Metodología de Desarrollo. Fuente Propia

DOCUMENTO DEL PROYECTO (PROYECTO SOFTWARE ESTRUCTURADO)
3. Objetivos.
General
Específicos
4. Justificación.
1. Antecedentes.
2. Marco Teórico
2. Cronograma.

1. Modelo de Negocio
Modelo de Procesos del Negocio
Modelo Transaccional
2. Metodología de Análisis
Descripción Detallada del Problema
Descripción del Dominio de la Función
Diccionario de Datos
Descripción del Dominio de la Información
Validación del Análisis
3. Metodología de Diseño
Modelo Arquitectónico.
Diseño de Estructuras de Datos / Bases de Datos
Diseño de Interfaces
Diseño de Librerías de Procedimientos
11. Ingeniería del Proyecto. Fuente Propia

5. MODELO DE DESARROLLO.
Acorde con: Factoría de Software, Ingeniería de Requerimientos, Modelos de Buenas Prácticas, Modelos
de Proceso de Software.
DOCUMENTO DEL PROYECTO (PROYECTO TELEMATICO)
3. Objetivos.
General
Específicos
4. Justificación.
1. Antecedentes.
2. Marco Teórico
2. Cronograma.
Tabla 5. Ingeniería del Proyecto Telemático
5. ANÁLISIS DE RESULTADOS OBTENIDOS VERSUS OBJETIVOS ESPECÍFICOS O ANÁLISIS DE

RESULTADOS OBTENIDOS VERSUS RESULTADOS PROPUESTOS
6. CONCLUSIONES
7. RECOMENDACIONES
8. BIBLIOGRAFIA
DOCUMENTO DEL PROYECTO (PROYECTO SOFTWARE EDUCATIVO)
3. Objetivos.
General
Específicos
4. Justificación.
1. Antecedentes.
2. Marco Teórico
2. Cronograma.
1. Análisis del Sistema Software
Dominio Material y de Aplicación
Normalización e Identificación del Objeto
Capa Contenido
Capa Presentación
Capa Ayuda
Navegación
Estructura de un Componente
2. Diseño del Sistema Software
Modelo Esquemático
Descripción del Elemento Terminal (Escena)
Set de Escenas
Navegación
3. Implantación
4. Pruebas
5. ANÁLISIS DE RESULTADOS OBTENIDOS VERSUS OBJETIVOS ESPECÍFICOS O ANÁLISIS DE

RESULTADOS OBTENIDOS VERSUS RESULTADOS PROPUESTOS
6. CONCLUSIONES
7. RECOMENDACIONES
8. BIBLIOGRAFIA
Notas Aclaratoria
Primera Nota. Un Modelo es un prototipo que sirve de referencia y ejemplo para todos los que diseñan y
confeccionan productos de la misma naturaleza.
Segunda Nota. Como metodología se denomina la serie de métodos y técnicas de rigor científico que se
aplican sistemáticamente durante un proceso de investigación para alcanzar un resultado teóricamente válido.
En este sentido, la Metodología es el conjunto de métodos, conceptos o procedimientos basados en principios
lógicos para alcanzar un objetivo
Tercera Nota. Para las Fases de Análisis y Diseño se hace uso de metodologías porque se requiere de
métodos, conceptos o procedimientos como diagramas, descripciones, diccionarios de datos e inclusive
modelos de datos en un rigor u orden determinado.
ANEXO1. ESTADO DEL ARTE
¿Qué es el estado del arte?
Apartes tomados de: https://normasapa.net/que-es-el-estado-del-arte/
El estado del arte establece ―el estado o situación de un tema o tendencia en la actualidad‖. Es una forma
de aludir a lo que se sabe sobre un asunto, lo que se ha dicho hasta el momento, que ha sido más
relevante.
En el área de los estudios académicos el estado del arte hace referencia a la construcción de un análisis de
tipo documental. Este muestre los avances más importantes que se han logrado con respecto al conocimiento
de un tema. Además, la finalidad es hacer una recopilación de fuentes importantes, ideas, conceptos,
opiniones, para que luego, el estudiante puede refutar o complementar, para que así, se posicione a la
vanguardia de las fuentes ya previamente consultadas.
Características del estado del arte

En el estado del arte por fuerza deberá considerar todos los aportes teóricos importantes que se relacionan
con la materia de estudio, aunque sean contradictorias entre sí. Eso significa que debe conocer todos los
argumentos, entenderlos perfectamente y ser capaz de asimilar las diferencias y semejanzas entre las ideas,
como también, postulación de nuevos conocimiento e ideas.
EJEMPLOS DE RELACION ESTADO DEL ARTE CON METODOLOGIA
CASO 1. TEORÍAS DE LA SOCIEDAD DEL CONOCIMIENTO. FUENTE: LA SOCIEDAD
DE LA INFORMACIÓN Y DEL CONOCIMIENTO. INTRODUCCIÓN A LA
BIBLIOTECOLOGÍA Y CIENCIAS DE LA INFORMACIÓN
Proyecto: Las Pymes Bogotanas y el Acceso a las Tecnologías de la Información en La
Sociedad del Conocimiento: Alcance y Perspectivas, Iván Felipe Jiménez Cardona
TEORÍAS IDEAS AUTORES OBRAS
La revolución científico-técnica
transforma la estructura y
dinámica de las fuerzas
productivas y las condiciones
de producción de la vida
Revolución humana. La ciencia se Civilization at
científico- convierte en una fuerza the Crossroads,
tecnológica productiva directa. El trabajo Richta et al. 1968. (301.243
humano se va convirtiendo R534c).
progresivamente en más
creativo o implica meramente
control y regulación.
Sociedad post- Es una etapa posterior a las Touraine La société post-
industrial sociedades industriales, en la Bell industrielle,
que se las llama sociedades 1969. (309
programadas, por la naturaleza T727s).
de su modo de producción y de The coming of
organización económica. post-industrial
society, 1973.
Para Bell las dimensiones que (309 B433a).
caracterizan a la sociedad
post-industrial son: el gran
peso del sector terciario en la
vida económica, la
preeminencia de las clases
profesionales y técnicas en la
distribución ocupacional, la
primacía del conocimiento
TEORÍAS ID AUTORES OBRAS
E
A
S
teórico como fuente
permanente de innovación,
la planificación y el control
del crecimiento tecnológico
y la creación de una
―tecnología intelectual‖
apta para resolver los
problemas de la
complejidad.
Inteligencia como Teorías que explican la Gouldner The future of
clase sociedad en función de las Konrad y intellectuals and
relaciones entre los Szelényi the rise of the
poseedores de Perkin new class,
conocimiento. Preconizan 1979. (301.44
que las relaciones
G696fu).
humanas en el futuro serán
reguladas por los expertos Die Intelligenz
más que por la acción auf dem Weg
política. Los expertos zur
asumirán el poder en Klassenmacht,
forma de tecnócratas. 1978. (301.445
K82in)
The rise of the
professional
society, 1989.
Sociedad de la Teorías que pueden Varios Theories of the
información agruparse en torno a cinco Webster information
dimensiones por las que se society, 1995.
define la sociedad de la
información: tecnológica,
económica, ocupacional,
espacial y cultural.
Sociedad de la El verdadero motor de la Kreibich Die
ciencia sociedad es el Wissenschaftsg
complejo conglomerado esellschaft,
entre ciencia, Tecnología e 1986
Industria. La modernidad
implica un desarrollo
científico- tecnológico
progresivo y continuo.
TEORÍAS IDEAS AUTORES OBRAS
Sociedad del El conocimiento es Böhme y Sther The knowledge

conocimiento considerado como una society, 1986.
capacidad social. La sociedad
de la información se distingue
por un incremento significativo
en las posibilidades para la
acción, tanto individual como
colectiva. Las características
de la sociedad de la
información son: la extensión
de la etapa educativa y la
reducción de la etapa laboral
en la vida de las personas; la
auto-apropiación de la
sociedad a través del
conocimiento y la tendencia
social a acomodarse a formas
de conocimientos mediante
normas; la distribución
ocupacional y de influencia de
acuerdo al conocimiento, es
decir, al intercambio del capital
cultural.
CASO 2. RECONOCIMIENTO DE SISTEMAS EMERGENTE Y STAKEHOLDERS, MÓNICA
PINEDA FORERO, UNIVERSIDAD AUTÓNOMA, 2018
METODOLOGÍA DE DESARROLLO
● Estructura del modelo: se basará en la figura anteriormente representada para la
reunión e implementación de la información requerida, de este modo estructurar el
posible modelo y soluciones que se podrían implementar, realizando una investigación
cualitativa con el fin de recopilar la mayor información con sus respectivos autores
para revisar conceptos, y así tener una idea base hacia la solución del problema.
● Diseño del modelo: una vez recopilada y categorizada toda la información, se
planteará la posible solución de modelo a seguir para el problema en cuestión.
● Establecimiento de reglas: en esta parte de la metodología se plantearan las reglas
necesarias con ciertas condiciones, que para algunos casos se tendrán que cumplir a
cabalidad en otros casos se podrá tener el no cumplimiento de alguna de ellas.
Esto para identificar los stakeholders potenciales, y entre ellos generar un trabajo
colectivo que sea de beneficio a la organización.
● Simulación de pruebas: basada en el diseño el modelo se dará a conocer un
primer ejemplo de simulación donde se vea aplicada la posible solución
metodológica del problema de manera específica.
CASO 3. JUAN MANUEL CAMARGO HURTADO, ANTE PROYECTO DE GRADO,
UNIVERSIDAD SANTO TOMAS, 2017
1. Estado del Arte Herramientas
1.1 Ciclo de Deming
El ciclo Deming es una herramienta de mejora continua. El ciclo consiste de una
secuencia lógica de cuatro pasos repetidos que se deben de llevar a cabo
consecutivamente. Estos pasos son:
Ciclo Deming
Los resultados de la implementación de este ciclo permiten a las empresas una mejora
integral de la competitividad, de los productos y servicios, mejorando continuamente la
calidad, reduciendo los costes, optimizando la productividad, reduciendo los precios,
incrementando la participación del mercado y aumentando la rentabilidad de la empresa u
organización.
1.2 ISO/IEC 27002:2013
Código de prácticas para la gestión de la seguridad de la información". Es un modelo
que da recomendaciones para las buenas prácticas. Es un modelo basado en el anexo
A de la ISO/IEC 27001:2005, el cual amplia y explica de forma detalla como implantar
los controles del anexo A de la ISO/IEC 27001:2005, este método no puede utilizarse
para la certificación.
ISO/IEC 27002:2013
1.3 Diagrama de flujo BPMN

Es una notación gráfica que describe la lógica de los pasos de un proceso de negocio.
Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos
y los mensajes que fluyen entre los participantes de las diferentes actividades, con las
siguientes características:
 Es un estándar internacional de modelado de procesos.
 Independiente de cualquier metodología de modelado de procesos.
 Crea un puente estandarizado para disminuir la brecha entre los procesos de la
organización y la implementación de éstos.
 Permite modelar los procesos de manera unificada y estandarizada permitiendo un
entendimiento a todas las personas de la organización
1.3.1 Gestión de proyectos – PMBOK
La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y
técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La
dirección de proyectos se logra mediante la aplicación e integración de los procesos de
dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre. El
director del proyecto es la persona responsable de alcanzar los objetivos del Proyecto La
dirección de un proyecto incluye:
 Identificar los requisitos
 Establecer unos objetivos claros y posibles de realizar
 Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costos
 Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y
expectativas de los diferentes interesados.
Los directores del proyecto a menudo hablan de una ―triple restricción‖ - alcance, tiempos y
costes del proyecto - a la hora de gestionar los requisitos concurrentes de un proyecto. La
calidad del proyecto se ve afectada por el equilibrio de estos tres factores. Los proyectos
de alta calidad entregan el producto, servicio o resultado requerido con el alcance
solicitado, puntualmente y dentro del presupuesto. La relación entre estos tres factores es
tal que, si cambia cualquiera de ellos, se ve afectado por lo menos otro de los factores. Los
directores de proyectos también gestionan los proyectos en respuesta a la incertidumbre.
El riesgo de un proyecto es un evento o condición inciertos que, si ocurre, tiene un efecto
positivo o negativo al menos en uno de los objetivos de dicho proyecto.
1.3.2 Análisis de brechas
Esta herramienta será usada para identificar las brechas entre el desempeño de la
organización y el desempeño que se espera según la ISO 27001, con el fin de llevar a
cabo en forma exitosa el modelo de gestión.
El análisis de brechas es el examen detallado de la distancia existente entre cada
elemento del diseño del SGSAI y de la situación actual de la empresa.
Las tácticas para cerrar las brechas son:
 Ampliar el marco de tiempo para cumplir con el objetivo.
 Reducir el tamaño o alcance del objetivo
 Reasignar recursos para lograr las metas.
 Obtener nuevos recursos.
Cuando no se pueda cerrar la brecha
 Si se evidencia que no hay posibilidad de cerrar una brecha, el equipo de
planeación debe repetir el ciclo hasta el diseño de la estrategia del negocio y
examinar el conjunto de metas en esta área.
 Se hace evidente que cada brecha se puede cerrar en forma individual,
pero que en la realidad no es posible cerrarlas de manera simultánea, resulta
necesario elegir arias alternativas. Repetir el ciclo entre el análisis de brechas y la
reelaboración del modelo de la estrategia del negocio son mecanismos que se deben
continuar hasta que surja uno que lleve claramente al logro exitoso.
2. RESTRICCIONES
Para preservar la confidencialidad en la información, se omitirán o modificarán en éste
trabajo algunas partes información específica que ponga en riesgo la seguridad de la
compañía. Específicamente información confidencial se refiere a aquella protegida por la
reserva de privacidad y aquella que pueda poner en desventaja competitiva a la compañía
3. DISEÑO METODOLOGICO
1. Serie de normas ISO
1.1. Norma ISO 27002
2. Procesos
2.1. Modelo SIPOC
2.2. Mejoramiento de procesos
2.3. Rediseño de procesos industriales
3. Estrategia competitiva
3.1. Ventaja competitiva
4. Empresa objeto del estudio
4.1. Datos generales
4.2. Reseña histórica
4.3. Misión
4.4. Portafolio de productos
5. Diagnostico estratégico
5.1. Análisis externo (POAM)
5.2. Análisis interno (PCI perfil capacidad interna)
5.3. Análisis DOFA
6. Identificación de las necesidades de la empresa
6.1. Factores de éxito
6.2. El sistema de gestión de seguridad de la información como estrategia
6.3. Diagnóstico y análisis del sistema de gestión de información
7. Plan de acción
7.1. Estructura documental
7.2. Procedimientos de gestión de información
8. Control y medición de los procesos
9. Diseño o adecuación de los procesos
9.1. Identificación de procesos críticos
9.2. Documentación procesos críticos
9.3. Aplicación de herramientas de ingeniería para el proceso
10. Evaluación económica
CASO 4. JHERSON A. COHECHA SALGUERO, SISTEMA DE
ADMINISTRACIÓN DE PRESUPUESTOS BAJO PLATAFORMA WEB,
UNIVERSIDAD AUTONOMA DE COLOMBIA
Metodología del Proyecto: Se realizara una investigación, un estudio, un diseño,
se definirá una población y variables a evaluar.
Investigación: La metodología de este proyecto informático se basara en la
investigación de campo, mediante el uso de la observación en contacto directo
con el objeto de estudio, como también, la recolección de información,
obteniendo una realidad objetiva de los procesos y debilidades de estos.
Estudio: Estandarizar procesos a partir de la investigación de campo, que
permitan disminuir las debilidades halladas durante la observación. Y mediante
una relación causa – efecto, cumplir el objetivo de la empresa JASM S.A.S. de
ser más eficiente en el desarrollo de proyectos y disminuir el desperdicio de
suministros.
Diseño: Se realizara mediante la técnica de recolección de datos de la fuente,
para así, realizar prototipos que permitan refinar requerimientos de manera
progresiva o evolutiva.
Población: Funcionarios de la empresa JASM S.A.S., que estén vinculados en
la parte de desarrollo de proyectos o interventoría.
Variables: Las variables a evaluar en el proyecto serán tiempo y el
seguimiento (estado de solicitud y estado de entrega) de los suministros, los
cuales se definen en una relación causa y efecto, debido que si hay una
buena gestión de los recursos (Suministros), el tiempo invertido en las
actividades con respecto a cada proyecto de la empresa JASM S.A.S.
Metodología de Desarrollo: Estará basada en el modelo de cascada, compuesto por cuatro
faces que son; análisis del problema, diseño de la solución, programación del sistema, y
pruebas del sistema. Se hace uso de este modelo por ser uno de los más funcionales y
robusto a la hora de desarrollar software.
Análisis. A partir del material entregado por parte la empresa JASM S.A.S., y
reuniones con el representante de la misma. Y el análisis realizado a la
herramienta utilizada actualmente para la gestión de presupuestos, se
definirán los requerimientos para hacer un aplicativo web robusto y funcional
para la empresa.
Diseño. Partiendo de los requerimientos obtenidos en el análisis
empezaremos a diseñar la solución pare el manejo (Entendemos por manejo la
inserción, modificación, eliminación, validación) de una base de conocimiento,
mediante una plataforma web; para ello tendremos en cuenta el lenguaje de
moldeamiento unificado (UML) para el diseño del aplicativo usando diagramas
de casos de uso y diagramas de clases.
Programación. Programar el diseño realizado usando un modelo, vista,
controlador. El lenguaje de desarrollo utilizado será Java, el framework spring
MVC, los datos se almacenaran en una base de datos Mysql.
Pruebas. Realizar las pruebas de funcionamiento y validación de los procesos
que realice el aplicativo web, verificado por un usuario de la empresa JASM
S.A.S.
ANEXO2. MODELOS DE NEGOCIOS/MODELOS DE REQUISITOS/POSICIONAMIENTO SEO Y SEM
Los derechos de propiedad intelectual de la idea como modelo de negocio pertenecen a los estudiantes, por lo
cual, toda la información contenida en el presente trabajo sólo puede ser usada con fines académicos.
Cualquier uso, reproducción parcial o total destinada a otros fines, deberá estar autorizada por las partes
mencionadas.
Que es un Modelo de Negocio
https://www.emprendedores.es/crear-una-empresa/a69057/que-significa-modelo-de-negocio/
Un modelo de negocio es una herramienta que permitirá definir con claridad qué se va a ofrecer al mercado, cómo se va
a hacer, a quién se le va ofertar/ofrecer, cómo se va a vender y de qué forma se va a generar ingresos. Es una
herramienta de análisis que permite saber quién eres, cómo lo haces, a qué coste, con qué medios y qué fuentes de
ingresos vas a tener. Definir tu modelo de negocio es saber cuál es tu ADN, cómo está hecho, cómo se puede modificar,
cómo pulir, cómo cambiar, cómo moldear…
Cuando se habla, coloquialmente, de modelo de negocio se suele concretar en la forma que tiene una empresa de ganar
dinero. Y también es eso, pero es mucho más. ―Se suele relativizar lo del modelo de negocio con los flujos de ingresos, y
el modelo de negocio habla no sólo de cómo ganar dinero sino también de quiénes son tus clientes, de cómo vas a llegar
a ellos, qué cosas tienes que hacer para entregarles tu propuesta de valor, qué es lo que te hace único, qué estructura
de costes tienes, etc.; es una visión sistémica de tu negocio‖, subraya Javier Megías, experto en creación de empresas y
modelos de negocio.
Los modelos que están funcionando son aquellos capaces de crear valor para el cliente, es decir, que tienen una
propuesta de valor clara, que son capaces de llegar al cliente, de diferenciarse, de establecer fuertes lazos con el cliente,
de fidelizar y que son capaces de producirlos también de una manera especial.
La manera de validar un modelo de negocio es teniendo clientes que paguen por tu producto y/o servicio. Esa es la
manera de validar tu propuesta de valor. ¿Cómo se crea valor? Estando muy cerca del cliente. Estableciendo una
relaciones muy estrechas desde el principio para saber cuáles son sus necesidades o problemas que tienen. Y una vez
en el mercado puedes encontrarte con que tu modelo de negocio necesita modificarse. "El modelo de negocio puede
variar constantemente. De hecho, no cambiar de modelo de negocio o no hacer variaciones importantes es aterrador"
METODO CANVAS
Fuente: https://www.marketingyfinanzas.net/2013/03/modelo-canvas-una-herramienta-para-generar-
modelos-de-negocios/
El Método Canvas consiste en poner sobre un lienzo o cuadro nueve elementos esenciales de las
empresas y testar estos elementos hasta encontrar un modelo sustentable en VALOR para crear un
negocio exitoso, hace parte de la metodología ―Lean Startup‖ que junto al Producto Mínimo Viable
ponen a su mano herramientas muy sencillas de probar cual puede ser el producto o el servicio más
viable para las empresas en crecimiento.
El Método Canvas busca con un modelo integral analizar la empresa como un todo y sirva como
base para desarrollar diferentes modelos de negocios, se ha convertido en una herramienta de
Innovación Estratégica.
Elementos o bloques del Método Canvas
1. Segmentos de Clientes: estos resultan ser los más importantes dentro del modelo, saber y conocer
perfectamente nuestros clientes, responde la pregunta ¿para Quién?
2. Propuesta de Valor: aquí es muy importante descubrir cómo queremos generar VALOR para
nuestros clientes, con propuestas novedosas e innovadoras. Responde la pregunta ¿el Qué?
3. Canal: Como entregar la propuesta de valor para nuestros clientes? Cómo hacemos llegar los
productos a nuestros clientes?
4. Relación con los Clientes: Qué tipo de relación esperan nuestros clientes, qué relación tenemos
ahora?
5. Flujo de Ingresos: cuál es valor que están dispuestos a pagar nuestros clientes por nuestros
productos?
6. Recursos Claves: qué recursos claves necesito para generar Valor en mis productos?
7. Actividades Claves: qué actividades claves necesito desarrollar para generar valor en mis productos
o servicio?
8. Alianzas: este bloque es muy importante ya que debemos definir cuáles serán nuestros socios
estratégicos en proveedores, clientes y accionistas entre otros.
9. Costos: es muy importante saber que estructura de costos voy a implementar ya que en este punto
sabremos qué utilidad podríamos tener de nuestro negocio
Orden Para Completar el Método Canvas
http://innokabi.com/canvas-de-modelo-de-negocio/
Para hacer un canvas, primero se rellenan los módulos del lienzo de la parte derecha. Estos bloques hacen
referencia a la parte externa de la compañía, al mercado. El que se rellene esta parte inicialmente no es
casualidad, la razón por la que se trabaja de esta manera es que primero debes conocer y analizar el entorno
en el que opera o va a operar tu empresa, identificando inicialmente tu segmento de clientes, qué es lo que
vas a ofrecerles, cómo vas a llegar a ellos, qué relación vas a mantener con ellos y finalmente cómo van a
pagarte.
Paso 1. Reflexión de la parte derecha del Canvas. La del mercado:

Céntrate en la parte derecha del canvas de modelo de negocio y reflexiona sobre…
1. Segmento de clientes: Para determinar tu nicho de mercado pregúntate a quién creas valor! Para
analizar este bloque existen lienzos de trabajo específicos que explicaremos en otros posts como el
lienzo de propuesta de valor, el lienzo de persona o los conocidos mapas de empatía. Imaginarium:
Padres con niños hasta 10 años de edad
2. Propuesta de Valor: Para definir tu propuesta de valor es crítico saber qué problema ayudas a
solucionar a tus clientes. Imaginarium: Educación y juego en un solo concepto
3. Canales: Identifica cuál va a ser el medio por el que vas a hacer llegar tu propuesta de valor a tu
segmento de clientes objetivo. A veces tu estrategia de Marketing online será clave en este apartado y
otras menos. Imaginarium: Tiendas propias y modelo de franquicia
4. Relación con clientes: Reflexiona sobre cuál va a ser tu relación con los clientes. Dónde empieza y
dónde acaba esta relación. También tu estrategia en Redes Sociales y en Marketing online será clave
en tu relación con clientes. Imaginarium: Asistencia personal y call-center para atender el servicio
postventa
5. Flujo de ingresos: Tienes que tener claro cómo vas a ganar dinero. Al principio pon todas las opciones
que se te ocurran y posteriormente testa cómo y cuánto está dispuesto a pagar tu cliente objetivo
(venta de activos, suscripción, publicidad…) Imaginarium: Venta de juguetes
Paso 2. Analiza internamente tu propia empresa sobre el modelo canvas:
Una vez conozcas el entorno de tu compañía, adapta las piezas (bloques) internos para aportar la
―propuesta de valor‖ detectada de la mejor manera posible; crea alianzas con los agentes
necesarios, céntrate en las actividades nucleares de tu negocio y piensa qué necesitas y cuál es la
estructura de costes. Es decir, analiza;
1. Recursos Clave: ¿Qué necesitas para llevar a cabo la actividad de tu empresa? Los recursos pueden
ser físicos, económicos, humanos o intelectuales. Imaginarium: Tienda, juguetes, personal.
2. Actividades Clave: Cuáles son las actividades nucleares para tu empresa. Es importante tener claro
este bloque porque es a lo que se dedicará tu empresa, el resto, lo que aporta menos valor, podrás
subcontratarlo. Imaginarium: Diseño, producción y venta de juguetes educativos
3. Asociaciones Clave: Enumera los agentes con los que necesitas trabajar para hacer posible el
funcionamiento del modelo de negocio (alianzas estratégicas, proveedores…) Imaginarium:
proveedores, franquiciados…
4. Estructura de Costes: Después de analizar las actividades clave, los recursos clave y asociaciones
clave, reflexiona sobre los costes que tiene tu empresa. Imaginarium: Personal, inmovilizado, diseño y
producción de juguetes…
Modelo de Negocios: Solución Tecnológica de Conectividad en los Procesos de Producción y
Medición de Pozos Petroleros
Carlos Eduardo Maldonado Clavijo, Hernando Yepes Patalagua
Universidad Santo Tomas
VUAD
Programa Ingeniería en Informatica
CAU Bogotá
CAU Bogotá
Modelo de Negocios: Aplicación móvil para la enseñanza de artículos determinados e indeterminados

de la gramática española
Zully Jazmín Torres
VUAD
CAU Bogotá
Modelo de Negocios: Tienda en Línea
José Ricardo Muñoz G
VUAD
CAU Bogotá
Modelo de Negocios: E-pets
John Alejandro Garzón Fajardo
VUAD
Programa Administración de Sistemas Informáticos
CAU Bogotá
Modelo de Negocios: PIDEMEYAPP
ADRIANA PÁEZ JIMÉNEZ - PATRICIA ROJAS TRISTANCHO
VUAD
Programa Administración de Sistemas Informáticos
CAU Bogotá
Luz Adriana León Ríos
Ingeniería informática
CAU Manizales
Modelo de Requisitos UML
Tomado de: https://es.slideshare.net/ramirezjaime/modelo-requisitos-uml
Modelo de Requisitos de Usuarios. Fuente Microsoft

Tomado de: https://msdn.microsoft.com/es-co/library/dd409376.aspx
CÓMO DISEÑAR UNA PÁGINA WEB EN 6 PASOS FÁCILES
Tomado de: https://www.hostinger.co/tutoriales/como-disenar-una-pagina-web/
Hay dos cosas que los sitios web más exitosos tienen en común: excelente contenido y un diseño maravilloso. Si el
diseño de tu sitio es mediocre, tu contenido no podrá brillar y los visitantes se alejarán. Eso significa que debes comenzar
a pensar en el estilo desde el momento en que tienes la idea para un nuevo proyecto.
En este artículo, te enseñaremos cómo diseñar una página web desde cero. Pasaremos por los seis pasos requeridos,
que incluyen:
1. Encontrar un proveedor de hosting web confiable.

2. Elegir una plataforma para construir tu sitio web.
3. Configurar las herramientas que necesitas para darle vida a tu diseño.
4. Crear un bosquejo de tu diseño web.
5. Trabajar en un prototipo de diseño.
6. Comprobar si tu diseño se ve bien en dispositivos móviles.
No te preocupes, puedes crear un sitio web impresionante incluso si eres un completo principiante. ¡Así que vamos a
hablar de cómo diseñar una página web!
Paso 1: Encontrar un hosting web confiable
Antes de empezar a hablar sobre cómo diseñar un sitio web, debemos ocuparnos de algunos asuntos técnicos. Primero,
eso significa encontrar un proveedor de hosting web de calidad para tu nuevo sitio.
Mucha gente solo busca el hosting más barato que pueda encontrar y luego se dan una palmada en la espalda, pero eso
suele ser un error. No todos los proveedores de hosting ofrecen el mismo nivel de servicio o características, por lo que
tendrás que mirar varias opciones hasta encontrar una opción confiable.
Cuando se trata de alojamiento web, esto es lo que debes tener en cuenta para identificar un proveedor de calidad:
 Excelente servicio al cliente

 Gran rendimiento para los sitios que alojan
 Funciones adicionales para hacerte la vida más fácil, como copias de seguridad automatizadas
 Documentación sólida, para que puedas resolver problemas por tu cuenta
 Soporte para cualquier plataforma que quieras utilizar para construir tu sitio web
Como es de esperar, la mayoría de los proveedores de hosting afirman cumplir con todos estos criterios, así que
depende de ti hacer tu propia investigación. La mejor manera de hacerlo es buscar múltiples reseñas independientes del
proveedor que estés considerando.
Además de ofrecer hosting accesible, también incluimos un dominio gratuito con nuestros planes anuales de
hosting Empresarial y Premium, así que recuerda darles un vistazo.
Paso 2: Elegir una plataforma para construir tu sitio web
Cuando hayas resuelto el tema del hosting web, lo que sigue es elegir la plataforma a utilizar para crear tu sitio web.
Siempre puedes codificarla desde cero si lo deseas, pero esa es la opción más adecuada para desarrolladores
experimentados.
En lo que respecta a las plataformas de sitios web, somos grandes admiradores de los Sistemas de gestión de contenido
(CMS). Estas herramientas permiten crear sitios web profesionales y administrar grandes bibliotecas de contenido, y aun
así, la mayoría pueden ser utilizadas por principiantes.
Hay muchas opciones de CMS que puedes elegir, como WordPress:
Esta plataforma en particular es utilizada por más del 30% de la internet, lo cual nos indica que es una opción seria.
WordPress es fácil de usar y ofrece una cantidad asombrosa de opciones de personalización gracias a sus plugins y
temas.
A continuación, veamos a Joomla:
Esta plataforma en particular tiene una mayor complejidad que WordPress, pero compensa el trabajo adicional
involucrado con sus funciones integradas de optimización para motores de búsqueda (SEO) y configuración de
seguridad. Además, Joomla hace un excelente trabajo en cuanto el manejo de tipos de contenido personalizados sin
tener que añadir extensiones, que es un área en la que WordPress tiene ciertas dificultades si no se realiza un cierto
nivel de personalización.
Aparte de los CMS, también puedes utilizar creadores de páginas web. Estas soluciones permiten crear sitios web
utilizando constructores visuales con función de arrastrar y soltar, junto con colecciones de elementos listos para usar:
Los creadores de páginas web ofrecen una forma fácil de poner tu sitio en funcionamiento rápidamente, a la vez que
permiten un grado decente de personalización. Si te llama la atención, ofrecemos un creador de páginas web con todos
los planes de Hostinger, así que quizás puedes empezar por allí.
Durante el resto de este tutorial, nos centraremos en WordPress, ya que es la plataforma más popular para crear páginas
web. Además, ofrece muchas herramientas para ayudarte a aprender cómo diseñar una página web.
Paso 3: Configurar las herramientas que necesitarás
Después de instalar WordPress, también tendrás que configurar algunas herramientas adicionales si quieres hacer
realidad tus diseños. En primer lugar, necesitarás una plantilla que corresponda con el estilo que tienes en mente para tu
sitio web.
Hay miles de opciones para elegir cuando se trata de plantillas de WordPress. Sin embargo, recomendamos que
empieces utilizando un tema gratuito mientras te acostumbras a la plataforma. Puedes encontrar la mejor selección en
el repositorio oficial de
WordPress.org:
Busca algún tema que te guste, manteniéndote atento a que tenga buenas calificaciones y actualizaciones recientes. Si
un tema no tiene ninguno de ellos, entonces es mejor evitarlo, porque es mucho más probable que cause problemas.
Cuando ya te hayas decidido por un tema en particular, puedes instalarlo y activarlo.
En esta etapa, también te recomendaremos usar un plugin de creador de páginas de WordPress. Estas herramientas
permiten diseñar fácilmente sitios web con altos niveles estéticos. WordPress puede ser fácil de usar, pero lograr que tu
sitio web se vea como tu quieres requiere algo de delicadeza. Con un plugins de creación de sitios web, puedes modificar
el diseño sobre la marcha.
Como puedes imaginar, no hay escasez de plugins de creación de páginas para usuarios de WordPress. Sin embargo,
somos partidarios de Beaver Builder debido a su facilidad de uso y su gama de funciones:
Aprender a diseñar una página web con este plugin es algo muy intuitivo. Con Beaver Builder, obtienes acceso a una
amplia colección de elementos que puedes agregar a cualquiera de tus páginas, simplemente arrastrándolos hasta la
ubicación que quieras. Luego puedes editar cada elemento, para que se vea genial:
Si no te entusiasma Beaver Builder, no te preocupes, hay muchas otras opciones que puedes probar. Cuando hayas
encontrado el que te guste, es hora de dar el siguiente paso para aprender a diseñar una página web.
Paso 4: Crear un bosquejo de tu diseño web
Hasta ahora, hemos estado sentando las bases técnicas necesarias antes de comenzar a diseñar una página web.
Ahora, sin embargo, es cuando puedes dejar fluir toda tu creatividad.
En este momento, tienes un sitio web de WordPress con una plantilla de buen aspecto y un plugin de creación de
páginas listo para funcionar. A continuación, vas a sacar papel y lápiz (sí, vamos a hacerlo ‗a la antigua‘), que usarás
para dibujar cómo quieres que se vea tu sitio web.
Este es un bosquejo y no tiene que ser demasiado detallado. Lo importante es que incluya todos los elementos que
quieres ver en el sitio web. Por supuesto, puedes agregar tantos detalles como desees. En última instancia, este
bosquejo servirá como referencia visual cuando comiences a diseñar tu sitio web en la realidad.
Si no eres de los que usan lápiz y papel, también hay muchas herramientas que puedes usar para crear bosquejos en
tu computadora. El inconveniente es que todos conllevan una curva de aprendizaje, lo que significa que tendrás que
dedicar un poco más de tiempo a este paso.
En cualquier caso, revisa y modifica tu bosquejo tantas veces como quieras, hasta que te sientas cómodo con su
aspecto. Luego de eso, pasemos al siguiente paso.
Paso 5: Comenzar a trabajar en un prototipo de diseño y refinarlo
Cuando tu bosquejo ya esté listo, vamos a pasarlo del papel al mundo digital. En otras palabras, vas a comenzar a crear
un prototipo de tu diseño web.
Como ya tienes el creador de páginas web listo, el primer paso debería ser abrirlo con el editor de WordPress. Luego,
puedes comenzar a agregarle a tus páginas los elementos que desees y organizarlos tal como aparecen en tus
bosquejos.
Este proceso podrá variar según el plugin de creador de sitios que elijas, por supuesto. Sin embargo, en esta etapa,
recomendamos que no te quedes atascado en los detalles, como decidir qué tamaño de fuente utilizar o elegir los colores
perfectos. Todavía habrá tiempo para refinar el diseño más adelante.
Lo importante ahora es que construyas un prototipo funcional de tu sitio web, que incluya todos los elementos que
incorporaste en el bosquejo. Con un prototipo listo, podrás detectar cualquier decisión de diseño que no funcione y
realizar cambios para mejorar el diseño de tu sitio web. En este punto es en donde comenzarás a enfocarte en los
detalles más pequeños.
En la mayoría de los casos, los bosquejos no pasaran ilesos por la transición hacia un prototipo. Pero eso es
completamente normal. Del mismo modo, el primer prototipo probablemente no se parecerá mucho al sitio terminado.
Además, el tiempo que demores en diseñar un sitio web dependerá de qué tan perfeccionista seas. Probablemente
tengas docenas de elementos para personalizar y opciones de diseño para jugar, así que no te apresures.
Un consejo rápido para tener en cuenta ahora es no preocuparse demasiado por el texto del sitio web y otros tipos de
contenido. Para lograr tener listos los prototipos más rápido, utiliza texto ficticio e imágenes de stock. Cuando hayas
terminado el diseño y todo esté en su lugar, puedes reemplazarlos por el contenido que realmente usarás.
Paso 6: Verificar que el diseño se vea bien en dispositivos móviles
En este punto, ya has aprendido mucho sobre cómo diseñar una página web. Sin embargo, hay un último paso antes de
que puedas decir que tu diseño está listo para el show, y es asegurarse de que se vea bien en los dispositivos móviles.
Hoy en día, el tráfico móvil ha superado a sus contrapartes, por lo que asegurarse de que tus diseños se vean bien en
resoluciones más pequeñas es clave. Si tu sitio web se desfigura cuando alguien accede a él desde un smartphone,
tendrás muchos visitantes decepcionados y una tasa de rebote bastante alta, que es algo que debes evitar.
La buena noticia es que la mayoría de los creadores de páginas de WordPress (como Beaver Builder) están optimizados
para dispositivos móviles por defecto. Eso significa que los diseños que realices con ellos deberían verse bien en
dispositivos móviles, sin que tengas que hacer nada más.
Sin embargo, nunca está de más ser cauteloso y verificar cómo se ve tu sitio web en una pantalla más pequeña. Hay
muchas maneras de hacerlo. Por ejemplo, puedes usar tu propio dispositivo móvil para acceder al sitio web. Otra
alternativa mejor es usar las herramientas de desarrollo de Chrome, que permiten visualizar tu sitio web en diferentes
resoluciones.
Para acceder a las herramientas de desarrollo de tu navegador, haz clic derecho en cualquier lugar del sitio web, luego
presiona el botón Inspeccionar (Inspect). Luego, mira la parte superior de la pantalla. Verás un par de campos donde
puedes ingresar una resolución personalizada y ver cómo se ve tu sitio web en ese tamaño:
Si quieres ser minucioso, te recomendamos probar varias resoluciones para asegurarte de que tu sitio web se vea y
funcione correctamente en todas ellas. Si tienes algún problema, regresa a la etapa de prototipo y usa el creador de
páginas web para solucionarlo. Luego de solucionar los imprevistos, tu diseño finalmente estará listo para el público.
Otra mirada puede ser con el diseño profesional de Páginas web profesionales con wix
Editor de Wix. Libertad total de diseño. Se comienza desde cero o se elige entre más de 500 plantillas para crear el sitio
Wix. Con el sistema de arrastrar y soltar, puedes personalizar o cambiar cualquier cosa. Haz que tu sitio cobre vida con
fondos de video, efectos de desplazamiento y animaciones. Con el Editor de Wix, se puede crear una página web
profesional sin ayuda de nadie.
Conclusión
Si tienes un sitio web de aspecto profesional, entonces ya has ganado la mitad de la batalla. Con un buen diseño, la
gente prestará más atención a lo que tienes que decir y así debería ser más fácil conseguir conversiones. La buena
noticia es que no necesitas ser un profesional para aprender a diseñar un sitio web que se vea fantástico. Todo lo que se
necesita es seguir algunas de las mejores prácticas, usar las herramientas adecuadas y trabajar hasta que tu sitio se vea
genial.
¿QUÉ ES EL POSICIONAMIENTO SEO Y SEM?
Tomado de: https://www.palbin.com/es/blog/p32-seo-y-sem-que-es-el-posicionamiento-seo-y-sem.html
SEO Y SEM son las dos técnicas de posicionamiento en buscadores que debes incluir en tu estrategia de marketing y
publicidad, gracias a las cuales una página o sitio web consigue su mejor colocación a la hora de hacer una búsqueda
determinada en cualquier herramienta de análisis (en el caso español, Google la más utilizada). La misión del
posicionamiento es hacer que un determinado sitio o web sea encontrado de forma fácil en los buscadores
¿Qué es el SEO?
El significado del SEO (Search Engine Optimization en inglés) es la optimización que hacemos en una página para que
aparezca en los motores de búsqueda, por ejemplo Google o Bing. Herramienta indispensable en la estrategia de
marketing.
Estamos hablando de la aparición de forma natural, orgánica, sin pagar en las primeras posiciones de los resultados de
búsqueda para las principales palabras clave de nuestro negocio. Se trata pues de un tráfico casi gratuito porque no se
paga por cada click (a diferencia del SEM). Sin embargo, hay que aclarar que para gestionar el SEO de forma natural hay
que tener en cuenta muchas características y factores dictados por estos buscadores. Por ejemplo, hay que obtener
información sobre qué tiene en cuenta el algoritmo de los buscadores (que se actualiza de forma frecuente), las palabras
clave más interesantes para cada negocio, el contenido de la página, los enlaces, indexación, optimización del código de
la web, etc. En otras palabras podríamos decir que es necesario cumplir con todas las premisas del buscador. Si ya
trabajamos con una web o tienda online optimizada, según los expertos en marketing y posicionamiento SEO, lo más
laborioso es la selección de las palabras clave adecuadas, tanto por el volumen idóneo como por su fácil accesibilidad en
función del nivel de competencia. Este paso está directamente relacionado con otro aspecto a tener en cuenta, que
contribuirá a mejorar el resultado de la búsqueda, el cual son los enlaces. Un sitio web que dispone de un gran número
de enlaces a través de una palabra clave será mucho más relevante que otro. Ahora, eso sí, el hecho de lograr un buen
posicionamiento en un momento determinado no nos asegura el mantenernos de forma permanente, por lo que implica
un trabajo ininterrumpido para ocupar siempre los primeros lugares.
Características principales del posicionamiento SEO. Para conocer más a fondo de en qué consiste el SEO y su
utilidad en el entorno digital se presenta a continuación las principales características:
Es gratuito: Es una técnica muy rentable y beneficiosa para la salud de la web porque no necesita de inversión
inicial
Requiere de conocimientos técnicos: Es importante conocer bien las técnicas buenas, ya que realizar malas
prácticas mal vistas para google (Black Hat SEO) pueden ser penalizados por Google y acarrear resultados
desafortunados en una página web.
Consume tiempo: Los resultados no se aprecian de un día para otro por lo que es necesario invertir mucho
tiempo, paciencia y cariño al proyecto.
Se basa en las directrices que marcan los algoritmos del buscador: Google normalmente modifica sus
algoritmos varias veces al año y hay que estar continuamente actualizados para adaptarse a esos cambios.
Se obtiene resultados a largo plazo: Se debe tener la paciencia y constancia necesarias, los resultados de
posicionamiento serán mucho más estables y valiosos a largo plazo, siendo así mucho más difícil descender
posiciones que con una campaña de pago
Tipos de SEO. Como se comentaba con anterioridad, el posicionamiento SEO u orgánico trabaja cientos de factores
para optimizar una página web y hacerla más importante a vista de google. De esta forma que puede salir más arriba en
los resultados de búsqueda. Existen dos principales tipos de técnicas de posicionamiento SEO que deben ser trabajadas
comúnmente para alcanzar las primeras posiciones. Es importante destacar que no servirá de nada trabajar o centrarte
en unas técnicas más que otras, sino que la clave está en trabajar todas (o las más necesarias para la web) a la vez.
El SEO On Page (En página) hace referencia a la optimización dentro de una página web de cara a los
buscadores y a la experiencia del usuario. En SEO On Page el objetivo es destacar entre todas las otras webs,
haciéndola una web agradable para Google. Existen cientos de factores On page que pueden ser optimizados y
que se dividen en estas temáticas entre otras. Análisis de palabras clave: Toda la creación de la web y
contenidos tiene que realizarse en función a un buen estudio de palabras clave para conseguir información y
atraer tráfico a la web. Velocidad de carga de la página: una web no debe tardar más de 3 segundos en cargarse
completamente si no queremos ir a las últimas posiciones del ranking de Google Estructura Web: Crear una
buena jerarquía de paginación y enlazado interno es imprescindible. Optimización del código fuente: la mejor
práctica es mantenerlo limpio y organizado para facilitar su lectura. Actualización y creación de información y
contenido: En SEO se dice que el contenido es el rey, por lo que es muy importante crear nuevo contenido y
actualizar el viejo, para demostrar que es una web activa y actualizada.
El SEO off page se centra en todo lo que ocurre alrededor de nuestra web y que no está a nuestro alcance. El
propósito principal de esta técnica es la de crear un red de enlaces entrantes o Linkbuilding a nuestra web.
Google entiende que cuantas más páginas webs ajenas tengan enlaces hacia nuestra web, más interesante será
nuestro contenido y por tanto más personas querrán ver el contenido de esta, haciéndonos ascender en las
posiciones en Google. Lo más difícil de esta técnica es cómo conseguir buenos enlaces entrantes o backlinks,
ahí entra la labor del buen especialista en SEO.
¿Qué es el SEM? La definición del SEM es Search Engine Marketing se puede utilizar en la estrategia de marketing y
hace mención a la optimización que hace una página con publicidad en los motores de búsqueda como Google o Bing.
En el SEM si se crean correctamente los anuncios y siempre que se tenga presupuesto el buscador mostrará la página
en los primeros resultados de búsqueda reservados para anuncios. Por tanto, los resultados de pago hacen referencia a
las campañas de pago por clic, es decir, el enlace aparece en los enlaces patrocinados pagando una suma de dinero por
cada vez que algún usuario accede a nuestro sitio web, en otras palabras podríamos decir que son anuncios. Si se hace
bien la campaña SEM como resultado se obtiene un tráfico cualificado muy segmentado con el mayor control de los
resultados. El precio de este servicio está controlado ya que depende del presupuesto que haya decidido el anunciante y
la rapidez de lanzamiento puede reducirse a unas pocas horas. En el SEM cada vez que una persona hace clic en cada
anuncio el buscador (Adwords para Google por ejemplo) nos cobrará por ello. Esta es la gran diferencia con el SEO. Si
bien es cierto que hacer una campaña rentable en el SEM tiene su miga. Hay que enfocarse en palabras que impliquen
la intención de comprar, reservar, registrar o que satisfaga el objetivo que tengamos como empresa.
Características del posicionamiento
Anuncios de pago: aunque existen otras opciones de pago, la más habitual es la del coste por clic o CPC:
A corto plazo: ideal para campañas de duración determinada como Navidad, Black Friday o rebajas. Sin
embargo, los anuncios desaparecerán en cuanto dejes de pagar, y no generará ningún valor adicional a largo
plazo a la web derivado de estos anuncios.
Rápido: a publicación: los anuncios aparecerán en el mismo momento en que crees los anuncios y
desaparecerán en el momento que los elimines.
Tipos de campañas SEM. Dentro del SEM existen varios tipos de campañas que pueden ser interesantes en función de
las características de la web, ya que cada una de ellas tiene un objetivo y funcionalidades diferentes. A continuación se
describe:
Google Shopping. Si lo que tenemos es un comercio online y lo que nos interesa es aumentar las ventas de nuestro
negocio lo más recomendado es utilizar Google Shopping. Los años de experiencia en creación de tiendas online
demuestran que es una gran herramienta que favorece las ventas en la web por una sencilla razón, su funcionamiento es
muy sencillo y se anuncian todos y cada uno de los productos que aparecen en la web. Además en varias ocasiones
hemos llevado a cabo experimentos con Google Shopping con grandes resultados y que nos dan la razón en este
aspecto. Pero, ¿cómo aparecer en google shopping? Cabe destacar que no todas las tiendas online pueden acceder a
este tipo de campañas por que Google pone unas restricciones que se deben ajustar en la web, para que así, la
publicidad no sean rechazados por Google.
Más info en: https://www.palbin.com/es/blog/p32-seo-y-sem-que-es-el-posicionamiento-seo-y-sem.html

Optimización de motores de búsqueda: Wix con SEO para tu página web
https://es.wix.com/about/faq-seo
La mayoría de las personas encontrarán su página web usando un buscador como Google. Un buen SEO les ayudará a
encontrarte más rapida y fácilmente puesto que aparecerás en un mejor lugar en la lista de resultados.
Las páginas web de Wix están listas para ser personalizadas con un contenido único que describa eln egocio. Esto
facilita a Google saber de qué se trata la página web y presentarla en los resultados de búsqueda relevantes.
Se puede administrar SEO directamente desde el panel de control de Wix.
Se recuerda que SEO (por sus siglas en inglés: Search Engine Optimization, es decir optimización de motores de
búsqueda) es el conjunto de acciones que ayudan a los motores de búsqueda a encontrarte. Estas acciones consisten en
resaltar el contenido de la página web en cuanto a textos, fotos y videos, para que Google y otros buscadores puedan
encontrarlo y presentarlo como relevante en los resultados.
Por ejemplo, se tiene una página web de Wix para un negocio de bicicletas. Se interesa lograr que Google muestre la
página web a las personas que están buscando comprar una nueva bici. Mejorar el SEO de la página web les ayudará a
los motores de búsqueda a hacer esta conexión. Con Wix es fácil tener un excelente SEO para tu sitio.
Figura. Página web final. De la Fuente

¿Qué herramientas de SEO da Wix?
 SEO en el editor - Establece un SEO único para cada página del sitio.
 SEO para imágenes - Optimiza todas las imágenes usando el texto alternativo (Alt text) en el editor de Wix.
 Guía SEO - Usa guía gratuita con instrucciones paso a paso para mejorar tu SEO.
 El blog de Wix - Lee interesantes artículos y herramientas de ayuda.
 Wix App Market - Descubre todas las apps que pueden ayuda a mejorar tu SEO.
 Centro de Ayuda - Si tienes más preguntas, contácta a nuestro equipo que con gusto te ayudará.
¿Por qué es importante personalizar el contenido de una página web?

Las plantillas de Wix están prediseñadas para ayudar a saber dónde es recomendable que use texto. Se Puede ver
ejemplos de párrafos y descripciones en cada página.
Asegúrese de reemplazar este texto con tu propio contenido.
Agregar propio contenido con detalles específicos sobre el negocio ayudará a que las personas que buscan lo que
ofreces te puedan encontrar. A continuación se dan algunos consejos de cómo incluir el mejor contenido posible:
 Ser específico. Incluye tus productos, servicios y especialidades.
 Ser original. No copies el texto de otras páginas web.
 Agregar descripciones vívidas de todas tus fotos e imágenes.
 Mantener una página web actualizada.
 Recuerda siempre verificar la ortografía.
¿Cómo elegir las palabras clave?
Al usar Google, las personas teclean las palabras específicas que están buscando. Después Google muestra los
resultados de las páginas web que incluyen esas palabras. Así que antes de empezar el trabajo de SEO haz una lista de
las palabras clave que describen tu negocio, sin incluir el nombre de tu negocio. Descubre cuáles son las palabras más
efectivas para tu negocio abriendo una cuenta con el planeador de palabras clave de Google Adwords.
Por ejemplo, de acuerdo a la búsqueda en Google Adwords search, las palabras clave para la tienda de bicicletas en
Bogotá podrían ser:
 Bicicletas
 Bicicletas híbridas
 Bicicletas de ciudad
 Llantas para bicicletas
 Bicicletas de montañas
¿Qué es un título de página, una descripción, las palabras clave y dónde se puede escribir?
El título y la descripción son las primeras cosas que las personas ven cuando hacen una búsqueda en Google, por lo
tanto son las primeras cosas que la gente lee sobre el negocio. Optimiza el título y la descripción usando las palabras
clave más relevantes con las que una audiciencia buscará tu negocio.
Estos estos pasos se deben seguir para crear un título y una descripción eficientes:
En el sitio de Wix, ve a Inicio, se elige Páginas y se hace clic en SEO. Se verá los campos de título, descripción y
palabras clave. Llenar los campos en cada una de las páginas.
Título del sitio
Crear un título que incluya el nombre del negocio y las palabras clave relevantes. Debe contener hasta 50 caracteres
(incluyendo espacios). Para incluir su ubicación usa una barra vertical ( | ).
Por ejemplo: Bicis Urbanas I Bogotá
Descripción del sitio
La descripción del sitio es el pequeño texto que aparece debajo del título en los listados de Google. Debe contener hasta
155 caracteres y describir lo que los visitantes encontrarán en tu página web.
Por ejemplo: Tienda de bicicletas en Bogotá, con bicis de montaña y de ciudad. Reparaciones rápidas y económicas.
Repuesto.
Palabras clave
Ya se tiene establecidas algunas de las palabras clave para describir el negocio. Ahora se selecciona 10 de ellas y
escribirlas aquí, separadas por una coma.
Figura. Palabras Claves. De la Fuente

¿Qué se debe hacer para que el negocio aparezca en los listados de los directorios locales?
Es importante que se cree una comunicación con los clientes potenciales que viven cerca al negocio. Para eso es importante enlistar,
monitorear y publicar la información del negocio en los listados de búsqueda más populares como Google, Google, Maps, Yelp,
Yahoo, Bing y otros.
La aplicación Site Booster, disponible en el Wix App Market, para darle a la página web la mayor visibilidad posible entre los clientes
cercanos.
ANEXO3
PROCESOS DEL NEGOCIO/FLUJOS DE TRABAJO/MODELANDO LOS PROCESOS DEL NEGOCIO

PROCESOS DEL NEGOCIO
Los procesos del negocio determinan la forma como un conjunto de actividades pueden lograr los objetivos
específicos de una organización describiendo su forma de operar, tomar decisiones y establecer el flujo de la
información necesario entre los participantes del proceso. Cada proceso es motivado por un evento interno o
externo a la organización; se procesa la información de entrada, se manipulan los objetos necesarios, se
toman las decisiones requeridas y se generan la información y los eventos de salida. Los procesos están
restringidos por un conjunto de reglas de negocio, que determinan las políticas y la estructura de la
información del negocio.
Un proceso puede estar compuesto de subprocesos o actividades, reglas del negocio y de flujos de control
(figura 1).
Los procesos del negocio son la base de todo buen desarrollo de software y normalmente se identifican en la
primera fase del proceso. Facilitan la abstracción del problema para construir la solución informática, y su
análisis está orientado a la identificación de los objetivos generales, los requisitos del software, la selección
del tipo de sistema de información y la arquitectura sobre la cual se debe construir el sistema.
El término "Workflow", que se traduce literalmente como "flujo de trabajo", hace referencia a la gestión
modelada y computarizada de todas las tareas que deben llevarse a cabo y de los distintos protagonistas
involucrados en realizar el proceso de negocios (también llamado proceso operativo). También puede
traducirse el término Worflow como gestión electrónica de procesos de negocios.
Un proceso de negocios representa interacciones bajo la forma de un intercambio de información entre los
distintos protagonistas, por ejemplo:
• Personas
• Aplicaciones o servicios
• Procesos de terceros
En la práctica, un Workflow puede describir:
• El circuito de validación.
• Las tareas que deben realizarse entre los distintos participantes de un proceso.
• Los plazos que deben respetarse.
• Los modos de validación.
Además, le proporciona a cada protagonista la información necesaria para que pueda completar su tarea. Por
ejemplo, en el caso de un proceso de publicación en línea, el Workflow da forma a las tareas de la cadena de
edición completa, desde la propuesta del editor hasta la validación de la persona a cargo de la publicación.
En la figura 2 presentan un mapa conceptual de cómo un proceso del negocio puede ser automatizado desde
su definición y su uso en un sistema (motor) administrador de workflow.
Un workflow está compuesto por los siguientes elementos:
1. Ítem. Es una clasificación de un componente que hace parte de un proceso. En otros térmi-nos, es todo
objeto/documento que requiera tramitarse por medio del workflow.
2. Atributos. Son las propiedades que describen cada ítem identificado en el workflow. Por ejemplo, si un
ítem es “Registrar Idea de Negocio”, entonces algunos atributos de ese ítem pueden ser la descripción de
la idea y el sector de negocio.
3. Proceso. Está compuesto de actividades (íconos) y transiciones (líneas de conexión o flechas).
4. Actividad. Es una unidad de trabajo que contribuye a la ejecución de un proceso. Puede ser una
notificación, una función, un evento, un proceso o subproceso.
5. Notificación. Es el resultado de cada actividad dentro del flujo de trabajo, es decir, es la forma de anunciar
los cambios de estado de los objetos del sistema que interesan a los actores del proyecto. Así, en la figura
3 hay varias notificaciones, entre ellas: “Aprueba idea de negocio”.
6. Función. Actividad usada para ejecutar pasos totalmente automatizados en el proceso. Los pasos
automatizados de ordinario los realiza una aplicación transaccional.
7. Evento. Representa un acontecimiento del negocio dentro de un proceso. Un evento puede recibir, atender
o enviar un acontecimiento del negocio.
Las actividades de función y de evento tienen un costo asociado. El costo es un valor que re-presenta el
tiempo (número de segundos) que la actividad tarda en recibir una función, un evento o una notificación
para darle continuidad al flujo. El tiempo es calculado por el motor del workflow.
8. Mensajes. Se refiere a una actividad de notificación asociada a un ítem que puede enviar a un usuario o
rol.
Modelando los Procesos de Negocios
Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto
de procesos de negocio. Cada uno de ellos se caracteriza por una colección de datos que
son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes
(por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo
determinado. Además, estos procesos se hallan sujetos a un conjunto de reglas de negocio,
que determinan las políticas y la estructura de la información de la empresa. Por tanto, la
finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus
datos, actividades (o tareas), roles (o agentes) y reglas de negocio (que determina como se
van a estructurar la información y las políticas de la organización).
Notación del Modelado de Proceso
Un modelo de proceso de negocio típicamente define los siguientes elementos:
Actores o participantes en el proceso
El Objetivo
Las Reglas o pautas del Negocio
Las Entradas específicas
Las Salidas especificas
Los Recursos consumidos
La secuencia de las Actividades; y Los
Eventos que dirigen el proceso El
proceso de negocio:
Puede afectar a más de una unidad organizacional
Tiene un impacto horizontal en la organización
Actores
Los actores pueden ser personas (roles que desempeñan las personas), aparatos eléctricos
o mecánicos, y otros sistemas de cómputo que intervienen en el negocio. Se pueden definir
categorías generales de actores (como cliente en el ejemplo de abajo) y especializarlos
(como ClienteComercial) a través de relaciones de generalización.
Ejemplo:
El Proceso de Negocio
Un proceso de negocio es una colección de actividades diseñadas para producir una salida
específica para un cliente o un mercado en particular. Esto implica un fuerte énfasis en cómo se
realiza el trabajo dentro de una organización, en contraposición con un enfoque del producto en
qué se produce. Por lo tanto, el proceso es una secuencia específica de actividades de trabajo
a través del tiempo y del espacio, con un inicio, un final y unas entradas y salidas claramente
definidas: una estructura para la acción.
A continuación se dibuja la notación que se utiliza para indicar un proceso de negocio:
La notación de proceso implica un flujo de actividades de izquierda a derecha. Un

elemento de evento típicamente se ubica a la izquierda del proceso y la salida a la
derecha.
Objetivo (goal)
Un proceso de negocio tiene algún objetivo bien definido. Esta es la razón por la que la
organización realiza su trabajo y se debería definir en términos de los beneficios que este
proceso tiene para la organización como un todo y para satisfacer sus necesidades de
negocio.
Un conector ―goal‖ indica que el objeto adjunto al proceso describe el objetivo del proceso. Un
objetivo es la justificación para llevar a cabo la actividad.
Reglas o pautas del Negocio
En una organización, tanto los procesos como los datos que estos manejan, están
restringidos por las reglas del negocio. Estas reglas aseguran que la actividad de la empresa
se lleva a cabo de acuerdo a restricciones impuestas desde el entorno (leyes o normas) o
desde dentro de la propia organización.
Las reglas de negocio deben ser:
1. Reglas de Flujo. Estas reglas determinan y delimitan como fluye la información a través del
proceso. Generalmente asociadas a la aceptación o rechazo de un trámite. Ejemplo: Si el
valor del servicio académico no supera un salario mínimo y el pago es con tarjeta débito o
crédito se recibe en caja, caso contrario, se debe hacer una consignación
2. Reglas de Operación: Se debe establecer las condiciones para realizar la operación. Puede
asociarse a precondiciones y postcondiciones (antes y después de la operación). A
continuación se presenta Reglas de operación mediante una tabla diseñada por el profesor.
DESCRIPCIÓN DE LA REGLA
CRITERIOS DE VALIDACIÓN
Nombre de la Descripción
regla de la
ID Regla Elementos Objetos de Atributo Operador Objetos de Atributo Operador Condición
negocio Lógico negocio (AND/OR)
Servicio
Académico
Condición Cuenta Saldo > Valor Precondición
Valor servicio
Realizar un Se debe
académico
pago con verificar si el Condición menor a un
tarjeta debito saldo es
mayor al salario mínimo
valor del
servicio Qué hacer
académico
R1 con el
Resultado Si se Acciones Imprimir Recibo Post
de la presenta Condición
Evaluación
de las Se puede
Condiciones realizar el
Si no se Acciones servicio
presenta académico
Un conector ―regla‖ indica que el objeto adjunto al proceso descríbe las reglas del
negocio aplicadas
Entradas, Recursos e Información
Los procesos de negocio emplean información para adaptar o completar sus actividades. La
información, a diferencia de los recursos, no se consume en los procesos, sino que se usa
como parte del proceso de transformación. La información puede provenir de fuentes externas,
de los clientes, de las unidades organizacionales internas e inclusive puede ser el producto de
otros procesos.
Un recurso es una entrada para un proceso de negocio y, a diferencia de la información,
típicamente se consume durante el procesamiento. Por ejemplo, a medida que cada servicio
diario de tren sale y registran las novedades, el recurso servicio se usa tanto como concierna
al proceso de registración de novedades de tiempos de los trenes.
A continuación se muestra la notación para ilustrar la información y los recursos:
El conector ―supply‖ indica que la información u objeto conectado al proceso no se gasta en la

fase de procesamiento. Por ejemplo, las plantillas de la orden se pueden usar una y otra vez
para proveer nuevas órdenes de un cierto estilo -las plantillas no se gastan ni se alteran
durante esta actividad.
Un conector ―input‖ destaca que el objeto o recurso conectado se consume durante el
procesamiento. Por ejemplo, a medida que las órdenes de servicio se procesan, ellas se
completan y se firman y típicamente se utilizan sólo una sola vez por cada recurso único
(orden).
Eventos
Un evento es la recepción de algún objeto, un momento o fecha cumplidos, una notificación
o cualquier otro disparador que inicie un proceso de negocio. El evento se puede consumir y
transformar (por ejemplo una orden de cliente) o simplemente actuar como un catalizador
(por ejemplo, el proceso en lote nocturno).
Salidas
Un proceso de negocio típicamente producirá una o más salidas de valor para el negocio, para
uso interno o para satisfacer requisitos externos. Una salida puede ser un objeto físico (tal
como un informe o una factura), una transformación de recursos crudos con un nuevo
ordenamiento (una agenda diaria) o un resultado final de un proceso tal como completar una
solicitud de cliente.
Una salida de un proceso de negocio puede alimentar a otro, como un ítem requerido o como
un disparador para iniciar nuevas actividades.
Un conector ―output‖ indica que el proceso de negocio produce algún objeto (físico o lógico)
que es de valor para la organización, como un ítem externamente visible o como un producto
interno (posiblemente alimentando otro proceso).
Juntando las piezas

El diagrama siguiente ilustra cómo los diferentes elementos del modelo se pueden
agrupar para producir una vista coherente de un proceso de negocio determinado.
Están incluidos las entradas, las salidas, los eventos, los objetivos y otros recursos que
son significativos.
Un Ejemplo
El siguiente es un ejemplo del tipo de modelo que se puede construir para
representar un modelo de negocio. El objetivo del proceso de negocio es tomar las
órdenes de los clientes (Order) y despacharlas (Deliver Order). Un usuario comienza
el proceso con una solicitud (User Enquiry) que involucra al catálogo de libros (Book
Catalogue), al carro de compras (Shopping Cart), a las páginas en línea (On-line
Pages) y al inventario del almacén (Warehouse Inventory). La salida de valor de este
proceso es una orden de cliente (Order).
La segunda parte del modelo de proceso está para responder a una orden de
cliente y para despachar los ítems requeridos. Este proceso involucra el
inventario, la empresa distribuidora y se completa cuando la orden se entrega al
cliente.
ANEXO4 MODELAMIENTO DE UN SISTEMA
Introducción
Una de las principales capacidades que debe poseer un Ingenierio Informático es la habilidad de
modelar sistemas. Estos sistemas suelen ser fundamentalmente empresas aunque también deberán ser
capaces de modelar aplicaciones software, dispositivos hardware, procesos de producción, etc. El
ingeniero informático domina y utiliza un conjunto de metodologías de los Sistemas de Información y de la
Ingeniería del Software, como también modelos de desarrollo, que usa para conocer el comportamiento de
los sistemas (de información o software) con el que se enfrenta, entender lo que el cliente le desea
transmitir, lograr una especificación clara de los requerimientos del software, de arquitectura etc.
Es pues, el modelado una actividad frecuente en el ingeniero informático y debe éste ser
consciente de los procesos y entidades que entran en juego cuando esta modelando.
La necesidad de modelar
A grandes rasgos, el ingeniero informático necesita modelar por,
- Simplificar la realidad consiguiendo una mejor comprensión de la misma.
- Dividir el sistema en subsistemas para observar como interactúan sus diferentes partes.
- El diseño de software de un sistema bien modelado es mucho más sencillo de desarrollar y
mantener.
- Adquirir y comprender todos los requerimientos que el cliente le exige al software.
Todo el conocimiento humano se estructura bajo infinidad de modelos, pero el ingeniero informático
debe tener la capacidad de simplificar estos modelos y ser capaz de expresarlos en ―el papel‖ y aplicarlos
en el desarrollo del software.
Los tres mundos
Si se propone como ejercicio el modelar como cocinar un arroz, al principio se puede pensar que es
fácil de hacer, pero después se reflexiona, sobre ello surgen mil y una duda de cómo hacerlo, tales como:
qué tipo de arroz, margarina o aceite, condimentos (cebolla o ajo), agua, etc. Esto hace reflexionar lo difícil
que es modelar hasta los sistemas más simples y que es imposible modelar un sistema contemplando
todos los casos. Además la concepción del sistema para cada ingeniero informático es diferente y esto
hará que cada uno genere modelos diferentes.
El ingenieiro informático (analista), en su tarea de modelar debe ser consciente de los tres mundos
en los que debe ―vivir y trabajar‖. En primer lugar, está el MUNDO 1, este es el mundo que le rodea y que
debe modelar, es un mundo complejo con infinidad de subsistemas relacionados entre sí (no isolados). De
este mundo el informático estará interesado en un segmento del mismo, normalmente, la EMPRESA.
Por otro lado está el MUNDO 3, el mundo ―del saber humano‖ o de los modelos. Y en medio de los
dos mundos, el MUNDO 2, que es el ingeniero informático con sus órganos sensoriales y de percepción,
su experiencia, su conocimiento, etc.
Además, el ingenieiro informático vive en el mundo 1, luego en cierta manera, en el mundo 2 está
inmerso dentro del mundo 1.
Las acciones fundamentales que hace el ingenieiro informático para modelar son:
- Observar el mundo 1.
- Extraer casos, peculiaridades (proceso de inducción).
- Exportarlas al mundo 3.
- Verificación del modelo
Inducción y deducción. Circulo mayéutico
En el arte de crear modelos participan los procesos de inducción y deducción. La inducción se
refiere a la capacidad generalizar, observando multitud de casos el informático es capaz crear un modelo.
Y en el proceso de deducción el ingenieiro informático utiliza el modelo para obtener nuevos casos
específicos.
Estos procesos de inducción/deducción se engloban dentro lo que se llama circulo mayéutico.

Isomorfía e Isolación
Aunque muchos autores los confundan hay que tener claro la diferencia entre los mundos 1 y 3.
Estos mundos no son isomorfos entre sí, es decir, no existe una correspondencia entre ambos. Además
el mundo 3 no se crea a partir del mundo 1 sino que depende de la percepción del sujeto en el mundo 2.
Así, por ejemplo, si estamos modelando en Diseño Orientado a Objetos el comportamiento de una
puerta no podemos hablar directamente que la puerta tiene un número de propiedades (alto, ancho, etc.) y
de métodos (abrir, cerrar) sino que el modelo que creamos va a tener estos métodos y propiedades.
Otro concepto importante es el de isolación: que se refiere al grado de separación/relación de los
diferentes subsistemas. En el mundo 1 no existen sistemas naturales isolados (solo existen sistemas
abiertos), en cambio en el mundo 3 la conexión entre entidades es mucho menor.
Por ejemplo, si una empresa/organización/comunidad en el mundo 1 tiene varias relaciones con el
entorno, además, de ser verdaderamente difícil de identificar los límites o fronteras de las mismas. En
cambio, la empresa/organización/comunidad modelada en mundo 2 tiene sus fronteras mejor delimitadas y
sus interacciones con las entidades externas claramente definidas. Como podemos ver en el siguiente
modelo de Diagrama de Contexto.
Modelos de referencia
Dentro del mundo 2, es útil para el ingenieiro informático reconocer y utilizar entre todos los
modelos que lo forman aquellos que le sirvan de referencia para crear nuevos modelos. El proceso se
indica en el siguiente esquema:
El ingeniero informático observa el mundo 1 (usando sus sentidos de percepción de manera

empírica) y por el otro lado está el mundo 3 (activación del saber de manera racional) considerado los dos
mundos, el ingeniero informático debe ser capaz, de encontrar similitudes entre los subsistemas que esta
analizando y los modelos que ya existen en el mundo 3.
Como ejemplo de lo que quiero decir imaginemos que el ingeniero informático necesita realizar un
software de gestión de facturas para una empresa que tiene clientes a los que emite ordenes (facturas)
que esta formado por líneas que hacen referencia a productos. El modelo entidad de datos que crea e l
ingeniero informático en el mundo 2 podría ser:
Como desarrolló un buen software, el ingeniero informático sigue trabajando y después de un año
la empresa/organización/comunidad necesita ampliar el software para gestionar las ordenes de los
proveedores. El ingeniero informático, entonces, en lugar de crear un modelo nuevo exclusivamente desde
el mundo 1 podría usar del mundo 3 el modelo de entidad de datos anterior para crear el nuevo debido a
su similitud.
Con el ejemplo anterior, entonces que es mejor aquel ingeniero informático con mayor experiencia,
pues tendrá mayor número de modelos de referencia para aplicar en diferentes situaciones. Esto es así,
pero el ingenieiro informático experto debe ser consciente de los modelos de referencia que aplica, usar
por inercia o de manera inconsciente un modelo de referencia puede hacer que el modelo creado pierda
peculiaridades importantes del sistema que no se pueden obviar.
Un informático experto tiende a ver la empresa de manera general, comparando sus subsistemas y
modelos a los subsistemas y modelos de otras empresas que ya ha estudiado. En cambio, un ingenieiro
informático junior al no tener experiencia tenderá a considerar las peculiaridades de la empresa y le será
más difícil crear modelos generales que se adapten a ella.
Modelos de empresa
El principal sistema donde trabaja el ingenieiro informático es en la
empresa/organización/comunidad. Es por tanto importante conocer las diferentes teorías de como se
estructuran y organizan.
Muy básicamente podemos tener dos visiones sobre la empresa/organización/comunidad, una
horizontal y otra vertical:
Al ingenieiro informático le interesará mas fijarse en una visión horizontal de la empresa, en

especial como el flujo de información desde que una solicitud entra en la empresa hasta que tiene su
respuesta hacia el exterior en lo que se llama los Business Process Reengineering (BPR).
Valor Añadido. Un nuevo valor para el informático
Un ingeniero informático debe conocer en gran medida la actividad del negocio de la empresa, no
sólo porque es necesario para poder realizar su tarea de informático analizando la
empresa/organización/comunidad y desarrollando software para ella, sino como un medio para ser
aceptado por el resto de trabajadores de la misma, y dejar de ser ―el informático‖ para ser ―algo más‖. Lo
que se propone es dar un salto cualitativo y añadir a la figura de ingeniero informático un nuevo valor; el
valor de no sólo ser informático sino además conocer el sector de mercado de la empresa y aportar ideas,
proyectos, soluciones en este ámbito.
ANEXO5. DIAGRAMUML
FLUJOS DE TRABAJO (WORKFLOWS)
DIAGRAMAS UML
Un Diagrama es una representación gráfica de una colección de elementos de modelado, a menudo
dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un
diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos
semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados.
Un diagrama está contenido dentro de un paquete.
La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas
conectadas por rutas. La información está sobre todo en la topología, no en el tamaño o la colocación
de los símbolos (hay algunas excepciones como el diagrama de secuencia con un eje métrico de
tiempo). Hay tres clases importantes de relaciones visuales: conexión (generalmente de líneas a formas
de dos dimensiones), contención (de símbolos por formas cerradas de dos dimensiones), y adhesión
visual (un símbolo que está "cerca" de otro en un diagrama). Estas relaciones geométricas se re
asignan a conexiones entre nodos en un gráfico en la forma analizada de la notación.
La notación de UML está pensada para ser dibujada en superficies bidimensionales. Algunas formas
bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se
representan como íconos en una superficie bidimensional.
Hay cuatro clases de construcciones gráficas que se usan en la notación de UML: íconos, símbolos
bidimensionales, rutas y cadenas.
Un ícono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a su contenido.
Los iconos pueden aparecer dentro de símbolos de área, como terminadores en las rutas o como
símbolos independientes que puedan o no conectar con las rutas.
Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir
otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos están divididos en
compartimientos similares o de tipos diferentes. Las rutas se conectan con los símbolos, el arrastrar o
suprimir uno de ellos afecta a su contenido y las rutas conectadas.
Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales.
Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular
gráficamente. Un segmento no debería existir separado de su ruta. Las rutas siempre van conectadas
en ambos extremos.
Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que
cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser analizada la información
del modelo subyacente. Las cadenas pueden existir como el contenido de un compartimiento, como
elementos en las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos
independientes en un diagrama.
UML está compuesto por los siguientes diagramas:
Área Vista Diagramas Conceptos Principales
Clase, asociación, generalización,

Vista Estática Diagrama de Clases
dependencia, realización, interfaz.
Vista de Casos de Diagramas de Casos Caso de Uso, Actor, asociación,

Uso de Uso extensión, generalización.
Estructura
Vista de Diagramas de Componente, interfaz, dependencia,

Implementación Componentes realización.
Diagramas de Nodo, componente, dependencia,

Vista de Despliegue
Despliegue localización.
Vista de Estados de Diagramas de

Estado, evento, transición, acción.
máquina Estados
Diagramas de Estado, actividad, transición,

Vista de actividad
Actividad determinación, división, unión.
Comportamiento
Diagramas de
Interacción, objeto, mensaje, activación.
Secuencia
Vista de interacción
Diagramas de Colaboración, interacción, rol de

Colaboración colaboración, mensaje.
Administración o Gestión Vista de Gestión de Diagramas de

Paquete, subsistema, modelo.
de modelo modelo Clases
Restricción, estereotipo, valores,

Extensión de UML Todas Todos
etiquetados.
DIAGRAMAS DE ESTRUCTURA
VISTA ESTATICA
Diagramas de Objetos
Objeto es una entidad discreta con límites bien definidos y con identidad, es una unidad atómica que
encapsula estado y comportamiento. La encapsulación en un objeto permite una alta cohesión y un bajo
acoplamiento. El Objeto es reconocido también como una instancia de la clase a la cual pertenece.
La encapsulación presenta tres ventajas básicas:
1. Se protegen los datos de accesos indebidos

2. El acoplamiento entre las clases se disminuye
3. Favorece la modularidad y el mantenimiento
Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de un determinado
instante de tiempo que posee un valor específico (Un objeto puede caracterizar una entidad física -coche-)
y como un poseedor de identidad que tiene distintos valores a lo largo del tiempo (abstracta -ecuación
matemática-).
Cada objeto posee su propia identidad exclusiva y se puede hacer referencia a él mediante una
denominación exclusiva que permite accederle. El Modelado de Objetos permite representar el ciclo de
vida de los objetos a través de sus interacciones. En UML, un objeto se representa por un rectángulo con
un nombre subrayado.
 Objeto = Identidad + Estado + Comportamiento

 El estado está representado por los valores de los atributos.
 Un atributo toma un valor en un dominio concreto.
La regla general para la notación de instancias consiste en utilizar el mismo símbolo geométrico que el
descriptor. En la instancia se muestran los posibles valores pero las propiedades compartidas sólo se
ponen de manifiesto en el descriptor. La notación canónica es un rectángulo con tres compartimientos. En
el primero va el nombre del objeto, en el segundo sus atributos y en el tercero sus operaciones. Este
último puede ser omitido si así se prefiere.
Oid (Object Identifier)
Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes características:
 Constituye un identificador único y global para cada objeto dentro del sistema.
 Es determinado en el momento de la creación del objeto.
 Es independiente de la localización física del objeto, es decir, provee completa independencia de
localización.
 Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de
estructura.
 No cambia durante toda la vida del objeto. Además, un oid no se reutiliza aunque el objeto deje de
existir.
No se tiene ningún control sobre los oids y su manipulación resulta transparente. Sin embargo, es preciso
contar con algún medio para hacer referencia a un objeto utilizando referencias del dominio (valores de
atributos).
Características alrededor de un objeto:

Estado:
El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento agrupa
las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las operaciones de un
objeto son consecuencia de un estímulo externo representado como mensaje enviado desde otro objeto.
Persistencia:
La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo,

podremos después reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecución
(materialización del objeto). Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual
debería ser transparente, un objeto existe desde su creación hasta que se destruya.
Comunicación:
Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que trabajan
de manera coordinada en la consecución de un fin específico. El comportamiento global se basa pues en
la comunicación entre los objetos que la componen.
Categorías de objetos:
 Activos o Pasivos
 Cliente -- Servidores, Agentes
1. Objeto Activo: posee un hilo de ejecución (thread) propio y puede iniciar una actividad.
2. Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos una vez que se le
solicita un servicio.
3. Cliente es el objeto que solicita un servicio.
4. Servidor es el objeto que provee el servicio solicitado.
5. Los agentes reúnen las características de clientes y servidores. Son la base del mecanismo de
delegación. Introducen indirección: un cliente puede comunicarse con un servidor que no conoce
directamente.
Mensajes:
La unidad de comunicación entre objetos se llama mensaje. El mensaje es el soporte de una comunicación
que vincula dinámicamente los objetos que fueron separados previamente en el proceso de
descomposición. Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinámico. Un
estímulo causará la invocación de una operación, la creación o destrucción de un objeto o la aparición de
una señal. Un mensaje es la especificación de un estímulo.
Tipos de flujo de control:
1. Llamada a procedimiento o flujo de control anidado

2. Flujo de control plano
3. Retorno de una llamada a procedimiento
4. Otras variaciones
5. Esperado (balking)
6. Cronometrado (time-out)
Diagrama de Objetos
Diagramas de Clases
El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta
las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye
definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer
las clases, objetos, atributos y operaciones.
El mundo real puede ser visto desde abstracciones diferentes (subjetividad)
Mecanismos de abstracción:
1. Clasificación / Instanciación
2. Composición / Descomposición
3. Agrupación / Individualización
4. Especialización / Generalización
La clasificación es uno de los mecanismos de abstracción más utilizados. La clase define el ámbito de
definición de un conjunto de objetos, y cada objeto pertenece a una clase, Los objetos se crean por
instanciación de las clases.
Cada clase se representa en un rectángulo con tres compartimientos:
 nombre de la clase
 atributos de la clase
 operaciones de la clase
Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta
razón se crearon niveles de visibilidad para los elementos que son:
 (-) Privado: es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en
terminología C++)
 (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases
derivadas de la original.
 (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se
está transgrediendo el principio de encapsulación)
Relaciones entre clases:
Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relación son:
 Asociación y Agregación (vista como un caso particular de asociación)

 Generalización/Especialización.
Las relaciones de Agregación y Generalización forman jerarquías de clases.

Asociación:
La asociación expresa una conexión bidireccional entre objetos. Una asociación es una abstracción de la
relación existente en los enlaces entre los objetos. Puede determinarse por la especificación de
multiplicidad (mínima...máxima)
 Uno y sólo uno

 0..1 Cero o uno
 M…N Desde M hasta N (enteros naturales)
 * Cero o muchos
 0..* Cero o muchos
 1..* Uno o muchos (al menos uno)
Agregación:
La agregación representa una relación parte_de entre objetos. En UML se proporciona una escasa
caracterización de la agregación. Esta relación puede ser caracterizada con precisión determinando las
relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos
componentes.
Una agregación se podría caracterizar según:

Puede el objeto parte comunicarse directamente con objetos externos al objeto agregado?
No => inclusiva
Si => no inclusiva
Puede cambiar La composición del objeto agregado?
Si => dinámica
No => estática
Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un
Diagrama de Clases muestra la abstracción de una parte del dominio. Un Diagrama de Objetos representa
una situación concreta del dominio. Las clases abstractas no son instanciadas.
Generalización:
Permite gestionar la complejidad mediante un ordenamiento taxonómico de clases, se obtiene usando los
mecanismos de abstracción de Generalización y/o Especialización. La Generalización consiste en
factorizar las propiedades comunes de un conjunto de clases en una clase más general. Los nombres
usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada. Las
subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de
la clase padre están disponibles en sus clases hijas. La Generalización y Especialización son equivalentes
en cuanto al resultado: la jerarquía y herencia establecidas. Generalización y Especialización no son
operaciones reflexivas ni simétricas pero sí transitivas. La especialización es una técnica muy eficaz para
la extensión y reutilización.
La noción de clase está próxima a la de conjunto. Dada una clase, podemos ver el conjunto relativo a las
instancias que posee o bien relativo a las propiedades de la clase. Generalización y especialización
expresan relaciones de inclusión entre conjuntos
Diagrama de Clases
Ejemplo de Diagrama de Clases

VISTA CASOS DE USO
Diagramas de Caso de Uso
Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo
se desea que trabaje. No pertenece estrictamente al enfoque orientado a objeto, es una técnica para
captura de requisitos.
 Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el p.d.v. del usuario.
 Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.
 Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la
implementación.
 Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado.
 Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a
la determinación de requisitos.
 Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios
que participan en el mismo.
 Están basados en el lenguaje natural, es decir, es accesible por los usuarios.
Actores
 Principales: personas que usan el sistema.

 Secundarios: personas que mantienen o administran el sistema.
 Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la
aplicación y deben ser utilizados.
 Otros sistemas: sistemas con los que el sistema interactúa.
La misma persona física puede interpretar varios papeles como actores distintos, el nombre del actor
describe el papel desempeñado.
Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción,
los escenarios, desde el punto de vista del usuario. Los casos de uso intervienen durante todo el ciclo de
vida. El proceso de desarrollo estará dirigido por los casos de uso. Un escenario es una instancia de un
caso de uso.
UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
 Comunicación
 Inclusión: una instancia del Caso de Uso origen incluye también el comportamiento descrito por
el Caso de Uso destino. «include» reemplazó al denominado «uses»
 Extensión: el Caso de Uso origen extiende el comportamiento del Caso de Uso destino.
«extend»
 Herencia: el Caso de Uso origen hereda la especificación del Caso de Uso destino y
posiblemente la modifica y/o amplía.
Parámetros para la construcción de un caso de uso:
Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a
cada Caso de Uso. Preguntas clave:
1. cuáles son las tareas del actor?

2. qué información crea, guarda, modifica, destruye o lee el actor?
3. debe el actor notificar al sistema los cambios externos?
4. debe el sistema informar al actor de los cambios internos?
La descripción del Caso de Uso comprende:
1. el inicio: cuándo y qué actor lo produce?

2. el fin: cuándo se produce y qué valor devuelve?
3. la interacción actor-caso de uso: qué mensajes intercambian ambos?
4. objetivo del caso de uso: qué lleva a cabo o intenta?
5. cronología y origen de las interacciones
6. repeticiones de comportamiento: qué operaciones son iteradas?
7. situaciones opcionales: qué ejecuciones alternativas se presentan en el caso de uso?
Diagrama de Caso de Uso

VISTA DE IMPLEMENTACION
Diagramas de Componentes
Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones. Muestran las
opciones de realización incluyendo código fuente, binario y ejecutable. Los componentes representan
todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden
ser simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Las relaciones de
dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los
servicios ofrecidos por otro componente.
Un diagrama de componentes representa las dependencias entre componentes software, incluyendo

componentes de código fuente, componentes del código binario, y componentes ejecutables. Un módulo
de software se puede representar como componente. Algunos componentes existen en tiempo de
compilación, algunos en tiempo de enlace y algunos en tiempo de ejecución, otros en varias de éstas.
Un componente de sólo compilación es aquel que es significativo únicamente en tiempo de compilación.
Un componente ejecutable es un programa ejecutable.
Un diagrama de componentes tiene sólo una versión con descriptores, no tiene versión con instancias.
Para mostrar las instancias de los componentes se debe usar un diagrama de despliegue.
Un diagrama de componentes muestra clasificadores de componentes, las clases definidas en ellos, y las
relaciones entre ellas. Los clasificadores de componentes también se pueden anidar dentro de otros
clasificadores de componentes para mostrar relaciones de definición.
Un diagrama que contiene clasificadores de componentes y de nodo se puede utilizar para mostrar las
dependencias del compilador, que se representa como flechas con líneas discontinuas (dependencias) de
un componente cliente a un componente proveedor del que depende. Los tipos de dependencias son
específicos del lenguaje y se pueden representar como estereotipos de las dependencias.
El diagrama también puede usarse para mostrar interfaces y las dependencias de llamada entre
componentes, usando flechas con líneas discontinuas desde los componentes a las interfaces de otros
componentes.
El diagrama de componente hace parte de la vista física de un sistema, la cual modela la estructura de
implementación de la aplicación por sí misma, su organización en componentes y su despliegue en nodos
de ejecución. Esta vista proporciona la oportunidad de establecer correspondecias entre las clases y los
componentes de implementación y nodos. La vista de implementación se representa con los diagramas de
componentes.
Diagrama de Componentes
Qué es Componente?
Es una parte física reemplazable de un sistema que empaqueta su implementación y es conforme a un

conjunto de interfaces a las que proporciona su realización.
Algunos componentes tienen identidad y pueden poseer entidades físicas, que incluyen objetos en tiempo
de ejecución, documentos, bases de datos, etc. Los componentes existentes en el dominio de la
implementación son unidades físicas en los computadores que se pueden conectar con otros
componentes, sustituir, trasladar, archivar, etc.
Los componentes tienen dos características: Empaquetan el código que implementa la funcionalidad de un
sistema, y algunas de sus propias instancias de objetos que constituyen el estado del sistema. Los
llamados últimos componentes de la identidad, porque sus instancias poseen identidad y estado.
Código:
Un componente contiene el código para las clases de implementación y otros elementos. Un componente
de código fuente es un paquete para el código fuente de las clases de implementación. Algunos lenguajes
de programación distinguen archivos de declaración de los archivos de método, pero todos son
componentes. Un componente de código binario es un paquete para el código compilado. Una biblioteca
del código binario es un componente.
Cada tipo de componente contiene el código para las clases de implementación que realizan algunas
clases e interfaces lógicas. La relación de realización asocia un componente con las clases y las interfaces
lógicas que implementan sus clases de implementación. Las interfaces de un componente describen la
funcionalidad que aporta. Cada operación de la interfaz debe hacer referencia eventualmente a un
elemento de la implementación disponible en el componente.
La estructura estática, ejecutable de una implementación de un sistema se puede representar como un
conjunto interconectado de componentes. Las dependencias entre componentes significan que los
elementos de la implementación en un componente requieren los serivios de los elementos de
implemntación en otros componentes. Tal uso requiere que dichos elementos sean de visibilidad pública.
Identidad:
Un componente de identidad tiene identidad y estado. Posee los objetos físicos que están situados en él.
Puede tener atributos, relaciones de composición con los objetos poseídos, y asociaciones con otros
componentes. Desde este punto de vista es una clase. Sin embargo la totalidad de su estado debe hacer
referencia a las instancias que contiene.
Estructura:
Un componente ofrece un conjunto de elementos de implementación, esto significa que el componente
proporciona el código para los elementos. Un componente puede tener operaciones e interfaces. Un
componente de identidad es un contenedor físico para las entidades físicas como bases de datos. Para
proporcionar manejadores para sus elementos contenidos, puede tener atributos y asociaciones salientes,
que deben ser implementadas por sus elementos de implementación. Este componente se representa con
un rectángulo con dos rectángulos más pequeños que sobresalen en su lado izquierdo.
Las operaciones e interfaces disponibles para los objetos exteriores se pueden representar directamente
en el símbolo de clase. Estos son su comportamiento como clase. Los contenidos del subsistema se
representan en un diagrama separado.
Las dependencias de un componente con otros componentes o elementos del modelo se representan
usando líneas discontinuas con la punta de flecha hacia los elementos del proveedor. Sí un componente
es la realización de una interfaz, se representa con un círculo unido al símbolo del componente por un
segmento de línea.
Paquetes
Cualquier sistema grande se debe dividir en unidades más pequeñas, de modo que las personas
puedan trabajar con una cantidad de información limitada, a la vez y de modo que los equipos de
trabajo no interfieran con el trabajo de los otros.
Un paquete es una parte de un modelo. Cada parte del modelo debe pertenecer a un paquete. Pero
para ser funcional, la asignación debe seguir un cierto principio racional, tal como funcionalidad
común, implementación relacionada y punto de vista común. UML no impone una regla para
componer los paquetes.
Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando
elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema).
Los paquetes son unidades de organización jerárquica de uso general de los modelos de UML. Pueden
ser utilizados para el almacenamiento, el control de acceso, la gestión de la configuración y la construcción
de bibliotecas que contengan fragmentos reutilizables del modelo.
Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a
(está definido en) sólo un paquete.
Los paquetes contienen elementos del modelo al más alto nivel, tales como clases y sus relaciones,
máquinas de estado, diagramas de casos de uso, interacciones y colaboraciones; atributos, operaciones,
estados, líneas de vida y mensajes están contenidos en otros elementos y no aparecen como contenido
directo de los paquetes.
Dependencias en los paquetes
Las dependencias que se presentan entre elementos individuales, pero en un sistema de cualquier
tamaño, deben ser vistas en un nivel más alto. las dependencias entre paquetes resumen dependencias
entre los elementos internos a ellos, es decir, las dependencias del paquete son derivables a partir de las
dependencias entre los elementos individuales.
La presencia de una dependencia entre paquetes implica que existe en un enfoque ascendente (una
declaración de existencia), o que se permite que exista más adelante en un enfoque descendente (una
restricción que limita cualquier otra relación), por lo menos un elemento de relación con el tipo de
dependencia indicado entre elementos individuales dentro de los paquetes correspondientes.
Las dependencias múltiples del mismo tipo entre elementos individuales se agregan a una sola
dependencia entre los paquetes que contienen los elementos. Si las dependencias entre elementos
contienen estereotipos, éste puede ser omitido en la dependencia del paquete, para dar una sola
dependencia de alto nivel.
VISTA DE DESPLIEGUE
Diagramas de Despliegue
Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que componen un
sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la
disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces
de comunicación. Un nodo es un recurso de ejecución tal como un computador, un dispositivo o memoria.
Los estereotipos permiten precisar la naturaleza del equipo:
 Dispositivos
 Procesadores
 Memoria
Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse.
Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos. Las
instancias de los nodos pueden contener instancias de ejecución, como instancias de componentes y
objetos. El modelo puede mostrar dependencias entre las instancias y sus interfaces, y también
modelar la migración de entidades entre nodos u otros contenedores.
Esta vista tiene una forma de descriptor y otra de instancia. La forma de instancia muestra la
localización de las instancias de los componentes específicos en instancias específicas del nodo
como parte de una configuración del sistema. La forma de descriptor muestra qué tipo de
componentes pueden subsistir en qué tipos de nodos y qué tipo de nodos se pueden conectar, de
forma similar a un diagrama de clases, esta forma es menos común que la primera.
DIAGRAMAS DE COMPORTAMIENTO
VISTA DE MAQUINA DE ESTADOS
Diagrama de Estado
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con
los cambios que permiten pasar de un estado a otro.
Los Diagramas de Estado representan autómatas de estados finitos, desde el p.d.v. de los estados y las
transiciones. Son útiles sólo para los objetos con un comportamiento significativo. Cada objeto está en un
estado en cierto instante. El estado está caracterizado parcialmente por los valores algunos de los
atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto
sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de
Estados y escenarios son complementarios, los Diagramas de Estados son autómatas jerárquicos que
permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y
deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de un evento.
Estado
Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna
operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se representa
mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el
nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones
que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente
Eventos
Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede
ser una de varias cosas:
 Condición que toma el valor de verdadero o falso

 Recepción de una señal de otro objeto en el modelo
 Recepción de un mensaje
 Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular
El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase
que lo nombre.
Envío de mensajes
Además de mostrar y transición de estados por medio de eventos, puede representarse el momento en el
cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al diagrama
de estados del objeto receptor del mensaje.
Transición simple
Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado
puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas
condiciones son satisfechas. Se representa como una línea sólida entre dos estados, que puede venir
acompañada de un texto con el siguiente formato:
event-signature "[" guard-condition] "/" action-expression "^"send-clause
event-signature es la descripción del evento que da lugar la transición, guard-condition son las
condiciones adicionales al evento necesarias para que la transición ocurra, action-expression es un
mensaje al objeto o a otro objeto que se ejecuta como resultado de la transición y el cambio de estado y
send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envío de
eventos a otros paquetes o clases.
Transición interna
Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos.
Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el
compartimiento de acciones del estado.
Acciones:
Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede
especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la
ocurrencia de un evento
Generalización de Estados:
Podemos reducir la complejidad de estos
 diagramas usando la generalización de estados.
 Distinguimos así entre superestado y subestados.
 Un estado puede contener varios subestados disjuntos.
 Los subestados heredan las variables de estado y las transiciones externas.
 La agregación de estados es la composición de un estado a partir de varios estados
independientes.
La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los
subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata
alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado
asociado, no el fin del objeto.
Subestados
Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel
superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen
conectados a las entradas y salidas del nivel inmediatamente superior.
Transacción Compleja
Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples
destinos. Representa la subdivisión en threads del control del objeto o una sincronización. Se representa
como una línea vertical de la cual salen o entran varias líneas de transición de estado.
Transición a estados anidados
Una transición de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al
estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como
transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).
Transiciones temporizadas
 Las esperas son actividades que tienen asociada cierta duración.
 La actividad de espera se interrumpe cuando el evento esperado tiene lugar.
 Este evento desencadena una transición que permite salir del estado que alberga la actividad de
espera. El flujo de control se transmite entonces a otro estado.
Diagrama de Estado
Ejemplo de Diagrama de Estado

VISTA DE ACTIVIDADES
Diagrama de Actividades
El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de las
acciones y usado para especificar:
 Un método
 Un caso de uso
Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una
operación. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Los
grafos de actividades se muestran en diagramas de actividades. Las actividades se enlazan por
transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente
actividad.
Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la
ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. Los parámetros de
entrada y salida de una acción se pueden mostrar usando las relaciones de flujo que conectan la
acción y un estado de flujo de objeto.
 Un proceso de negocio (Workflow)
Un grafo de actividades contiene estados de actividad que representa la ejecución de una secuencia en un
procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En vez de esperar un evento,
como en un estado de espera normal, un estado de actividad espera la terminación de su cómputo.
Cuando la actividad termina, entonces la ejecución procede al siguiente estado de actividad dentro del
diagrama. una transición de terminación es activada en un diagrama de actividades cuando se completa la
actividad precedente. Los estados de actividad no tienen transiciones con eventos explícitos, peor pueden
ser abortados por transiciones en estados que los incluyen.
Un grafo de actividades puede contener también estados de acción, que son similares a los de actividad
pero son atómicos y no permiten transiciones mientras están activos. Los estados de acción se deben
utilizar para las operaciones cortas de mantenimiento.
Un diagrama de actividades puede contener bifurcaciones, así como divisiones de control en hilos
concurrentes. los hilos concurrentes representan actividades que se pueden realizar concurrentemente por
los diversos objetos o personas. La concurrencia se representa a partir de la agregación, en la cual cada
objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultáneamente o en
cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que permite el
control de concurrencia además del control secuencial.
Notación
Un estado de actividad se representa como una caja con los extremos redondeados que contiene una
descripción de actividad. Las transacciones simples de terminación se muestran como flechas. Las ramas
se muestran como condiciones de guarda en transiciones o como diamantes con múltiples flechas de
salida etiquetadas. Una división o una unión de control se representan con múltiples flechas que entran o
salen de la barra gruesa de sincronización.
Cuando es necesario incluir eventos externos, la recepción de un evento se puede mostrar como un
disparador en una transición, o como un símbolo especial que denota la espera de una señal.
A menudo es útil organizar las actividades en un modelo según su responsabilidad. Esta clase de
asignación puede mostrarse organizando las actividades en regiones distintas separados por líneas en el
diagrama. Debido a su aspecto, esto es conocido como Calles.
Un diagrama de actividades puede mostrar el flujo de objetos como valores. Para un valor de salida, se
dibuja una flecha con línea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja
una flecha con línea discontinua desde el objeto a una actividad.
Diagrama de Actividades
Ejemplo de Diagrama de Actividades
VISTA DE INTERACCION
Diagramas de Interacción:
La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan
el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripción de un
objeto, que desempeña un determinado papel dentro de una interacción, distinto de los otros objetos de la
misma clase. Esta visión proporciona una vista integral del comportamiento del sistema, es decir, muestra
el flujo de control a través de muchos objetos. La vista de interacción se exhibe en dos diagramas
centrados en distintos aspectos pero complementarios: centrados en los objetos individuales y centrados
en objetos cooperantes.
Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los
diagramas de interacción muestran cómo se comunican los objetos en una interacción. Existen dos tipos
de diagramas de interacción: el Diagrama de Colaboración y el Diagrama de Secuencia.
El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las
interacciones, muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo
real y para escenarios complejos. El Diagrama de Colaboración ofrece una mejor visión espacial
mostrando los enlaces de comunicación entre objetos, muestra las relaciones entre objetos y son mejores
para comprender todos los efectos que tiene un objeto y para el diseño de procedimientos. El diagrama de
Colaboración puede obtenerse automáticamente a partir del correspondiente diagrama de Secuencia (o
viceversa).
Diagramas de Secuencia:
1. Muestra la secuencia de mensajes entre objetos durante un escenario concreto

2. Cada objeto viene dado por una barra vertical
3. El tiempo transcurre de arriba abajo
4. Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua
Diagramas de Colaboración:
1. Muestra la secuencia de mensajes entre objetos durante un escenario concreto

2. Cada objeto viene dado por una barra vertical
3. El tiempo transcurre de arriba abajo
4. Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua
Diagramas de Colaboración:
1. Son útiles en la fase exploratoria para identificar objetos.

2. La distribución de los objetos en el diagrama permite observar adecuadamente la interacción de un
objeto con respecto de los demás
3. La estructura estática viene dada por los enlaces; la dinámica por el envío de mensajes por los
enlaces
Qué es una Colaboración?
Es una descripción de una colección de objetos que interactúan para implementar un cierto
comportamiento dentro de un contexto. Describe una sociedad de objetos cooperantes unidos para
realizar un cierto propósito. Una colaboración contiene ranuras que son rellenadas por los objetos y
enlaces en tiempo de ejecución. Una ranura de colaboración se llama Rol porque describe el propósito de
un objeto o un enlace dentro de la colaboración.
Un rol clasificador representa una descripción de los objetos que pueden participar en una ejecución de la
colaboración, un rol de asociación representa una descripción de los enlaces que pueden participar en una
ejecución de colaboración. Un rol de clasificador es una asociación que está limitada por tomar parte en la
colaboración. Las relaciones entre roles de clasificador y asociación dentro de una colaboración sólo
tienen sentido en ese contexto. En general fuera de ese contexto no se aplican las mismas relaciones.
Una Colaboración tiene un aspecto estructural y un aspecto de comportamiento. El aspecto estructural es
similar a una vista estática: contiene un conjunto de roles y relaciones que definen el contexto para su
comportamiento. El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados a
los roles. Tal conjunto de mensajes en una colaboración se llama Interacción. Una colaboración puede
incluir una o más interacciones.
Qué es una Interacción?
Es el conjunto de mensajes intercambiados por los roles de clasificador a través de los roles de
asociación. Un mensaje es una comunicación unidireccional entre dos objetos, un flujo de objeto con la
información de un remitente a un receptor. Un mensaje puede tener parámetros que transporten valores
entre objetos. Un mensaje puede ser una señal (comunicación explícita entre objetos, con nombre y
asíncrona) o una llamada (la invocación síncrona de una operación con un mecanismo para el control, que
retorna posteriormente al remitente). Un patrón de intercambios de mensajes que se realizan para lograr
un propósito específico es lo que se denomina una interacción.
Qué es Patrón?
Un patrón es una colaboración parame trizada, junto con las pautas sobre cuándo utilizarlo. Un parámetro
se puede sustituir por diversos valores, para producir distintas colaboraciones. Los parámetros señalan
generalmente las ranuras para las clases. El uso de un patrón se representa como una elipse de línea
discontinua conectada con cada una de las clases por una línea discontinua, que se etiqueta con el
nombre del rol.
Diagrama de Secuencia
Diagrama que muestra las interacciones entre los objetos organizadas en una secuencia temporal. En
particular muestra los objetos participantes en la interacción y la secuencia de mensajes intercambiados.
En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro
programa y ponemos qué llamadas van haciendo unos a otros para realizar una tarea determinada.
Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que
llamo subcaso de uso).
El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama
y a quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un
paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso
clases que representen un ejecutable.
Un diálogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa
los objetos que participan en la interacción. En general, el tiempo avanza hacia abajo dentro de la página
(se pueden invertir los ejes si se desea). Con frecuencia sólo son importantes las secuencias de mensajes
pero en aplicaciones de tiempo real el eje temporal puede ser una métrica. La ordenación horizontal de los
objetos no tiene ningún significado.
Cada objeto representa una columna distinta, se pone un símbolo de objeto al final de la flecha que
representa el mensaje que ha creado el objeto; está situada en el punto vertical que denota el instante
en que se crea el objeto. Esta se conoce como línea de vida del objeto. Se pone una X grande en el
punto en que deja de existir el objeto o en el punto en que el objeto se destruye a sí mismo. Para el
periodo durante el cual esté activo el objeto, la línea de vida se amplía para ser una línea doble
continua. Si el objeto se llama a sí mismo, entonces se superpone otra copia de la doble línea para
mostrar la doble activación. El orden relativo de los objetos no tiene significado aun cuando resulta útil
organizarlos de modo que se minimice la distancia de las flechas.
Cada mensaje se representa mediante una flecha horizontal que va desde la línea de vida del objeto
que envió el mensaje hasta la línea de vida del objeto que ha recibido el mensaje. Si un mensaje
requiere un cierto tiempo para llegar a su destino, entonces la flecha del mensaje se dibuja
diagonalmente hacia abajo.
Para un flujo de objeto asíncrono entre objetos activos, los objetos se representan mediante líneas
dobles continuas y los mensajes se representan como flechas. Se pueden enviar simultáneamente dos
mensajes pero no se pueden recibir simultáneamente porque no se puede garantizar una recepción
simultánea.
Las bifurcaciones se muestran partiendo la línea de vida del objeto. Cada bifurcación puede enviar y
recibir mensajes. Eventualmente las líneas de vida del objeto tienen que fusionarse de nuevo.
Un diagrama de secuencia también se puede mostrar en forma de descriptor, en el cual los

constituyentes son roles en lugar de objetos. Este diagrama muestra en el caso general, no una sola
ejecución del mismo. Los diagramas del nivel de descriptores se dibujan sin subrayados porque los
símbolos denotan roles y no objetos individuales.
Ejemplo de Diagrama de Secuencia

DIAGRAMAS DE SECUENCIA: UN PASO A LA VEZ
A pesar de que a partir de los diagramas de casos de uso y de los diagramas de robustez ya
tenemos entre un 75 y 80 por ciento de atributos de nuestras clases identificados, es hasta el diagrama de
secuencia donde se empiezan a ver que métodos llevaran las clases de nuestro sistema. Esto se debe
que hasta que vemos interactuando a los objetos de nuestras clases con los actores y con otros objetos de
manera dinámica, hasta ese momento tenemos suficiente información como para poder empezar a
especificar los métodos de nuestras respectivas clases.
El diagrama de secuencias es el núcleo de nuestro modelo dinámico, y muestra todos los cursos
alternos que pueden tomar todos nuestros casos de uso. Los diagramas de secuencias se componen de 4
elementos que son: el curso de acción, los objetos, los mensajes y los métodos (operaciones). Estos 4
elementos son los que ya han sido analizados en clase con anterioridad dentro de la primera unidad.
Los 4 pasos a seguir:

A continuación se dará una muy breve descripción de los 4 pasos que se deben de seguir para
dibujar correctamente diagramas de secuencia:
-Paso 1: Copia el texto de la especificación de tu caso de uso y pégalo en la parte superior de tu

diagrama de secuencia. Con esto siempre se tendrá en cuenta que es lo que debe de hacer el diagrama
de secuencia.
-Paso 2: Cada uno de los objetos entidad de tu diagrama de robustez es una instancia de la clase
que debe de ser agregada a tu diagrama de secuencias ya que representa tu modelo estático. Hay que ser
muy meticuloso con este paso, ya que representa el último de tu modelo estático antes de codificar.
-Paso 3: Agrega las interfaces del diagrama de robustez. Con esto ya tenemos el diagrama de
secuencias construido. Ahora, el cuarto paso es para decidir cuales métodos irían en cuales clases, lo cual
es la esencia del modelo de iteraciones.
-Paso 4: Pon los métodos en las clases, lo cual significa convertir los controles uno por uno de tu
diagrama de robustez en métodos y mensajes. Verifica que para cada control dibujado le pertenecen los
mensajes correctos dentro del diagrama de secuencias.
Top Ten de errores de los diagramas de secuencia:

A continuación se presentan los 10 errores más comúnmente cometidos por los estudiantes al
intentar hacer sus diagramas de secuencia.
10.- No hacen un diagrama de secuencia para cada caso de uso: Hacer esto es muy importante, ya
que solo así se puede saber cuál es el rol y las responsabilidades de cada objeto.
9.- No ponen el texto del caso de uso en el diagrama de secuencia: El poner de vuelta este texto al
margen del diagrama de secuencia provee de la visión necesaria para poder hacer diagramas de
secuencia correctos de acuerdo al caso de uso que se está modelando.
8.- No identifican todos los objetos necesarios desde el diagrama de robustez: Si tienes problemas
al realizar los diagramas de secuencia es porque tienes mal modelados tus casos de uso o tus diagramas
de robustez están incompletos.
APLICACIÓN DE DIAGRAMAS UML EN FORMULACION
DE PROYECTOS
PROPUESTA DE MEJORA
“Implementación de Gestión de Incidentes (Soporte y Eventos de seguridad TI) y mesa de servicio, bajo los
estándares internacionales de ITIL V3 y Best Practice”.
ESTUDIANTE:
OSCAR ANDRÉS BETANCOURT BELTRÁN
UNIVERSIDAD SANTO TOMÁS

VICERRECTORÍA DE UNIVERSIDAD ABIERTA Y A DISTANCIA
INGENIERIA EN INFORMATICA
Modelo de Dominio: Los modelos de domino son utilizados comúnmente para el diseño de
software ya que muestra clases conceptuales importantes para el desarrollo y solución del
problema, pues el modelo de dominio no es más que una representación de las clases
conceptuales del mundo real en un dominio de internes. A continuación, se evidenciará un
modelo UML donde se indican las entidades del sistema y actividades de cada componente.
Betancourt, O. (2016). Modelo de Dominio. [Imagen]. Recuperado de

https://www.gliffy.com/go/html5/launch?app=1b5094b0-6042-11e2-bcfd-0800200c9a66
El modelo de análisis tiene como objetivo generar una arquitectura de objetos indicando las
variables claves para la mejor compresión de conceptos representando la relación del sistema
organizacional con su entorno de modo que sirva como base para el diseño del sistema.
Diagrama de secuencia: Este tipo de diagrama muestra la forma en que los objetos se
comunican entre sí al transcurrir el tiempo mostrando interacciones y mensajes de secuencia.
Betancourt, O. (2016). Diagrama de Secuencia. [Imagen]. Recuperado de

https://cacoo.com/diagrams/5vTLsNOu08tO3hhB
Diagrama de contratos: Los contratos pueden ayudar a definir el comportamiento del sistema,
puesto que describen el resultado de la ejecución de las operaciones del sistema en función de
los cambios de estado de los objetos del dominio. A continuación, se realizan los contratos para el
registro de eventos de red, de seguridad y Cambios.
Contrato CO1 Registrar evento de red.
Operación: Registrar evento de red (Dispositivo, Evento, Fecha, Categoría,

Prioridad )
Referencias cruzadas: Caso de Uso: Ingresar Dispositivo
Responsabilidades: El sistema registra un evento de red a nivel de infraestructura

para un dispositivo creando un caso en Service Manager.
Excepciones: Existencia de un caso abierto.
Precondiciones:
 prueba de ping
 Prueba de SNMP
Postcondiciones :
 Se crea un numero de caso en Service Manager (IM)
 Se ingresa el evento en la base de datos
 Se registra la fecha en seguimiento
 Se asigna una categoría
 Se asigna una Prioridad
 Se calcula un tiempo de respuesta dependiente la categoría y prioridad.
Salidas: Numero de caso y correo automáticamente generando al responsable.

Contrato CO2 Registrar evento de Seguridad
Operación: Registrar evento de seguridad (Dispositivo, Evento, Fecha, Categoría,

Prioridad )
Referencias cruzadas: Caso de Uso: Ingresar servidor.
Responsabilidades: El sistema registra un evento de seguridad a nivel de

infraestructura para un dispositivo creando un caso en Service Manager.
Precondiciones:
 Correlación de eventos.
Postcondiciones :

Contrato CO3 Registrar Cambios.
Operación: Registrar Cambio (Dispositivo, Tipo de cambio, Fecha, Fase )
Referencias cruzadas: Caso de Uso: Descubrir Items de Configuración.
Responsabilidades: El sistema registra un cambio para un dispositivo creando un

caso en Service Manager.
Excepciones: Ninguna.
Precondiciones:
 Descubrimiento de cambio de estado en un dispositivo.
Postcondiciones :
 Se crea un numero de caso en Service Manager (C)
 Se registra el tipo de cambio
 Se ingresa una de fecha
 Se registra una fase.
Salidas: Numero de caso y correo automáticamente generado al Gestor de

Cambios.
FORMULACION DEL PROBLEMA DEL PROYECTO DE GRADO.
La solución del problema informático se toma como el problema del proyecto informático.
Solución:
En el contrato 209 de 2015 El FNA invirtió una gran cantidad de recursos en un centro de seguridad
informática, donde se observa que se tiene entre sus herramientas una CMDB (Configuration Management
Database,) que se encuentra funcional con el 20% de su capacidad operativa y solamente se encuentra
funcionando el módulo de reconocimiento de dispositivos subutilizando la herramienta y dejando
deshabilitado el 80% de su potencial, el cual puede controlar, gestionar y almacenar en su base de datos
alrededor de 10000 componentes de infraestructura e identificar sus relaciones de cambios.
Con el fin de poder obtener un inventario actualizado y validar los cambios sobre la infraestructura, el FNA
bajo el diagnostico de estudio realizado por el grupo de consultores decide habilitar todos los módulos de
la uCMDB y obtener una mejora en automatización, adaptación y configuración adecuada sobre la
herramienta.
MODELO DE REQUISITOS: Este modelo tiene como fin reconocer el sistema y delimitar su alcance
durante el proyecto.
El Diagrama de Casos de Uso es utilizado para describir un sistema en términos de sus distintas formas
de utilización.
Betancourt, O. (2016) Diagrama Casos de Uso. [Imagen] Recuperado de

https://cacoo.com/diagrams/D5WgRWaGOrKeqhbw.
Modelo de Dominio: Este diagrama da una representación de las clases que se utilizan para la
ejecución del programa.
Betancourt, O. (2016) Modelo de Dominio. [imagen]
MODELO DEL NEGOCIO: Este modelo es realizado para evaluar el costo beneficio que se obtiene por
adquirir un producto o un servicio.
Modelo de procesos de Negocio: Es un modelo que permite evidenciar las actividades correspondientes
a cada área implicada en el proceso.
Betancourt, O. (2016). Modelo de proceso de Negocio. [Imagen].

Modelo de procesos de Transaccional: Se trata de un sistema de información que representa
el diseño del software a nivel transaccional, es decir, evidencia la recolección, almacenamiento y
modificación de datos dentro del sistema.
Se realiza un programa por medio de la herramienta Netbeans para que el operador pueda
visualizar la información y el administrador pueda almacenar, eliminar y modificar la información
de forma manual.
Betancourt, O. (2016). Interfaz Grafica UCMDB. [Imagen].
Base de datos en phpMyAdmin = ucmdb y tabla gestión.
Betancourt, O. (2015), Base de datos. [Imagen]
Búsqueda de datos: Para realizar la búsqueda en el aplicativo se debe ingresar la palabra y hacer
clic en el botón buscar en este caso existen dos posibilidades.
a) Si la palabra se encuentra en cualquier campo de la tabla el programa retornara las coincidencias

de búsqueda en la parte inferior de la pantalla:
Betancourt, O. (2016). Buscar Datos. [Imagen]
Si existen varios valores de búsqueda podrá visualizarlos haciendo clic derecho en alguna de las
filas inferiores y escoger la opción ―Ver Archivos‖, esto diligenciara todos los campos de la parte
superior de la interfaz y podrá visualizar todos los datos en las casillas correspondientes, como
se evidencia a continuación:
Betancourt, O. (2016). Visualizar Datos. [Imagen]

b) Si la palabra buscada no se encuentra en ningún campo de la tabla el programa retornara un aviso
informando: ―No se encontró en la búsqueda‖.
Betancourt, O. (2016). Buscar Datos. [Imagen]
Adición: Para adicionar un nuevo elemento de forma manual a la tabla, tener en cuenta:
a) Si el identificador (Llave primaria) no existe en la base de datos, podrá diligenciar todos los datos
de las casillas y hacer clic en el botón insertar.
Betancourt, O. (2016). Adicionar Datos. [Imagen]
b) Si el identificador (Llave primaria) ya existe en la base de datos no se podría ingresar ninguna

información y aparecerá en pantalla el mensaje: ―El registro ya existe, no se puede insertar‖.
Betancourt, O. (2016). Adicionar Datos2. [Imagen]
Edición de información: Para actualizar algún campo de la tabla se debe seleccionar el ítem a
modificar en la parte inferior de la interfaz, realizar clic derecho y escoger la opción ―Ver Archivo‖,
allí se diligenciaran automáticamente todos los cuadros de texto con los datos del dispositivo a
modificar.
Betancourt, O. (2016). Modificiar Datos. [Imagen]
Eliminar Información: Se puede eliminar cualquier registro de la base de datos haciendo clic
derecho sobre el ítem a eliminar y escoger la opción ―Eliminar‖
Betancourt, O. (2016). Modificiar Datos. [Imagen]
Modelo Entidad-Relación
Betancourt, O. Modelo Entidad-Relacion. (2016) [Imagen] Retomado de:

https://www.gliffy.com/go/html5/launch?app=1b5094b0-6042-11e2-bcfd-0800200c9a66
MODELO DE ANALISIS: Este modelo utiliza una mezcla de formatos en texto y diagramas para
representar los requisitos del software, las funciones y el comportamiento, haciendo más fácil la
comprensión del proyecto.
CRITERIO
ETAPA ENTREGABLE
FINALIZACIÓN
Adquisición de - Entrega de suministros de Sw, Hw y - Factura radicada
suministros Licenciamiento
Diseño - Documento de Diseño final del SOC - Documentos Firmados
Implementación - Acta de entrega de la - Firmas Actas de
Implementación universal CMDB implementación
- Acta de entrega del monitoreo y
gestión de redes
- Acta de entrega de la gestión de
servicios e integraciones – BSM
- Acta de entrega de suministros de
10 cámaras IP inalámbricas y 2
pantallas de monitoreo
- Acta de entrega de la plataforma
SIEM
- Acta de entrega la plataforma de
incidentes de seguridad
Pruebas - Informe del resultado del plan de - Aceptación por parte del
pruebas. FNA del plan de pruebas
Documentación - Memoria Técnica - Firma documento de

- Manuales de Fabricante memoria técnica por parte
del FNA
Capacitación - Material de Capacitación - Encuesta de satisfacción
firmada por los asistentes
por parte del cliente
- Listados de Asistencia
Entrega - Acta de entrega de las herramientas. - Acta de Cierre del
proyecto firmada
Diagrama de secuencia: Este tipo de diagrama muestra la forma en que los objetos se
comunican entre sí a medida del tiempo, mostrando interacciones y mensajes de secuencia:
Betancourt, O. (2016). Diagrama de Secuencia Cliente. [Imagen] Recupeardo de:

https://cacoo.com/diagrams/5vTLsNOu08tO3hhB/edit
Betancourt, O. (2016). Diagrama de Secuencia Administrador. [Imagen] Recupeardo de:

Betancourt, O. (2016). Diagrama de Secuencia Operador. [Imagen] Recupeardo de:
Diagrama de contratos: Los contratos pueden ayudar a definir el comportamiento del sistema,
puesto que describen el resultado de la ejecución de las operaciones del sistema en función de
los cambios de estado de los objetos del dominio.
A continuación, se realizan los contratos para el registro de eventos de red y Cambios.
Contrato CO1 Registrar evento de red.
Operación: Registrar evento de red (Dispositivo, Evento, Fecha, Categoría,

Prioridad )
Referencias cruzadas: Caso de Uso: Ingresar Dispositivo
Responsabilidades: El sistema registra un evento de red a nivel de infraestructura

para un dispositivo creando un caso en Service Manager.
Precondiciones:
 prueba de ping
 Prueba de SNMP
Postcondiciones :

Contrato CO3 Registrar Cambios.
Operación: Registrar Cambio (Dispositivo, Tipo de cambio, Fecha, Fase )
Referencias cruzadas: Caso de Uso: Descubrir Items de Configuración.
Responsabilidades: El sistema registra un cambio para un dispositivo creando un

caso en Service Manager.
Excepciones: Ninguna.
Precondiciones:
 Descubrimiento de cambio de estado en un dispositivo.
Postcondiciones :
 Se crea un numero de caso en Service Manager (C)
 Se registra el tipo de cambio
 Se ingresa una de fecha
 Se registra una fase.
Salidas: Numero de caso y correo automáticamente generado al Gestor de

Cambios.
Betancourt, O. (2016). Tabla de contratos. [Tabla]
Diagrama de colaboración: Este tipo de diagrama se utiliza para representar la interacción entre
objetos ya que muestra como las instancias de cada clase trabajan juntas para conseguir la
solución del problema.
Betancourt, O. (2016). Diagrama de Colaboraciòn . [Imagen]
Descripción de la secuencia:
ID Nombre Evento Descripción

Recepción de LOG de seguridad Los dispositivos envían o entregan a ArcSight Connector los
1A eventos de seguridad.
Integration ArcSight Connector + Gracias al ArcSight connector se reciben los logs de las
ArcSight Logger aplicaciones, de este punto son enviados al manejador de logs
1B
(ArcSight Logger)
Integration ArcSight Connector + Los eventos que llegan al ArcSight connector son
1C ArcSight ESM reenviados al ArcSight ESM, para que puedan ser correlacionados.
ArcSight ESM + BSM/OMi Si existe algún tipo de regla que deba abrir un incidente
de seguridad, se enviará este evento a BSM + Omi
1D
Recepción de mensajería SNMP Network Node Manager (NNM) a través de mensajería

2A SNMP consulta a los dispositivos su estado.
NNM + BSM/OMi NNM envía a BSM o la topología de la red y envía los
2B eventos de disponibilidad que sea necesario escalar.
uCMDB + Service Manager Existe una comunicación bidireccional entre uCMDB y
Service manager que tiene como propósito que service
manager pueda conocer los ítems de configuración (CI).
3 Adicionalmente, gracias al módulo de cambio en SM
cuando la uCMBD detecte un cambio en un ítem de
configuración (CI), se abrirá en SM un caso de cambio no
planeado.
uCMDB + BSM/OMi BSM para poder abrir los ticket en service manager
necesita conocer el ítems de configuración (CI)
4
referenciado para esto se integra con Ucmdb
BSM/OMi + Service Manager Cada vez que se solicite a BSM abrir un incidente en
Service Manager este se comunica para abrir el incidente
5 requerido.
Diagrama de Clases: Estos diagramas visualizan las relaciones entre las clases que involucran
el sistema.
Betancourt, O.
(2016) Diagrama
de Clases.
[Imagen]
MODELO DE DISEÑO: Este modelo se utiliza para planificar y desarrollar el proyecto.
Diagrama Arquitectónico: Es la representación del diseño y los procesos de ingeniería de requerimientos.
Betancourt, O. (2016) Modelo de Diseño. [Imagen]

Diseño de Clases y datos: Es un tipo de diagrama de estructura estática que describe la estructura de un
sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los
objetos.
Betancourt, O.
(2016)
Diagrama de
clases y datos.
[Imagen]
Diseño de
paquetes: Es
un tipo de
diagrama donde
se evidencian
todos los
procesos del
sistema, los
cuales son
colocados en
componentes
separados de tal
manera que
todos los datos y
funciones dentro
de cada
componente
estén
relacionados.
Betancourt, O. (2016) Diseño de paquetes. [Imagen] recuperado de:
https://cacoo.com/diagrams/5vTLsNOu08tO3hhB
Diseño de interfaces graficas: Consiste en el diseño de la aplicación grafica con el fin de que el usuario
obtenga mayor familiaridad con la aplicación y la interacción sea muy intuitiva es decir que el usuario pueda
comunicarse con el software y aprender rápidamente su funcionamiento a través de los recursos gráficos,
simbología, pictogramas y estereotipos.
Representación entrada, proceso y salida de la intefaz:
Betancourt, O. (2016) Diseño Interfaz Grafica. [Imagen]

INTERFAZ GRAFICA:
Betancourt, O. (2016) Diseño Interfaz Grafica 2. [Imagen]
Puede consultar cualquier registro que se encuentre en la base de datos uCMDB desde la tabla que
se encuentra en la parte inferior del programa y se puede ampliar su información haciendo clic
derecho sobre el registro a consultar y escoger la opción ―Visualizar Activo‖, automáticamente se
llenaran todas las casillas con la información correspondiente al registro seleccionado como se
evidencia en la imagen.
Betancourt, O. (2016) Diseño Interfaz Grafica 3. [Imagen]

ANEXO5
METODOLOGIA SOFTWARE EDUCATIVO
METODOLOGIA EDUMATICA (Mario Contreras, 2016)
Los derechos de propiedad intelectual de la Metodología pertenece al Docente, por lo cual, toda la información
contenida en el presente trabajo sólo puede ser usada con fines académicos. Cualquier uso, reproducción
parcial o total destinada a otros fines, deberá estar autorizada por el Docente.
METODOLOGIA SOFTWARE EDUCATIVO
Análisis del Sistema Edumático
 Situación Problémica
 Recolección de Información
 Diagnostico
 Formulación del Problema
 Planteamiento del Problema
 Dominio Material y de Aplicación
 Normalización e Identificación del Objeto
 Capa Contenido
 Capa Presentación
 Capa Ayuda
 Navegación
 Estructura de un Componente
Diseño del Sistema Edumático
 Modelo Esquemático
 Descripción del Elemento Terminal (Escena)
 Set de Escenas
 Navegación
Análisis del Sistema Edumático
En el Análisis Edumático una vez que se haya recolectado la información de la situación problemica,
identificado la población objetiva, diagnosticado y formulado el problema Edumático, como también, justificado
el sistema Edumático; se plantea el Dominio Material y de Aplicación del tema como resultado de Solución de
una Deficiencia o Satisfacción de una Necesidad.
1 Identificación de los objetos de conocimiento, de formación y de estudio del tema
Tabla 1. Tabla de Dominio Material del Tema. Fuente Propia
Objetos de Conocimiento Objetos de Formación Objetos de Estudio se deben
(se deben Definir) (se deben Demostrar) saber (Docente) y Aprender
(Estudiante)
Que se debe Definir Como se puede ampliar, Que se quiere aprender

profundizar, Que se debe enseñar
ejemplarizar, jugar
Recursos como: Actividades como: Es lo que quiere-saber o lo que
Teorías, Teoremas, Aplicaciones, debe-saber o lo que debe saber-
leyes, reglas, fenómenos, situaciones, hacer un estudiante
metodologías, modelos. progresos, posturas,
situaciones, casos de
estudio, lúdica
Los recursos del Objeto Los recursos del Objeto El objeto de estudio como un
de Conocimiento como de Conocimiento como conjunto de conceptos o
una organización mental la relación entre representación mental de
de conceptos(Ámbito conceptos y actividades. conceptos
Conceptual)
Organizar conceptualmente (Ámbito Conceptual) haciendo uso de uno de estos
recursos:
- Jerarquía de conceptos mediante la relación y/o asociación.
- El Mapa Mental como un diagrama usado para representar las palabras, ideas,
tareas y dibujos u otros conceptos ligados y dispuestos radialmente alrededor de
un objeto.
- El Mapa Conceptual como técnica usada para la representación gráfica de un
Objeto. Un mapa conceptual es una red de Conceptos.
- Y otros recursos
2 Organización Conceptual del Tema

3 El Tema se presenta inicialmente como un Dominio Material que establece la relación entre el objeto
de conocimiento y el objeto de estudio con su ámbito conceptual ante sus medios de presentación.
4 El tema se presenta el tema como el Dominio de Aplicación como la relación entre las actividades y los
medios a hacer utilizados.
5 Normalización e Identificación de cada Objeto (Conocimiento, Formación, y de estudio). Se Normaliza
cada objeto como Componente (Conocimiento, Formación, y de estudio) y se identifica hacia el interior
del Sistema Edumático. Además, para que exista coherencia con lo planteado en el Decimo Referente
Arquitectura del Sistema Edumático se establece que la Capa de Contenido será formada por los
componentes de Conocimiento, Formación y Estudio.
6 El componente Menú aparece ante la oportunidad de seleccionar o elegir un componente de
contenido de una lista de opciones (cada opción es un componente de contenido). Por ejemplo, en un
Menú de Continentes existe cada continente, por decir, América, Asís, Europa, África, Oceanía como
una opción de una lista de opciones.
7 Cada componente de la Capa de Contenido debe tener una estructura como:
Tabla 2. Estructura Componente Capa de Contenido. Fuente Propia
CAPA DE PRESENTACION
COMPONENTE IDENTIFICACION MEDIOS
COMPONENTE IMAGEN SONIDO TEXTO
Conocimiento Dibujo Fondo musical Narrativo
Formación Animación Vocal Narrativo Descriptivo
Estudio Video Vocal Descriptivo
Menú Cortina musical
8 En la Capa de Presentación se puede establecer la tabla de identificación de componentes como:
Tabla 3. Identificación Componentes Capa de Presentación. Fuente Propia
Componente Identificación como Ejemplo de Identificación
Componente de Componente
Portada PO_Objeto (el PO_Integrantes

nombre de objeto
debe ser titulado)
Presentación PR_Objeto (el PR_PresentacionTema

nombre de objeto
debe ser titulado)
Instrucciones PI_Objeto (el nombre PI_Juego

de objeto debe ser
titulado) PI_Software
Agradecimientos PA_Objeto (el PA_Familia

nombre de objeto
debe ser titulado) PA_Institucion
Antecedentes PN_Objeto (el PN_EstudioSocial

nombre de objeto
debe ser titulado)
9 Cada componente de la Capa de Presentación debe tener una estructura como:

Tabla 4. Estructura Componente Capa de Presentación. Fuente Propia
CAPA DE PRESENTACION
Portada Dibujo Fondo musical Narrativo
Presentación Animación Vocal Narrativo Descriptivo
Instrucciones Video Vocal Descriptivo
Agradecimiento Cortina musical
Antecedentes
10 En la Capa de Ayuda se puede establecer la tabla de identificación de componentes como:
Tabla 5. Capa de Ayuda. Fuente Propia
Proyecto AP_Objeto (el AP_Simbolos

nombre de objeto
debe ser titulado)
Componente AC_Objeto (el AC_JuegoPar

nombre de objeto
debe ser titulado)
11 Cada componente de la Capa de Ayuda debe tener una estructura como:

Tabla 6. Estructura Componente Capa de Ayuda. Fuente Propia
CAPA DE AYUDA
Proyecto Dibujo Fondo musical Narrativo
Componente Animación Vocal Narrativo Descriptivo
Video Vocal Descriptivo
Cortina musical
12 La navegación se manifiesta como quiere que se aprenda el tema. Entonces, cada componente cumple
con ser una secuencia, un menú, una opción de o un llamado de. Por lo tanto, se puede pensar en una
navegación lineal o secuencial, navegación por menús, navegación hipermedial donde cada componente
es una opción, navegación por hipermedia (un componente es llamado y retorna al componente que
llamo)
Figura 1. Navegación Lineal. Fuente Propia
Figura 2. Navegación por Menús. Fuente Propia

Figura 3. Navegación por Hipermedia. Fuente Propia
13 Se representa cada componente como la integración de una Navegación y un Contenido (Tabla 7).
Tabla 7. Estructura de un Componente. Fuente Propia
COMPONENTE COMPONENTE COMPONENTE
PREVIO SIGUIENTE
Nombre: Nombre: Nombre:
Identificación: Identificación: Identificación:
Pertenece a la: Pertenece a la: Pertenece a la:
Capa Presentación Capa Presentación Capa Presentación
_ Portada _ Portada _ Portada
_ Presentación _ Presentación _ Presentación
_ Instrucciones _ Instrucciones _ Instrucciones
_ Agradecimiento _ Agradecimiento _ Agradecimiento
_ Antecedentes _ Antecedentes _ Antecedentes

Capa Contenido Capa Contenido Capa Contenido
_ Conocimiento _ Conocimiento _ Conocimiento
_ Formación _ Formación _ Formación
_ Estudio _ Estudio _ Estudio
_ Menú _ Menú _ Menú

Capa Ayuda Capa Ayuda Capa Ayuda
_ Proyecto _ Proyecto _ Proyecto
_ Componente _ Componente _ Componente

----------------------------- -------------------------
Nombre: MEDIOS Nombre:
Identificación: IMAGEN SONIDO TEXTO Identificación:
Capa Presentación Dibujo Fondo Narrativo Capa Presentación
_ Portada Animación musical Descriptivo _ Portada
Video Vocal
_ Presentación Narrativo _ Presentación
Vocal
_ Instrucciones Descriptivo _ Instrucciones
Cortina
_ Agradecimiento musical _ Agradecimiento
_ Antecedentes _ Antecedentes
Capa Contenido Capa Contenido
_ Conocimiento _ Conocimiento
_ Formación _ Formación
_ Estudio _ Estudio
_ Menú _ Menú
Capa Ayuda Capa Ayuda
_ Proyecto _ Proyecto
_ Componente _ Componente
COMPONENTE COMPONENTE COMPONENTE
PREVIO SIGUIENTE
14 En la Capa de Ayuda se puede establecer la tabla de identificación de componentes como:
Tabla 8. Capa de Ayuda. Fuente Propia

Proyecto AP_Objeto (el AP_Simbolos

nombre de objeto
debe ser titulado)
Componente AC_Objeto (el AC_JuegoPar

nombre de objeto
debe ser titulado)
15 Cada componente de la Capa de Ayuda debe tener una estructura como:

Tabla 11. Estructura Componente Capa de Ayuda. Fuente Propia
CAPA DE AYUDA
Proyecto Dibujo Fondo musical Narrativo
Componente Animación Vocal Narrativo Descriptivo
Video Vocal Descriptivo
Cortina musical
Diseño Sistema Edumático
1. Modelo Esquemático
Esquema es la representación gráfica del Proyecto/Software Edumático.
Se aplica el concepto de:
Globalización. El proyecto es visto como un todo
Especialización. Se divide el proyecto de acuerdo al contenido; cada división es una Especialización del
Elemento Global.
Entonces se puede decir en lenguaje natural:
- Forma1. La División es Parte de un Proyecto
- Forma2. Proyecto está compuesto de una división
A su vez esta división pasa a ser Global. Esta división a su vez se divide sucesivamente hasta llegar a un
elemento terminal (Escena) o un Set de Escenas
Entonces cada escena representa un Componente.
Entonces un Set de Escenas es la integración de varios Componentes en una sola escena (no se debe
confundir con componente Menú).
Cada escena se identifica ídem que su componente asociado.
2. Descripción de una Escena
- Medios
- Escenario
- Áreas
3. Set de Escenas
4. Guion
5. Navegación
ANEXO6
PROCESO DE DESARROLLO DE SOFTWARE
Tomado de: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc

METODOLOGÍAS PARA DESARROLLO DE SOFTWARE
Un proceso de software detallado y completo suele denominarse ―Metodología‖. Las metodologías se basan
en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.).
Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados,
junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para
uso de herramientas de apoyo, etc. Habitualmente se utiliza el término ―método‖ para referirse a técnicas,
notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por
ejemplo, suele hablarse de métodos de análisis y/o diseño.
Si se toma como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de
análisis y diseño, se puede clasificar las metodologías en dos grupos: Metodologías Estructuradas y
Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas
metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de
requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada
Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más
orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo
pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran
activamente al cliente en el proceso.
A continuación se revisan brevemente cada una de estas categorías de metodologías.
Metodologías Estructuradas
Los métodos estructurados comenzaron a desarrollarse a fines de los 70‘s con la Programación Estructurada,
luego a mediados de los 70‘s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura)
primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son
particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta
generación.
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE 1 (Francia), MÉTRICA2 (España),
SSADM3 (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane &
Sarson4, Ward & Mellor5, Yourdon & DeMarco6 e Information Engineering7.
Metodologías de Análisis y Diseño Orientadas a Objetos

Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más
representativos: a fines de los 60‘s SIMULA, a fines de los 70‘s Smalltalk-80, la primera versión de C++ por
Bjarne Stroustrup en 1981 y actualmente Java8 o C# de Microsoft. A fines de los 80‘s comenzaron a
consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una
unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para
dar lugar al Unified Modeling Language (UML) 9, la notación OO más popular en la actualidad.
Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad &
Yourdon, Shaler & Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process
(RUP)10, OPEN11, MÉTRICA (que también soporta la notación estructurada).
Metodologías tradicionales (no ágiles)

Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el
proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa
etapa de análisis y diseño antes de la construcción del sistema.
1
http://perso.club-internet.fr/brouardf/SGBDRmerise.htm (7.5.2002)
2
http://www.map.es/csi/metrica3/ (7.5.2003)
3
http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html (7.5.2003)
4
http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc (29.8.2003)
5
http://www.yourdon.com/books/coolbooks/notes/wardmellor.html (29.8.2003)
6
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco (29.8.2003)
7
http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html (29.8.2003)
8
http://java.sun.com/ (7.5.2003)
9
http://www.uml.org/ (7.5.2003)
10
http://www.rational.com/products/rup/index.jsp (7.5.2003)
11
http://www.open.org.au/ (17.9.2003)
Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales.
Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las
condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración
adecuada, podría considerarse Ágil.
Metodologías ágiles
Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con
ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana
comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y
adaptable (permite realizar cambios de último momento).
Entre las metodologías ágiles identificadas se destacan:
1. Extreme Programming (XP).
Figura 1. Metodología Programación Extrema XP.

Fuente. https://www.mindmeister.com/es/258146343/metodolog-a-programaci-n-extrema-xp
2. Metodología Scrum.
Referente. https://proyectosagiles.org/que-es-scrum/
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar
colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se
apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
Un proyecto con Scrum se ejecuta en bloques temporales cortos y fijos (iteraciones que normalmente son
de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback y
reflexión). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final
que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del
proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su
coste y quedan repartidos en iteraciones y entregas.
Figura 2. Metodología SCRUM.

Fuente. https://proyectosagiles.org/que-es-scrum/
3. Familia de Metodologías Crystal.

El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad
(como en los minerales, color y dureza).
Por ejemplo.
 Clear es para equipos de hasta 8 personas o menos.
 Amarillo para equipos entre 10 a 20 personas.
 Naranja para equipos entre 20 a 50 persona.
 Roja para equipos entre 50 a 100 personas.
 Azul para equipos entre 100 a 200 personas.
La Metodología Crystal puede ser usada en proyectos pequeños y como casi todos los otros métodos
consisten en valores, técnicas y procesos.
Se hace menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser
probadas.
La Metodología Crystal da vital importancia a las personas que componen el equipo de un proyecto, y por
tanto sus puntos de estudio son:
- Aspecto humano del equipo
- Tamaño de un equipo (número de componentes)
- Comunicación entre los componentes
- Distintas políticas a seguir
- Espacio físico de trabajo
4. Feature Driven Development.
Es una metodología ágil diseñada para el desarrollo de software, basada en la calidad y el monitoreo
constante del proyecto.
Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de
entregar menos de lo deseado.
Propone tener etapas de cierre cada dos semanas. Se obtienen resultados periódicos y tangibles.
Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y
la dirección de la empresa pueden ver y monitorear.
Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.
No hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de diseño y
construcción.
2. Proceso Unificado Rational (RUP), una configuración ágil.

Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los procesos y se
mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML, constituye
la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas
orientados a objetos.
El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada organiza
Principales características
Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
Pretende implementar las mejores prácticas en Ingeniería de Software.
Desarrollo iterativo
Administración de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificación de la calidad del software
3. Dynamic Systems Development Method (DSDM).
El Método de Desarrollo de Sistemas Dinámicos (en inglés Dynamic Systems Development Method o
DSDM) es un método que provee un framework para el desarrollo ágil de software, apoyado por su
continua implicación del usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos
cambiantes, para desarrollar un sistema que reúna las necesidades de la empresa en tiempo y
presupuesto
Su meta es entregar los sistemas del software a tiempo y en el presupuesto mientras ajustando para los
requisitos cambiantes a lo largo del proceso de desarrollo. DSDM es uno de varios métodos Ágiles para el
software en vías de desarrollo, y forma una parte de la Alianza Ágil.
7. Adaptive Software Development (ASD).

El método ágil ASD (Adaptive Software Development) traducido en español significa Desarrollo Adaptable
de Software es un modelo de implementación de patrones ágiles para desarrollo de software. Al igual que
otras metodologías ágiles, su funcionamiento es cíclico y reconoce que en cada iteración se producirán
cambios e incluso errores.
El desarrollo de software adaptable (Adaptive Software Development - ASD) es una metodología de
desarrollo que hace énfasis en aplicar las ideas que se originaron en el mundo de los sistemas complejos,
adaptación continua del proceso al trabajo.
Sus principales características del ASD son:
- Iterativo.
- Orientado a los componentes de software (la funcionalidad que el producto va a tener, características,
etc.) más que a las tareas en las que se va a alcanzar dicho objetivo.
- Tolerante a los cambios.
- Guiado por los riesgos
- La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo
8. Open Source Software Development.

Desarrollo del software de código abierto es el proceso por el que se desarrolla el software de código abierto,
o de manera similar aquel software cuyo código fuente está disponible de manera pública. Estos son
productos de software disponibles con su código fuente bajo una licencia de código abierto que permite
estudiar, cambiar y mejorar el diseño de estos programas. Ejemplos de algunos productos populares de
software de código abierto son Mozilla Firefox, Google Chromium, Android, LibreOffice y el paquete de oficina
Apache OpenOffice Suite.
El uso de software de código abierto es común porque los desarrolladores encuentran que pueden obtener un
prototipo en pruebas y producción más rápido y prácticamente sin costo alguno. El resultado es un tiempo
más corto para el mercado a un costo menor – es obvio para cualquier empresa que busque prosperar en el
mercado-.
Las bases de datos NoSQL subieron en popularidad sobre la ola de estas tendencias. Normalmente, de
código abierto y construido con prácticas de software moderno en mente, las bases de datos NoSQL permiten
un desarrollo más rápido a menor costo que con la antigua generación de bases de datos relacionales.
PROCESO DE DESARROLLO DE SOFTWARE
Introducción
Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se
realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente
definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina construida por
el hombre. Sin embargo, respecto del software, su construcción y resultados han sido históricamente
cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes [1]:
 Los sistemas no responden a las expectativas de los usuarios.
 Los programas ―fallan‖ con cierta frecuencia.

 Los costes del software son difíciles de prever y normalmente superan las estimaciones.
 La modificación del software es una tarea difícil y costosa.
 El software se suele presentar fuera del plazo establecido y con menos prestaciones de las
consideradas inicialmente.
 Normalmente, es difícil cambiar de entorno hardware usando el mismo software.
 El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele
cumplirse.
Según el Centro Experimental de Ingeniería de Software (CEIS) 12, el estudio de mercado The Chaos Report
realizado por Standish Group Internactional13 en 1996, concluyó que sólo un 16% de los proyectos de
software son exitosos (terminan dentro de plazos y costos y cumplen los requerimientos acordados). Otro 53%
sobrepasa costos y plazos y cumple parcialmente los requerimientos. El resto ni siquiera llega al término.
Algunas deficiencias comunes en el desarrollo de software son:
 Escasa o tardía validación con el cliente.
 Inadecuada gestión de los requisitos.
 No existe medición del proceso ni registro de datos históricos.
 Estimaciones imprevistas de plazos y costos.
 Excesiva e irracional presión en los plazos.
 Escaso o deficiente control en el progreso del proceso de desarrollo.
 No se hace gestión de riesgos formalmente.
 No se realiza un proceso formal de pruebas.
 No se realizan revisiones técnicas formales e inspecciones de código.
El primer reconocimiento público de la existencia de problemas en la producción de software tuvo lugar en la
conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch (Alemania), dicha
situación problemática se denominó crisis del software. En esta conferencia, así como en la siguiente
realizada en Roma en 1969, se estipuló el interés hacia los aspectos técnicos y administrativos en el
desarrollo y mantenimiento de productos software. Se pretendía acordar las bases para una ingeniería de
construcción de software. Según Fritz Bauer [2] lo que se necesitaba era ―establecer y usar principios de
ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente
sobre máquinas reales‖. Esta definición marcaba posibles cuestiones tales como: ¿Cuáles son los principios
robustos de la ingeniería aplicables al desarrollo de software de computadora? ¿Cómo construimos el
software económicamente para que sea fiable? ¿Qué se necesita para crear programas de computadora que
funcionen eficientemente no en una máquina sino en diferentes máquinas reales?. Sin embargo, dicho
planteamiento además debía incluir otros aspectos, tales como: mejora de la calidad del software, satisfacción
del cliente, mediciones y métricas, etc.
12
http://www.ceis.cl/Gestacion/Gestacion.htm (5.3.2003)
13
http://standishgroup.com/ (5.3.2003)
El ―IEEE Standard Glossary of Software Engineering Terminology‖ (Stad. 610.12-1990) ha desarrollado una
definición más completa para ingeniería del software [1]: ―(1) La aplicación de un enfoque sistemático,
disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación
de ingeniería al software. (2) El estudio de enfoques en (1)‖.
Pressman [1] caracteriza la Ingeniería de Software como ―una tecnología multicapa‖, ilustrada en la Figura 3.
Figura 3. Capas de la Ingeniería de Software.

Dichas capas se describen a continuación:
 Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un esfuerzo de
organización de calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura
continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la
ingeniería del software.
 El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco de trabajo
para un conjunto de áreas clave, las cuales forman la base del control de gestión de proyectos de
software y establecen el contexto en el cual: se aplican los métodos técnicos, se producen resultados de
trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.
 Los métodos de la ingeniería de software indican cómo construir técnicamente el software. Los métodos
abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas,
pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiern an
cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.
 Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-automático
para el proceso y los métodos, a estas herramientas se les llama herramientas CASE (Computer-Aided
Software Engineering).
Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de calidad (tanto en
su forma final como durante su elaboración), mediante un proceso apoyado por métodos y herramientas.
A continuación nos enfocaremos en el proceso necesario para elaborar un producto de software.
El proceso de desarrollo del software
Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto
software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la Figura 4
[3]. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas
[4]. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro
proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos
esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades
asociadas al desarrollo de software y que influyen en su proceso de construcción.
Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un
programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación
exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de
variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el
cual se ejecuta, etc.).
Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y
sus requisitos, sobre todo cuando no se tiene precedentes en productos software similar. Esto hace que los
requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no
sólo después de entregado en producto sino también durante el proceso de desarrollo.
Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como
disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no
es más que un inútil consuelo.
Requisitos nuevos Sistema nuevo
o modificados o modificado
Proceso de Desarrollo
de Software
Figura 4. Proceso de desarrollo de software.
El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo
para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un
proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades
fundamentales que se encuentran presentes en todos ellos [4]:
9. Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe
cumplir el software.
10. Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación.
11. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.
12. Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.
Además de estas actividades fundamentales, Pressman [1] menciona un conjunto de ―actividades
protectoras‖, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación:
13. Seguimiento y control de proyecto de software.
14. Revisiones técnicas formales.
15. Garantía de calidad del software.
16. Gestión de configuración del software.
17. Preparación y producción de documentos.
18. Gestión de reutilización.
19. Mediciones.
20. Gestión de riesgos.
Pressman [1] caracteriza un proceso de desarrollo de software como se muestra en la Figura 5. Los
elementos involucrados se describen a continuación:
 Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que
son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad.
 Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de
proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que
las actividades del marco de trabajo se adapten a las características del proyecto de software y los
requisitos del equipo del proyecto.
 Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del
software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de
cualquier actividad del marco de trabajo y aparecen durante todo el proceso.
Figura 5. Elementos del proceso del software
Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer
las relaciones entre elementos que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe
hacerlo [5].
Figura 6. Relación entre elementos del proceso del software

En la Figura 6 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. Así las
interrogantes se responden de la siguiente forma:
 Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles
específicos.
 Qué: Un Artefacto14 es producido por un Rol en una de sus Actividades. Los Artefactos se especifican
utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando
ciertas Notaciones.
 Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de
desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado
de terminación de ciertos Artefactos.
14
Un artefacto es una pieza de información que (1) es producida, modificada o usada por el proceso, (2) define un área de responsabilidad para un rol
y (3) está sujeta a control de versiones. Un artefacto puede ser un modelo, un elemento de modelo o un documento.
La composición y sincronía de las actividades está basada en un conjunto de Principios y Prácticas. Las
Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo:
desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente,
verificar continuamente la calidad, gestionar los cambios, etc.
Modelos de proceso software
Sommerville [4] define modelo de proceso de software como ―Una representación simplificada de un proceso
de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados,
por lo tanto un modelo de procesos del software es una abstracción de un proceso real.‖
Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son
abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software.
Modelos que se van a discutir a continuación:
 Codificar y corregir
 Modelo en cascada
 Desarrollo evolutivo
 Desarrollo formal de sistemas
 Desarrollo basado en reutilización
 Desarrollo incremental
 Desarrollo en espiral
Codificar y corregir (Code-and-Fix)
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:
 Escribir código.
 Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y
mantenimiento.
Este modelo tiene tres problemas principales [7]:
 Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los
arreglos sean muy costosos.
 Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que
es rechazado o su reconstrucción es muy cara.
 El código es difícil de reparar por su pobre preparación para probar y modificar.
Modelo en cascada
El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería [8]. Éste
toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las
representa como fases separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios
del sistema. Se busca hacer esta definición en detalle.
2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la
arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los
componentes del sistema.
3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan
pruebas de cada unidad.
4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se
entrega el conjunto probado al cliente.
5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se
realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican
nuevos requisitos.
La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como resultado documentos que
deben ser aprobados por el usuario.
Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los
problemas encontrados en fases previas.
Figura 1: Modelo de desarrollo en cascada.

En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de
desarrollo. Algunos problemas que se observan en el modelo de cascada son:
 Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de
documentos.
 Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes
fases.
 Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o
corregidos de una forma poco elegante.
 Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo
tiempo de entrega del producto.
 Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios
en los requisitos.
Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos
grandes.
Desarrollo evolutivo
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los
comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6
se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el
desarrollo de las versiones hasta llegar al producto final.
Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades
de especificación, desarrollo y pruebas se ejecutan en cada iteración.
Figura 2: Modelo de desarrollo evolutivo.

Existen dos tipos de desarrollo evolutivo:
 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar
a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona
conforme se añaden nuevas características propuestas por el usuario.
 Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la
calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos
que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo
ayuda a terminar de definir estos requisitos.
Entre los puntos favorables de este modelo están:
 La especificación puede desarrollarse de forma creciente.
 Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora
de la calidad del software.
 Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.
Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:
 Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se
necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.
 Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura
del software haciendo costoso el mantenimiento.
 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden
ser incompatibles con otras o que poca gente sabe utilizar.
Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta
500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión.
Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un
prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los
subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de
usuario se puede especificar utilizando un enfoque exploratorio.
Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.
Desarrollo
Desiciones Formal
Especificación
Código
Informal
Tranformación Transformación Fuente
Especificación
Especificación Interactiva Especificación Automática
de alto nivel de bajo nivel
(prototipo)
Optimización
Validación de
Especificación
Mantenimiento
Figura 3: Paradigma de programación automática.

La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación automática. Se distinguen dos
fases globales: especificación (incluyendo validación) y transformación. Las características principales de este
paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la
especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la
especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene
una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la
especificación (no sobre el código fuente), la documentación es generada automáticamente y el
mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación).
Observaciones sobre el desarrollo formal de sistemas:
 Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que
verifican la correspondencia con la especificación no son necesarias.
 Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.
 Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.
Desarrollo basado en reutilización
Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4
fases ilustradas en la Figura 8. A continuación se describe cada fase:
1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en
cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los
componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que
seguir buscando componentes más adecuados (fase 1).
3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe
tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.
4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los
componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.
Las ventajas de este modelo son:
 Disminuye el costo y esfuerzo de desarrollo.
 Reduce el tiempo de entrega.

 Disminuye los riesgos durante el desarrollo.
Figura 4: Desarrollo basado en reutilización de componentes
Desventajas de este modelo:

 Los ―compromisos‖ en los requisitos son inevitables, por lo cual puede que el software no cumpla las
expectativas del cliente.
 Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del
sistema.
Procesos iterativos
A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las
iteraciones:
 Desarrollo Incremental.
 Desarrollo en Espiral.
Desarrollo incremental
Mills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el
proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir
experiencia con el sistema (ver Figura 9). Es una combinación del Modelo de Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones
hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del
conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede
optar por cascada, si es dudoso, evolutivo.
Figura 5: Modelo de desarrollo iterativo incremental.

Entre las ventajas del modelo incremental se encuentran:
 Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo
desde el primer incremento.
 Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.
 Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.
 Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en
estos módulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
 Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
 Cada incremento debe aumentar la funcionalidad.

 Es difícil establecer las correspondencias de los requisitos contra los incrementos.
 Es difícil detectar las unidades o servicios genéricos para todo el sistema.

Desarrollo en espiral
El modelo de desarrollo en espiral (ver Figura 10) es actualmente uno de los más conocidos y fue propuesto
por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades
sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
4. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto.
Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran
estrategias alternativas dependiendo de estos.
5. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden
desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para
reducir los riesgos.
6. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El
modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado
para esa fase.
7. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.
Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad
importante en la administración del proyecto.
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas
alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos
con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se
planifica la siguiente fase.
Figura 6: Modelo de desarrollo en Espiral
¿Cuál es el modelo de proceso más adecuado?

Cada proyecto de software requiere de una forma de particular de abordar el problema. Las propuestas
comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración puede utilizarse
uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definición de
requisitos, tamaño del proyecto, riesgos identificados, entre otros).
En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la selección de
un modelo de proceso [10], la medida utilizada indica el nivel de efectividad del modelo de proceso de acuerdo
al criterio (Por ejemplo: El modelo Cascada responde con un nivel de efectividad Bajo cuando los Requisitos y
arquitectura no están predefinidos):
Modelo de Desempeño Permite
Produce Visibilidad
proceso si no se Gestión de cambio
software del
/ predefinen riesgos sobre la
fiable progreso
Criterio requisitos marcha
Codificar y
Bajo Bajo Bajo Alto Medio
corregir
Desarrollo
Bajo Alto Bajo Bajo Bajo
en cascada
Desarrollo
Alto Medio Medio Alto Alto
Evolutivo
Desarrollo
Bajo a
formal de Bajo Alto Bajo Bajo
Medio
sistemas
Desarrollo
Bajo a
basado en Medio Bajo a Alto Alto Alto
Medio
reutilización
Desarrollo
Bajo Alto Medio Medio Bajo
Incremental
Desarrollo
Alto Alto Alto Medio Medio
Espiral
Tabla 1. Comparación entre modelos de proceso de software.

ANEXO7
ANALISIS Y DISEÑO ORIENTADO A OBJETOS

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
Las Herramientas a aplicar son las siguientes:
Herramienta Preguntas que responde

Requerimientos ¿Cuáles son las necesidades o deseos del producto?
Casos de uso ¿Cuáles son los procesos del dominio?
Modelo conceptual ¿Cuáles son los conceptos, los términos?
Diagramas de secuencia ¿Cuáles son los eventos y las operaciones del sistema?
Contratos ¿Qué hacen las operaciones del sistema?
Diagramas de estado ¿Cuáles son los estados de los objetos en los eventos?
Diagramas de ¿Cómo hacen los objetos para cumplir con las
colaboración operaciones?
La habilidad más importante en el análisis y diseño orientado a objetos es asignar

eficientemente las responsabilidades a los componentes de software.
En segundo lugar aparece la determinación de las clases de objetos.
Durante el análisis y diseño orientado a objetos, se procura identificar, describir y definir los
objetos que finalmente serán implementados en un lenguaje de programación orientado a
objetos.
Ejemplo: Un juego de dados.

Se tiene un juego de dados en que un jugador lanza dos dados. Si el total obtenido es siete,
el jugador gana, de lo contrario pierde.
1. Definición de casos de uso

Los casos de uso son descripciones narrativas en lenguaje natural de los procesos del
dominio en un formato estructurado de prosa. Los casos de uso no son propiamente un
elemento del análisis y diseño orientado a objetos (pueden ser utilizados en análisis no
orientados a objetos), pero constituyen un paso preeliminar muy útil porque describen las
especificaciones de un sistema.
Caso de uso: Jugar un juego.
Participantes: Jugador.
Descripción: Este caso de uso comienza cuando el jugador recoge y tira los dados.
Si los puntos suman siete, gana y pierde si suman cualquier otro número.
El diagrama UML correspondiente sería similar a este:
2. Definición de un modelo conceptual

Un modelo conceptual muestra gráficamente, a través de un grupo de diagramas, los
conceptos (clases de objetos), los atributos y las asociaciones más importantes del
dominio.
3. Definición de los diagramas de colaboración

Los diagramas de colaboración representan el flujo de mensajes entre las instancias
y la invocación de métodos.
Notación: Clases de objetos e instancias de las clases (objetos).

4. Definición del diseño de clases
Para definir las clases de objetos se deben contestar dos preguntas: ¿cómo se conectan
unos objetos a otros? y ¿cuáles son los métodos de cada clase?. Un diagrama de diseño de
clases contesta estas preguntas. El siguiente es un ejemplo del diagrama de diseño de
clases del juego de dados.
Análisis y diseño
La mayoría de proyectos de software son complejos, y la estrategia primaria para superar la
complejidad, es la descomposición (divide y vencerás). La estrategia es dividir el problema
en unidades más pequeñas que sean manejables. Un enfoque tradicional para realizar esto
fue el análisis y diseño estructurados, donde se trata de descomponer el problema en
funciones o procesos. Este método origina una división jerárquica de procesos constituidos
por sub-procesos. Por ejemplo, una descomposición por funciones o procesos en análisis y
diseño estructurados, de un Sistema de Información de Biblioteca podría ser el siguiente:
Otra forma de realizar la descomposición, es usando un esquema de análisis y diseño
orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no
en funciones. Por ejemplo, una descomposición orientada a objetos del Sistema de
Información de Biblioteca podría ser la siguiente:
Algunas de las tareas a realizarse en la etapa de análisis son las siguientes:

1. Definir los requerimientos.
2. Definir los casos esenciales de uso.
3. Crear y perfeccionar los diagramas de casos de uso.
4. Crear y perfeccionar el modelo conceptual.
5. Crear y perfeccionar el glosario.
6. Definir los diagramas de secuencia de los sistemas.
7. Definir los contratos de operaciones.
Algunas de las tareas a realizarse en la etapa de diseño son las siguientes:
1. Definir los casos reales de uso.
2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas.
3. Perfeccionar la arquitectura del sistema.
4. Definir los diagramas de interacción.
5. Definir los diagramas de diseño de clases.
6. Definir el esquema de la base de datos.
Caso de estudio: el punto de venta

Supongamos como caso de estudio el sistema de una terminal de punto de venta. Esta
terminal es un sistema automatizado con el que se registran las ventas y se realizan los
pagos. Por lo general este tipo de sistemas comprenden hardware (un computador y un
lector de código barras) y software (el sistema que se ejecuta en la terminal). Suponga que
se nos ha contratado para crear este software.
Los requerimientos
Los requerimientos son una descripción de las necesidades o deseos de un producto. La
meta principal en esta etapa es identificar y documentar lo que en realidad se necesita, en
una forma en que pueda fácilmente ser transmitido al cliente y al equipo de desarrollo. Se
recomienda aquí definir al menos los siguientes puntos:
· Panorama general
· Metas
· Funciones del sistema
· Atributos del sistema
a) Panorama general
Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se
utilizará en las ventas al menudeo.
b) Metas
En términos generales, la meta es una mayor automatización del pago en las cajas
registradoras, y dar soporte a servicios más rápidos, más baratos y mejores. Más
concretamente, la meta incluye:
· Pago rápido de los clientes.
· Análisis rápido y exacto de las ventas.
· Control automático del inventario.
c) Funciones del sistema
Las funciones del sistema son lo que éste deberá de hacer. Hay que identificar estas
funciones y listarlas en grupos lógicos. Para verificar que X es en verdad una función del
sistema, la siguiente frase deberá tener sentido: "El sistema deberá hacer X". Por ejemplo: "el
sistema deberá autorizar pagos a crédito".
Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las
evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas
también deben realizarse, y puede que no sean visibles para el usuario. Muchas de estas
funciones se omiten (erróneamente) durante el proceso de obtención de requerimientos.
Las superfluas son opcionales, y su inclusión no repercute significativamente en el costo
ni en otras funciones.
Las siguientes son algunas de las funciones más representativas del sistema de punto de venta:
Funciones básicas:
Referencia Función Categoría
R1.1 Registra la venta en proceso (actual): los productos comprados. evidente

R1.2 Calcula el total de la venta actual; se incluye el impuesto. evidente
Captura la información sobre el objeto comprado usando su

R1.3 código de barras y un lector, o usando una captura manual de un evidente
código de producto.
R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta
R1.5 Se registran las ventas efectuadas. oculta
R1.6 El cajero debe introducir una identificación y una contraseña evidente

para poder utilizar el sistema.
R1.7 Ofrece un mecanismo de almacenamiento persistente. oculta

R1.8 Ofrece mecanismos de comunicación entre los procesos y oculta
entre los sistemas.
R1.9 Muestra la descripción y el precio del producto registrado. evidente
Funciones de pago:
Referencia Función Categoría
R2.1 Maneja los pagos en efectivo, capturando la cantidad evidente

ofrecida y calculando el saldo deudor.
Maneja los pagos a crédito, capturando la información

R2.2 crediticia a partir de una lectora de tarjetas, o mediante evidente
captura manual, y autorizando los pagos con el servicio de
autorización (externa) de créditos de la tienda a través de una
conexión por modem.
Maneja los pagos con cheque, capturando el número de RUT y
R2.3 teléfono mediante captura manual, y autorizando los pagos con el evidente
servicio de autorización (externo) de cheques de la tienda a través
de consulta telefónica.
R2.4 Registra los pagos en el sistema de cuentas por cobrar, pues el oculta
servicio de autorización de crédito debe a la tienda el monto del
pago.
d) Atributos del sistema
Los atributos del sistema son cualidades no funcionales que a menudo se confunden con
las funciones. Por ejemplo: facilidad de uso, tolerancia a fallas, tiempo de respuesta,
metáfora de interfaz, plataformas.
Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser
valores discretos, confusos o simbólicos. Por ejemplo:
Tiempo de respuesta = (psicológicamente correcto)
Metáfora de interfaz = (gráfico, colorido, basado en formularios)
Algunos atributos del sistema también pueden tener restricciones de frontera del atributo,
que son condiciones obligatorias de frontera, generalmente en un rango numérico de
valores de un atributo. Por ejemplo:
Tiempo de respuesta = (dos segundos como
máximo) Algunos atributos del sistema de punto de
venta son:
Atributo Detalles y restricciones de frontera
Tiempo de (restricción de frontera) Cuando se registre un producto
respuesta vendido, la descripción y el precio aparecerán en un segundo.
(detalle) Ventanas orientadas a la metáfora de un formulario y
Metáfora de cuadros de diálogo.
interfaz
(detalle) Maximiza una navegación fácil con teclado y no con mouse.
(restricción de frontera) Debe registrar los pagos a crédito autorizados
Tolerancia a fallas que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun
cuando se produzcan fallas de energía o del equipo.
Plataformas del (detalle) Microsoft Windows xxx.
sistema operativo
Finalmente, es conveniente describir todos los atributos del sistema que se relacionen
claramente con las funciones especificadas. Además, los detalles de los atributos y las
restricciones de frontera pueden catalogarse como obligatorios u opcionales. Por ejemplo:
Ref. Función Categoría Atributo Detalles y Categoría

restricciones
Mostrar la descripción y Tiempo de 1 segundo
R1.9 el precio del producto Evidente respuesta como máximo Obligatorio
registrado.
Metáfora de Pantallas basadas

interfaz en formularios. Obligatorio
Con colores.
Registrar los pagos a Debe registrar en las

crédito en el sistema de cuentas por cobrar en
cuentas por cobrar, Tolerancia a un plazo de 24 horas,
R2.4 pues el servicio de Oculto fallas aun cuando se Obligatorio
autorización de crédito produzcan fallas de
debe a la tienda el energía o del equipo.
importe del pago.
Tiempo de 10 segundos Obligatorio

respuesta como máximo
Casos de uso
Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos
del sistema. Un caso de uso es un documento narrativo que describe la secuencia de
eventos de un actor (agente externo) que utiliza un sistema para completar un proceso.
Para especificar los casos de uso en el lenguaje UML, se utiliza una elipse que encierra el
nombre del caso.
El formato para la descripción de los casos de uso es el siguiente:
Caso de uso: Nombre del caso de uso
Actores: Lista de actores (agentes externos), en la cual se

indica quién inicia el caso de uso
Propósito: Intención del caso de uso

Resumen: Repetición del caso de uso de alto nivel o alguna
síntesis similar.
Tipo: Los casos primarios de uso
representan los procesos comunes
más importantes. Los casos
secundarios de uso representan
procesos menores o raros.
Finalmente, los casos opcionales de
uso representan procesos que
pueden no abordarse.
Referencias Cruzadas: Casos relacionados de uso y funciones también
relacionadas del sistema
Descripción: Descripción del caso de uso.
Precondición: La precondición está formada por el conjunto de

condiciones que se tienen que cumplir para que se
pueda iniciar un caso de uso. En muchos casos
supone la ejecución de casos de uso previos.
PostCondición: La postcondición refleja el estado en que se queda el
sistema una vez ejecutado el caso de uso
Ejemplo: el uso del sistema de punto de venta:
Caso de uso: Comprar productos en efectivo
Actores: Cliente (iniciador), Cajero
Propósito: Capturar una venta y su pago en efectivo
Resumen: Un Cliente llega a la caja registradora con artículos
que desea comprar. El Cajero registra los productos y
recibe un pago en efectivo. Al terminar la operación, el
Cliente se marcha con los productos comprados.
Tipo: Primario y esencial
Referencias Cruzadas: Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1.
Descripción: Un Cliente llega a la caja registradora con los artículos
que va a comprar. El Cajero registra los artículos y
cobra el importe. Al terminar la operación, el Cliente se
marcha con los productos.
Precondición: Registro de Articulo
PostCondición: Generación de Factura
La siguiente figura muestra un diagrama parcial de casos de uso para el sistema de

punto de venta (TPDV).
Este esquema tiene por objeto ofrecer una clase de diagrama contextual que nos permita
conocer rápidamente los actores externos de un sistema y las formas básicas en que lo
utilizan.
Un caso de uso describe la interacción con un sistema. Las fronteras del sistema se
representan en el diagrama por un rectángulo exterior. Las fronteras corresponden a: la
frontera hardware/software de un dispositivo o sistema de cómputo, un departamento de una
organización, o la organización entera.
Curso normal de los eventos:
Acción del actor Respuesta del sistema

1. Este caso de uso comienza cuando un
cliente llega a una caja del terminal de punto
de venta (TPV) con productos para comprar.
2. El Cajero registra el identificador de cada 3. Determina el precio del producto e

producto. Si hay varios productos de una incorpora a la transacción actual la
misma categoría, el Cajero también puede información correspondiente.
introducir la cantidad.
4. Al terminar de introducir los productos, el 5. Calcula y presenta el total de

Cajero indica al TPV que se concluyo la captura la venta.
de los mismos.
6. El Cajero le indica el total al cliente.
7. El Cliente efectúa un pago en efectivo,

posiblemente mayor que el total de la
venta.
8. El Cajero registra la cantidad de efectivo 9. Muestra al Cajero y al Cliente la
recibida. diferencia. Genera la boleta.
10. El cajero deposita el efectivo recibido en la 11. Registra la venta concluida.

caja, y extrae el cambio.
12. El cliente se marcha con los

artículos comprados.
Cursos alternos
- Item 2: Introducción de identificador inválido. Indicar error.

- Item 7: El cliente no tiene suficiente dinero. Cancelar transacción de
venta o restar productos.
Definiciones
Los casos de uso se emplean para capturar el comportamiento deseado del sistema en
desarrollo, sin tener que especificar cómo 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. Además ayudan a validar la
arquitectura y a verificar el sistema mientras evoluciona a lo largo del desarrollo. Por lo
general el nombre de un caso de uso comienza con un verbo en infinitivo. Un caso de uso
describe un proceso de principio a fin, es decir, una secuencia de eventos, las acciones y las
transacciones que se requieren para realizarlo. Debe ser posible revisar en las referencias
cruzadas, que todas las funciones (de los requerimientos) hayan sido asignadas.
Fronteras
Un caso de uso define la interacción con un sistema. Las fronteras del sistema normalmente
son: la frontera software/hardware de un dispositivo o sistema de cómputo, el departamento
de una organización, la organización entera. Las fronteras son importantes para definir lo
que es interno y externo al sistema. El ambiente externo está representado exclusivamente
por los actores. Las dos siguientes figuras muestran dos fronteras diferentes para el mismo
sistema.
Casos de uso y actores cuando el sistema TPV es la frontera.
Casos de uso y actores cuando la tienda es la frontera.

Objetos, clases y herencia
Actores
Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos
de uso cuando interactúan con éstos. Los actores pueden ser personas (roles que
desempeñan las personas), aparatos eléctricos o mecánicos, y otros sistemas de
cómputo. Se pueden definir categorías generales de actores (como cliente en el ejemplo
de abajo) y especializarlos (como ClienteComercial) a través de relaciones de
generalización. Ejemplo:
Los casos de uso pueden ser versiones especializadas de otros casos de uso, casos de
uso incluidos como parte de otros casos de uso, y casos de uso que extienden el
comportamiento de otros casos de uso básicos.
Organización de casos de uso

Los casos de uso pueden organizarse agrupándolos en paquetes. También se pueden
especificar relaciones de generalización, inclusión y extensión. Generalización significa que
el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre, donde el
hijo puede agregar o redefinir el comportamiento del padre. La generalización entre casos de
uso se representa como una línea continua con una punta de flecha vacía.
Una relación de inclusión (<<include>>) entre dos casos de uso significa que un caso de uso
base incorpora explícitamente el comportamiento de otro caso de uso en el lugar especificado
en el caso base. Aquí el caso de uso base toma el comportamiento del caso de uso
proveedor. Esta relación se usa para evitar describir el mismo flujo de eventos repetidas
veces, poniendo el comportamiento común en un caso de uso aparte (que será incluido por
un caso base). Una relación de inclusión se representa como una dependencia, usando la
palabra include. Para especificar la posición en un flujo de eventos, se usa la palabra include
seguido del caso de uso que se quiere incluir. Por ejemplo, para describir el flujo de Seguir
pedido:
Flujo de eventos principal: Obtener y verificar el número de pedido. include
(validar usuario). Examinar el estado de cada parte del pedido y preparar un
informe para el usuario.
Una relación de extensión entre casos de uso significa que un caso de uso base incorpora
implícitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente
por el caso de uso que extiende al base. Un caso de uso puede extenderse solamente en
ciertos puntos, llamados puntos de extensión. La extensión se puede ver como que el caso
de uso que extiende, incorpora su comportamiento en el caso de uso base. Se representa
como una dependencia con la palabra <<extend>>. Los puntos de extensión sólo son
etiquetas que pueden aparecer en el flujo del caso de uso base. Por ejemplo, el flujo de
Hacer pedido podría escribirse así:
Flujo de eventos principal: include (Validar usuario). Recoger los ítemes del pedido del
usuario. (Establecer prioridad). Enviar el pedido para ser procesado.
Una relación de extensión se usa para modelar la parte de un caso de uso que el usuario
puede ver como comportamiento opcional del sistema. De esta forma se separa el
comportamiento opcional del obligatorio. Es decir, un caso de uso base puede, bajo ciertas
condiciones, incorporar el comportamiento de otro caso de uso en el lugar especificado.
Ejemplo 1: Sistema de ventas. Un sistema de ventas debe interactuar con clientes, los
cuales efectúan pedidos. Además, los clientes pueden hacer un seguimiento de sus propios
pedidos. El sistema envía los pedidos y las facturas a los clientes. En algunos casos, según
la urgencia de los clientes, se puede adelantar parte del pedido (pedidos parciales).
Como se muestra en la figura anterior, el comportamiento de este sistema se puede

modelar usando los casos de uso Hacer pedido, Seguir pedido, Enviar pedido, Facturar
cliente. El comportamiento común puede factorizarse (Validar cliente) y también pueden
distinguirse sus variantes (Enviar pedido parcial). Cada caso de uso debe incluir una
especificación de su comportamiento.
Ejemplo 2: Validación de tarjetas de crédito. La figura de abajo muestra el contexto de un
sistema de validación de tarjetas de crédito. Se puede ver que existen dos categorías de
clientes: clientes individuales, clientes corporativos. Estos actores representan los roles que
juegan las personas que interactúan con el sistema. También hay actores que representan
otras instituciones, como Comercio, con el cual el cliente realiza una transacción para
comprar un artículo o servicio, y Entidad financiera, que por lo general es una entidad
bancaria donde el usuario tiene la tarjeta de crédito.
Modelado del contexto de un sistema

Modelo conceptual
Un modelo conceptual explica los conceptos más significativos en un dominio del problema,
identificando los atributos y las asociaciones, y es la herramienta más importante del análisis
orientado a objetos. Los casos de uso son una importante herramienta para el análisis de
requerimientos, pero realmente no están orientados a objetos. Un modelo conceptual
representa cosas del mundo real, no componentes del software. En UML se representa
mediante un grupo de diagramas de estructura estática donde no se define ninguna
operación. En estos diagramas se muestran conceptos (objetos), asociaciones entre
conceptos (relaciones) y atributos de conceptos (atributos). La siguiente figura muestra un
modelo conceptual parcial del dominio de la tienda y las ventas.
Un modelo conceptual es una descripción del dominio de un problema real, no es una

descripción del diseño del software. Debido a esto, no es conveniente aquí incluir elementos
como ventanas o bases de datos.
En el dominio real de comprar productos en una tienda usando una terminal de punto de
venta (TPDV), intervienen tres conceptos principales: tienda, TPDV y una venta.
Por lo general es mejor exagerar un poco y especificar un modelo conceptual con muchos
conceptos. Esto debido a que es frecuente omitir conceptos durante el análisis, y al
descubrirlos más tarde, es más difícil incorporarlos.
La siguiente lista muestra un conjunto de conceptos idóneos para ser incluidos en el
modelo conceptual.
Categoría del concepto Ejemplos

Objetos físicos o tangibles TDPV, Dado
Especificaciones, diseño o descripciones de EspecicacióndeProducto, ReglasdeJuego
cosas
Lugares Tienda, MesadeJuego
Transacciones Venta, Pago, Reservacion, Apuesta
Línea o renglón de un elemento de transacciones VentasLineadeProducto
Rol de las personas Cajero, Gerente, Jugador
Contenedores de otras cosas Tienda, Cesto, Biblioteca
Cosas dentro de un contenedor Producto, Libro
Otros sistemas de cómputo o SistemaAutorizacionTarjetasdeCredito
electromecánicos externos al sistema
Conceptos de nombres abstractos Hambre, Suerte
Organizaciones DepartamentodeVentas, LineaAerea
Eventos Venta, Robo, Junta, Vuelo, Accidente,
RodarDados
Procesos (A menudo no están representados VentaUnProducto, ReservacionAsiento
como conceptos, pero pueden estarlo)
Reglas y políticas PoliticadeReembolso,
PoliticadeCancelacione
s
Catálogos CatalogodeProductos, CatalogodeLibros
Registros de finanzas, de trabajo, de contratos, Recibo, Mayor, ContratodeEmpleo
de asuntos legales
Instrumentos y servicios financieros LineadeCredito, Existencia
Manuales y libros ManualdePersonal, ManualdeReparaciones
Otra forma simple de obtener conceptos, es identificarlos de un análisis semántico de
las descripciones textuales referentes al dominio del problema. Para hacer esto, los
casos de uso expandidos proveen una buena fuente de conceptos. Por ejemplo, el caso
de uso Comprar productos:
Acción de los actores Respuesta del sistema
1. Este caso de uso comienza cuando
un Cliente llega a una caja de TPV con
los productos que desea comprar.
2. El Cajero registra el código de barras 3. Determina el precio del producto y a la

de cada producto. Si hay más de un transacción de venta le agrega la información
producto, el Cajero puede introducir sobre el producto. Se muestra la descripción y
también la cantidad. el precio del producto actual.
A partir de la lista de categorías de conceptos podemos generar un conjunto de conceptos

para nuestro problema del punto de venta:
TPV EspecificaciondeProducto
Producto VentasLineadeProductos
Tienda Cajero
Venta Cliente
Pago Gerente
CatalogodeProductos
¿Se debería incluir la boleta que imprime el punto de venta? Esta boleta es un informe del
sistema, y dado que toda su información proviene de otros objetos, no es necesario incluirlo.
Sin embargo, es posible que en una etapa posterior (por ejemplo cuando se implemente
devolver productos) se justifique su inclusión.
Por tanto, el modelo conceptual inicial del sistema de punto de venta (sin incluir
atributos ni asociaciones) sería:
Falta ahora agregar los atributos relevantes de cada concepto, y las asociaciones.
Atributos
Un atributo es un valor lógico de un dato de un objeto. Es preferible que los atributos sean
simples. Entre los tipos de atributos más comunes se encuentran: booleanos (o lógicos),
fechas, números, texto y horas. Algunos tipos comunes son: dirección, color, teléfono,
RUT, código de barras, código postal.
Los atributos no deberían usarse para relacionar conceptos en el modelo conceptual,

solamente para describir estos conceptos. Una de las violaciones más comunes a esta
regla consiste en agregar atributos como llaves foráneas. Por ejemplo:
Uno de los errores más frecuentes al crear modelos conceptuales, es representar algo como
un atributo, cuando debería haber sido un concepto aparte. Una regla práctica para evitar
esto es: si en el mundo real no consideramos algún concepto X como número o texto,
probablemente X sea un concepto y no un atributo.
Por ejemplo, en un dominio de reservaciones en líneas aéreas, ¿el Destino debería ser un
atributo de Vuelo u otro concepto?
En el mundo real, un aeropuerto de destino no se considera número ni texto, por lo que

debería ser un concepto.
Sugerencia: En caso de duda, convierta el atributo en un concepto
independiente. Otro error común, es incluir atributos con multiplicidad mayor
que 1. Por ejemplo:
Asociaciones
Una asociación es una relación entre dos conceptos que indica alguna conexión significativa
entre ellos. Las asociaciones útiles a determinar, suelen incluir el conocimiento de una
relación que ha de preservarse por algún tiempo: puede tratarse de milisegundos o de años
(según el contexto). Por ejemplo, ¿debemos recordar cuales instancias de
VentasLineadeProducto están asociadas a Venta? Claro que si, porque de lo contrario no
sería posible reconstruir la venta, imprimir la boleta ni calcular el total de la venta. Por otra
parte, ¿necesitamos recordar una relación entre una Venta y Gerente? Probablemente no es
indispensable ni útil dentro del contexto de nuestros requerimientos.
Una asociación se representa como una línea entre conceptos, con el nombre de la
asociación. La asociación es intrínsecamente bidireccional, es un posible nexo lógico entre
los objetos. Este nexo es totalmente abstracto, no es una afirmación sobre las conexiones
entre las entidades del software. Los extremos de una asociación pueden contener una
expresión de multiplicidad que indica la relación numérica entre las instancias de los
conceptos. Opcionalmente se puede poner una flecha que indique la dirección en que debe
leerse el nombre de la asociación (no indica nada más, es sólo una ayuda para leer el
diagrama).
Para identificar las asociaciones más comunes, la siguiente lista es de gran ayuda.
Categoría de la asociación Ejemplos

A es una parte física de B Caja-TPDV
A es una parte lógica de B VentasLíneadeProducto-Venta
A está físicamente contenido en B TPDV-Tienda, Producto-
Estante
A está contenido lógicamente en B DescripcióndeProducto-
Catálogo
A es una descripción de B DescripcióndeProducto-
Producto
A es un elemento de línea (o renglón) en una transacción VentasLíneadeProducto-Venta
o reporte B
A se conoce/introduce/registra/presenta/captura en B Venta-TPDV
A es miembro de B Cajero-Tienda
A es una unidad organizacional de B Departamento-Tienda
A usa o dirige a B Cajero-TPDV
A se comunica con B Cliente-Cajero
A se relaciona con una transacción B Pago-Venta
A es una transacción relacionada con otra transacción B Pago-Venta
A es propiedad de B TPDV-Tienda
Las asociaciones más importantes son las siguientes:

· A es una parte física o lógica de B
· A está física o lógicamente contenido en B
· A está registrado en B
Las asociaciones son importantes, pero no se debe dedicar tiempo excesivo a ellas. Es
más importante identificar los conceptos que las asociaciones. Muchas asociaciones
tienden a confundir el modelo conceptual, en vez de aclararlo. Se pueden incorporar las
que se indican en los casos de uso, y las que se consideren necesarias para un adecuado
entendimiento del problema.
La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una instancia del
tipo B en determinado momento. Las expresiones de multiplicidad son las siguientes:
* cero o más,
muchos 1..* uno o
más
1..40 de uno a cuarenta
5 exactamente cinco
2,4,6 exactamente dos, cuatro o seis
Por ejemplo:
Los nombres de las asociaciones deben ser lo más claros posibles, y deben permitir
leer y entender fácilmente las relaciones entre conceptos. Por ejemplo:
En síntesis, para construir un modelo conceptual se deben aplicar los siguientes pasos:
1. Liste los conceptos idóneos usando la lista de categorías de conceptos.
2. Dibújelos en un modelo conceptual.
3. Incorpore las asociaciones necesarias para registrar las relaciones más
importantes (las que se deben recordar).
4. Agregue los atributos necesarios para cumplir con las necesidades de
información. El modelo conceptual de la siguiente figura muestra un conjunto de
conceptos, asociaciones y atributos idóneos para la aplicación de punto de venta.
El modelo conceptual es una herramienta de comunicación, con la cual se intenta
comprender los conceptos importantes y sus relaciones. Es también útil para transmitir este
conocimiento a otros.
Paquetes: Organización de los elementos
Veamos el caso de uso extendido del Pago con tarjeta de crédito.

Acción de los actores Respuesta del sistema
1. Este caso de uso comienza
cuando un Cliente decide
pagar con tarjeta de crédito,
una vez que le han
comunicado el total de la
venta.
2. El Cliente entrega su 3. Genera una Solicitud de pago con tarjeta de crédito y la envía a un
tarjeta de crédito al Cajero, Servicio externo de autorización de crédito, a través de un modem
quien la pasa por un lector conectado al TPV. Requiere que se registren los datos de la compra, se
de tarjetas para efectuar el transmitan, y se espera por el registro de respuesta.
pago con tarjeta de
crédito.
4. Recibe una respuesta aprobando el crédito por parte del Servicio de
autorización.
5. Registra en el sistema Cuentas por cobrar el pago con la tarjeta de
crédito y la respuesta aprobando la transacción. (El Servicio externo de
autorización le debe dinero a la tienda, y por eso Cuentas por Cobrar le
debe dar seguimiento).
6. Muestra el mensaje de autorización del crédito.
Falta considerar el caso en que la tarjeta se reprueba. El caso de uso para pago con
cheque es similar.
Después de analizar todos los casos de uso extendidos (análisis semántico), y revisar la
lista de posibles candidatos a conceptos, se obtiene la versión preliminar del modelo
conceptual.
Cuando el número de elementos del modelo conceptual empieza a ser grande, se hace
necesario buscar una forma de organizarlos, y para esto usaremos paquetes. Un paquete
UML se muestra gráficamente como una carpeta etiquetada. En su interior se pueden
incluir los paquetes subordinados.
Ejemplo:
Un elemento es propiedad del paquete en el cual está definido, pero puede referenciarse en
otros paquetes. En este caso, para referenciar el nombre de ruta se usa el nombre del
paquete y luego el nombre del elemento, de la siguiente forma:
NombrePaquete::NombreElemento. Ejemplo:
Si un elemento de un modelo depende de otro, esta dependencia puede mostrarse a través

de una relación de subordinación. Ejemplo:
Para dividir el modelo conceptual en paquetes, se deben reunir los elementos que:
- Se encuentren en la misma área o tema (estrechamente relacionados).
- Se encuentren en la misma jerarquía de tipos.
- Participen en los mismos casos de uso.
Es conveniente crear un paquete llamado Conceptos del dominio, para agrupar todos
los elementos del modelo conceptual. Los conceptos comunes compartidos por la
mayoría de paquetes, se pueden agrupar en un paquete llamado Elementos básicos.
De esta forma, el modelo conceptual del Sistema de TPV podría organizarse de la
siguiente manera:
Los Patrones de Software
Los patrones de software describen un problema que ocurre repetidas veces en algún contexto
determinado del proceso de desarrollo de software, y entregan una buena solución ya probada.
Esto ayuda a diseñar correctamente en menos tiempo, ayuda a construir problemas
reutilizables y extendibles, y facilita la documentación y la comunicación con otros miembros
del equipo de desarrollo.
La idea de patrones de software tuvo su origen del campo de la arquitectura. Christopher
Alexander, un arquitecto, escribió dos libros revolucionarios que describían patrones en
arquitectura de construcción y planificación urbana: A Pattern Language: Towns, Buildings,
Construction (Oxford University Press, 1977) y The Timeless Way of Building (Oxford
University Press, 1979). Las ideas presentadas en estos libros son aplicables a varios campos
además de la arquitectura, incluyendo el software. En 1987, Ward Cunningham y Kent Beck
usaron algunas de las ideas de Alexander y desarrollaron cinco patrones para el diseño de
interfaces de usuario (UI), que publicaron en un artículo de OOPSLA'87 llamado Using Pattern
Languages for Object-Oriented Programs. En 1994 Erich Gamma, Richard Helm, John
Vlissides y Ralph Johnson publicaron uno de los libros más influyentes de esta década: Design
Patterns.
Este libro, también llamado "Gang of Four" (o GoF), popularizó la idea de patrones.
Ejemplo: Delegación (Patrón de Diseño)
Este es un patrón fundamental de tipo estructural. Indica cuándo no usar herencia. La
delegación es una forma de extender y reutilizar la funcionalidad de una clase, escribiendo una
clase adicional con funcionalidad extra que usa instancias de la clase original para proveer su
propia funcionalidad. La delegación es una forma de extender el comportamiento de una clase
mediante llamadas a métodos de otra clase, más que heredando de ella. La delegación es más
apropiada que la herencia en muchas situaciones. Por ejemplo, la herencia es útil para modelar
relaciones de tipo es-un o es-una, ya que estos tipos de relaciones son de naturaleza estática.
Sin embargo, relaciones de tipo es-un-rol-ejecutado-por son mal modeladas con herencia. En
este tipo de relaciones, instancias de una clase pueden jugar múltiples roles.
Por ejemplo, supongamos que tenemos el caso de una universidad donde se tienen tres tipos
de roles: estudiantes, académicos y funcionarios. Es posible representar esta situación
mediante una clase llamada Persona (o Personal-universitario) que tiene las subclases
correspondientes a cada uno de los roles.
El problema con este diagrama, es que una misma persona puede jugar más de un rol al
mismo tiempo. Alguien podría ser funcionario y a la vez estar estudiando una carrera. Del
mismo modo, alguien podría ser académico y estar ocupando un puesto administrativo. Para
modelar adecuadamente esta situación, se necesitarían 7 subclases de Persona:
Estudiante, Académico, Funcionario, AcadémicoyEstudiante, FuncionarioyEstudiante,
AcadémicoyFuncionario, EstudianteyAcadémicoyFuncionario. En este tipo de situaciones, el
número de subclases que se necesitan, se incrementa exponencialmente con el número de
roles (por ejemplo, se necesitarían 63 subclases para modelar 6 roles). Pero el problema
más serio se presenta cuando la misma persona puede jugar combinaciones distintas de
roles en distintos tiempos. La herencia es una relación estática que no cambia con el tiempo.
Para resolver esta situación, es posible representar personas en diferentes roles usando
delegación, como se muestra en la siguiente figura.
La solución general propuesta en este patrón es: incorporar la funcionalidad de la clase
original usando una instancia de la clase original y llamando sus métodos.
En el diagrama anterior, se muestra una clase con rol Delegador que usa una clase con el rol
Delegado. Aquí se usa la delegación para reutilizar y extender el comportamiento de la clase.
Patrones de Análisis
Los patrones de análisis son un conjunto de clases y relaciones entre ellas, que tienen algún
sentido en el contexto de una aplicación. Representan una estructura que puede ser válida
para otras aplicaciones.
Ejemplo 1: Casa reparadora de computadores (Eduardo Fernández)

Se tiene una casa reparadora de computadores (casa matriz) que coordina una cadena de
casas reparadoras. Los clientes traen las computadoras dañadas a alguna de estas casas, y
un técnico realiza una estimación del daño y del costo de la reparación. Si el cliente está de
acuerdo con la estimación, se asigna un técnico. Todos los eventos que ocurren durante la
reparación son guardados en una especie de "expediente" del equipo (para futuras
reparaciones).
El modelo conceptual de este problema podría ser como el siguiente:

El diagrama de modelo de estados podría ser el siguiente:
Ejemplo 2: Hospital (Eduardo Fernández)

En un hospital se atienden personas. Por lo general, un hospital forma parte de una cadena
de hospitales. Una persona trae al paciente al hospital. Los médicos hacen un diagnóstico de
cada paciente que ingresa. Si el paciente (o la persona que lo trae) está de acuerdo, se le
asigna un médico para que lo trate. Los eventos durante la estadía del paciente se
almacenan en su expediente.
El modelo conceptual de este problema podría ser como el siguiente:
El diagrama de modelo de estados podría ser el siguiente:
Diagramas de secuencia
El diagrama de secuencia de un sistema muestra gráficamente los eventos que originan los
actores y que impactan al sistema. La creación de los diagramas de secuencia forma parte de
la investigación para conocer el sistema, por lo que es parte del análisis del mismo. La
creación de los diagramas de secuencia depende de la formulación de los casos de uso. Los
casos de uso indican cómo los actores interactúan con el sistema. Durante la operación del
sistema, los actores generan eventos, solicitando alguna operación a cambio. Por ejemplo,
cuando un cajero ingresa un código de barras de un artículo, está pidiendo al sistema de TPV
que registre esa compra. Con este evento se inicia una operación en el sistema.
Antes de iniciar el diseño lógico de la aplicación de software, es necesario investigar y definir
su comportamiento como una "caja negra". Vamos a estudiar el comportamiento del
sistema, desde la perspectiva de qué es lo que hace, y no de cómo lo hace.
Def.: El diagrama de secuencia de un sistema es una representación que muestra, en
determinado escenario de un caso de uso, los eventos generados por actores externos, su
orden y los eventos internos del sistema. Lo importante aquí son los eventos originados por los
actores, que trascienden las fronteras del sistema. Los sistemas mismos son cajas negras.
Recordemos el caso de uso Comprar productos:
Caso de uso: Comprar
productos Actores: Cliente,
cajero Tipo: Primario
Descripción: Un Cliente llega a la caja registradora con los artículos que va a comprar. El
Cajero registra el código de cada producto. Si hay más de una unidad de un
producto, puede registrar la cantidad. El sistema determina el precio del producto,
y agrega la información a la transacción actual de venta. Se muestra la
descripción del producto y el precio. Esto se repite para todos los artículos. Al
final, el cajero cobra el importe. Al terminar la operación, el Cliente se marcha con
los productos.
El siguiente diagrama de secuencia describe el caso de uso Comprar productos. En
estos diagramas el tiempo avanza hacia abajo, y el orden de los eventos debería
seguir el orden indicado en el caso de uso correspondiente.
En el diagrama anterior, se indica que el Cajero es el único actor, y que se generan los
eventos del sistema: pasarProducto, terminarVenta y efectuarPago.
Def.: Un evento es un hecho externo de entrada, que un actor produce en el sistema. Cada
evento da origen a una operación del sistema como respuesta. En el ejemplo anterior, se
tienen tres eventos: pasarProducto, terminarVenta y efectuarPago. Los eventos y las
operaciones del sistema tienen el mismo nombre, por ejemplo, cuando el cajero genera un
evento de pasarProducto, causa que en el sistema se ejecute la operación pasarProducto.
Una vez que se identifican los eventos, se "registran" en la entidad que corresponda,
como operaciones. Por ejemplo:
En esta notación UML los parámetros son opcionales. Es conveniente que los nombres
de los eventos comiencen con un verbo, pues están orientados a comandos del sistema.
Dado que los eventos son hechos externos de entrada, es necesario definir la frontera del sistema.
Por lo general la frontera será el sistema de software (puede también incluir el hardware).
Es en este contexto que decimos que un evento del sistema es un hecho externo que
estimula directamente al software.
Observe que la representación del tipo Sistema es muy diferente a lo que se expresó en el
modelo conceptual. Los elementos del modelo conceptual representan conceptos del mundo
real, en cambio, el tipo Sistema es un concepto artificial. Además muestra las operaciones
que realiza.
Esto se debe a que, a diferencia del modelo conceptual, que representa información
estática, estamos ahora describiendo el comportamiento del sistema, que es
información dinámica.
En el caso de uso anterior (Comprar productos) lo primero que se hace es determinar los
actores que interactúan directamente con el sistema de software. En este caso, el cliente
interactúa con el cajero, pero no directamente con el software TPV. Es el cajero quien
interactúa con el software. Por tanto, el cliente no genera eventos en el sistema.
A veces es conveniente mostrar algunos fragmentos del texto del caso de uso dentro del
diagrama de secuencia. Por ejemplo:
Contratos
Antes de construir el diseño lógico que dice cómo funcionará la aplicación de software, es
conveniente definir su comportamiento como una caja negra. El comportamiento del sistema
es una descripción de lo que hace, y no de cómo lo hace. Los contratos son documentos
útiles para describir estos comportamientos, a partir de las operaciones del sistema o eventos.
Un contrato ve las relaciones entre los proveedores y sus clientes como un acuerdo formal,
que expresa los derechos y obligaciones de cada parte.
La correctitud de un programa es algo relativo, y depende en gran parte de la especificación. Una
Fórmula de corrección (o tripleta de Hoare) es una expresión de la forma:
(1) {P} A {Q}
La fórmula de corrección anterior se lee: una ejecución de A que comience en un estado en
el que se cumpla P terminará en un estado en el que se cumple Q. Aquí A denota una
operación. P y Q se denominan aserciones, de las cuales Pserá la pre-condición y Qserá la
post-condición.
Ejemplo:
{x >= 9} x := x + 5 {x >= 13}
En este caso, una post-condición más fuerte sería {x >= 14}. Las condiciones más fuertes
acotan más el resultado. Una condición más débil hace lo contrario, por ejemplo: {x >= 10} es
una post-condición más débil, pero para nuestros efectos, no es muy útil.
La pre-condición establece las propiedades que se tienen que cumplir cada vez que se
ejecute el procedimiento. La post-condición establece las propiedades que debe garantizar el
procedimiento cuando termine.
La propiedad de que un programa satisfaga su especificación, si termina, se conoce

como corrección parcial. Si un programa satisface su especificación y termina, se
dice que es totalmente correcto (total corrección implica además terminación).
Las aserciones permiten, a quienes desarrollan software, construir programas
correctos, y documentar por qué son correctos.
Ejemplo: En un TDA PILA se tienen las siguientes operaciones: put (o push), remove (o
pop), item (o top), empty y make (o new). Las operaciones remove e item solamente son
aplicables si el número de elementos de la pila es mayor o igual a uno.
En (1), la rutina A le está diciendo a sus clientes: "si usted me promete que al
llamarme se satisface P, entonces yo le prometo entregar un estado final en el que se
satisface Q".
En los contratos:
· La pre-condición compromete al cliente: define las condiciones bajo las cuales es
legítima la llamada a una rutina. Es una obligación para el cliente y un beneficio
para el proveedor.
· La post-condición compromete al proveedor: define las condiciones que debe

asegurar el procedimiento al ejecutarse. Esto es un beneficio para el cliente y una
obligación para el proveedor.
Ejemplo: El siguiente es un ejemplo de contrato de la rutina putpara una clase PILA.
put OBLIGACIONES BENEFICIOS

(Satisfacer pre-condición) (De la post-condición)
Cliente Sólo puede llamar a put(x) Obtiene una pila
en una pila que no esté actualizada: no está vacía,
llena. tiene a x en la cima (si se
aplica itemse obtiene x) y
count se ha incrementado
en 1.
(Satisfacer post-condición)
Actualiza la representación (De la pre-condición)
Proveedor de la pila, de modo que tenga Procesamiento más
a x en la cima (item devolverá simple, ya que supone
x), countse incrementa en 1, que la pila no está llena.
la pila queda no vacía.
Note que el cuadro inferior derecho obliga al cliente a llamar a la rutina con una pila que no
está llena. En caso de que el cliente no cumpla esta pre-condición, el proveedor puede retornar
cualquier cosa, podría quedarse en un ciclo infinito, o podría terminar abruptamente el
programa, sin que esto sea considerado un error.
El uso de contratos simplifica la programación, pues el programador puede dar por supuesto
que las pre condiciones se cumplen, sin tener que verificarlas.
Ejemplo: Si una función raíz cuadrada sqrt(int x) que produce un número real como
resultado, tiene como pre-condición que el valor de x tiene que ser mayor que cero, el
programador puede escribir el algoritmo sin preocuparse del caso en que x sea negativo.
El método de diseño por contrato va más allá. Escribir esta rutina de la forma:
if x < 0 then
// Tratar el error de alguna manera else
// Proceder con el cálculo de la raíz cuadrada end
no sólo es innecesario, sino inaceptable!
Def.: Principio de no redundancia. Bajo ninguna circunstancia debe, el cuerpo de la
rutina, verificar el cumplimiento de la pre-condición de la rutina.
Esto último es contrario a lo que proponen la mayoría de libros de texto en

ingeniería de software: es mejor comprobar demasiado, que demasiado poco (este
último principio es comúnmente llamado programación defensiva).
El diseño por contrato invita a identificar las condiciones de consistencia que son necesarias
para el funcionamiento correcto de cada cooperación cliente-proveedor (cada contrato) y a
especificar, para cada una de estas condiciones, de quién es la responsabilidad de
asegurar la misma: del cliente o del proveedor.
Si una rutina tiene una pre-condición, y se realiza una llamada que no la cumple, es un
error ("bug") en el software. La violación de una pre-condición es la manifestación de un
"bug" en el cliente (el proveedor es inocente). La violación de una post-condición es la
manifestación de un "bug" en el proveedor (el cliente es inocente).
Contratos para las operaciones
Para ayudar a explicar lo que una operación (o evento del sistema) se propone hacer, es
conveniente usar contratos. Un contrato de operación del sistema describe los cambios de
estado del sistema total cuando se llama a una de sus operaciones.
A continuación como se describe un contrato:
Contrato: Nombre de Contrato
Responsabilidades: Actividades a cumplir haciendo uso de las siguientes

categorías: creación y eliminación de instancias,
modificación de los atributos, asociaciones formadas y
canceladas.
Tipo: Sistema / Usuario
Referencias Cruzadas: Funciones relacionadas del sistema
Excepciones: Cuando no se cumple
Precondición: La precondición está formada por el conjunto de

condiciones que se tienen que cumplir para que se
pueda cumplir con el contrato.
PostCondición: Se describe en forma declarativa los cambios de

estado de los objetos en el modelo conceptual.
Algunas recomendaciones para la elaboración de los contratos:
1. Identificar las operaciones a partir de los diagramas de secuencia.
2. Elaborar un contrato por cada operación.
3. Redactar inicialmente la sección de Responsabilidades.
4. Para decribir las Precondiciones y Postcondiciones
Ejemplo:
Contrato: efectuarPagoTarjetaCredito(num:número,
fechaVencimiento:fecha)
Responsabilidades: Crear y solicitar autorización de un pago con
tarjeta de crédito.
Tipo: Sistema
Referencias Cruzadas: Funciones del sistema: R2.1. Casos de uso:
Comprar productos con tarjeta de crédito
Excepciones: Si la venta no está concluida, indicar que se
cometió un error
Precondición: Se terminó la venta actual.
PostCondición: • Se creó un pagoTarjeta pgo.
• Se asoció el pgo con la Venta actual.
• Se creó una tarjetaCrédito tc con tc.numero =
tc.Num, tc.fechaVencimiento =
fechaVencimiento.
• Se asoció tc a pgo.
• Se creó una solicitudPagoTarjeta spt.
• Se asoció spt a servicioAutorizacionCredito.
Otros diagramas de secuencia del sistema son los siguientes:
Pago con tarjeta de crédito
Pago con
cheque
Diagramas de estado
Los diagramas de estado describen gráficamente los eventos y los estados de los objetos. Los
diagramas de estado son útiles, entre otras cosas, para indicar los eventos del sistema en los
casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la
condición de un objeto en un momento determinado: el tiempo que transcurre entre eventos.
Una transición es una relación entre dos estados, e indica que, cuando ocurre un evento, el
objeto pasa del estado anterior al siguiente.
En UML, los estados se representan mediante óvalos. Las transiciones se representan
mediante flechas con el nombre del evento respectivo. Se acostumbra poner un estado
inicial (círculo negro). Por ejemplo:
Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le

ocurren, sus transiciones, y los estados que median entre estos eventos.
En particular, es útil hacer diagramas de estado para describir la secuencia permitida de
eventos en los casos de uso. Por ejemplo, en el caso de uso comprarProductos no está
permitido efectuar pagoTarjeta mientras no haya ocurrido el evento terminarVenta.
Un diagrama de estado que describe los eventos globales del sistema y su secuencia en un
caso de uso es un diagrama de estado para casos de uso. Por ejemplo, una versión
simplificada del diagrama de estados para el caso de uso comprarProductos es el siguiente:
Una versión más completa del diagrama anterior se muestra en la siguente figura:
El diagrama anterior aun no está completo, pues falta considerar algunos casos
excepcionales, como por ejemplo, si al rechazar una tarjeta de crédito o un cheque, el
cliente decide pagar usando otro método, por ejemplo pagando en efectivo.
Una transición puede tener una protección condicional, o prueba booleana, que permite
pasar al siguiente estado solemente si esta protección es válida. Estas protecciones se
colocan entre paréntesis debajo de los eventos (ver validación del usuario al descolgar el
auricular, en la siguiente figura). También se pueden tener sub-estados anidados.
Las herramientas usadas en la etapa de análisis (investigación del problema) se pueden
resumir en la siguiente tabla.
Herramienta de análisis Preguntas que responde

Diagramas de secuencia ¿Cuáles son los eventos y las operaciones del
sistema?
Casos de uso reales
Los casos reales de uso representan un diseño concreto de cómo se va a realizar el caso, a
partir de una tecnología particular. Por ejemplo, si se necesita una interfaz gráfica de usuario,
se deben incluir diagramas de las ventanas requeridas. Los diagramas de ventanas de todos
los casos de uso, así como el modelo de navegación de éstas, constituye la versión "en papel"
del primer prototipo del sistema. Para la creación de los casos de uso reales, se refinan los
casos esenciales creados en la etapa de análisis.
Diagramas de colaboración
Los contratos muestran qué hacen las operaciones del sistema, pero no muestran cómo los
objetos de software van a cumplir con ellas. Los diagramas de interacción (diagramas de
secuencia o diagramas de colaboración) explican gráficamente cómo los objetos interactúan a
través de mensajes para realizar las tareas. Antes de definir estos diagramas, hay que generar
el modelo conceptual, los contratos de operación y los casos de uso reales (estos últimos se
generan a partir de los casos de uso definidos en el análisis).
Los diagramas de colaboración explican gráficamente las interacciones entre las instancias
del modelo (objetos). Por ejemplo:
El punto de partida de las interacciones son las postcondiciones de los contratos de

operación. El siguiente ejemplo muestra el diagrama de colaboración de la operación
efectuarPago.
Note que el primer mensaje corresponde a uno de los "mensaje externos" del
diagrama de secuencia del sistema.
Los diagramas de interacción constituyen una de las herramientas más importantes para
el análisis y diseño orientado a objetos. El tiempo y esfuerzo dedicado a la preparación
de éstos, correponde a un porcentaje considerable de la actividad total del proyecto.
Notación: Para representar gráficamente el hecho de que un mensaje devuelva un valor, se
puede hacer de la siguiente manera:
Notación: Un objeto puede enviarse un mensaje a si mismo:
También es posible indicar el número de veces (iteraciones) que un mensaje va a ser

enviado. Por ejemplo, el siguiente método:
msg1() {
for i := 1 to 10 {
miB.mens2();
miC.mens3();
}
}
puede ser representado mediante el siguiente diagrama:
Notación: El siguiente ejemplo muestra la forma de definir la secuencia de los mensajes

dentro de un diagrama de colaboración.
Notación: Es posible definir mensajes condicionales. Para esto, se define la condición
entre corchetes, y el mensaje se envía solamente si la condición es verdadera. Por
ejemplo:
Notación: Es posible definir trayectorias condicionales mutuamente excluyentes. Por ejemplo:
Notación: Un multiobjeto, o conjunto de instancias (por ejemplo un arreglo en Java), se

dibuja en forma de pila. Por ejemplo:
De esta forma, también podemos enviar mensajes a multiobjetos. Por ejemplo:
La siguiente figura muestra cómo enviar mensajes para crear una instancia de un
objeto, y agregarla a un multiobjeto.
También es posible enviar mensajes a la clase y no a una instancia, con el fin de llamar a
métodos de la clase. Por ejemplo:
Las herramientas utilizadas en las etapas anteriores se pueden resumir en la siguiente tabla:
Herramienta Preguntas que responde

Requerimientos ¿Cuáles son las necesidades o deseos del producto?
Diagramas de secuencia ¿Cuáles son los eventos y las operaciones del sistema?
Diagramas de estado ¿Cuáles son los estados de los objetos en los eventos?
Diagramas de ¿Cómo hacen los objetos para cumplir con las
colaboración operaciones?
Un sistema orientado a objetos se compone de objetos que envían mensajes a otros

objetos para que lleven a cabo ciertas operaciones. Cada clase de objetos tiene ciertas
responsabilidades, que son cumplidas a través de sus métodos, y por la forma en que
colabora con las otras clases de objetos.
Decisiones poco acertadas sobre la asignación de responsabilidades de cada clase, dan
origen a sistemas y componentes frágiles y difíciles de mantener, entender, reutilizar o
extender.
Veremos algunos patrones que se pueden aplicar durante la elaboración de los diagramas
de interacción, al asignar las responsabilidades a los objetos y al diseñar la colaboración
entre ellos.
Responsabilidades
Las responsabilidades se relacionan con las obligaciones de un objeto respecto de su
comportamiento. Estas responsabilidades pertenecen, esencialmente, a dos categorías:
conocer y hacer. Entre las responsabilidades de un objeto relacionadas con el hacer se
encuentran:
· Hacer algo en uno mismo.
· Iniciar una acción en otros objetos.
· Controlar y coordinar actividades en otros objetos.
Entre las responsabilidades de un objeto relacionadas con el conocer se encuentran:
· Estar enterado de los datos privados encapsulados.
· Estar enterado de la existencia de objetos conexos.
· Estar enterado de cosas que se pueden derivar o calcular.
Las responsabilidades se asignan a los objetos durante el diseño orientado a objetos. Por
ejemplo, podría decirse que una Venta es responsable de imprimirse ella misma (un
hacer), o que una Venta tiene la obligación de conocer su fecha (un conocer).
Responsabilidad no es lo mismo que método: los métodos se usan para cumplir con las
responsabilidades. Éstas se implementan usando métodos que operen solos o en
colaboración con otros métodos y objetos. Así por ejemplo, la clase Venta podría definir
uno o varios métodos para imprimir una instancia Venta (por ejemplo el método imprimir).
Para hacer esto, Venta puede colaborar con otros objetos, por ejemplo, enviando
mensajes a VentasLineadeProducto para que se impriman ellos mismos.
Los diseñadores expertos en orientación a objetos, van formando un amplio repertorio de
principios generales que los guían al crear software. Estos principios son llamados
patrones, y se codifican en un formato estructurado que describe el problema y su
solución. Cada patrón tiene un nombre. Los patrones no se proponen descubrir ni
expresar principios nuevos en Ingeniería de Software. Todo lo contrario, intentan codificar
el conocimiento y los principios ya existentes: cuanto más generalizados y usados, mejor.
Cinco patrones útiles para la asignación de responsabilidades son: Experto, Creador,
Controlador, Bajo acoplamiento y Alta cohesión. A continuación se describen estos
patrones.
El patrón Experto
[Larman 98] Nombre:
Experto.
Problema: ¿Cuál es el principio fundamental en virtud del cual se
asignan las responsabilidades en el diseño orientado a
objetos?
Un modelo de clase puede definir docenas y hasta cientos de clases de
software, y una aplicación tal vez requiera el cumplimiento de cientos o
miles de responsabilidades. Durante el diseño orientado a objetos,
cuando se definen las interacciones entre los objetos, se toman
decisiones sobre la asignación de responsabilidades a clases. Si se
hace en forma adecuada, los sistemas tienden a ser más fáciles de
entender, mantener y ampliar, y se nos presenta la oportunidad de
reutilizar los componentes en futuras aplicaciones.
Solución: Asignar una responsabilidad al experto en información: la clase que
cuenta con la información necesaria para cumplir la responsabilidad.
Ejemplo: En la aplicación del punto de venta, alguna clase necesita conocer el gran
total de la venta.
Beneficios: Se conserva el encapsulamiento, ya que los objetos se valen de su
propia información para hacer lo que se les pide. Esto provee un bajo
nivel de acoplamiento, lo que favorece el hecho de tener sistemas más
robustos y de fácil mantenimiento. El comportamiento se distribuye entre
las clases que cuentan con la información requerida, lo que ayuda a
definir clases "sencillas" y más cohesivas, que son más fáciles de
comprender y mantener.
A partir de esta recomendación, se puede plantear la pregunta: ¿Quién es el
responsable de conocer el gran total de la venta?
Desde el punto de vista del patrón Experto, deberíamos buscar la clase de objetos que
posee la información necesaria para calcular el total. Por ejemplo:
¿Qué información hace falta para calcular el gran total? Hay que conocer todas las
instancias VentaLineadeProducto de una venta, y la suma de sus subtotales, y esto lo
conoce únicamente la instancia Venta. Por tanto, desde el punto de vista del Experto,
Venta es la clase de objetos correcta para asumir esta responsabilidad. Venta es el
experto en información. Entonces:
Todavía no terminamos. ¿Qué información hace falta para determinar el subtotal de la

línea de productos? Se necesitan VentasLineadeProducto.cantidad y
EspecificaciondeProducto.precio. VentasLineadeProducto conoce su cantidad y su
correspondiente EspecificaciondeProducto. Por tanto, desde la perspectiva del patrón
Experto, VentasLineadeProducto debería calcular el subtotal.
VentasLineadeProducto no puede cumplir la responsabilidad de conocer y dar el

subtotal, si no conoce el precio del producto. EspecificaciondeProducto es un Experto
en información para contestar su precio. Por tanto, habrá que enviarle un mensaje
preguntándole el precio.
En conclusión, para cumplir con la responsabilidad de conocer y dar el total de la
venta, se asignaron tres responsabilidades a las tres clases de objetos:
Clase Responsabilidad
Venta Conoce el total de la venta
VentasLineadeProducto Conoce el subtotal de la línea de

producto
EspecificaciondeProducto Conoce el precio del producto
Note que el cumplimiento de una responsabilidad requiere a menudo información distribuida en varias
clases de objetos. Es decir, hay muchos "expertos parciales" que colaboran en la tarea.
Cuando la información se encuentre esparcida entre varios objetos, éstos tendrán que
interactuar a través de mensajes para compartir el trabajo.
ANEXO8
ANALISIS Y DISEÑO ESTRUCTURADO

FACTIBILIDAD Y REQUERIMIENTOS DE UN PROYECTO
FUNDAMENTOS DEL PROYECTO
El analista debe dominar:
a) Iniciación del proyecto
b) Determinación de la factibilidad del proyecto
c) Calendarización del proyecto
d) Administración de las actividades y los miembros del equipo para logra productividad.
OPORTUNIDAD DE MEJORAS
Aceleración de un proceso
Análisis de un proceso mediante la eliminación de pasos innecesarios
SELECCIÓN DEL PROYECTO

 Temporización
 Posibilidad de mejoras en los objetivos del negocio
 Practico
Un proyecto de sistema comienza con problemas y oportunidades de mejora dentro de un negocio. Una
vez que es sugerido un proyecto, el analista trabajara rápidamente con los tomadores de decisiones, para
determinar si es factible, si es aprobado se hará un estudio de sistemas completo. Las actividades son
calenda rizadas mediante el uso de herramientas como gráficas de Gantt y PERT para que el proyecto se
realizar a tiempo.
INICIO DEL PROYECTO

Los sistemas se inician por muchas causas y razones diferentes. Algunos proyectos sobrevivirán, otros no
sobrevivirán a las diversas etapas de evaluación.
Los proyectos son sugeridos por dos razones.
 Para experimentar en problemas que les lleven por sí mismo a soluciones de sistemas.
 Para reconocer oportunidades y hacer mejoras mediante la actualización, alteración o instalación
de nuevos sistemas.
Problemas d la organización
Razones para
Inicio del sugerir el Selección del proyecto
Proyecto proyecto
Oportunidades de mejoras
PROBLEMAS DENTRO DE LA ORGANIZACIÓN
Los problemas con proceso que son visibles en la salida que pueden requerir la ayuda de un analista,
incluyen errores excesivos y trabajado desarrollado demasiado lento, incompleto, en forma incorrecta o
incluso que no se realiza.
Otros síntomas de problemas se hacen evidentes cuando las personas no logran los objetivos.
Errores
Revisar salida contra Trabajo lento
Trabajo incorrecto
Criterios de desempeño Trabajo incompleto
Trabajo no terminado
Para identificar Ausentismo

Ob. del comportamiento Insatisfacción
Problemas Rotación del puesto
Quejas
Sugerencias de mejoras
Retroalimentación Perdida de ventas
Menores ventas
DETERMINACION DE LA FACTIBILIDAD
Nota. El estudio de factibilidad debe estar altamente comprendido en tiempo, comprendiendo varias
actividades en un pequeño lapso.
PLANEACION Y CONTROL DE LAS ACTIVIDADES
Planeación:
 Seleccionar un equipo para el análisis del sistema
 Asignar a los miembros en proyectos adecuados
 Estimación de tiempo requerido para cada tarea
 Calendarización del proyecto para determinar las tareas y su orden
Estimación
del tiempo
requerido
Planeació
n y
control de
las Uso de
actividade gráficas de
s Gantt, Pert
Planeación Control Usar la retroalimentación Compara el plan con su

para monitorear el proyecto evolución actual
Tomar acciones
adecuadas para agilizar
o recalendarizar las
actividades para
terminar a tiempo y
motivas a los analistas
ESTIMACION DE TIEMPO REQUERIDO
Ciclo menor – ciclo de vida

de un
Sistema
Determinar
1ra. cantidad de detalles
decisión que se necesitan
para la definición
de actividades
Ciclo alto – Cada paso
detallado
QUE ES UN REQUERIMIENTO
Según el Glosario Estándar de la Terminología de la Ingeniería de Software de la IEEE(1997), un
requerimiento es:
(1) Una condición o capacidad que un usuario necesita para resolver un problema o alcanzar un objetivo.
(2) Una capacidad o condición que debe poseer el sistema o los componentes del sistema para satisfacer
un contrato, estándar, especificación.
Otras Definiciones…
―Un requerimiento puede ser algo que el producto debe hacer o una cualidad que el producto debe tener.
Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades o
porque el cliente quiere que ese requerimiento sea parte del producto final‖.
―Requerimiento es una especificación de que debería ser implementado. Son descripciones de cómo el
sistema debería comportarse, o de las propiedades o atributos de un sistema. También pueden ser una
limitación en el proceso de desarrollo del sistema.‖
Niveles de Requerimientos
Requerimientos de Negocio: Representan a gran nivel los objetivos de la organización y/o las solicitudes
del cliente con respecto al sistema o producto.
Requerimientos de Usuarios: Describen las tareas de los usuarios que deben poder ser realizadas con el
producto.
Requerimientos del Sistema: Definen la funcionalidad del software que los desarrolladores deben construir
dentro del producto para permitir al usuario realizar sus tareas y satisfacer los Requerimientos del Negocio.
Tipos de Requerimientos de Sistema

Software
- Requerimientos Funcionales: Define que hace el sistema (describen entradas y salidas), es decir,
las funciones del sistema.
- Requerimientos No Funcionales: Definen los atributos que le indican al sistema como realizar su
trabajo (eficiencia, hardware, software, interfaces, usabilidad, etc.). Es el cómo, cuándo y cuánto
del que.
Hardware
Restricciones: tipo de máquina, Desempeño, tiempo, carga, etc.
DETERMINACION DE REQUERIMIENTOS
Determinación de requerimientos. Estudio de un sistema para conocer cómo trabaja y donde es
necesario efectuar mejoras.
Requerimientos. Es una característica que debe incluirse en un nuevo sistema.
REQUERIMIENTOS BASICOS
Los analistas estructuran sus investigaciones al buscar respuestas a las siguientes cuatro importantes
preguntas:
¿Cuál es el proceso básico de la empresa?
¿Qué datos utiliza y produce este proceso?
¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
¿Qué controles de desempeño utiliza?
Comprensión del proceso

Los analistas hacen preguntas que, cuando reciben respuestas, proporcionan antecedentes sobre detalles
fundamentales relacionados con el sistema y que sirve para describirlo. Las siguientes preguntas son de
utilidad para adquirir la comprensión necesaria:
¿Cuál es la finalidad de esta actividad dentro de la empresa?
¿Qué paso se siguen para llevarla a cabo?
¿Dónde se realizan estos pasos?
¿Quiénes lo realizan?
¿Cuánto tiempo tardan en efectuarlo?
¿Con cuanta frecuencia lo hacen?
¿Quiénes emplean la información resultante?
Frecuencia y volumen del proceso

La frecuencia con la que se presentan las actividades en una empresa cambia mucho.
El volumen de artículos manejados, puede aumentar el tiempo necesario para completar la actividad.
Aunque la frecuencia de esta actividad es muy baja cuando el calendario inicia la actividad al finalizar cada
trimestre, el volumen de trabajo es muy grande ya que, en ocasiones, se necesitan prepara decenas de
miles de estados de cuenta. La cantidad total de pasos de que consta una actividad, puede generar
problemas especiales para el estudio que efectúa el analista, aun cuando la actividad ocurra con poca
frecuencia.
Identificación de controles
La falta o debilidad de los controles es un descubrimiento importante en cualquier investigación de
sistemas.
Las dos secciones siguientes muestran cómo utilizar las preguntas básicas para comprender sistemas
hacia transacciones y hacia decisiones.
REQUERIMIENTOS DE LAS TRANSACCIONES DE LOS USUARIOS

Los sistemas a nivel de transacciones, capturan, procesan y almacenan datos por alguna razón.
Los analistas seleccionados para trabajar en un sistema de procesamiento de pedidos, deben conocer
todo lo relacionado con la forma en que se procesan estas transacciones. Para entender los
requerimientos de transacciones, los analistas sin lugar a dudas formularan preguntas como las siguientes:
¿Qué es lo que forma parte de la transacción que está siendo procesada?
¿Qué es lo que inicia la transacción?
¿Quién inicia los pedidos? ¿Con que propósito?
¿Con que frecuencia ocurren los pedidos?
¿Qué volumen está asociado con cada pedido?
¿Existen diferentes condiciones que pueden afectar la forma en que se procesan los pedidos?
¿Qué detalles son necesarios para procesar las transacciones?
¿Qué información se genera? ¿Qué datos se guardan?
REQUERIMIENTOS DE DECISON DE USUARIOS

A diferencia de las actividades de transacción, las relacionadas con decisiones no siguen un procedimiento
específico. Las rutinas no son muy claras y es posible que los controladores sean vagos. Las decisiones
se toman al integrar la información en forma tal que los gerentes puedan saber qué acciones emprender.
Los analistas que investigan sistemas para el soporte de decisiones deben formularse las mismas
preguntas sobre frecuencia y volumen, mencionadas anteriormente, pero también hacerse otras para
determinar los requerimientos de las decisiones:
¿Qué información se utiliza para la toma de decisiones?
¿Cuál es la fuente de información?
¿Qué sistemas de transacciones producen los datos utilizados en el proceso de decisión?
¿Qué otros datos son necesarios y no es posible obtener del procesamiento de transacciones?
¿Qué datos se originan en fuentes externas de la organización?
¿Cómo se deben procesar los datos para producir la información necesaria?
¿Cómo debe presentarse la información?
PROTOTIPOS
La elaboración de prototipos de un sistema es una técnica valiosa para la recopilación rápida de
información específica acerca de los requerimientos de información de los usuarios.
Los prototipos activos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas,
durante la fase de determinación de requerimientos. Sin embargo la elaboración de prototipos es una
técnica compleja que requiere el conocimiento del ciclo de vida del desarrollo del ciclo de vida completo
antes de que pueda ser lograda satisfactoriamente.
REACCIONES INICIALES DE LOS USUARIOS

El analista de sistemas buscara las relaciones iniciales de los usuarios y de la administración hacia el
prototipo, sugeridas de los usuarios sobre cambios o limpieza del sistema para el que se construye el
prototipo, posibles innovaciones y planes de revisión que detallan que partes del sistema necesitan
analizarse primero.
Las reacciones de los usuarios son recopiladas por medio de la observación, entrevistas y formas de
retroalimentación.
Las reacciones le permiten al analista descubrir algunas percepciones de los usuarios como por ejemplo si
les agrada el sistema o si habrá dificultad al implementarlo.
SUGERENCIAS DEL USUARIO

De cómo refinar o cambiar el prototipo presentado. Las sugerencias son recolectadas de aquellos que
experimentan el prototipo cuando trabajan con él en un periodo determinado.
INNOVACIONES
Es añadir capacidades nuevas del sistema que no habían sido pensadas antes de la interacción con el
prototipo.
PLANES DE REVISION
Los planes de revisión ayudan a identificar prioridades para lo que se debe construir un prototipo. La
información recolectada en la fase de construcción del prototipo permite al analista asignar prioridades y
de dirigir los planes sin realizar gastos.
TIPOS DE PROTOTIPOS
 Prototipo parchado
Un prototipo en sistemas es un modelo operable que tiene todas las características necesarias,
pero que es ineficiente debido a que los programas fueron hechos a la carrera con el objetivo de ser
funcionales en vez de ser eficientes.
Un prototipo parchado es un sistema de información que tiene todas las características propuestas
pero es realmente un modelo básico que eventualmente será mejorado.
 Prototipo no operacional
Un modelo a escala no funcional de un sistema de información pude ser hecho cuando la
codificación requerida por las aplicaciones es muy amplia para hacer el prototipo.
Este modelo a escala no funcional es utilizado con el objeto de aspecto de diseño y no
funcionalidad.
 Prototipo primero de una serie
La elaboración de prototipos involucra la creación de un primer modelo a escala completa de un
sistema, llamado a veces piloto.
Ejemplo: la elaboración del prototipo de un primer avión de una serie. El modelo es completamente
operacional y es una realización de lo le diseñador espera que será de una serie de aviones con
características idénticas.
VENTAJAS DE LA ELEBORACION DE PROTOTIPOS

 Cambios de un sistema en tempranas de su desarrollo
La elaboración de prototipos satisfactorio depende de la retroalimentación temprana y
frecuentemente de los usuarios para que ayuden modificar el sistema, los cambios tempranos son menos
caros que los cambios hechos posteriormente en el desarrollo del proyecto.
La retroalimentación ayudara a decirle si los cambios están garantizados en la entrada, el
procesamiento o la salida, o si los tres necesitan ajuste.
El prototipo representa una versión de tiempo y dinero. Los problemas del sistema y olvido son más
fáciles de trazar y detectar en un prototipo con características limitadas.
 Desechos de sistemas indeseables
Desechar un sistema que los usuarios y analistas esperanban.se hace la eliminación de sistemas si
no es útil y si no satisface los requerimientos de información. Aunque desechar el prototipo es una decisión
difícil de tomar, es mucho mejor que poner cantidades de dinero y tiempo cada vez más grande en un
proyecto que es realmente no funcional.
 Diseño de un sistema para las necesidades y expectativas de los usuario
El sistema que está siendo desarrollado debe ajustarse mejor a las necesidades y expectativas de los
usuarios. Es común que los analistas de sistemas desarrollen sistemas mientras están separados de los
usuarios durante este periodo.
Interactuar con los usuarios a lo largo del ciclo de vida del desarrollo de sistemas. Si el equipo compromete
a los nuevos usuarios a involucrarse en todas las fases del proyecto, el prototipo puede ser usado como
una herramienta interactiva que da forma al sistema final para que refleje precisamente los requerimientos
de los usuarios. Los usuarios que se apropian tempranamente del sistema de información trabajan más
fuerte para lograr su éxito.
El sistema está funcionando bien de mantener el prototipo andando y continuar expandiéndolo para
concluir otras funciones.
PAPEL DEL USUARIO EN LOS PROTOTIPOS

Al darse cuenta de la importancia del usuario para el éxito del proceso el equipo de análisis de sistema
debe motivar y dar buena acogida a los comentarios recibidos y resguardarse contra su propia resistencia
natural a cambiar el prototipo.
 Experimentando tonel prototipo
A diferencia de una simple lista de características del sistema, el prototipo permite a los usuarios la
realidad de interacción real.
El sistema final será entregado con documentación que indique la manera en que debe ser usado el
sistema y eso restringe la experimentación. Los analistas necesitan estar presentes al menos parte del
tiempo en que sucede la experimentación.
Cuando se revisan los prototipos los analistas deben circular sus observaciones registradas entre los
miembros del equipo para que todos estén complemente informados.
 Reacción abiertamente ante el prototipo
El hacer que los usuarios se sientan los suficientemente seguros para dar una reacción abierta de la
relación entre los analistas y usuarios que el equipo debe de ser un proyecto consentido de su superiores
iguales dentro de la organización es poco probable que se den reacciones abiertas ante los prototipos.
 Sugiriendo acciones y eliminaciones de prototipos
Sugerir adiciones y eliminaciones a las características que se están probando. El papel del analista es
deducir tales sugerencias, a asegurando a los usuarios que la retroalimentación que proporciona es
tomada en serio, observando a los usuarios mientras interactúan y realizando entrevistas cortas y
especificar con los usuarios con relación con su experiencia con el prototipo.
Aunque se les pedirá a los usuarios que proporcionen sugerencias e innovaciones para el prototipo, es a
final de cuentas, responsabilidad del analista valorarlas y traducirlas a cambios funcionales cuando sea
necesario. El analista de sistemas debe recomendar que haya que enfatizar ante los usuarios y la
administración cuando se está elaborando el prototipo es el momento más adecuado de hacer cambios al
sistema.
PROTOTIPOS COMO ALTERNATIVA AL CICLO DE VIDA DE DESARROLLO DE SISTEMAS (SDL)
Existen dos temas principales que están interrelacionados con SDL
1. Tiempo requerido para pasar por el ciclo de vida del desarrollo de sistemas.
2. El uso del SDLC por que los requerimientos de los usuarios cambian a lo largo del tiempo.
Existe un intervalo cuando son analizados los requerimientos del usuario y entregado el sistema terminado
por lo tanto los requerimientos del sistema se van evolucionando.
Prototipo: Se usa como alternativa al ciclo de vida de desarrollo de sistemas donde se pueden resolver
algunos problemas sobre la identificación de los requerimientos de información de los usuarios.
Desventajas del prototipo dentro del ciclo de vida de desarrollo de sistemas
 Forma prematura de sistema.
 Inadecuado uso para las necesidades de sistemas generales.
La elaboración de sistemas es un método especializado adicional para la averiguación de los
requerimientos de información del usuario.
Desarrollo de prototipo: Es una forma magnifica para deducir, retroalimentación acerca del sistema
propuesto y que satisface las necesidades del usuario.
Existen 4 lineamientos para el desarrollo de un prototipo.
1. Trabajo en módulos manejables.
2. Construir un prototipo.
3. Modificar el prototipo.
4. Enfatizar la interfaz del usuario.
CONSTRUCCION RAPIDA DEL PROTOTIPO

La velocidad es esencial para la elaboración satisfactoria del prototipo en su sistema de información.
Ya que es demasiado largo el intervalo entre la determinación y la entrega del sistema completo, el
analista debe o puede usar la elaboración de información tradicional y después de tomar decisiones que
llevan a un modelo funcional.
El prototipo debe llevarse menos de una semana para ensamblarse y lo preferible son dos o tres días.
MODIFICACION DEL PROTOTIPO

En el lineamiento de la construcción se debe dar la motivación del prototipo.
Cada modificación debe estar evaluada por los usuarios, también deben ser velozmente realizadas, deben
demorar de uno a dos días, pero también depende de los usuarios la interacción del prototipo.
Al realizar el sistema se debe realizar el lineamiento de una futura modificación.
ENFATIZAR LA INTERFAZ DE USUARIO

Es de suma importancia ya que el usuario se relacionara con el prototipo y detectara los problemas a
grandes rasgos, además de que adopta el sistema rápidamente y no lo deja a un lado.
Se da con el fin de detectar cualquier tipo de problemas que pudiese darse más adelante.
Desventajas de los prototipos
 Es difícil mantener el prototipo como un proyecto dentro de un esfuerzo para un sistema
grande.
 El analista y el usuario toman el prototipo como un sistema completo, cuando no loes.
MANEJO DEL PROYECTO

El prototipo trae consigo problemas, para locuaz es necesario que el analista lleve una relación de cómo
fue recolectada, analizada para el prototipo y se dará una retroalimentación para la solución del problema.
ADAPTACION DE UN SISTEMA IMCOMPLETO COMO SI ESTUVIERA COMPLETO
Si un sistema es necesario es bienvenido rápidamente, lo cual puede ser aceptado sin ser terminado y
presionada para que sea puesto en servicio sin las especificaciones necesarias.
Además no realiza todas las funciones necesarias, para lo cual es muy fácil de que pueda ser rechazado
por el usuario y es desventajoso.
Para lo cual se debe entregar un sistema previamente terminado.
TABLAS DE DECISION Y OTROS CONCEPTOS
TABLAS DE DECISION
Más que un árbol, tabla de decisión es una matriz de renglones y columnas que indican condiciones y
acciones. Las reglas de decisión, incluidas en una tabla de decisión, establecen el procedimiento a seguir
cuando existan ciertas condiciones.
CARACTERISTICAS DE LS TABLAS DE DECISION

La tabla de decisión está integrada por cuatro secciones:
1. Identificación de condiciones. Señala aquellas que son relevantes.
2. Entrada de condiciones. Indican que valor, si es que lo hay, se debe asociar para una determinada
condición.
3. Identificación de acciones. Enlista el conjunto de todos los pasos que deben seguir cuando se
presenta cierta condición.
4. Las entradas de acción. Muestran las acciones específicas del conjunto que deben emprenderse
cuando ciertas condiciones o combinaciones de éstas son verdaderas.
Las columnas del lado derecho de la tabla enlazan condiciones y acciones, forman reglas de decisión que
establecen la condiciones que deben satisfacer para emprender un determinad conjunto de acciones.
CONDICION REGLAS DE DECISION

Identificación de condiciones Entradas de acciones
Identificación de acciones Entradas de condiciones
COMO CONSTRUIR TABLAS DE DECISIÓN

Para desarrollar tablas de decisión, los analistas deben emprender los siguientes pasos:
1. Determinar los factores considerados como más relevantes en la toma de decisiones. Esto permite
identificar las condiciones en la decisión. Cada condición seleccionada debe tener la característica de
ocurrir o no ocurrir.
2. Determinar los pasos o actividades más factibles bajo condiciones que cambian. Esto permite
identificar acciones.
3. Estudiar las diferentes posibilidades de combinaciones de condiciones. Para cualquier número N de
condiciones, existen 2N combinaciones a considerar.
4. Llenar la tabla con la reglas de decisión. Primero es llenar los renglones de condiciones con valores si
o no para cada combinación posible de condiciones, esto es llenar la primera mitad de renglones con si
y la segunda con no. el siguiente renglón se llena alternando con S y N cada renglón.
VERIFICACION DE TABLAS
Después de construir una tabla, los analistas verifican que sea correcta y completa con la finalidad de
asegurar que la tabla incluye todas las condiciones junto con las reglas de decisión que las relacionan con
las acciones. Asimismo, los analistas también deben examinar la tabla para encontrar redundancias y
contradicciones.
 Eliminación de la redundancia. Las tablas de decisión pueden volverse muy grandes y difíciles de
manejar si se permite que crezcan sin ningún control. Remover las entradas redundantes puede ser de
ayuda para manejar el tamaño de la tabla. La redundancia se presenta cuando las siguientes
condiciones son verdaderas al mismo tiempo 1) dos reglas de decisión son idénticas salvo para una
condición del renglón, 2) las acciones para las dos reglas son idénticas.
 Supresión de contradicciones. Las reglas de decisión son contradictorias entre si cuando dos o más
reglas tienen el mismo conjunto de contradicciones pero sus acciones son diferentes.
Las contradicciones indican que la información que tiene el analista es incorrecta o bien que existe un error
en la construcción de la tabla. Muchas veces la contradicción es resultado de las discrepancias en la
información que recibe el analista de diferentes personas con respeto a la forma en que estas toman
decisiones.
Así puede quedar una tabla una vez eliminadas las discrepancias.
CONDICION REGLAS DE
DECISION
1 2 3 4 5
Suficiente efectivo S - S N N
Crédito bueno S S N N N
Desea ―hacerse a un lado‖ - N S S S
Seleccionar el articulo a comprar x x x x
No seleccionar ningún articulo x
TIPOS DE ENTRADAS EN TABLA
1.-Forma de entrada limitada. En la estructura básica de la tabla se dice que es limitada porque se llena
con un sí(S) o un no(N). Este es uno de los formatos más comunes, ejemplo:
2.-Forma de entrada extendida. Esta forma reemplaza las S y N con acciones que le indican al lector
cómo decidir. En este formato, los identificadores de condición y acción no están complejos y es la razón
por la que las entradas contienen más detalle que una S y N. la forma de entrada extendida tiene sólo una
identificación de acción: ACCION. Para cada regla, se coloca una frase breve en la sección de
identificación de acciones: descontar 3%, descontar 2%, pagar el monto total de la factura. Muchas
personas favorecen este formato sobre el método de entradas limitadas porque es más explícito para
señalar las acciones, ejemplo:
3.-Forma de entrada mixta. En ocasiones los analistas prefieren combinar en la misma tabla las
características de los dos métodos anteriores.
4.-Forma ELSE. Esta es otra variante en las tablas de decisión que tiene como finalidad omitir la repetición
por medio de reglas else. Para construir una tabla de decisión en la forma else, se especifican las reglas,
junto con las entradas de decisiones, que cubren todo el conjunto de acciones con excepción de una que
se convierte en la regla a seguir cuando ninguna de las demás condiciones explicitas es verdadera. Esta
regla se encuentra en la columna else. Si ninguna de las otras condiciones es válida, entones se sigue la
regla de decisión else, esta regla elimina la necesidad de repetir condiciones que conducen a las mismas
acciones.
DESARROLLO DE DECLARACIONES ESTRUCTURADAS
Emplea tres tipos básicos de declaraciones para describir un proceso: estructuras de secuencias,
estructuras de decisión y estructura de iteración. Estas estructuras son adecuadas son adecuadas para el
análisis de decisión y pueden trasladarse al desarrollo de software y programación.
Estructuras de secuencia: una estructura de secuencia es un solo paso o acción incluido en un proceso.
Este no depende de la existencia de ninguna condición y, cuando se encuentra, siempre se lleva acabo.
En general, se emplean varias instrucciones en secuencia para describir un proceso.
Por ejemplo, es probable que la compra de un libro siga un procedimiento similar al siguiente:
1. Escoger el libro deseado.

2. Llevar el libro al mostrador de salida.
3. Pagar el libro.
4. Obtener el recibo.
5. Abandonar la librería.
Este ejemplo muestra una secuencia de 5 pasos. Ninguno contiene alguna decisión o condición para
determinar la realización del siguiente paso.
Estructura de decisión: El español estructurado es otro camino para mostrar el análisis de decisión. A
menudo se incluyen las secuencias de acciones entre estructuras de decisión que sirven para identificar
condiciones. Es así como las estructuras de decisión aparecen cuando se pueden emprender dos o más
acciones, lo que depende del valor de una condición específica. Primero se evalúa la condición y después
se toma la decisión de emprender las acciones asociado con esta condición. Una vez determinada la
condición las acciones son incondicionales.
Estas condiciones junto con las acciones pueden indicarse de la siguiente manera:
Si se encuentra el libro deseado ENTONCES.
Llevar el libro al mostrador de salida para libro.
Pagar el libro
Asegurase de obtener el recibo de compras
Abandonar la librería
DE OTRO MODO
No llevar los libros al mostrador
La estructura de decisión que emplea las frases SI / ENTONCES / DE OTRO MODO, señala con bastante
claridad las alternativas de proceso de decisión. En este caso se indican dos condiciones y dos acciones.
Las estructuras de decisión no está limitada a pares de combinaciones condición – acción. Pueden existir
muchas condiciones.
Estructuras de iteración: En las actividades rutinarias de operación, es común encontrar que algunas de
ellas se repiten mientras existan ciertas condiciones o hasta que estas se representan. Las instrucciones
de iteración permiten al analista describir estos casos.
La búsqueda de un libro en la librería puede realizarse repitiendo los siguientes pasos:
EJECUTAR MIENTRAS se examinan más libros:
Leer el título del libro
Si el titulo suena interesante
ENTONCES tomar el libro y hojearlo
Buscar el precio
Si la decisión es llevar el libro
Colocarlo en la filas de LIBROS PARA LLEVAR
OTRO regresar el libro al instante
FIN DE SI
OTRO continuar
FIN DE EJECUTAR
SI se encuentra en los libros deseados ENTONCES
Llevar los libros al mostrador de salida
Pagar los libros
Asegurarse de obtener el recibo
OTRO
No llevar al libro al mostrador de salida
FIN DE SI
El español estructurado puede ser de utilidad para describir con claridad condiciones y acciones.
HERRAMIENTAS PARA DOCUMENTAR PROCEDIMIENTOS DE DECISIONES

Seguir procedimientos y tomar decisiones son aspectos importantes de cualquier empresa. Algunas como,
aceptar o no ofertas afectan a todas las organizaciones, otras como saber cuándo pedir materiales del
almacén. Dependen de pocas personas y sigue los procedimientos pasos por paso. Sin embargo las
decisiones y procedimientos son de importancia para el analista cuando este conduce una investigación de
sistemas dentro de la empresa.
HERRAMIENTAS
Es cualquier dispositivo, objetivo, objetos u operación utilizada para ejecutar una tarea específica. El
analista de sistema depende de las herramientas para realizar su trabajo de la misma manera que otras
personas de sus actividades cotidianas.
Las herramientas ayudan al analista a recopilar los datos por los diversos métodos en la sección anterior.
CONCEPTOS BÁSICOS SOBRE DECISIONES

Condiciones y variables de decisión.
Cuando se observa un sistema y se pregunta ¿Cuáles son las posibilidades ó que puede suceder? En
realidad se está preparando por las condiciones, que son los posibles estados (personas, lugar, objeto o
eventos) las variables de cabían y es por esto que el analista se refiere a ellas como variables de
decisiones.
ACCIONES
Son alternativas, pasos, actividades o procedimientos que deben emprenderse cuando se toman una
decisión específica.
ÁRBOLES DE DECISION.
Son uno de los tres métodos que se emplean para describir decisiones y que evita dificultades en la
comunicación.
acción
condición
acción
Raíz
acción
condición
acción
CARACTERISTICAS DE LOS ÁRBOLES DE DECISION

El árbol de decisión es un diagrama que representa en forma secuencial condiciones y acciones.
La raíz del árbol es decir, la secuencia de decisión es de izquierda a la derecha.
USO DE ÁRBOLES DE DECISIÓN

El desarrollo de árboles de decisión beneficia al analista, primero que todo, la necesidad de describir
condiciones y acciones lleven a los analistas a identificar de manera formal las decisiones que actualmente
deben tomarse. De esta forma es difícil para ellos, pasar por alto cualquier etapa del proceso de decisión.
IDENTIFICACIÓN DE LOS REQUERIMIENTOS DE DATOS

Se ha demostrado que los árboles de decisión son eficaces cuando es necesario describir problemas con
más de una dimensión o condición. Sin embargo también son útiles para identificar los requisitos de datos
críticos que rodean al proceso de decisión; es decir; los árboles indican los conjuntos de datos que la
gerencia requiere para formular decisiones o tomar acciones
COMO EVITAR LOS PROBLEMAS QUE SE GENERAN AL UTILIZAR ÁRBOLES DE DECISIÓN

Los árboles de decisión no siempre son una buena herramienta, que sí tiene varias ramas ocasiona
problemas al analista; lo cual corre el riesgo de no determinar que política o estrategia de la empresa es la
especifica.
DIAGRAMAS FISICOS DE FLUJO DE DATOS

Proporcionan un panorama del sistema en uso, que es dependiente de la implantación, que muestra que
tareas se llevan a cabo y cómo. Las características físicas incluyen:
 Nombres de personas.
 Nombres con números de formatos y documentos.
 Nombres de departamentos.
 Archivos maestros y de transacciones.
 Equipo y dispositivos utilizados.
 Ubicaciones.
 Nombres de procedimientos.
El enfoque más amplio y útil para desarrollar una descripción exacta y completa del sistema en uso,
comienza con el desarrollo de los diagramas físicos de fijo de datos. El empleo de estos diagramas
especiales por tres razones.
Primera, es común que los analistas de sistemas encuentren mucho más fácil escribir la interacción entre
los componentes físicos que comprender la política empleada para administrar la aplicación.
Segunda, los diagrama físicos de flujo de datos son de utilidad para comunicarse con los usuarios. Están
relacionados con facilidad a las personas, las localidades y los documentos ya que trabajan todos los días
en cada entidad.
Tercera, los diagramas físicos de flujo de datos proporcionan un camino para validar y verificar el punto de
vista del usuario sobre la forma en que el sistema en uso.
DIBUJO DEL DIAGRAMA DE CONTEXTO

Los primeros pasos para determinar los requisitos tiene como finalidad conocer las características
generales del proceso bajo investigación. Conforme los analistas comprenden mejor los detalles, ahondan
con mayor profundidad para recopilar información más precisa y detallada. Cada mes se formulan
preguntas más específicas utilizando para ello el análisis descendente.
A menudo diagrama de alto nivel se denomina diagrama de alto nivel se denomina diagrama de contexto
define el sistema que va ser estudiado en el sentido de que determinan las fronteras.
DESARROLLO DE GRAFICAS DE PROCESO
Un sistema está formado por varias actividades o proceso. En la programación de computadoras, los
programadores con frecuencia desarrollar el software como una colección de módulos independientes pero
interactúan entre si. A menudo estos módulos encuentran en los diagramas de jerarquía.
Estos diagramas son similares a los desarrollados por los programadores. Los diagramas de jerarquía de
procesos continúan hasta los niveles que sean necesarios para identificar las actividades que forman parte
del sistema.
DESARROLLO DEL PRIMER NIVEL DE UN DIAGRAMA FISICO DE FLUJO DE DATOS

Algunos analistas encuentren ventajoso trabajar primero con todos los flujos de datos y asimilar nombres
que sean descriptivos y útiles. Se identifican todos los procesos pero no se les da nombre hasta que están
bien comprendidos todos los flujos de datos.
Después, cuando se les ha asignado nombre de los procesos, si el analista tiene dificultada para ligar los
flujos de datos con los nombres apropiados entonces esta situación indica que es necesario dividir aún
más el proceso. Para algunos analistas lo anterior da buenos resultados, para describir el sistema.
El diagrama físico de flujo de datos, emplea sólo símbolos estándar para describir el sistema de soporte
automatizado para preparar de diagramas de flujo de datos.
DESCRIPCION DEL PANORAMA LOGICO.
Los diagramas físicos de flujo de datos son un medio para alcanzar un fin, no un fin en si mismo.
Recuérdese que se elaboran para describir la implantación del sistema existente, aspecto que este interés
por dos razones:
 Estar seguro de tener la compresión correcta de la implantación real del sistema existente.
 La propia implantación puede ser un problema un factor limitante; cambiar la implantación, más que el
concepto del sistema; proporcionan a los resultados deseado.
DIAGRAMA LOGICO DE FLUJO DE DATOS

Proporcionan un panorama del sistema independiente de la implantación, que se centra el flujo de datos
entre los procesos sin considerar los dispositivos específicos y la localización de almacenes de datos o
personas en el sistema. En este tipo de diagramas no se indican las características físicas, las cuales sí
suceden con los diagramas físicos de flujo.
Deducción de panorama lógico:
El panorama lógico es una visión retrospectiva de la implantación actual y proporciona la base para
examinar la combinación de procesos, flujo de datos, almacenes de datos, entradas y salidas sin tomar en
cuenta dispositivos físicos, personas a los aspectos de control que caracterizan la implantación.
El diagrama lógico de flujo de datos se obtiene del diagrama físico al llevar a cabo lo siguiente:
 Señalar los datos necesarios en este momento para un proceso, no los documentos que los contiene.
 Promover la información relacionada con las rutas de datos; esto es, indicar el flujo entre
procedimientos y no entre personas, oficinas o localidades.
 Remover las herramientas y dispositivos (por ejemplo: fólder y gabinetes de archivos).
 Remover la información de control.
 Consolidar los almacenes de datos redundantes.
 Remover los procesos innecesarios, como los que no cambian los datos o flujo de datos (por ejemplo:
de itinerario, de almacenamiento y de copiado), y que son independiente de los dispositivos donde
ocurre (preparación o actividades de entrada de datos), o que representan un proceso único dentro del
sistema (si existen procesos duplicado entonces deben considerarse en un comentario al margen).
Usos de diagramas físicos y lógicos de flujo de datos:

Cuando se inicia el estudio de sistemas en un área poco familiar, el analista necesita obtener un panorama
del terreno.
Una vez que se tiene el panorama del terreno se puede estudiar con mayor cuidado los aspectos
esenciales de una tarea. Para esto es necesario, por lo decirlo de algún modo, ir debajo de la superficie.
Los diagramas lógicos de flujo son los que permiten hacer lo anterior.
Los diagramas lógicos de flujo de datos describen datos, procesos y eventos en forma diferente. Son más
abstractos que sus contrapartes físicas, pero esta diferencia es importante.
Reglas generales para el dibujo de Diagramas Lógicos de Flujo de Datos

1. Cualquier flujo de datos que abandone un proceso debe estar basado en los datos que entran al
proceso.
2. Todos los flujos de datos reciben un nombre, el nombre refleja los datos que influyen entre procesos,
almacenes de datos, fuente o destinos.
3. Solo deben entrar al proceso los datos necesarios para llevarlo a cabo.
4. un proceso no debe saber nada de ningún otro en el sistema.
5. Los procesos siempre están en continua ejecución; no se inician y tampoco se detienen (los sistemas
nunca son estáticos).
6. La salida de los procesos pueden tomar una de las siguientes formas:
a. Flujo de datos con información añadida por el proceso (por ejemplo una anotación en la factura).
b. Una respuesta o cambio en la forma de datos (como un cambio en la forma de expresar las
utilidades de dólares a porcentajes).
c. Un cambio de condición (de no autorizado a autorizado).
d. Un cambio de contenido (integración o separación d la información contenida en uno o más flujos
entrantes de datos).
e. Cambio en la organización (por ejemplo separación física o sea como de datos).
ANALISIS ESTRUCTURADOS
Ya sea un nuevo sistema o recomendaciones para hacer cambios en el ya existente debe conducir a una
mejora.
Para tener buenos resultados se espera que los analistas hagan lo siguiente:
 Aprendan los detalles y procedimientos del sistema en uso.
 Obtengan una idea de las demandas futuras de la organización como resultado del crecimiento, del
aumento de la competencia en el mercado, los cambios en las necesidades de los consumidores.
 Documentar detalles del sistema actual para su revisión y discusión por otros.
 Evaluar la eficiencia y efectividad actual y sus procedimientos. Recomendar todas las revisiones y
ampliaciones del sistema actual señalando su justificación.
 Fomentar la participación de gerentes y empleados en todo el proceso y aprovechar sus conocimientos
y experiencias.
¿Qué es el Análisis Estructurado?
Considérese las siguientes preguntas:
 ¿Deben dos analistas desarrollar una lista idéntica de requerimientos cuando estudian de forma
independiente lamisca situación?
 Para una situación dada, ¿Existe siempre un solo diseño correcto para el sistema?
 ¿Las aplicaciones que el analista observa tiene una naturaleza bien estructurada o están mal
definidas?
El hecho es que dos analistas que examinan una situación en forma independiente, sin lineamientos y
técnicas preestablecidas recopilan información diferente para describir el sistema. Por lo tanto, la
determinación de requerimientos es diferente los sistemas dependen de los seres humanos para funcionar
o no funcionar se ven influenciados por las políticas de la organización, restricciones sobre costos y
ganancias, política en general.
¿Qué es lo que se desea estructurar? ¿Qué significa ―estructura‖? el objetivo que persigue el analista es
organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión
completa y exacta de una situación dada.
Componentes del análisis estructurado
El análisis estructura hace uso de los siguientes componentes:
1. Símbolos gráficos. Íconos y convenciones para identificar y describir los componentes de un sistema
junto con las relaciones entre estos componentes.
2. Diccionario de datos. Descripción de todos los datos utilizados para el sistema. Puede ser manual
automatizado (y estar incluido en el diccionario de un proyecto más grande que quizás contengan las
descripciones de los procesos que integran el sistema).
3. Descripción de procesos y procedimientos. Declaraciones formales que emplean técnicas y
lenguajes que permitan a los analistas describir actividades importantes que forman parte del sistema.
4. Reglas. Estándares para describir, documentar el sistema en forma correcta y completa.
¿Qué es el análisis de flujo de datos?

Los datos son la guía de actividades de la empresa. Ellos pueden iniciar eventos y pueden ser procesados
para dar información útil.
Segur el flujo de datos por todos los procesos de la empresa, que es la finalidad de análisis de flujo de
datos.
En el transcurso del manejo de transacciones y terminaciones de tareas los datos entran, son procesados,
almacenados, recuperados, analizados, utilizados, cambiados y presentados como salidas.
El análisis de flujo de datos estudia el empleo de los datos en cada actividad.
HERRAMIENTAS EN LA ESTRATEGIA DE FLUJO DE DATOS
 Diagrama de flujo de datos. Una herramienta gráfica se emplea para describir y analizar el movimiento
de datos a través de un sistema ya sea que este fuera manual o automatizado incluyendo procesos,
lugares para almacenar datos y retrasos en el sistema.
 Diccionario de datos. Contiene las características lógicas de los sitios donde se almacenan los datos
del sistema. También identifican los procesos donde se emplean los datos y los sitios donde se
necesita el acceso inmediato a la información.
 Diagrama de estructura de datos. Es una descripción de la relación entre entidades de un sistema y el
conjunto de información relacionado con la entidad.
 Graficas de estructura. Muestra con símbolo la relación entre los módulos de procesamiento y el
software de la computadora. Incluye el análisis de las transformaciones entrada/salida y el análisis de
transacciones.
DIAGRAMAS DE FLUJO DE DATOS
Los diagramas de datos se pueden dibujar solo con cuatro notaciones sencillas, y dependiendo del
enfoque que se aplique ya se el Yourdon o el de Gane-sarson.
Flujo de datos: Es la dirección en la que viajan los datos.
YOURDON GNE-SEARSON
Proceso: Son las personas, procedimientos o dispositivos que utilizan o producen datos.
YOURDON GANE-SARSON
Fuente o destino de los datos: Pueden ser personas, programas, organizaciones u otras entidades
que interactúan con el sistema.
YUORDON GANE-SARSON
Almacenamiento de datos: Es donde se guardan los datos los datos o al que hacen referencia los
procesos del sistema.
YOURDON GANE-SARSON
Los diagramas de flujo Se datos se refieren al movimiento de datos a trabes del sistema, no en los
dispositivos o el equipo.
ALGUNOS SIMBOLOS UTILIZADOS EN LOS DIAGRAMS DE FLUJO
SIMBOLOS TIPO DESCRIPCION
SEÑALA DOSCTOS
ENTRADA/SALIDA
IMPRESOS
ALMACENAMIENTO EN
ENTRADA/SALIDA
LINEA
ENTRADA/SALIDA DESPLEGADO VISUAL
PROCESAMIENTO POR
PROCESAMIENTO
COMPUTADORA
PROCESAMIENTO
PREDEFINIDO (DEFINIDO
PROCESAMIENTO
EN OTRO LUGAR U OTRO
DIAGRAMA DE FLUJO
PROCESAMIENTO ENTRADA/SALIDA
PROCESAMIENTO DECISION
PROCESAMIENTO OPERACIONAL MANUAL
INDICA PRINCIPIO Y FIN

DESCRIPTIVO
DE LOS PROCESOS
INDICA CONTINUACION
DESCRIPTIVOS
CON OTRA PAGINA
DESCRIPTIVO CONECTOR
Relación iteración. La iteración implica repetición. Al definir estructuras de datos la relación de iteración
implica que los elementos que componen una estructura están perdidos.
¿Cuántas veces? Esto depende de la entidad específica descrita en ese momento. En general, sin
embargo, se suele afirmar que una relación de iteración los datos en la estructura de datos se repiten 0,
una o más veces. El analista de sistemas puede indicar para una aplicación específica valores mínimos y
máximos para la repetición de los datos; o dejarlos sin definir.
Relación opcional. Algunos elementos dato pueden ser opcionales. Más que mostrarlos como un caso
especial de iteración, esto es como cero una iteración; es más eficiente indicar que estos casos elementos
pueden o no estar incluidos.
Notación empleada en el diccionario de datos. Los analistas utilizan símbolos especiales con la
finalidad de liminar la cantidad de texto necesario para descubrir las relaciones entre datos y al mismo
tiempo mostrar con claridad las relaciones estructurales.
Las estructuras de datos se describen al vincular los datos sobre artículos en particular con un signo (+).
En algunos casos se emplean varios términos diferentes para describir la misma entidad. Los alias, como
se denomina a estos sinónimos, se representan con finalidad con un signo igual (=) que vincula datos.
Registro de las descripciones de datos. Dado que las descripciones de los datos se utilizaran una y otra
vez durante toda la investigación durante el diseño, es aconsejable adoptar un formato fácil de usar tanto
para el registro como para la recuperación de detalles cuando sea necesario es esta sesión se presentan
varias muestras de formatos. Estos emplean los principios y la notación desarrollada en la sesión anterior.
Definición de los flujos y almacenes de datos. Una explicación completa de todos los elementos del
diagrama de flujo de datos y procesos.
Todos estos detalles son capturados en una forma especial para el flujo de datos. Cada flujo de datos
recibe un nombre y se describe de manera breve. Así mismo, se incluyen los nombres y la identificación de
los procesos asociados con el flujo de datos. Para completar la definición del flujo de datos se listan todas
las estructuras de datos apropiadas. (No es necesario definir el contenido d las estructuras de datos, este
se encuentra en otra parte del diccionario de datos).
Definición de estructuras de datos. Los flujos y almacenes de datos son estructuras de datos. Dicho de
otra forma, si las estructuras de datos están en movimiento reciben el nombre de flujo de datos. En
contraste, las estructuras de datos, que no están en movimiento se denominan almacenes de datos.
Se utilizan definiciones por separado para los artículos con la finalidad de describir los valores permisibles
para lo mismo.
Descripción del proceso. También se proporciona una definición por separado de cada proceso en el
sistema.
DICCIONARIO DE DATOS
Qué es un Diccionario de Datos
Un diccionario de datos (DD) es un catálogo, un depósito de los elementos de un sistema de flujo de
datos y auxilia al analista en la determinación de los requerimientos del sistema.
Características del Diccionario de Datos

Los diccionarios de datos son un componente importante del análisis estructurado ya que por sí solos los
diagrama de flujo de datos no describen el objeto de la investigación. Los diccionarios de datos
proporcionan más información relacionadas con el sistema.
Uso de los detalles contenidos en el diccionario de datos.

Tener un conjunto de definiciones concisas para todas las entidades del proceso bajo el estudio es algo
muy valioso.
 Listado de dato y estructura de datos. Conjunto completo de todos los datos utilizados por el
sistema bajo investigación y que incluyen nombre, descripción, longitud y alias.
 Listado de los procesos. Conjunto completo de todos los procesos que se llevan a cabo en el
sistema junto con una descripción de las actividades asociadas con cada uno de ellos.
 Verificación con referencias cruzadas. Determinación de los lugares donde se emplean los datos
en el sistema; ¿qué proceso los utiliza? y ¿qué datos no se emplean?
 Detección de errores. Descubrimiento de inconsistencia en el área bajo estudio como por ejemplo
los datos necesarios para un proceso con un flujo de datos internos o que no producen como
saluda flujo de datos, o también procesos que duplican las finalidades de otros.
Importancia del Diccionario de Datos

 Manejo de detalles. Todos los sistemas implementan cambios continuos y manejan de manera
completa todos los detalles de un desafío. Con franqueza es imposible que los analistas recuerden
todos los detalles. Los mejores analistas inventan recordar todo en lugar de hacerlo registran toda la
información.
 Comunicación de significados. Los DD proporcionan asistencia para asegurar significados comunes
para los elementos y actividades del sistema.
 Documentación de las características del sistema. Las características incluyen partes y
componentes así como los aspectos que los distribuyen, tener la descripción formal de las
características del sistema, produce una comprensión más completa de este. Aun en los diccionarios
manuales del proceso de registrar la información revela los errores.
Contenido de un Registro de Diccionario

Este contiene dos tipos de descripción para el flujo de datos dentro del sistema.
 Elementos de datos. Son los bloques básicos para todos los demás datos del sistema por sí
mismo, no conllevan suficiente significado para ningún usuario. Otros nombres que le dan a este
término son: campo, dato o parte elemental.
 Estructura de datos. Es un grupo de datos elementales que están relacionados con otros y que en
conjunto describen un componente del sistema.
Descripción de los Elementos de Datos
Cada entrada del diccionario de datos consiste en un conjunto de detalles que describen los datos
utilizados por el sistema. Cada uno está identificado con un nombre, descripción, alias y longitud junto con
un intervalo de valores específicos para el dato permitido.
Nombre de los datos. Los nombres se emplean para hacer referencia a cada elemento durante el
proceso del desarrollo del sistema por lo consiguiente, debe tener:
 Relación de iteración (repetitiva). Define la repetición de un componente 0 o más veces.
 Relación opcional. Caso especial de la iteración, los datos pueden estar uno incluido, esto es una o
ninguna iteración.
TRANSICION DEL ANALISIS HACIA EL DISEÑO
MANEJO DEL PROCESO DE DISEÑO PARA APLICACIONES INSTITUCIONALES

El manejo del proceso de diseño significa tomar los pasos necesarios para que el esfuerza de desarrollo
avance en forma apropiada y produzca los resultados esperados.
Carpeta de descripción del diseño de sistema
Los analistas de sistema denominan a estas especificaciones información liberada o carpeta de diseño.
La información liberada incluye los siguientes aspectos:
 Cuadro de despliegue. Descripciones de las entradas y salidas donde se muestra la ubicación de
todos los detalles que aparecerán en los reportes, documentos y pantallas de terminal.
 Estructuras de registros. Descripciones de todos los datos contenidos en los archivos maestros y de
transacciones así como los diagramas relacionados con la base de datos.
 Sistemas de codificación. Descripciones de los códigos que explican o identifican tipos de
transacciones, clasificaciones y categorías de eventos o entidades.
 Especificaciones de los programas. Cuadros, tablas y descripciones gráfica de los módulos y
componentes del software de computadora junto con la interacción entre cada una de ellos.
 Especificaciones de procedimientos. Procedimientos planificados para instalar y operar el sistema
cuando esté terminado.
 Plan de desarrollo. Cronogramas que indican los tiempos necesarios para el desarrollo de las
actividades.
 Costo del paquete. Gastos anticipados para el desarrollo, implantación y operación de nuevos
sistemas, clasificados por categorías tales como personal, equipo, comunicaciones, facilidades y
suministros.
Diseño ergonómico. En el contexto de los sistemas, la ergonomía estudia los factores físicos que afectan
el rendimiento, la comodidad y la satisfacción d los usuarios directos.
Proporcionar especificaciones detalladas para el desarrollo del software

Estas especificaciones establecen las funciones de entrada/salida y los procesamientos así como los
algoritmos necesarios para efectuarlas.
¿QUE CARACTERISTICAS SE DEBEN DISEÑAR?
Electos del diseño
Los componentes de un sistema de información descritos durante el análisis de requerimientos son el
punto focal del diseño de sistemas.
 Flujos de datos. Movimientos de datos hacía, alrededor y desde el sistema.
 Almacenes de datos. Conjunto temporales o permanentes de datos.
 Procesos. Actividades para aceptar, manejar y suministrar datos e información.
 Procedimientos. Métodos y rutinas para utilizar el sistema de información y lograr con ello los
resultados esperados.
 Controles. Estándares y lineamientos para determinar si las actividades que están ocurriendo en la
forma anticipada o aceptada.
 Funciones del personal. Las responsabilidades de todas las personas que tiene que ver con el nuevo
sistema, incluyendo los usuarios, operadores d computadora y personal de apoyo.
Diseño de salidas
Para muchos usuarios finales, la salida es la única razón para el desarrollo del sistema y la base sobre la
que ellos evaluarán la utilidad de la aplicación.
Cuando se diseñan las salidas, los analistas deben realizar lo siguiente:
 Determinar qué información presentar.
 Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el medio de
salida.
 Disponer la presentación en un formato aceptable.
 Decidir cómo distribuir la salida entre los posibles destinatarios.
Diseño de archivos
El diseño de archivo incluye decisiones con respecto a la naturaleza y contenido del propio archivo como si
se fuera a emplear para guardar detalles de las transacciones, datos de tipos histórico o información de
referencias.
 Los datos que deben incluirse en el formato de los registros contenidos en el archivo.
 La longitud de cada registro, con base en las características de los datos que contiene.
 La secuencia a disposición de los registros dentro del archivo (la estructura de almacenamiento que
puede ser secuencia, indexada o relativa).
Tal vez la nueva aplicación necesite hacer referencia sólo al archivo maestro.
Diseño de interacción con la base de datos
En estos casos, el analista de sistemas no afecta el diseño de la base de datos sino que consulta al
administrador.
A su vez el papel del administrador de base de datos incluye las siguientes responsabilidades:
 Evaluar la conveniencia de la solicitud del analista.
 Describir los métodos para interactuar con la base de datos.
 Asegurar que la aplicación no pueda dañar la base de datos o que la afecte de manera adversa a las
necesidades de otros sistemas.
Diseño de la entrada
Los analistas de sistemas deciden los siguientes detalles del diseño de entradas:
 Que datos ingresan los sistemas.
 Que medios utilizar.
 La forma en que se debe disponer o codificar los datos.
 El diálogo que servirá de guía a los usuarios para dar entrada a los datos.
 Validación necesaria de datos y transacciones para detectar errores.
 Métodos para llevar a cabo la validación de las entradas y los pasos a seguir cuando se presentan
errores.
Las decisiones de diseño para el manejo de entradas especifican la forma en que serán aceptados los
datos para su procesamiento por computadora.
El diseño e a entrada también incluye la especificación de los medios por los que tanto los usuarios finales
como los operadores dar instrucciones al sistema sobre las acciones que deben emprender.
DIAGRAMAS HIPO.
HIPO son las siglas de jerarquía (más) entrada/proceso/salida. Las siglas proporcionan una mejor idea
del objetivo de ésta técnica.
El diagrama HIPO es jerárquico debido a que el sistema completo consiste o está formado de
subsistemas más pequeños. Esta técnica da soporte a un enfoque de diseño de arriba hacia abajo y
también reduce la complejidad percibida del sistema, debido a que cada uno de los subcomponentes
puede ser manejado por separado.
Las siglas del diagrama recuerdan las tres partes fundamentales de cualquier sistema, la entrada, el
proceso y la salida.
Tabla Visual de Contenido de un Sistema Universitario, el objetivo es mapear el sistema para hacer más
fácil la identificación de los módulos que lo componen y lograr una mejor comprensión de la distribución
de éstos.
Tabla Visual de Contenido del Sistema

DESCRIPCION GENERAL DE LOS MÓDULOS DEL SISTEMA.
1.0 Conexión a la base de datos e inicialización de la interfaz de usuario.

Módulo inicial encargado de establecer la conexión a la base de datos y presentar los
elementos que componen al sistema.
2.0 Autenticación de usuario y acceso al sistema.
Módulo encargado de determinar si un usuario que intenta ingresar al sistema posee
los permisos necesarios, establece el nivel que posee el usuario y muestra las opciones
a las que tiene acceso.
3.0 Identificación de usuario.
Muestra la información del usuario que ha ingresado al sistema.
4.0 Desarrollo de actividades formativas (PRH-01).
Define las diferentes acciones que se desarrollan para llevar a cabo la Formación
del personal docente y administrativo de la Universidad.
4.1 Captura de Cuestionarios.
Captura todos los cuestionarios que se generan en el proceso del desarrollo de
actividades formativas.
4.2 Recepción de Cuestionarios.
Módulo en el que se presenta la información de todos los cuestionarios generados
para su respectivo análisis por parte de los jefes de unidad.
4.3 Matriz de Competencias.
Módulo que administra la matriz de competencias del personal de la Universidad.
4.4 Seguimiento de la formación del personal.
Módulo que administra los cuestionarios de seguimiento de la formación del
personal de la Universidad.
5.0 Evaluación del desempeño del personal no docente (PRH-02).
Detecta el nivel de rendimiento laboral del personal no docente que trabaja en la
Universidad.
5.1 Captura de cuestionarios de evaluación del desempeño laboral.
Módulo que administra los cuestionarios de evaluación.
5.2 Recepción de cuestionarios.
Módulo de recepción de cuestionarios, para su respectivo
análisis.
6.0 Evaluación del desempeño del personal docente (PRH-03).
Detecta el nivel de rendimiento laboral del personal docente que trabaja en la
Universidad.
6.1 Captura de cuestionarios de evaluación del desempeño docente.
Módulo que administra los cuestionarios de evaluación.
6.2 Recepción de cuestionarios.
Módulo de recepción de cuestionarios, para su respectivo
análisis.
7.0 Reclutamiento y selección de personal (PRH-04).
Garantiza objetividad y precisión en el reclutamiento y selección del personal con
el fin de contar con personal calificado y competente.
7.1 Control de empleados.
Módulo encargado de administrar a los empleados.
7.2 Requisición de personal.
Módulo que genera las requisiciones de personal.
7.3 Ingreso de curriculums.
Ingreso al sistema de los curriculums de los solicitantes.
7.4 Recepción e inicio del trámite de la requisición.
Módulo de recepción de requisiciones, para su respectivo
análisis.
7.5 Ingreso de solicitudes de empleo.
Ingreso al sistema de solicitudes de empleo.
7.6 Verificación del estado de la requisición.
Módulo de consulta del estado de las requisiciones.
8.0 Proceso de administración del sistema.
Módulo que se encarga de administrar, controlar y monitorear el uso del sistema por parte de los
usuarios.
8.1 Configuración de usuarios.
Módulo que administra a los usuarios del sistema.
8.2 Monitoreo del sistema.
Módulo que presenta al administrador del sistema herramientas para verificar
el comportamiento del sistema, gráficas de rendimiento, información de la
bitácora, etc.
DISEÑO DE ENTRADAS.
El diseño de entradas consiste en desarrollar diversas formas o formularios para capturar información, por
lo regular la entrada clásica es la pantalla.
El sistema tiene una interfaz de usuario sencilla y fácil de utilizar y entender; a continuación se describen
las principales características de las entradas:
 Pantalla Prototipo:
1 2
7
4
6
Componente Descripción
1. Apartado Dividen el formulario en secciones dependiendo de la
tarea, dichos apartados se encuentran subrayados y
resaltados, el tipo de letra es Arial tamaño 10 color
2. Cuadro de Texto negro.

Son los controles más comunes que se encuentran en
las entradas de SIRH UFG, en dichos controles se
introducirá la información requerida por el sistema, el
tipo de letra es Arial tamaño 10 color negro sobre un
3. Objeto en Edición fondo blanco.

El objeto en el que se esté editando información tiene
un color de fondo anaranjado que lo diferencia de los
4. Calendario demás. comúnmente en las entradas, éste control
Utilizado
proporciona una forma más fácil de introducir fechas al
sistema.
5. Botones de Comando Se utilizan en las entradas para desencadenar o activar

una actividad específica, como guardar la información
o pasar a la siguiente pantalla, por ejemplo.
6. Aviso o Alerta Se despliegan en la ―Barra de Alertas‖ al mismo tiempo

que se establece como ―Objeto en Edición‖ al control al
que hace referencia dicha alerta, el tipo de letra es
Arial tamaño 12 y resaltada.
7. Área de Trabajo Consiste en una superficie central de color gris, en

donde se ubican todos los objetos que interactúan con
el usuario.
DISEÑO DE SALIDAS.
Las salidas se refieren a los resultados e información generada por el sistema; es producto de una
solicitud a la base de datos por medio del sistema.
Las salidas en SIRH UFG son de dos tipos, consultas (información en pantalla) o reportes (información
impresa).
Consultas.
Información presentada en pantalla, resulta de una solicitud de datos por parte de un usuario a la base de
datos. El formato de la información es el siguiente:
 Ejemplo de una consulta en el Sistema:

Reportes.
La información que presenta los reportes generados por SIRH UFG son los diferentes formularios
que se utilizan en cualquiera de los procedimientos de recursos humanos (PRH-01, PRH-02, PRH-03 y
PRH-04) debidamente aprobados por la Dirección de Gestión de Calidad de la
Universidad.
1.
Botones
2.
Contenido
del
reporte.
3. Cuadro de
Diálogo de
impresión.
Componente Descripción
1. Botones. Permiten realizar las funciones principales del
módulo de reportes, como lo es la navegación entre
páginas (de existir más de una), impresión y cerrar el
2. Contenido del reporte. módulo.
Espacio donde se encuentra la información
presentada en el reporte.
3. Cuadro de diálogo de Impresión. Módulo que permite al usuario configurar la
impresión del reporte.
ANEXO9
Las buenas prácticas de los Framework en las Capas Arquitectónicas

(Mario Contreras- Gonzalo Gutiérrez, 2017)
Los derechos de propiedad intelectual de buenas prácticas pertenece a los Docentes, por lo cual, toda la
información contenida en el presente documento sólo puede ser usada con fines académicos. Cualquier
uso, reproducción parcial o total destinada a otros fines, deberá estar autorizada por los Docentes.
PRIMER MOMENTO. DISTINCIÓN ENTRE PRÁCTICA Y PROCESO
Existe una distinción importante entre prácticas y procesos. Las prácticas son lo que debe hacer y el
proceso es la estructura para hacer las tareas. El proceso define el orden en el cual aplicar las prácticas y
hacer el trabajo, de forma que obtenga resultados de ingeniería significativos. Las prácticas aprovechan el
proceso de ingeniería de software que explica las tareas y el orden en el que se deben realizar para crear
productos de trabajo específicos. Lasfases generales clave del proceso son:
•Preparación del proyecto
•Análisis de requisitos
•Análisis funcional
•Síntesis de diseño
•Implementación
•Prueba de unidad
SEGUNDO MOMENTO. QUE SE ENTIENDE POR BUENAS PRACTICAS

Por buenas prácticas se entiende como un conjunto coherente de acciones que han rendido buen o
incluso excelente servicio en un determinado contexto y que se espera que, en contextos similares, rindan
similares resultados.
TERCER MOMENTO. BUENAS PRÁCTICAS EN CODIFICACIÓN DE PROGRAMAS
Definición de la Naturaleza de los símbolos
Fig. 2. Naturaleza de Símbolos en Java. Fuente Propia

Definición de Operadores.
Fig. 3. Definición de Operadores en Java. Fuente Propia

Comentario. Construcción en un lenguaje de programación destinada a incrustar anotaciones legibles al
programador en el código fuente de un Programa informático. En el caso de lenguaje de programación
python: La primera y más apropiada para comentarios largos es utilizando la notación ''' comentario ''', tres
apóstrofos de apertura y tres de cierre. La segunda notación utiliza el símbolo #, y se extienden hasta el
final de la línea.
Fig. 4. Comentario en Python. Fuente Propia

Estilo de programación (también llamado estándares de código o convención de código). Término
que describe convenciones para escribir código fuente en ciertos lenguajes de programación.
Estilo de indentación. Símbolos que delimitan un bloque lógico de código en un lenguaje de
programación. En el caso de java o c++ son {}.
Formateo en Líneas de Código. La tabulación acorde con el nivel de la línea de código. En el caso de
lenguaje Python cada nivel se identifica por la tabulación.
Fig. 5. Formateo en Líneas de Código en Python. Fuente Propia

Nombre de variables y métodos. Que sigan los estándares del lenguaje usado, tales como
"nombre_variable" o "nombreMetodo".
Fig. 6. Definición de Operandos en Java. Fuente Propia

Modularización. Cada método o módulo cumple con un objetivo, o sea, realiza tareas específicas. La
programación que se basa en módulos o métodos se denomina Programación Modular.
Fig. 7. Programación Modular en C/C++. Fuente Propia

CUARTO MOMENTO. BUENAS PRÁCTICAS EN FRAMEWORKS JAVA
1. INTRODUCCIÓN
Según [1] los patrones de diseño en la construcción de software se especifican acorde a la etapa donde
se aplican: modelos de dominio, patrones arquitecturales (estilos), patrones de diseño, patrones de código
específicos a una tecnología (idioms), patrones de diseño implementados en una API (Frameworks),
patrones de procesos.
Antes de formular que es Framework, se hace necesario definir que la Arquitectura de Componentes
Software (Fig. 1) es el conjunto de componentes15 y sus relaciones16, sus interfaces17, obligaciones,
servicios o contratos18.
Fig. 1. Arquitectura de Componentes Software. Adaptación [1]
Un Framework se define como un cascaron o una estructura en bruto donde se van colocando los
componentes acorde con una necesidad, requerimiento o una exigencia basado en un análisis de alto
nivel, como también, en una valoración crítica. Entones, un Framework es una abstracción de un
componente de software (su construcción se basa en la experiencia) para resolver un problema en UN
CONTEXTO (ojo no confundir con PATRON DE DISEÑO que es para resolver un problema en
CUALQUIER contexto).
2. DESARROLLO DE BUENAS PRÁCTICAS

A. Primer Referente. Excel API
1) Teoría Comprobada. Excel Api19 es un componente que maneja el acceso y edición de un archivo
Excel en JAVA
2) Objetivos de las Prácticas. Primer Objetivo es búsqueda por internet y adjuntar el controlador Excel
Api (Controlador Jxl.Jar) a un Proyecto Java NetBeans. Segundo Objetivo es el desarrollo de una clase
que administre la Hoja Excel (Hojas). Tercer Objetivo es la creación de un archivo Excel.
15
Representa una unidad coherente de funcionalidad
16
Indican que aspectos de un componente son usados por otros componentes y cómo la comunicación entre componentes
procede sobre el tiempo
17
Es una estructura que especifica obligaciones o contratos de un Componente Software
18
Conjunto o una colección de operaciones a realizar por un componente software
19
Conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta
biblioteca para ser utilizado por otro software como una capa de abstracción
B. Segundo Referente. Interface MySql
1) Teoría Comprobada. Conjunto de API (JDBC20 y JNDI21) para la conexión a Bases de Datos
Relacionales con programas Java.
2) Objetivo de las Prácticas. Realizar en programas Java las operaciones de Consulta, Edición, Borrado y
Adición (CRUD) sobre una Tabla de una Base de Dato Relacional MySQL.
Se tuvo en cuenta para las prácticas los siguientes ítems:
1. Conexión a una Base de Datos a partir de la API JDBC. Entonces, la aplicación Java obtiene una
conexión a la Base de Datos para realizar operaciones de Consulta, Edición, Borrado y Adición
(CRUD), así mismo, el Servidor de aplicaciones obtiene una referencia de una conexión física a la
Base de Datos.
2. Uso del API JNDI para facilitar el nombre del directorio donde está localizado el recurso JDBC.
3) Actividades Desarrolladas.
- Actualizar componentes GlassFish
- Modelo de Bases de Datos(Conceptualización)
- Servidor GlassFish
Consola de Administración de Glass Fish
Activar Servidor GlassFish desde NetBeans
- Registro MySQL Server
- Conexión a la Base de Datos MySQL
- Creación de la Aplicación de Bases de Datos en NetBeans
- Ejecución
C. Tercer Referente. Hibernate Java

1) Teoría Comprobada. Persistir objetos Java es la manera de almacenar permanentemente objetos en
una tabla de una base de datos relacional o sea convertir objetos Java a columnas/registros de una base
de datos y viceversa. Por lo tanto, la persistencia es serializar objetos Java 22 estructurados en forma de
árbol a una base de ratos relacional estructurada de forma tabular y viceversa requiriendo el mapeo de los
objetos Java a columnas y registros de la base de datos de una manera optimizada en velocidad y
eficiencia.
Hibernate Java es una herramienta de persistencia "objeto-java-a-base-de-datos" o de Mapeo Objeto-
Relacional (ORM) haciendo de archivos declarativos (XML) para representar la transformación de los
datos de un modelo relacional a un modelo orientado a objetos (Pojo) y viceversa.
20
API [2] que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java,
independientemente del sistema operativo donde se ejecute o de la base de datos a la cual se accede, utilizando el dialecto
SQL del modelo de base de datos que se utilice
21
Java Naming and Directory Interface[2] es una Interfaz de Programación de Aplicaciones (API) para servicios de directorio
22
Consiste en obtener una secuencia de bytes que represente el estado de dicho objeto
Fig. 2. Hibernate Java. Fuente Propia
En la Figura 2 se persisten las Tablas User y Group para generar los objetos user, user_group, group.
2) Objetivo de las Prácticas. Utilizar Framework Hibernate en NetBeans para generación de Interfaces de
Captura y Consulta de Tablas de una Base de Datos MySQL.
- Instalación MySQL server
- Conceptualización de:
Que es Hibernate
El Lenguaje de Consulta Hibernate
Documentación Hibernate
- Descarga MySQL Connector
- Registro del Servidor MySQL en NetBeans
- Conexión a la Base de Datos MySQL en NetBeans
- Creación de la aplicación Hibernate en NetBeans
Primer Paso. Creación de la entidad Cliente
Segundo Paso. Escritura del Archivos de Mapeo y Configuración
Tercer paso. Creación Archivo de Mapeo Cliente.hbm.xml
Cuarto Paso. Escritura del Archivo Configuración Hibernate
Quinto Paso. Adicionar librería Hibernate JPA (Java Persistence Applications) como el Controlador
mySql Conector
Sexto Paso. Crear archivo de sesión y de ayudante (helper) hibernate
Séptimo Paso. Creación de un Archivo Menu
Octavo Paso. Actualizar la clase main
- Ejecución
D. Cuarto Referente. Frameworks Struts
1) Teoría Comprobada. Framework Struts es un framework que implementa el patrón de arquitectura MVC
en Java. El patrón de arquitectura MVC (Model-View-Controller) se define en el Model (Objetos de
Negocio), la View (interfaz con el usuario u otro sistema) y el Controller (controlador del workflow 23 de la
aplicación).
El Framework Struts 1.x implementa el patrón de arquitectura MVC separando el modelo o workflow de la
aplicación (se puede programar desde un archivo XML), del modelo de objetos de negocio y de la
generación de interfaz.
Las acciones se ejecutan sobre el Model (Objetos de Negocio) y se implementan basándose en clases
predefinidas por el framework a partir de un patrón de diseño Facade. La generación de la View (interfaz
con el usuario u otro sistema) se realiza a partir de un conjunto de Tags predefinidos por Struts generando
ventajas de mantenimiento y de desempeño (pooling de Tags, caching, etc). Así mismo, separa el
desarrollo de interfaz del workflow y lógica de negocio permitiendo desarrollar ambas en paralelo.
El Framework Struts 1.x permite la reutilización de componentes y puede hacer uso de múltiples interfaces
de usuario (Html, sHtml, Wml, Desktop applications, etc.) y de múltiples idiomas, localismos, etc.
El Controller (controlador) Struts se encarga de tres tareas:
1. Validaciones simples: extendiendo la clase ActionForm, se realiza validaciones simples sin acceder
al modelo, haciendo uso de expresiones regulares (comprobación formato y longitud de datos)
2. Validaciones Complejas: extendiendo la clase Action, se comprueba las reglas de negocio
(modelo). Por ejemplo: Se realizan consultas contra la base de datos y se obtienen los errores de
integridad, etc.
Control de flujo o de Navegación: a través de un archivo de configuración (struts-conf) se gestiona el flujo
de navegación entre páginas, que también se logra extendiendo la clase ActionForm y Action.
El Framework Struts 2.x establece:
1. Cuáles deben ser las peticiones o solitudes a recibir desde el usuario.
2. El elemento FilterDispatcher(administrador de responsabilidades) determina cual es el action( la clase
base de struts 2.x) que deberá responder a una determinada petición o solicitud. El framework struts posee
la estructura para que el administrador de responsabilidades (FilterDispatcher) determine qué action es el
responsable de recibir la petición, procesarla y publicar el resultado de su ejecución.
La clase Action:
- Es una clase java
- Esta clase java cumple con normatividad de variables javabeans: nombre en minúscula, acceso de
variables private, métodos getter y setter
- El Método execute() retorna ERROR cuando no cumple con lo solicitado. Retorna SUCCESS
cuando cumple con lo solicitado.
Acorde con la Tabla 1 (Tabla de Responsabilidades), se debe declarar: el nombre de la responsabilidad
(Action), el nombre de la clase Action, el nombre del interceptor24, el nombre de la página JSP que recibe
la petición, el nombre de la página JSP donde se publican los errores, el nombre de la página JSP donde
se publica el resultado de la ejecución con éxito, como también, en algunos casos el llamado a un
JavaBean para realizar un modelo de datos o lógica del negocio.
TABLA 1.
TABLA DE RESPONSABILIDADES
23
Estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su
orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al
cumplimiento de las tareas
24
Clases que se emplean para especificar el ciclo de vida de una petición, y están pensadas para añadir funcionalidad extra a las acciones. Los
interceptores se pueden configurar para que ejecuten diferentes servicios, a saber, workflows, validaciones, upload de archivos, etc. Entonces, los
interceptores en struts2 son clases que se ejecutan antes o después que se invoque un Action
3. Cada solicitud o petición dentro del servidor se relaciona con un Action (por nombre de
responsabilidad). Entonces, una vez recibida una solicitud o petición se ejecuta el interceptor siempre y
cuando el Action tenga asociado uno. Luego, se ejecuta la clase action haciendo uso del método execute()
y retornando un resultado. De acuerdo a este resultado (error o éxito en dar respuesta a la petición o
solicitud) se determina la página a publicar (Dispatcher).
4. Se publica el resultado en el cliente.
Un ejemplo, de acuerdo a la lógica a emplear en el FilterDispatcher (administrador de responsabilidades)
se describe a partir de la siguiente tabla:
TABLA 2.
TABLA EJEMPLO DE RESPONSABILIDADES
En el archivo struts.xml, se debe escribir el tag <action>…</action> para declarar los Actions de la
siguiente manera:
<action name="Crear">
<result>/Entrada.jsp</result>
</action>
<action name="Crear" class="Action.AccionCrear">
<result name="input">/Entrada.jsp</result>
<result name="error">/Entrada.jsp</result>
<result>/Creacion.jsp</result>
</action>
También, en el archivo struts.xml, se debe escribir el tag <interceptors>…</interceptors> para declarar los
interceptores de la siguiente manera:
<interceptors>
<interceptor name="Nuevo" class=" Action.Nuevo "/>
</interceptors>
Se puede decir entonces:
- El nombre de la responsabilidad o action se llama Crear
- La clase action se denomina AccionCrear
- La clase interceptor es Nuevo.class
- entrada.jsp es la página JSP donde se recibe la petición dentro del servidor. También, es donde se
retorna el control si existe error en dar respuesta a la petición o solicitud
- creación.jsp es la página JSP donde retorna el control si existe éxito en dar respuesta a la petición
o solicitud
- Cuenta se encuentra en el paquete Beans. Se hace uso de un javabean Cuenta si existe éxito en
responder la petición o solicitud.
El llamado del action Crear se hace desde una página JSP de la siguiente manera:
<s:a href="Crear.action">Creacion Cuenta</s:a>
El action Crear es el responsable de recibir la petición, procesarla y publicar el resultado de su ejecución

de acuerdo con la siguiente lógica:
- Se realiza el interceptor Nuevo.class
- Se ejecuta entrada.jsp. El usuario llenara los campos solicitados.
- Cuando se pulsa el botón submit, se hace un llamado a la clase AccionCrear
- En AccionCrear se actualizan las variables de clase mediante los métodos setter y después se
realiza el método execute().
- si existe error en dar respuesta a la petición o solicitud se despacha o publica la página JSP
entrada.jsp
- si existe éxito en dar respuesta a la petición o solicitud se despacha o publica la página JSP
creacion.jsp
El Controller (controlador) Struts 2.x se encarga de realizar tres tareas similares a Strut 1.x:
1. Validaciones simples.
2. Validaciones Complejas.
3. Control de flujo o de Navegación.
1) Objetivo de las Prácticas. Comprobar el patrón de arquitectura MVC (Model-View-Controller) hacia el
interior del Framework Strut en NetBeans.
- Actualización de Strut 2.x
Arquitectura Strut 2.x
Struts 1 vs Struts 2
Patrón de Diseño Cadena de Responsabilidades Descarga MySQL Connector
- Framework Strut en Netbeans
Primer Paso. Creación de Proyecto
Segundo Paso. Editando el archivo struts.xml
Tercer Paso. Eliminar index.html
Cuarto Paso. Adicionar index.jsp
Quinto Paso. Actualizar web.xml
Sexto Paso. Creando la clase Validar
Séptimo Paso. Creando JavaBeans Cuenta
Octavo Paso. Creando Páginas JSP Petición y Vista
Noveno Paso. Edición Transaccion.jsp
Decimo Paso. Edición Actualiza.jsp
Décimo Primer Paso. Edición Creacion.jsp
Décimo Segundo Paso. Creando Action AccionCrear
Décimo Tercer Paso. Modificar el método execute()
Décimo Cuarto Paso. Creando Action AccionActualiza
Décimo Quinto Paso. Modificar el método execute()
- Ejecución
E. Quinto Referente. Frameworks Spring
1) Teoría Comprobada. Spring es un framework liviano que generalmente los objetos que se programan no
tienen dependencias en clases específicas de Spring. Sus características principales son inyección de
dependencias y programación orientada a aspectos.
Inyección de dependencias. El objetivo es lograr un bajo acoplamiento entre los objetos de una
aplicación. Con el Patrón Inversión de Control25 (IoC), los objetos no crean o buscan sus dependencias
(objetos con los cuales colabora) sino que éstas son dadas al objeto. El contenedor (la entidad que
coordina cada objeto en el sistema) es el encargado de realizar este trabajo al momento de crear el objeto.
Se invierte la responsabilidad en cuanto a la manera en que un objeto obtiene la referencia a otro objeto.
De esta manera, los objetos conocen sus dependencias por su interfaz. Así la dependencia puede ser
intercambiada por distintas implementaciones a través del contenedor. En resumen, se programa
orientado a interface y se inyecta las implementaciones a través del contenedor.
Programación orientada a aspectos (AOP). Se trata de un paradigma de programación (Codigo, 2012)
que intenta separar las funcionalidades secundarias26 de la lógica de negocios.
Módulos de Spring. En la figura 4 se muestran los módulos del Spring. En su núcleo (Core) se encuentra
el BeanFactory – el contenedor fundamental de Spring y quien se encarga de la inyección de
dependencias. El contenedor ApplicationContext se basa en BeanFactory, eventos de ciclo de vida,
validación y mejor integración con AOP.
Fig. 3. Modulo Framework Spring. Fuente http://www.j2eebrain.com/wp-content/uploads/Spring-

Framework.png
AOP – provee la implementación de AOP, permitiéndonos desarrollar interceptores de método y puntos de

corte para desacoplar el código de las funcionalidades transversales.
DAO - Provee una capa de abstracción sobre JDBC, abstrae el código de acceso a datos de una manera
simple y limpia. Tiene una capa de expeciones sobre los mensajes de error provistos por cada servidor
específico de base de datos. Además cuenta con manejo de transacciones a través de AOP.
ORM – Provee la integración para las distintas APIs de mapeo objeto-relacional incluyendo JPA, JDO,
Hibernate e iBatis.
JEE – Provee integración con aplicaciones Java Enterprise Edition así como servicios JMX, JMS, EJB, etc.
25
IoC permite instanciar una clase (crear objetos) olvidando las dependencias que tiene. Para eso, primero se registran las clases
en un Contenedor (IoC Container). Segundo, haciendo uso de Dependency Injection, se generan los Constructores de las
clases registradas en el Contenedor (IoC Container), para así, recuperar fácilmente cualquier clase en cualquier otra clase. IoC
también es famoso por el principio de HollyWood: ―don‘t call us, we‘ll call you‖ (No nos llames, nosotros le llamaremos.)
26
―cross-cutting concerns‖ algo que se traduciría como ―preocupaciones transversales‖
Web – Módulo que aporta clases especiales orientadas al desarrollo web e integración con tecnologías
como Struts y JSF. Cuenta con el paquete Spring MVC, una implementación del conocido patrón de
diseño aplicando los principios de Spring.
2) Objetivo de las Prácticas. Desarrollar los módulos del Framework Spring en NetBeans.
Patrón Inversión de Control (IoC)
Que es Hibernate
Que es Framework Spring
- Instalación y registro MySQL server
- Desarrollo de Framework Spring en NetBeans
Primer Paso Creación de JavaBean Cliente
Segundo Paso Creación de InterfaceCliente
Tercer Paso. Escritura del Archivo de Mapeo
Cuarto Paso. Crear archivo Hibernate
Quinto Paso. Crear Archivo Interceptor
Sexto Paso. Crear Archivo Test
Séptimo Paso. Creación de JSP Actualiza
Octavo Paso. Creación de JSP Ayudante
Noveno Paso. Modificar redirect.jsp
- Ejecución
F. Sexto Referente. Framework para la persistencia de datos

1) Teoría Comprobada. JPA27 establece una interface común que es implementada por el proveedor de
persistencia eclipse.
.
En el archivo de configuración persistence.xml se define:
• Persistence-unit, atributo name: define una unidad de persistencia, es obligatorio darle un nombre, para
poder crear un EntityManager. El EntityManager es el encargado de manejar la persistencia de los datos.
• Provider: si se desea usar Hibernate o no como implementación JPA. En esta práctica se selecciona el
proveedor eclipse
• class: debe existir una etiqueta class por cada clase que se desee persistir, es decir, una por cada
entidad se formará una unidad de persistencia.
• Dentro de las etiquetas properties, se define propiedades prioritarias de la implementación JPA. Entre
ellas se destacan:
1. hibernate.connection.url: define la URL de conexión a la base de datos.
2. User
3. Password
4. Driver
2) Objetivo de las Prácticas. Desarrollo de JPA a partir de una Base de Datos Relacional MySQL.
- Creación de una Base de Datos con sus respectivas tablas
- Conceptualización
Que es Hibernate
Interfaz de Persistencia Java (JPA)
Diferencia entre Hibernate y JPA
- Desarrollo en NetBeans
Registro Servidor MySQL
Conexión a la Base de Datos MySQL
Creación de Aplicación JPA
- Ejecución
27
API de persistencia desarrollada para la plataforma Java EE. Es un Framework del lenguaje de programación Java que maneja datos relacionales en aplicaciones
usando la Plataforma Java en sus ediciones Standard (Java SE) y Enterprise (Java EE).
G. Séptimo Referente. Practica JSF (Java Server Face)
1) Teoría Comprobada. JSF (Java Server Faces) es un Framework MVC para desenvolvimiento web en
lenguaje de programación Java.
Principales características de JSF
a. Es un Framework que fue definido por JCP (Java Community Process), que es la entidad
que define las especificaciones de la evolución de la tecnología Java.
b. Conjunto de componentes para la interfaz del usuario.
c. Programadores pueden crear componentes adicionales.
d. Componentes visuales se conectan con los datos del servidor
e. Eventos de componentes visuales realizan funciones en el servidor. (ManagedBeans)
f. Validadores y convertidores de datos, todos los datos que llegan al servidor vienen en
formato texto, puede que nuestro usuario escriba una fecha de nacimiento, en JSF tenemos
conversores automáticos.
g. Soporte AJAX28, puede mostrar información que proviene del servidor sin necesidad de
recargar la página.
2) Objetivo de las Prácticas. Desarrollo de JPA Hibernate a partir de una Base de Datos Relacional
MySQL.
- Creación de una Base de Datos con sus respectivas tablas
Que es Framework Hibernate Java
HQL: El lenguaje de consulta de Hibernate
- Desarrollo en NetBeans
Registro Servidor MySQL
Conexión a la Base de Datos MySQL
Creación de Aplicación Hibernate
Primer paso. Modificar el archivo de configuración de Hibernate
Segundo paso. Crear archivo de sesión y de ayudante (Helper)
Tercer paso. Generación de archivos de mapeo Hibernate y las clases Java
Cuarto paso. Creación de los archivos Pojo y de Asignación
Quinto paso. Edición de una clase ayudante (Helper)
Sexto paso. Desarrollo de consultas y método de adición de registro
Séptimo paso. Crear páginas web
Octavo paso. Creación de archivos XML
- Ejecución
G. Octavo Referente. Practica Jquery

1) Teoría Comprobada. jQuery es un Framework de Javascript, o ambiente de desarrollo de JavaScript
que contiene librerías de funciones pre-desarrolladas ( funciones programadas, probadas y que pueden
ser utilizadas de manera más sencilla).
JavaScript haciendo uso del DOM29 accede a una página web y sus objetos (párrafos, divisiones, tablas,
formularios y campos), para así, consultar y modificar sus propiedades y métodos.
2) Objetivo de las Prácticas. Desarrollo de un proyecto NetBeans con la inclusión de un llamado al
Framework jQuery.
3) Actividades Desarrolladas
Ajax
jQuery
- Proyecto NetBeans
Modificar index.HTML
28
Acrónimo de Asynchronous Javascript and XML, es decir, Javascript y XML Asíncrono.
29
Document Object Model o DOM ('Modelo de Objetos del Documento' o 'Modelo en Objetos para la Representaci ón de Documentos') es
esencialmente una interfaz de plataforma que proporciona un conjunto estándar de objetos para representar, acceder y modif icar el contenido,
estructura y estilo de los documentos HTML y XML. El responsable del DOM es el World Wide Web Consortium (W3C).
Colocar campos de Captura de Datos
Búsqueda de bibliotecas de código abierto JavaScript
Colocar en el tag <script>
Adición de Hoja de Estilo (css)
Adición de archivos de datos
Creación de una clase Control
Creación del archivo servlet
Configuración archivo xml
Ejecución
Fig. 4. Gráfica de Buenas Prácticas de los Frameworks en las Capas Arquitectónicas. Fuente Propia
ANEXO10
Buenas Prácticas en Arquitectura Orientada en Servicios

(Mario Dustano Contreras Castro, 2017)
Los derechos de propiedad intelectual de buenas prácticas pertenece al docente, por lo cual, toda la
información contenida en el presente documento sólo puede ser usada con fines académicos. Cualquier
uso, reproducción parcial o total destinada a otros fines, deberá estar autorizada por el Docente.
INTRODUCCION A ARQUITECTURA DE SOFTWARE
Tomado de: Buenas Prácticas en Arquitectura Orientada en Servicios ISBN 978-620-0-03791-6
La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.
Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de
patrones y abstracciones coherentes que proporcionan el marco
Una arquitectura de software se selecciona y diseña con base en objetivos (requerimientos) y
restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los
de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción
con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las
tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más
recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para
determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas
para implementar sistemas en tiempo real.
La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea
de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable
en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada
cada tarea.
La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de
alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada
para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como
requerimientos no funcionales, como la confiabilidad
La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es un
paradigma de arquitectura (Google) del software creada para satisfacer los objetivos de negocio las cuales
incluyen facilidad y flexibilidad de integración con sistemas legados, alineación directa a los procesos de
negocio reduciendo costos de implementación, innovación de servicios a clientes y una adaptación ágil
ante cambios incluyendo reacción temprana ante la competitividad.
Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la
organización, a su vez brinda una forma bien definida de exposición e invocación de servicios
(comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes
sistemas propios o de terceros.
SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y
puede dar soporte a las actividades de integración y consolidación.
Modelos o vistas
Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de
estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es
importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y
es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser
coherentes entre sí, evidente dado que describen la misma cosa.
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una
arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier
arquitectura:
La visión estática: describe qué componentes tiene la arquitectura.
La visión funcional: describe qué hace cada componente.
La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y cómo interactúan
entre sí.
Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes.
El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los
diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista.
Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado
de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista
corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o
expresarlas de manera incomprensible).
Arquitecturas más comunes
Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de
información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes
para cada caso en concreto. Así, las arquitecturas más universales son:
Descomposicion Modular. Donde el software se estructura en grupos funcionales muy acoplados.
Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes pero sin
reparto claro de funciones.
Arquitectura de tres capas. Especialización de la arquitectura cliente-servidor donde la carga se divide en
tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de
usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento
(persistencia). Una capa solamente tiene relación con la siguiente.
CONCEPTOS DEL DOCENTE
1. Definiendo un servicio
Un servicio es un componente de software que, dependiendo de su tipo, puede tener una función mayor o
menor. Sin embargo existen ciertas cualidades que suele cumplir todo servicio:
 Está definido por una interface
 Está disponible a través de una red
 Opera sobre objetos de negocio
 Puede ser decorado con funcionalidad adicional
 Es reusable
Un servicio está definido por una interface, que actúa como un contrato para el uso de la misma (esto no
es distinto de una interface estándar en Java). La interface puede ser dependiente de una plataforma (por
ejemplo en un servicio EJB, donde sólo un cliente EJB podrá hacer uso del contrato) o por contra ser
independiente de una plataforma (por ejemplo REST, que actúa sobre XML y HTML y por tanto puede ser
accedida desde multitud de sistemas, por muy distintos que sean éstos).
Un servicio está disponible a través de una red, o lo que es lo mismo: puede ser accedido remotamente.
Esto incluye a otras aplicaciones, otras máquinas, etc.
Un servicio opera sobre objetos de negocio, los cuales representan una parte tangible del problema de
negocio que intentamos resolver. En un servicio que realice conversión de divisas entre dólares
americanos (USD) y francos suizos (CHF) la divisa es el objeto de negocio y la conversión de divisas es el
problema de negocio.
Un servicio puede ser decorado con funcionalidad adicional, de manera que le puedan ser aplicados
requerimientos tanto funcionales como no funcionales. En un servicio SOAP hay disponibles multitud de
especificaciones, como WS-ReliableMessaging y WS-SecureConversation, que proporcionan capas
adicionales de seguridad a un servicio SOAP estandar.
Por último, un servicio debe ser reusable, con una funcionalidad atómica y bien definida. Ya seas
arquitecto o programador, el concepto de reusabilidad debe ser tu mantra.
2. Definiendo SOA
La Arquitectura Orientada a Servicios (Service-Oriented Architecture, a partir de ahora SOA) es un tipo de
arquitectura que utiliza servicios para facilitar la integración entre sistemas. El termino arquitectura en SOA
debe ser tratado de forma distinta ha como es tratado el término objetos en Programación Orientada a
Objetos: en éste último caso los objetos suelen ser tratados como una unidad de medida, como el
resultado final y tangible de un problema de negocio. Por el contrario, cuando nos enfrentamos a SOA
debemos pensar en términos más abstractos, en un cómo en lugar de un qué. En otras palabras, es un
paradigma de diseño.
Elementos de SOA. Fuente: https://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios#cite_note-6

3. Identificando candidatos a servicio
Existen ciertas cuestiones que, cuando nos las planteamos, nos pueden resultar tremendamente útiles
para determinar si un proyecto de software es un candidato a servicio:
¿Va el servicio a ser consumido por distintas plataformas/sistemas?
¿Pueden ser usados protocolos como HTTP?
¿Van a ser salvadas barreras de integración implementando una funcionalidad como servicio (por ejemplo
reemplazando o envolviendo una interface propietaria punto-a-punto)?
¿Va a representar una carga demasiado pesada el proceso de tratamiento de datos desde y hacia XML?
¿Va a permitir en el futuro que sea reusable, ya sea por otros proyectos o servicios de negocio?
Debes aprender a identificar que problemas de negocio deben ser solventados por SOA, y cuales no.
Convertirlo todo en un servicio no es una buena idea, ya que al final acabarás manteniendo cientos o miles
de servicios, muchos de ellos inútiles. Esto es conocido como tool trap (trampa de la herramienta), que
dice que cuando tienes un martillo, todo parece un clavo.
4. Tipos de servicio
Podemos catalogar un servicio dado dentro de uno de los siguientes tres tipos:
De entidad
Funcional
De proceso
Veamos brevemente cada uno de ellos.
Un servicio de entidad representa aquel que actúa sobre entidades de negocio (objetos) los cuales
tienen un determinado estado, comportamiento e identidad. Ejemplos de entidades de negocio son un
cliente, una factura, un empleado, etc. Los servicios de entidad suelen realizar operaciones CRUD
(Create-Read-Update-Delete, Crear-Leer-Actualizar-Eliminar) sobre las entidades de negocio.
Un servicio funcional, a diferencia de un servicio de entidad, actúa sobre una tecnología. Su propósito es
proveer funcionalidad reusable y centralizada en la que otros servicios puedan confiar, y debe ser lo más
autónomo posible. Un ejemplo es un servicio de envío de email.
Por último, un servicio de proceso es aquel que representa un conjunto de tareas relacionadas, y es
visto como un conjunto de clientes de otros servicios o procesos (que a su vez pueden ser también
clientes de otros servicios o procesos). Un ejemplo sería un servicio para procesar la contratación de un
nuevo empleado, el cual haría uso de varios servicios para dar de alta al empleado, solicitar una nueva
estación de trabajo al departamento de IT, enviar un correo electrónico informativo al departamento al que
fuera a ser asignado el empleado, etc. Estas tareas deben estar íntimamente ligadas (ser parte del mismo
proceso) para que, a pesar de ser un conjunto de servicios, podamos seguir viéndolo como atómico
(cualidad que dijimos que debería tener todo servicio).
CONCEPTOS REFERENCIADOS
https://sites.google.com/site/soaymas/
La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es un
paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos. Las soluciones SOA han sido
creadas para satisfacer los objetivos de negocio las cuales incluyen facilidad y flexibilidad de integración
con sistemas legados, alineación directa a los procesos de negocio reduciendo costos de implementación,
innovación de servicios a clientes y una adaptación ágil ante cambios incluyendo reacción temprana ante
la competitividad.
Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la
organización, a su vez brinda una forma bien definida de exposición e invocación de servicios
(comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes
sistemas propios o de terceros.
SOA proporciona una metodología y un marco de trabajo (Framework) para documentar las capacidades
de negocio y puede dar soporte a las actividades de integración y consolidación.
Terminología
Término Definición / Comentario
Servicio Una función sin estado, auto-contenida, que acepta una(s) llamada(s) y devuelve una(s)
respuesta(s) mediante una interfaz bien definida. Los servicios pueden también ejecutar
unidades discretas de trabajo como serían editar y procesar una transacción. Los servicios
no dependen del estado de otras funciones o procesos. La tecnología concreta utilizada
para prestar el servicio no es parte de esta definición. Existen servicios asíncronos en los
que una solicitud a un servicio crea, por ejemplo, un archivo, y en una segunda solicitud se
obtiene ese archivo.
Orquestación Secuenciar los servicios y proveer la lógica adicional para procesar datos. No incluye la
presentación de los datos. Coordinación.
Sin estado No mantiene ni depende de condición pre-existente alguna. En una SOA los servicios no
son dependientes de la condición de ningún otro servicio. Reciben en la llamada toda la
información que necesitan para dar una respuesta. Debido a que los servicios son "sin
estado", pueden ser secuenciados (orquestados) en numerosas secuencias (algunas veces
llamadas tuberías o pipelines) para realizar la lógica del negocio.
Proveedor La función que brinda un servicio en respuesta a una llamada o petición desde un
consumidor.
Consumidor La función que consume el resultado del servicio provisto por un proveedor
Principios
No hay estándares en relación a la composición exacta de una arquitectura orientada a servicios, aunque
muchas fuentes de la industria han publicado sus propios principios.
Algunos de los principios publicados son los siguientes:
 Contrato de servicios estandarizados: los servicios adhieren a un acuerdo de comunicación,
según se define en conjunto con uno o más documentos de descripción de servicios.
 Acoplamiento débil de sistemas: los servicios mantienen una relación que minimiza las
dependencias y sólo requiere que mantengan un conocimiento de uno al otro.
 Abstracción de servicios: más allá de las descripciones del contrato de servicios, los servicios
ocultan la lógica a los demás.
 Reutilización de servicios: la lógica se divide en servicios con la intención de promover la
reutilización.
 Autonomía de servicios: los servicios tienen control sobre la lógica que encapsulan, desde una
perspectiva de diseño y ejecución.
 Servicios sin-estado: los servicios minimizan el consumo de recursos aplazando la gestión de la
información de estado cuando sea necesario.
 Descubrimiento de servicios: los servicios se complementan con los metadatos mediante los
cuales se pueden descubrir e interpretar la eficacia.
 Composición de servicios: servicios están compuestos por partes eficazmente,
independientemente del tamaño y la complejidad de la composición.
 Granularidad de servicios: una consideración de diseño para proporcionar un ámbito óptimo y un
correcto nivel granular de la funcionalidad del negocio en una operación de servicio.
 La normalización de servicios: los servicios se descomponen a un nivel de forma normal para
minimizar la redundancia. En algunos casos, los servicios se desnormalizan para fines específicos,
como la optimización del rendimiento, el acceso y agregación.
 Optimización de servicios: los servicios de alta calidad son preferibles a los de baja calidad.
 Relevancia de servicios: la funcionalidad se presenta en un nivel de granularidad reconocido por
el usuario como un servicio significativo.
 Encapsulación de servicios: muchos servicios están consolidados para el uso de SOA. A
menudo, estos servicios no fueron planificados para estar en un SOA.
 Transparencia de ubicación de servicios: se refiere a la capacidad de un consumidor de
servicios para invocar a un servicio independientemente de su ubicación en la red. Esto también
reconoce la propiedad de descubrimiento (uno de los principios fundamentales de SOA) y el derecho
de un consumidor para acceder al servicio. A menudo, la idea de la virtualización de servicios también
se refiere a la transparencia de ubicación. Aquí es donde el consumidor simplemente llama a un
servicio lógico, mientras que un SOA habilita la ejecución del componente de la infraestructura,
normalmente un bus de servicios, que mapea este servicio lógico y llama al servicio físico.
Capas de software
SOA define las siguientes capas de software:
 Aplicaciones básicas: sistemas desarrollados bajo cualquier arquitectura o tecnología,
geográficamente dispersos y bajo cualquier figura de propiedad;
 De exposición de funcionalidades: donde las funcionalidades de la capa aplicativa son
expuestas en forma de servicios (generalmente como servicios web);
 De integración de servicios: facilitan el intercambio de datos entre elementos de la capa
aplicativa orientada a procesos empresariales internos o en colaboración;
 De composición de procesos: que define el proceso en términos del negocio y sus necesidades,
y que varía en función del negocio;
 De entrega: donde los servicios son desplegados a los usuarios finales.
Metodologia Propuesta para Desarrollo de SOA
http://www.revistatonoetecsa.cu/articulo/propuesta-de-desarrollo-para-arquitecturas-orientadas-servicios
Al adoptar o diseñar una arquitectura orientada a servicios en conjunto con una metodología
de desarrollo de software que la sustente es de importancia vital para garantizar el éxito de
cualquier desarrollo basado en SOA. Dicha metodología de desarrollo de software debe
poseer las siguientes características:
 Centrada en la arquitectura: Gran parte del trabajo puede ser considerado como
arquitectura, por lo que es quien guía todo el desarrollo.
 Iterativa e incremental: Los servicios al enmarcarse en un dominio muy amplio
deben ser identificados, diseñados e implementados de una forma iterativa, es decir,
una determinada cantidad a la vez y no haciéndose un esfuerzo en identificar todos los
de la empresa u organización de una sola vez. Asimismo, la metodología debe
desarrollar una aplicación a la vez y debe existir una relación entre
aplicación/servicios que es a lo que se le puede llamar proyecto dentro de la
metodología.
 Con separación de intereses: Los intereses de quienes desarrollan las aplicaciones no
tienen que ser los mismos de aquellos que proyectan los servicios o de quienes se
ocupan de la infraestructura. Mantener equipos separados para cada una de estas tareas
es crucial para evitar conflictos de intereses que puedan crear una fuerte dependencia
entre el diseño de las aplicaciones, el diseño de los servicios y el diseño de la
infraestructura que los soporta y que impacten negativamente en la reutilización futura
de los servicios. Conjuntamente con estas características generales se debe tener en
cuenta el enfoque que se de a la metodología en cuanto a la forma de implementarse,
donde los más comunes son los siguientes:
 Enfoque de arriba hacia abajo: se considera el desarrollo de SOA como un esfuerzo
centrado en identificar todas las funcionalidades de un negocio que puedan ser
expuestas como servicios, en toda la empresa u organización, donde se obtiene un
inventario de servicios que deben ser diseñados, implementados y desplegados para su
uso por las aplicaciones. Tiene los riesgos asociados a las complicaciones del trabajo y
al tiempo de duración que puede ser de meses o años. Esto implica que no se
obtendrán resultados a corto plazo. El alcance de este enfoque es a nivel empresarial.
 Enfoque de abajo hacia arriba: este enfoque es contrario al anterior. En él cada
proyecto de desarrollo decide qué funcionalidades exponer como servicios sin
preocuparse de si tributan o no a los objetivos y procesos del negocio. Tampoco se
analiza si dichas funcionalidades están implementadas para reusarlas, lo que conlleva
a su duplicación. El alcance de este enfoque es a nivel de proyecto.
 Enfoque de encontrarse en el medio: se basa en utilizar lo mejor de los enfoques
anteriores, busca alinear los objetivos del negocio con el desarrollo de los servicios.
Este enfoque se considera menos riesgoso que los anteriores, al unirlos de una manera
iterativa donde se identifican servicios y, paralelamente, se determina si las
funcionalidades asociadas al servicio se encuentran implementadas ya como servicios
o contenidas en aplicaciones legadas. El alcance de este enfoque es a nivel de
dominios de negocio.
La propuesta de metodología presentada (Figura 1) identifica las principales áreas de
impacto y de resultados de una aplicación en un proyecto de desarrollo de software. Los
mayores aportes se han obtenido de IBM y CBDI (The Service Oriented Process) al
considerárseles de referencia en los temas tecnológicos y metodológicos.
Figura 1 Metodología propuesta para SOA

Los proyectos que se desarrollarán con esta metodología pueden clasificarse de la siguiente
manera:
 Proyectos de desarrollo de aplicaciones compuestas donde su lógica de negocio esté

contenida en servicios ya elaborados o por elaborar como parte del proyecto.
 Proyectos de racionalización del portafolio de aplicaciones, donde el enfoque tiende a
ser más de abajo hacia arriba que encontrándose en el medio. Se identifican servicios a
partir de las funcionalidades ya existentes para eliminar duplicaciones e incoherencias
en la información.
 Proyectos de integración de aplicaciones donde el mayor esfuerzo está en el desarrollo
de servicios que expongan funcionalidades de las aplicaciones para ser consumidas
por otras aplicaciones.
 Proyectos de mejora de la infraestructura a partir de la captura de requerimientos del
negocio, ya sea de seguridad, rendimiento, escalabilidad, etc.
Para lograr esto, la metodología se divide en disciplinas asociadas con las áreas de impacto
está compuesta por un total de 15 disciplinas que abarcan todas las acciones para el
desarrollo de una arquitectura orientada a servicios. A su vez, las disciplinas aparecen
identificadas por una capa y una fase dentro de la metodología, lo que permite ubicarla y
saber su función principal.
La estructuración en capas se hace buscando la separación de intereses, por lo tanto, existen
las siguientes capas:
 Capa de consumo: encargada de contener las disciplinas asociadas al desarrollo de

las aplicaciones.
 Capa de provisión: encargada de contener las disciplinas para el desarrollo de los
servicios.
 Capa de habilitación: encargada de contener las disciplinas que habilitan, desde el
punto de vista de la infraestructura de software y hardware, el soporte de los servicios
y las soluciones.
Cada una de estas capas debe tener equipos de trabajo identificados correctamente, que
podrán colaborar entre sí pero sin crear una interdependencia que pueda afectar su trabajo en
el proyecto. De esta forma se tendrán equipos de arquitectos, diseñadores y desarrolladores
para cada una de las capas. La ventaja de este enfoque es que los equipos de trabajo para su
colaboración solo deben establecer un contrato que deben cumplir. Entre los equipos de la
capa de consumo y de la capa de provisión, el contrato es la especificación de cada uno de
los servicios, mientras que entre los equipos de la capa de provisión y de la capa de
habilitación, el contrato tiene las especificaciones no funcionales de cada servicio. Ajustarse
a estos contratos es fundamental para el correcto funcionamiento de cada equipo de trabajo.
La separación en fases se hace con el objetivo de determinar, de manera general, cuál es el
avance de los proyectos que usan la metodología, ubicándolos en una fase u otra en función
del trabajo que se esté realizando, para lo cual se cuenta con las fases siguientes:
 Planeación: esta fase constituye el inicio de cualquier proyecto y abarca las tareas
relacionadas con la identificación del dominio del negocio, las problemáticas a
resolver y la obtención de la mayor cantidad de conocimientos sobre la organización
en donde se desarrollará el proyecto. Aquí se pueden obtener los objetivos del
negocio, los objetivos a cumplir con el proyecto, la cadena de valor y los principales
procesos que apoyan el funcionamiento del negocio y que serán tratados en el
proyecto.
 Arquitectura: esta fase enmarca todo el trabajo arquitectónico relacionado con la
arquitectura de la aplicación, las arquitecturas de especificación de servicios, de
implementación y despliegue para los servicios, la arquitectura de seguridad general, y
la arquitectura de infraestructura.
 Diseño: esta fase abarca todo el diseño de los componentes específicos de la solución,
el diseño de los servicios y de la infraestructura.
 Ensamblaje: durante la fase de ensamblaje, el trabajo fundamentalmente estará
centrado en la implementación de la solución técnica del proyecto y en la
implementación de los servicios, logrando que los equipos responsables de cada capa
laboren de conjunto.
 Ejecución: esta fase constituye la última de la metodología y se centra en el
despliegue de los componentes de la aplicación y de los servicios, además de realizar
las pruebas finales de cada uno de los componentes, incluida la monitorización a lo
largo del tiempo para validar que se ajustan a su diseño inicial.
Dentro de esta clasificación de las disciplinas hay dos que no se tienen en cuenta, vinculadas
con los temas de gobierno SOA. Estas disciplinas contienen tareas y procedimientos que se
ejecutan en cada una de las fases y que son las mismas para cada equipo de trabajo, por lo
tanto, no tiene sentido ubicarlas en una capa y fase dentro de la metodología.
Como esta metodología abarca no solo el desarrollo de las aplicaciones, sino de las
diferentes arquitecturas y de los servicios, posee varios flujos e iteraciones para hacer posible
la sincronía y la concordancia de todo el trabajo realizado.
Estos flujos aparecen identificados a continuación:
 Desarrollo de aplicaciones compuestas: comprende las disciplinas Arquitectura y

diseño de las soluciones, Aprovisionamiento de la solución, Mejora del negocio
orientado a servicios y Ensamblaje de la solución. Básicamente son las disciplinas
clásicas de análisis, diseño e implementación que aparecen en metodologías como
RUP —Rational Unified Process—, pero ajustadas a las características de los
proyectos basados en SOA.
De manera general, en la disciplina Arquitectura y diseño de las soluciones se determinan los
procesos a analizar, como parte del proyecto, y de forma iterativa son descompuestos
obteniéndose requerimientos funcionales, servicios candidatos como tentativas futuras de
servicios software y requerimientos no funcionales. Los requerimientos funcionales y no
funcionales pasan para la disciplina Aprovisionamiento de la solución junto con una
propuesta de arquitectura de la solución, y es en esta disciplina donde se diseñan los
componentes de la solución. Al mismo tiempo, los servicios candidatos pasan al flujo de
desarrollo de las arquitecturas y son devueltos en la disciplina Aprovisionamiento de la
solución como especificaciones formales que son usadas para diseñar los componentes que
consumirán estos servicios. Finalmente, en la disciplina Ensamblaje de la solución se
implementan los componentes y, de estar implementados los servicios que consumirán, se
prueba su funcionamiento. Puede darse el caso de que los servicios necesarios para la
implementación de la solución ya estén diseñados e implementados, por lo que este flujo se
desarrollará más rápidamente y solo tendrá que identificar los servicios necesarios.
 Desarrollo de las arquitecturas: este flujo basa su trabajo principal a partir de la

obtención de los requerimientos funcionales, no funcionales y servicios candidatos.
Tiene como objetivo instanciar la arquitectura de referencia a usar en el proyecto
establecida por la metodología. Los requerimientos permiten determinar las capas que
van a ser empleadas en la arquitectura de especificación de servicios, la forma de
implementarlos y desplegarlos, el nivel adecuado de seguridad y la infraestructura
necesaria para soportar servicios y soluciones. Evidentemente, este es un flujo de largo
plazo que se actualiza en iteraciones con cada proyecto, donde se modifican los
elementos de la arquitectura necesarios para soportar todos los requerimientos de cada
una de las soluciones desarrolladas. Es por ello que llevar un control y seguimiento de
cada decisión tomada es vital para impedir el desastre y, como solución, se hace uso
de la disciplina Gobierno SOA para capturar las políticas que normarán la
arquitectura, el diseño, la implementación, el despliegue, las pruebas y la seguridad de
todos los servicios, así como el ciclo de vida que seguirán los servicios y los estados
por los que transitarán. Este flujo para el tipo de proyecto que involucre reutilización
de funciones ya implementadas en sistemas existentes, aplica la disciplina Transición
de los sistemas legados, para extraer dichas funcionalidades con la planificación de
cuándo podrán ser expuestas como servicios.
 Desarrollo de los servicios: abarca las disciplinas Especificación y diseño de
servicios e Implementación de los servicios. Centra todo su trabajo en el diseño de los
servicios entregados como descripciones formales por el flujo de desarrollo de las
arquitecturas, una vez que han sido validados, aprobados e incluidos dentro del
portafolio del dominio al que pertenece el proyecto. El diseño de los servicios, una vez
concluido, es enviado a la disciplina Aprovisionamiento de la solución para que sea
incluido en el diseño de los componentes y, posteriormente, una vez implementados,
se envía una notificación a la disciplina Ensamblaje para que consuma los servicios ya
desarrollados. Estas notificaciones y envíos de especificaciones puede automatizarse
con el uso de herramientas que gestionen los estados por los que transitan los
servicios.
Como se observa, las interacciones entre las disciplinas son varias, y los flujos son
complicados pues abarcan intereses diferentes, siendo de distintos tamaños y de alcance en el
tiempo, lo que complejiza aún más la situación. De ahí la importancia de tener una correcta
separación entre los equipos de trabajo y de usar los contratos o especificaciones de servicio
y los requerimientos no funcionales como los elementos que normen las relaciones entre los
equipos.
Tal como se mencionaba al principio, esta metodología no es para desarrollar una aplicación
sino para desarrollar toda una arquitectura orientada a servicios que modifique la estructura y
el funcionamiento de los departamentos de tecnologías en cuanto a la forma en que
desarrollan o usan las aplicaciones y en cuanto a los recursos de hardware y software de que
disponen, así como en su relación con el negocio al cual tienen que tributar.
Para controlar este cambio y hacerlo de manera organizada y controlada se emplea la
disciplina Adopción y excelencia, que establece mecanismos para determinar el estado actual
de la empresa, el estado futuro al que se desea llegar y los pasos, proyectos y acciones que se
deben realizar. Todo controlado a través de un modelo de madurez e implementado con el
uso de procedimientos de gobierno que norman cada paso y decisión a tomar.

Metodologia de Proyectos de Grado en Ingenieria de Sistemas - 2020 PDF

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

Metodologia de Proyectos de Grado en Ingenieria de Sistemas - 2020 PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD AUTONOMA DE COLOMBIA

VICE RECTORIA ACADEMICA

METODOLOGIA DE PROYECTOS DE GRADO

MARIO DUSTANO CONTRERAS CASTRO

BOGOTA, MARZO 2020

El Desarrollo de un Proyecto Informático exige al proponente responder y establecer:

Delimitación la Situación Problemica

Figura. Aplicación de Espina de Pescado en Planteamiento de un Problema

Antecedente. Formulación del Problema del Proyecto

Figura 1. Planteamiento de un Problema

Se recomienda formular dos tipos de objetivos:

¿Cómo se redactan los Objetivos Generales?

Figura 3. Estudio de Viabilidad.

Figura 4. Cronograma de Actividades. Fuente Propia

Figura 2. Diagrama de Gantt y actividades

Figura. Cronograma de fases y actividades

Su objetivo es suministrar información sobre resultados obtenidos en proyectos anteriores (antecedentes),

- El número de conceptos corresponde al criterio del proponente.

Ejemplo tomado del Proyecto Control de Aplicaciones y Registro de Novedades:

QUE ES UN PROYECTO SISTEMICO Y TECNOLOGICO

Figura 5. Proyecto Informático. Fuente Propia

Figura 6. Fases de un Proyecto Informático. Fuente Propia

Figura 7. Modelado del Negocio. Fuente Propia

Figura 8. Marco de Referencia. Fuente Propia

4. INGENIERIA DEL PROYECTO

Figura 9. Ingeniería del Proyecto. Fuente Propia

Figura 10. Ejemplo de Metodología de Desarrollo. Fuente Propia

4. INGENIERIA DEL PROYECTO

11. Ingeniería del Proyecto. Fuente Propia

4. INGENIERIA DEL PROYECTO

Tabla 5. Ingeniería del Proyecto Telemático

5. ANÁLISIS DE RESULTADOS OBTENIDOS VERSUS OBJETIVOS ESPECÍFICOS O ANÁLISIS DE

5. ANÁLISIS DE RESULTADOS OBTENIDOS VERSUS OBJETIVOS ESPECÍFICOS O ANÁLISIS DE

Características del estado del arte

Sociedad del El conocimiento es Böhme y Sther The knowledge

1.3 Diagrama de flujo BPMN

Paso 1. Reflexión de la parte derecha del Canvas. La del mercado:

Modelo de Negocios: Aplicación móvil para la enseñanza de artículos determinados e indeterminados

Modelo de Requisitos de Usuarios. Fuente Microsoft

1. Encontrar un proveedor de hosting web confiable.

 Excelente servicio al cliente

Más info en: https://www.palbin.com/es/blog/p32-seo-y-sem-que-es-el-posicionamiento-seo-y-sem.html

Figura. Página web final. De la Fuente

¿Por qué es importante personalizar el contenido de una página web?

Figura. Palabras Claves. De la Fuente

PROCESOS DEL NEGOCIO/FLUJOS DE TRABAJO/MODELANDO LOS PROCESOS DEL NEGOCIO

La notación de proceso implica un flujo de actividades de izquierda a derecha. Un

El conector ―supply‖ indica que la información u objeto conectado al proceso no se gasta en la

Juntando las piezas

Estos procesos de inducción/deducción se engloban dentro lo que se llama circulo mayéutico.

El ingeniero informático observa el mundo 1 (usando sus sentidos de percepción de manera

Al ingenieiro informático le interesará mas fijarse en una visión horizontal de la empresa, en

Área Vista Diagramas Conceptos Principales

Clase, asociación, generalización,

Vista de Casos de Diagramas de Casos Caso de Uso, Actor, asociación,

Vista de Diagramas de Componente, interfaz, dependencia,

Diagramas de Nodo, componente, dependencia,

Vista de Estados de Diagramas de

Diagramas de Estado, actividad, transición,

Diagramas de Colaboración, interacción, rol de

Administración o Gestión Vista de Gestión de Diagramas de

Restricción, estereotipo, valores,

La encapsulación presenta tres ventajas básicas: