TRABAJO DE REVISIÓN BIBLIOGRÁFICA N°1

TEMAS Y SUBTEMAS A INVESTIGAR

1. INGENIERÍA DE SOFTWARE
 Definición, Beneficios e Importancia en el ámbito del desarrollo de Software:
Desarrollar un software significa construirlo simplemente mediante su descripción. Esta es
una muy buena razón para considerar la actividad de desarrollo de software como una
ingeniería. En un nivel más general, la relación existente entre un software y su entorno
es clara ya que el software es introducido en el mundo de modo que provocara ciertos
efectos en el mismo.
Aquellas partes del mundo que afectarán al software y que serán afectadas por él será el
Dominio de Aplicación. Es allí donde los usuarios o clientes observarán si el desarrollo del
software ha cumplido su propósito.
Una de las mayores deficiencias en la práctica de construcción de software es la poca
atención que se presta a la discusión del problema. En general los desarrolladores se
centran en la solución dejando el problema inexplorado. El problema a resolver debe ser
deducido a partir de su solución.
Esta aproximación orientada a la solución puede funcionar en campos donde todos los
problemas son bien conocidos, clasificados e investigados, donde la innovación se ve en
la detección de nuevas soluciones a viejos problemas
Pero el desarrollo de software no es un campo con tales características. La versatilidad de
las computadoras y su rápida evolución hace que exista un repertorio de problemas en
constante cambio y cuya solución software sea de enorme importancia.
Importancia del Software. La palabra software se refiere a las instrucciones que se
incorporan a un sistema informático para que este lleve a cabo una determinada
función. ... El software es imprescindible para cualquier sistema informático o basado en
informática, puesto que, sin él, este no funcionaría
2. Gestión de Proyectos Informáticos (Planificación, Organización Dirección,
Ejecución, Seguimiento y Control)
 Planificar Es el proceso metódico diseñado para obtener un objetivo
determinado. La planificación es un proceso de toma de decisiones para
alcanzar un futuro deseado, teniendo en cuenta la situación actual y los
factores internos y externos que pueden influir en el logro de los objetivos
 Iniciación o Iniciar un proyecto (o fase) consiste en reconocer y comenzar
un nuevo proyecto o una fase dentro de un proyecto ya existente o Las
principales salidas son:
Nombrar a la persona que dirigirá el proyecto
Identificar a los interesados o agentes (stakeholders) del proyecto
Completar y firmar el acta del proyecto
  Planificación: El principal objetivo es guiar la ejecución
Las salidas principales son:
 El contrato del equipo del proyecto
 La definición del alcance del proyecto
 El Diagrama de descomposición del trabajo
 El plan del proyecto ü El plan de riesgos ü El plan de calidad

 Ejecución
 Consume la mayor parte del tiempo y de los recursos
 Requiere de las habilidades de liderazgo de la dirección del proyecto
 La salida principal es el producto o servicio contratado

 Seguimiento y control
 Realizan la medición del progreso para la consecución de los objetivos del
proyecto, controlar las posibles desviaciones del plan y decidir las acciones
correctivas para volver a adecuar el progreso al plan
 Afecta a todos los grupos de procesos y se lleva a cabo durante todas las
fases del ciclo de vida del proyecto
 Las salidas de estos procesos son los informes de progreso, los cambios
requeridos y las actualizaciones del plan

3. Métricas De Software (Fiabilidad, Usabilidad, Flexibilidad, Mantenibilidad,

Reusabilidad, Mantenibilidad, Eficiencia, Portabilidad etc)

Calidad de Software.
Existen varias definiciones asociadas al concepto de Calidad de Software, Pressman
define la calidad de software como “la concordancia con los requisitos funcionales y de
rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se espera de todo software
desarrollado profesionalmente” [1]. Según ISO/IEC 8402 es un “Conjunto de
características y relaciones entre ellas que proveen la base para la especificación de los
requisitos de calidad y la evaluación de la calidad”. Humphrey (1997) la define como “La
ausencia de defectos, seguridad, confiabilidad y cumplimiento de las especificaciones”, y
sostiene que la calidad de software debe ser construida desde el comienzo, no puede ser
añadida después [2]. La Ingeniería de Software según [3] se define como:
“Establecimiento y uso de principios de ingeniería robustos, orientados a obtener software
económico que sea fiable y funcione de manera eficiente sobre máquinas reales”. La
Calidad es una de las áreas de la ingeniería de software, actualmente existe una fuerte
competencia por introducir productos en el mercado, pero no solamente se busca la
mayor inserción, sino también la satisfacción del cliente, es por eso que se le está dando
mayor importancia a la Calidad en todo el proceso de desarrollo de software. Calidad en
el desarrollo de software es asegurar el mínimo de sorpresas posibles durante todas las
etapas del proceso, por eso es recomendable la utilización de Estándares o modelo de
calidad. Un producto de alta calidad es uno que conlleva un conjunto de factores de
calidad. Estos factores pueden ser descriptos en la especificación de requerimientos;
pueden ser culturales, o sea que se espera que normalmente estén asociados con el
producto mediante familiaridad de uso; o pueden ser factores de calidad que el
desarrollador considere importante, aunque no estén en los requerimientos del cliente o
en las expectativas de usuarios.ISO 9001. Es importante hacer mención a algunos
términos utilizados en lo que a Calidad se refiere, en este sentido, Gestión de Calidad, es
un Conjunto de Actividades para la implementación de políticas de calidad en todo el
desarrollo de software. El fin de la gestión es interpretar al cliente y poner en práctica un
plan para satisfacer sus expectativas. Dentro las actividades que comprende la Gestión
de Calidad se encuentra el Control de Calidad de Software que consiste en una serie de
operaciones en las que se aplican técnicas para verificar la calidad del software y
mantener controlado todo el proceso a lo largo del ciclo de vida. Otra actividad importante
de la Gestión de Calidad es la Verificación y Validación del Software que consiste en
comprobar si el producto obtenido cumple con los requisitos establecidos, es decir si
funciona según lo solicitado por el usuario y cumple con sus expectativas. El Control de
Calidad tiene como objetivo la detección de errores en las fases tempranas del desarrollo,
para evitar la propagación de los mismos y reducir costos en correcciones.

Modelos de Calidad del Software

Es importante incluir en la calidad de software la importancia de los requerimientos
implícitos y explícitos del producto, que permiten medir la calidad del mismo, y los
estándares de calidad y modelos de calidad existentes. Cada uno de estos modelos de
calidad consiste en un conjunto de características y/o factores. Estos factores pueden ser
medidos directa o indirectamente, de medición directa como errores y unidades de tiempo
e indirectamente como la facilidad de mantenimiento. Las medidas obtenidas deben ser
comparadas para obtener una indicación de la realidad. Por ejemplo, mientras más alta es
la complejidad, más difícil es conseguir el fácil mantenimiento del producto, es decir que,
dependiendo del tipo de software y del cliente, distintos factores serán necesarios para
distintos atributos de calidad, esto indicará qué modelo de calidad o estándar se debe
elegir para realizar el control de la misma. Los modelos de calidad son aquellos
documentos que integran la mayor parte de las mejores prácticas, proponen temas de
administración en los que cada organización debe hacer énfasis, integran diferentes
prácticas dirigidas a los procesos clave y permiten medir los avances en calidad [4]. Los
estándares de calidad son aquellos que permiten definir un conjunto de criterios de
desarrollo que guían la forma en que se aplica la ingeniería de software. Los estándares
suministran los medios para que todos los procesos se realicen de la misma forma y son
una guía para lograr la productividad y la calidad [4]. En el cuadro 1 se describe la
estructura de un modelo de calidad
 Factores de Calidad v Criterios de Calidad v Métricas

Los factores de calidad o atributos externos, son características que componen la calidad,
representan la calidad desde el punto de vista del usuario. Los criterios de calidad o
atributos internos, son aquellos en los que se descomponen los diferentes factores,
representan la calidad desde el punto de vista del producto, son aspectos de calidad
asociados a cada factor. Las métricas se definen para cada criterio de calidad, son
medidas cuantitativas que indican el grado en el que está presente un atributo en el
producto. Calidad de software implica distinguir entre calidad del producto y calidad del
proceso. Cuando se hace referencia a la calidad del producto, lo importante es obtener un
software de alta calidad para enfrentar la fuerte competitividad existente actualmente,
mientras que la calidad en el proceso de desarrollo permite garantizar productos con
calidad aceptable. Para evaluar la calidad de un producto de software, han surgido
distintos modelos, formados por factores y criterios asociados. Al evaluar estos factores
de calidad en las diferentes jerarquías, se puede determinar la calidad del producto de
software. Entre los modelos más importantes que evalúan la calidad del producto de
software se encuentran los siguientes
Modelo Mc Call
Este modelo fue creado por Jim Mc Call en 1977. Establece 3 perspectivas para el
análisis de la calidad de software, define 11 factores y 23 criterios relacionados a estos.
Las métricas que propone son preguntas que ponderan numéricamente un determinado
atributo del producto de software. Después de obtener los valores para todas las métricas
de un criterio específico, el promedio de todas ellas es el valor para ese criterio.
PERSPECTIVAS FACTORES CRITERIOS
Operatividad del Producto: factores Usabilidad: La facilidad de Operatividad
de calidad que influyen en el grado uso del software. Entrenamiento
en que el software cumple con su Comunicación
especificación. Integridad: La protección de Control de Acceso
programa del acceso no Auditoría de Acceso
autorizado.
Corrección: El grado en que Rastreabilidad
una funcionalidad coincide Completitud
con su especificación. Consistencia
Fiabilidad – confiabilidad: Consistencia
La capacidad de los Exactitud
sistemas de no fallar / la Tolerancia a fallos
medida en que falla el
sistema
Eficiencia: Además Eficiencia en Ejecución Eficiencia en
clasificado en la eficiencia Almacenamiento
de la ejecución y la
eficiencia de
almacenamiento y por lo
general significa que el uso
de los recursos del sistema,
ejemplo: tiempo de
procesador, memoria
Revisión del Producto: factores de Mantenibilidad: Esfuerzo Simplicidad
calidad que influyen en la capacidad requerido para localizar y Concreción
de cambiar el producto de software. arreglar un fallo en el
programa dentro de su
entorno operativo.
Facilidad de Prueba: La Simplicidad
facilidad del programa de Instrumentación
realizar pruebas para Autodescripción
asegurarse de que está Modularidad
libre de errores y cumple
con su especificación
Flexibilidad: La facilidad de Autodescripción
hacer los cambios Capacidad de expansión Generalidad
necesarios según lo Modularidad
solicitado en el entorno
operativo
Transición del Producto: factores de Reusabilidad: La facilidad Autodescripción
calidad que influyen en la capacidad de reutilización de software Generalidad
de adaptar el software a los nuevos en un contexto diferente. Modularidad
entornos. Interoperabilidad: El Modularidad
esfuerzo requerido para Similitud de comunicación Similitud de
acoplar el sistema a otro datos Independencia del sistema
sistema. Independencia de la máquina
 Portabilidad: El esfuerzo Autodescripción Independencia del
requerido para transferir un sistema Independencia de la máquina
programa desde un entorno
a otro

Modelos De Desarrollo de Software:

✓ Cascada
✓ Iterativo
✓ Evolutivo
✓ Incremental
✓ Espiral
✓ DRA
✓ En V
✓ Por Prototipos

Modelo en cascada
Modelo en cascada o ciclo de vida clásico
El modelo de ciclo de vida en cascada es el modelo más simple en desarrollo de software.
En él las etapas se llevan a cabo una detrás de otra de forma lineal, así sólo cuando la
primera fase se termina se puede empezar con la segunda, y así progresivamente.
Este modelo asume que todo se lleva a cabo y tiene lugar tal y como se había planeado
en la fase anterior, y no es necesario pensar en asuntos pasados que podrían surgir en la
siguiente fase. Este modelo no funcionará correctamente si se dejan asuntos de lado en la
fase previa. La naturaleza secuencial del modelo no permite volver atrás y deshacer o
volver a hacer acciones.

Este modelo es recomendable cuando el desarrollador ya ha diseñado y desarrollado

aplicaciones similares con anterioridad, es decir, tiene la experiencia suficiente para
terminar con una etapa y comenzar la siguiente.

Son tres las fases en que se agrupan las etapas de este tipo de ciclo de vida:

Definición del problema, que incluye tanto la especificación de requisitos como el análisis
del sistema.
Desarrollo, que abarca el diseño, implementación y pruebas del sistema.
Mantenimiento, es decir, la instalación y el mantenimiento del sistema.
 Planeación
COMUNICACIÓN Estimulación programación
Modelado
seguimiento
Inicio del proyecto recabar
los requerimientos Análisis diseño

Despliegue
Construcción
Entrega
Código pruebas
Asistencia

Retroalimentación
 Modelos de proceso incremental
Modelos de proceso incremental

 Como resultado del uso y/o evaluación de los incrementos previos se desarrolla un
plan para el incremento que sigue.
 El plan incluye la modificación del producto fundamental para cumplir mejor las
necesidades del cliente, así como la entrega de características adicionales y más
funcionalidad.
 Este proceso se repite después de entregar cada incremento, hasta terminar el
producto final.
 En cada incremento se entrega un producto que ya opera.
 Útil en particular cuando no se dispone de personal para la implementación
completa del proyecto en el plazo establecido por el negocio.
 Modelo evolutivo
Modelos de proceso evolutivos
 Plazos apretados
 Se comprende bien el conjunto de requerimientos o el producto básico
 Los detalles del producto o extensiones del sistema aún están por definirse.

Los modelos evolutivos son iterativos.

❖Prototipo

❖Espiral

Modelos de proceso evolutivos

Prototipo
El modelado se centra en la representación de aquellos aspectos del software que serán
visibles para los usuarios finales

Plan rápido
Comunicación

Modelado
diseño rápido

Despliegue y
entrada de
retroalimentación Construcción
del prototipo

Modelo en cascada o ciclo

de vida clásico Modelo
en V
Modelos de proceso evolutivos Prototipo

✓El cliente define un conjunto de objetivos generales.

✓No identifica los requerimientos detallados para las funciones y características.

Modelos de proceso evolutivos Prototipo.

Problemas

✓Los participantes ven lo que parece ser una versión funcional del software, pero no se
consideró la calidad, la facilidad de mantenimiento, por la prisa. Los usuarios exigen el
prototipo como producto funcional.

✓Se toman decisiones que inicialmente son las adecuadas (con el fin de lograr el
prototipo rápidamente): Lenguaje de programación conocido, algoritmo ineficiente. Esta
elección formará parte del sistema final.

Paradigma exitoso si…

✓Se definen desde el principio las reglas del juego. El prototipo sirve como el mecanismo
para definir los requerimientos. Después se descartará (al menos en parte) y se hará la
ingeniería del software real con la mirada puesta en la calidad.
Modelos de proceso evolutivos. Espiral.
▪ Propuesto en primer lugar por Barry Boehm.
▪ Es un modelo con la naturaleza iterativa de hacer prototipos y los aspectos controlados y
sistémicos del modelo de cascada.
▪Representa el proceso de desarrollo de software como una espiral.

Consideración explícita del riesgo

Modelos de proceso evolutivos. Espiral.

1. Definición de objetivos.
• Definen los objetivos específicos.
• Identifica las restricciones del proceso y el producto.
• Se traza un plan detallado de gestión.
• Se identifican los riesgos del proyecto. Dependiendo de los riesgos se planean las
estrategias.

2. Evaluación y reducción del riesgo

• Análisis detallado de cada riesgo.
• Plan para reducir los riesgos. P.e. Si existe el riesgo de tener requerimientos
inapropiados, se puede resolver desarrollando un prototipo del sistema.

3. Desarrollo y validación.
• Se elige un modelo para el desarrollo del sistema.
• Si existen riesgos en la interfaz de usuario se elige la construcción de prototipo.
 • Si existe riesgo de integración entre subsistemas, se podría elegir el modelo en
cascada.

4. Planificación.
• El proyecto es revisado.
• Se decide si continuar con otro ciclo en la espiral.
• Si se decide continuar se desarrollan planes para la siguiente fase.

Modelo DRA
(Desarrollo Rápido de Aplicaciones), Modelo de proceso del desarrollo del software lineal
secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a
“Alta velocidad” en el que se logra el desarrollo rápido utilizando un enfoque de
construcción basado en componentes. Si se comprenden bien los requisitos y se limita el
ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema
completamente funcional” dentro de periodos cortos de tiempo.
Fases del Modelo DRA
Modelo DRA
Cuando se utiliza principalmente para aplicaciones de sistemas de información, el
enfoque DRA comprende las siguientes fases:

Modelado de gestión
El flujo de información entre las funciones de gestión se modela de forma que responda a
las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué
información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la
proceso?

Modelado de datos
El flujo de información definido como parte de la fase de modelado de gestión se refina
como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las
características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos
objetos.

Modelado de proceso
Los objetos de datos definidos en la fase de modelado de datos quedan transformados
para lograr el flujo de información necesario para implementar una función de gestión. Las
descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto
de datos. Es la comunicación entre los objetos.
Generación de aplicaciones
El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software
con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver
a utilizar componentes de programas ya existentes (cuando es posible) o a crear
componentes reutilizables (cuando sea necesario). En todos los casos se utilizan
herramientas automáticas para facilitar la construcción del software.

Metodologías De Desarrollo de Software:

 ✓ PMI
 ✓ XP
 ✓ SCRUM
 ✓ RUP
 ✓ EUP
 ✓ AUP
 ✓ CMMI
 ✓ RMM

ESTRATEGIA METODOLÓGICA
METODOLOGÍA Se desarrolló una investigación aplicada, relacionada con el proceso de
desarrollo de software y la calidad del producto de software en una PYME, con
componentes cuantitativos que incluyeron el análisis de datos históricos del proceso de
desarrollo de software llevado hasta antes de la aplicación del nuevo proceso, junto a los
datos que se recolectaron en la prueba piloto aplicando la integración de los modelos
mencionados anteriormente; también hay un componente cualitativo que corresponde a la
descripción del proceso anterior y las evaluaciones realizadas a los modelos
seleccionados, usando matrices de mapeo y comparación. El desarrollo del presente
proyecto, se efectuó en 5 Fases, de la siguiente manera:
Fase de diagnóstico Esta fase corresponde al estudio inicial de la organización, su estado
actual en cuanto a procesos, metodologías y modelos de calidad utilizados para el
desarrollo de software, realizando un análisis descriptivo de cómo se lleva a cabo el
proceso de desarrollo de software; para lo cual se usaron los siguientes instrumentos:

 Descripción textual del proceso actual

 Diagrama de Actividades del proceso de desarrollo

 Tabla de roles actuales del equipo de desarrollo

 Cuadro de Herramientas actualmente utilizadas en el proceso de desarrollo.

Se procedió a analizar los datos históricos de los proyectos llevados actualmente en la
organización en cuanto a estimaciones, calidad, estado de satisfacción de sus clientes y
percepción del equipo de desarrollo. Para esto se utilizaron tablas comparativas de
métricas de estos proyectos, recolectadas previamente y el desarrollo de encuestas:

 Encuesta de nivel de satisfacción del producto para clientes

 Encuesta de nivel percepción del proceso a equipo de desarrollo

 Tablas de métricas recolectadas previamente:

PMI
El Project Management Institute (PMI) es una organización estadounidense sin fines de
lucro que asocia a profesionales relacionados con la Gestión de Proyectos. Desde
principios de 2011, es la más grande del mundo en su rubro, dado que se encuentra
integrada por cerca de 500 000 miembros en casi 100 países.

XP
La metodología XP o Programación Extrema es una metodología ágil y flexible utilizada
para la gestión de proyectos.
Extreme Programming se centra en potenciar las relaciones interpersonales del equipo de
desarrollo como clave del éxito mediante el trabajo en equipo, el aprendizaje continuo y el
buen clima de trabajo. Esta metodología pone el énfasis en la retroalimentación continua
entre cliente y el equipo de desarrollo y es idónea para proyectos con requisitos
imprecisos y muy cambiantes.

SCRUM
Es un marco de trabajo para desarrollo ágil de software. 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 proyectos,
caracterizado por:1
Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución
completa del producto.
Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos
auto organizados, que en la calidad de los procesos empleados.
Solapar las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo
secuencial o en cascada.

RUP
(por sus siglas en inglés de Rational Unified Process) es un proceso de desarrollo de
software desarrollado por la empresa Rational Software, actualmente propiedad de IBM.1
Junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar
más utilizada para el análisis, diseño, implementación y documentación de sistemas
orientados a objetos.
El RUP
no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías
adaptables al contexto y necesidades de cada organización. También se conoce por este
nombre al software, también desarrollado por Rational, que incluye información
entrelazada de diversos artefactos y descripciones de las diversas actividades. Está
incluido en el Rational Method Composer (RMC), que permite la personalización de
acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado,

y una especificación más detallada, el Rational Unified Process, que se vendiera como
producto independiente

EUP.
Significa "Proceso unificado de empresa". EUP es una metodología de desarrollo de
software que ayuda a las empresas a crear software de manera estructurada y
organizada. Es una extensión de la Proceso racional unificado (RUP), agregando dos
nuevas fases de desarrollo: Producción y Retiro
AUP
El proceso unificado ágil (AUP) es una versión simplificada de RUP desarrollada por Scott
Ambler. Describe un enfoque simple, fácil de entender, del desarrollo de software de
aplicación de negocios usando técnicas y conceptos ágiles
CMMI 
Es el acrónimo de Capability Maturity Model Integration y se refiere a los modelos que
contienen las mejores prácticas que ayudan a las organizaciones a mejorar sus procesos.
RMM
RMM o Relationship Management Methodology se define como un proceso de análisis,
diseño y desarrollo de aplicaciones hipermedia. Los elementos principales de este método
son el modelo E-R (Entidad-Relación) y el modelo RMDM (Relationship Management
Data Model) basado en el modelo HDM

LENGUAJE DE MODELAMIENTO UNIFICADO (UML)

✓ Definición, características, ventajas, evolución histórica

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado visual
común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de
sistemas de software complejos, tanto en estructura como en comportamiento. UML tiene
aplicaciones más allá del desarrollo de software, p. ej., en el flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en diferentes tipos de diagramas.
En general, los diagramas UML describen los límites, la estructura y el comportamiento del sistema
y los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se pueden usar para
generar código en diversos lenguajes usando los diagramas UML. UML guarda una relación directa
con el análisis y el diseño orientados a objetos
La historia y los orígenes de UML

"The Three Amigos" (los tres amigos) de la ingeniería de software, como se los conocía, habían
desarrollado otras metodologías. Se asociaron para brindar claridad a los programadores creando
nuevos estándares. La colaboración entre Grady, Booch y Rumbaugh fortaleció los tres métodos y
mejoró el producto final.

Los esfuerzos de estos pensadores derivaron en la publicación de los documentos UML 0.9 y 0.91
en 1996. Pronto se hizo evidente que varias organizaciones, incluidas Microsoft, Oracle e IBM,
consideraron que UML era esencial para su propio desarrollo de negocios. Ellos, junto con muchas
otras personas y compañías, establecieron los recursos necesarios para desarrollar un lenguaje de
modelado hecho y derecho. "Los tres amigos" publicaron la Guía del usuario para el Lenguaje
Unificado de Modelado en 1999, y una actualización que incluye información sobre UML 2.0 en la
segunda edición de 2005.

Característica

Brindar a arquitectos de sistemas, ingenieros y desarrolladores de software las herramientas para

el análisis, el diseño y la implementación de sistemas basados en software, así como para el
modelado de procesos de negocios y similares.

Hacer progresar el estado de la industria permitiendo la interoperabilidad de herramientas de

modelado visual de objetos. No obstante, para habilitar un intercambio significativo de
información de modelos entre herramientas, se requiere de un acuerdo con respecto a la
semántica y notación.

UML cumple con los siguientes requerimientos:

 Establecer una definición formal de un metamodelo común basado en el estándar MOF

(Meta-Object Facility) que especifique la sintaxis abstracta del UML. La sintaxis abstracta
define el conjunto de conceptos de modelado UML, sus atributos y sus relaciones, así
como las reglas de combinación de estos conceptos para construir modelos UML parciales
o completos.
 Brindar una explicación detallada de la semántica de cada concepto de modelado UML. La
semántica define, de manera independiente a la tecnología, cómo los conceptos UML se
habrán de desarrollar por las computadoras.
 Especificar los elementos de notación de lectura humana para representar los conceptos
individuales de modelado UML, así como las reglas para combinarlos en una variedad de
diferentes tipos de diagramas que corresponden a diferentes aspectos de los sistemas
modelados.
 Definir formas que permitan hacer que las herramientas UML cumplan con esta
especificación. Esto se apoya (en una especificación independiente) con una especificación
 basada en XML de formatos de intercambio de modelos correspondientes (XMI) que
deben ser concretados por herramientas compatibles.

Arquitectura de Software UML (Vistas)

Arquitectura dirigida por modelos (MDA) Un enfoque y un plan para lograr un conjunto coherente
de especificaciones de tecnología dirigida por modelos.

Basados en el uso de múltiples vistas concurrentes".1 Las vistas suelen describir el sistema desde
el punto de vista de diferentes interesados, tales como usuarios finales, desarrolladores o
directores de proyecto. Las cuatro vistas del modelo son: vista lógica, vista de desarrollo, vista de
proceso y vista física. Además, una selección de casos de uso o escenarios suele utilizarse para
ilustrar la arquitectura sirviendo como una vista más. Por ello el modelo contiene 4+1 vistas:1

 Vista lógica: La vista lógica está enfocada en describir la estructura y funcionalidad del
sistema. Los diagramas UML que se utilizan para representar esta vista son los Diagrama
de Clase, Diagrama de Comunicación, Diagrama de Secuencia.2

 Vista de desarrollo: La vista de desarrollo ilustra el sistema de la perspectiva del

programador y está enfocado en la administración de los artefactos de software. Esta vista
también se conoce como vista de implementación. Utiliza el Diagrama de Componentes
UML para describir los componentes de sistema. Otro diagrama UML que se utiliza en la
vista de desarrollo es el Diagrama de Paquetes.2

 Vista de proceso: La vista de proceso trata los aspectos dinámicos del sistema, explica los
procesos de sistema y cómo se comunican. Se enfoca en el comportamiento del sistema
en tiempo de ejecución. La vista considera aspectos de concurrencia, distribución,
rendimiento, escalabilidad, etc. En UML se utiliza el Diagrama de Actividad para
representar esta vista.2

 Vista física: La vista física describe el sistema desde el punto de vista de un ingeniero de
sistemas. Está relacionada con la topología de componentes de software en la capa física,
así como las conexiones físicas entre estos componentes. Esta vista también se conoce
como vista de despliegue. En UML se utiliza el Diagrama de Despliegue para representar
esta vista.2

 Escenarios: La descripción de la arquitectura se ilustra utilizando un conjunto de casos de

uso, o escenarios lo que genera una quinta vista. Los escenarios describen secuencias de
interacciones entre objetos, y entre procesos. Se utilizan para identificar y validar el diseño
de arquitectura. Esta vista es también conocida como vista de casos de uso.
Descripción y ejemplos de los diferentes diagramas UML (Ejemplos gráficos)

 Diagramas estructurales
Los diagramas estructurales muestran la estructura estática del sistema y sus partes en
diferentes niveles de abstracción. Existen un total de siete tipos de diagramas de
estructura:

 Diagrama de clases
Muestra la estructura del sistema, subsistema o componente utilizando clases con sus
características, restricciones y relaciones: asociaciones, generalizaciones, dependencias,
etc.

 Diagrama de componentes
Muestra componentes y dependencias entre ellos. Este tipo de diagramas se utiliza para el
desarrollo basado en componentes (CDB), para describir sistemas con arquitectura
orientada a servicios (SOA).

 Diagrama de despliegue
Muestra la arquitectura del sistema como despliegue (distribución) de artefactos de
software.

 Diagrama de objetos
Un gráfico de instancias, incluyendo objetos y valores de datos. Un diagrama de objeto
estático es una instancia de un diagrama de clase; muestra una instantánea del estado
detallado de un sistema en un punto en el tiempo.
 Diagrama de paquetes
Muestra los paquetes y las relaciones entre los paquetes.

 Diagrama de perfiles
Diagrama UML auxiliar que permite definir estereotipos personalizados, valores
etiquetados y restricciones como un mecanismo de extensión ligero al estándar UML. Los
perfiles permiten adaptar el metamodelo UML para diferentes plataformas o dominios.

 Diagrama de estructura compuesta

Muestra la estructura interna (incluidas las partes y los conectores) de un clasificador
estructurado.

 Diagramas de comportamiento
A diferencia de los diagramas estructurales, muestran como se comporta un sistema de
información de forma dinámica. Es decir, describe los cambios que sufre un sistema a
través del tiempo cuando está en ejecución. Hay un total de siete diagramas de
comportamiento, clasificados de la siguiente forma

 Diagrama de actividades
Muestra la secuencia y las condiciones para coordinar los comportamientos de nivel
inferior, en lugar de los clasificadores que poseen esos comportamientos. Estos son
comúnmente llamados modelos de flujo de control y flujo de objetos.

 Diagrama de casos de uso

Describe un conjunto de acciones (casos de uso) que algunos sistemas o sistemas (sujetos)
deben o pueden realizar en colaboración con uno o más usuarios externos del sistema
(actores) para proporcionar algunos resultados observables y valiosos a los actores u otros
interesados del sistema(s).

 Diagrama de máquina de estados

Se utiliza para modelar el comportamiento discreto a través de transiciones de estados
finitos. Además de expresar el comportamiento de una parte del sistema, las máquinas de
estado también se pueden usar para expresar el protocolo de uso de parte de un sistema.

 Diagramas de interacción. Es un subconjunto de los diagramas de comportamiento.

Comprende los siguientes diagramas:

 Diagrama de secuencia
Es el tipo más común de diagramas de interacción y se centra en el intercambio de
mensajes entre líneas de vida (objetos).

 Diagrama de comunicación
Se enfoca en la interacción entre líneas de vida donde la arquitectura de la estructura
interna y cómo esto se corresponde con el paso del mensaje es fundamental. La secuencia
de mensajes se da a través de una numeración.

 Diagrama de tiempos
 Se centran en las condiciones que cambian dentro y entre las líneas de vida a lo largo de
un eje de tiempo lineal.

 Diagrama global de interacciones

Los diagramas globales de interacciones brindan una descripción general del flujo de
control donde los nodos del flujo son interacciones o usos de interacción

Formato de especificación de casos de uso (Casos de uso en formato expandido)

Formato Expandido
El formato Expandido en cambio muestra a detalle cada paso del diagrama de caso de uso, este
formato se lo utiliza para obtener una mejor comprensión de los procesos y requisitos del sistema.
El formato expandido cuenta con:

-Parte Superior:

Caso de uso: Nombre del Caso de Uso

Actores: Lista de actores, indicando quién inicial el caso de uso.
Propósito: Intención del caso de uso
Vista General: La misma descripción del caso de uso de alto nivel o algún resumen similar.
Tipo:
Primario, secundario u opcional (para discutir).
Esencial o real (para discutir).
Referencia cruzada: Funciones del sistema y casos de uso relacionados.

Sección Media o corazón

Curso típico de eventos en términos de cada una de las acciones del actor y la correspondiente
respuesta del sistema

– Sección Final

Curso de eventos alternativos (describe alternativas importantes o excepciones que pueden

presentarse respecto al curso típico).
Por ejemplo:
Referencias
http://www.lsi.us.es/docencia/get.php?id=9178

https://diagramasuml.com/

https://ingenieriadesoftwareutmachala.wordpress.com/2017/01/22/formato-de-alto-nivel-
formato-expandido/

http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:modelo4_1.pdf

file:///C:/Users/user/Downloads/Dialnet-ComparacionDeModelosDeCalidadFactoresYMetricas-
5123569.pdf

http://agrega.juntadeandalucia.es/repositorio/20022017/6b/es-
an_2017022012_9122843/51_ciclo_de_vida_clsico_o_en_cascada.html#:~:text=Ciclo%20de
%20vida%20cl%C3%A1sico%20o%20en%20cascada,la%20segunda%2C%20y%20as%C3%AD
%20progresivamente.

https://www.uv.mx/personal/ermeneses/files/2018/02/Clase8-
Modelos_de_procesos_de_desarrollo_de_softwareII.pdf

https://www.ecured.cu/Modelo_de_desarrollo_r
%C3%A1pido_de_aplicaciones#/media/File:DRA1.jpg

https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-de-modelado-uml