1.

INGENIERÍA DE SOFTWARE:

I) Definición:

La primera mención que se hace a la ingeniería de software fue en 1968 en una conferencia
financiada por la OTAN allí se adopta este término la primera persona en usarlo es Fritz Bauer
[1] quien la define de la siguiente manera: “La ingeniería de software es el establecimiento y uso
de principios fundamentales de la ingeniería con objeto de desarrollar en forma económica
software que sea confiable y que trabaje con eficiencia en máquinas reales” no obstante esta
definición resulta muy sencilla por lo que se hace necesario complementarla con la definición
contribuida por IEEE que dice: “La ingeniería de software es: 1) La aplicación de un enfoque
sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software;
es decir, la aplicación de la ingeniería al software. 2) El estudio de enfoques según el punto 1.”

La ingeniería de software es una disciplina de ingeniería que comprende la producción de

software y no solo comprende procesos técnicos, se puede decir que la ingeniería de software
es una tecnología de varias capas en donde su base es la calidad, luego le sigue proceso, métodos
y herramientas; lo principal para este desarrollo el proceso de software el cual define una
estructura, los métodos proporcionan la experiencia técnica para elaborarlo y las herramientas
brindan apoyo automatizado o semi para el proceso y los métodos. Cuando se implemente la
herramienta donde la información ya puede ser utilizada se dice que queda establecido un
sistema ingeniería de software.

Se hace necesario resaltar que el ingeniero de software no es igual que un programador ya que
el ingeniero está en la capacidad de crear una solución complejo en tiempo, costo y calidad
mientras el programador no. Se puede considerar una ingeniería que está más relacionada a la
computación no tanto a las ciencias tradicionales sin embargo también se hace uso de estas.

II) Beneficios, Desventajas e Importancia:

A través de la ingeniería de software el desarrollo de este ha crecido demasiado haciendo que

cada vez sus exigencias sean más complejas; al ser un campo tan amplio este proceso se ha
diversificado bastante.

No está restringido por materiales, ni procesos de manufactura lo cual la simplifica, sin embargo,
al no tener este tipo de limitaciones el software puede volverse complejo lo cual implica un difícil
entendimiento del mismo ya que es intangible.

Las nuevas herramientas y notaciones hacen que al aplicar adecuadamente la ingeniería de

software se reduzca el esfuerzo que se necesita para producir sistemas grandes y complejos, sin
embargo, muchos de los intentos por aplicar este tipo de desarrollo se ven truncados ya que no
se aplica de forma efectiva lo que termina en un software irrealizable.

La velocidad de cambia tecnológico es muy rápida, cada vez los clientes presentan nuevos
requerimientos este cierto tipo de presión limita el desarrollo de software.

La importancia del desarrollo de software radica en su amplia utilidad ya que en esta era existe
una gran cantidad de software en muchas de las cosas que se están acostumbrados a llevar a
cabo, dentro de sus más grandes rasgos se puede resaltar su aplicación en computadoras,
dispositivos móviles, para la educación, investigación, trabajo, comunicación, etc. La capacidad
de poder optimizar tareas, incrementar ganancias, aumenta ingresos, optimizar tiempo hace de
la ingeniería de software indispensable y fundamental para la sociedad de la actualidad.
III) Gestión de Proyectos Informáticos: el proyecto informático es una secuencia de actividades
con un tiempo determinado y con recursos limitados para obtener un resultado, tiene
diferentes etapas:
- Planificación: Se establece el ámbito del software, es decir, la función, rendimiento,
restricciones, interfaces, fiabilidad que le cliente requiere, también se establece la
estimación de los recursos requeridos.
- Organización: Estructurar los aspectos mencionados en la planificación para poder dar
un orden, organizar los medios humanos y materiales para poder cumplimiento a lo
pactado.
- Ejecución: Proceso donde el equipo comienza la construcción.
- Control: Asegura la adecuada ejecución del proyecto.

IV) Métricas De Software: Las métricas del software proporcionan una indicación de cómo se
ajusta el software a los requisitos implícitos y explícitos del cliente, es decir, la calidad la cual
como se menciona anteriormente es una base para el desarrollo adecuado de software, estas
proporcionan una forma de crear modelos efectivos. Dentro de estas características se
encuentran:

- Fiabilidad: Que tenga un procesamiento correcto, valide y recupere entradas usuario,

recuperación de errores.
- Usabilidad: se observa las características y estética de la interfaz, comprensión global
del sitio, características especiales
- Flexibilidad
- Reusabilidad: La utilización de componentes desarrollados en el proyecto.
- Mantenibilidad: facilidad de corrección, adaptabilidad, extensibilidad.
- Eficiencia: desempeño del tiempo de respuesta, velocidad.

2. MODELOS Y METODOLOGÍAS DE DESARROLLO DE SOFTWARE:

I) Modelos de Desarrollo de Software: Es una descripción simplificada del proceso que se va

a llevar a cabo estos se propusieron con el fin de poner orden, es decir brindan una
estructura a todo el proceso de desarrollo de software.

Imagen 1- Representación gráfica modelo cascada

 Cascada (Imagen 1): también llamado ciclo de la vida clásico tiene un enfoque secuencial
consta de las siguientes etapas: análisis y definición de requerimientos, diseño y del sistema
software, implementación y prueba de unidades, integración y prueba del sistema,
 funcionamiento y mantenimiento. Es necesario indicar el hecho de que para cada fase que
cambie es necesario que la anterior esté terminada, una de las ventajas de este proceso es
que la documentación se produce en cada fase y esta es compatible con otros modelos, por
otro lado, una desventaja es el hecho de ser inflexible en cuanto a dividir los procesos del
proyecto en distintas etapas a menos que se hagan compromisos al comienzo de las etapas.

El análisis y definición de requerimientos o comunicación son los servicios, restricciones y

metas del sistema que se definen con el cliente, se inicia el proyecto y se especifica los
requerimientos.

El diseño del sistema y del software o planeación implica establecer una arquitectura del
sistema, se identifica y describa las abstracciones fundamentales del sistema de software y
las relaciones que se tendrán.

En la implementación y prueba de unidades o modelado se hace el diseño del software y se

hace una prueba para que cumpla las especificaciones.

En la integración de pruebas de sistema o construcción se reúnen y prueban las unidades

para asegurarse que se cumplan los requerimientos después de esas pruebas en los sistemas
le es entregado al cliente.

En esta etapa final que es el funcionamiento y mantenimiento el sistema se instala, en esta

parte del funcionamiento se corrigen posibles errores, se mejora los servicios
implementación.

Imagen 2- Representación modelo incremental

 Incremental (Imagen 2): En este modelo se aplica secuencias lineales (escalonados) y cada
una de estas secuencias produce incrementos, es decir, cada incremento tiene su propio ciclo
y conforme se complete cada etapa se verifica y se integra con los otros incrementos ya
completados. Las actividades de este modelo se dividen en procesos y subprocesos (software
factory) y para poderse llevar a cabo esta etapa es necesario tener etapas que no requieran
cambiar resultados anteriores al agregar nuevas.

Dentro de sus ventajas están: el cliente no tiene que esperar hasta que esté completo ya que
con solo el primer requerimiento (satisface requerimientos críticos) puede comenzar a
utilizarlo, existe bajo riesgo de fallo total del proyecto, es más flexible lo que reduce su coste,
es más sencillo de probar.
 Sus desventajas son: los incrementos deben ser relativamente pequeños y cada uno debe
entregar una funcionalidad al sistema, cada fase no se puede superponer con otra. Este tipo
de modelo se encuentra una variante llamada programación extrema.

Imagen 3- Representación modelo evolutivo

 Evolutivo (Imagen 3): Para algunos casos es necesario que cambie los requerimientos del
negocio esto no se puede representar en un proceso rectilíneo por lo que se hace necesario
hacer uso de otro modelo como es el caso de este, la idea es desarrollar una idea central y
se expone a los comentarios de los usuarios hasta que se desarrolle un sistema adecuado, las
actividades de especificación y desarrollo se entrelazan en vez de separarse

Existen dos tipos de este modelo el primero es el exploratorio (objetivo es que cliente explore
sus requerimientos) y entregar un sistema final el segundo es el de prototipos desechables
donde objetivo es comprender los requerimientos y desarrollar una mejor versión.

Dentro de sus ventajas se encuentra que satisface las necesidades inmediatas a los clientes,
especificación se puede desarrollar en forma creciente, aunque también tiene dos problemas
el proceso no es visible y a menudo los sistemas tienen una estructura deficiente, por lo que
se recomienda trabajarlo para sistemas pequeños

Imagen 4- Representación modelo iterativo

 Iterativo (Imagen 4): Consiste de la iteración de varios ciclos en cascada, en cada iteración
se le entrega al cliente una versión mejorada o que tenga mayor funcionalidad, cliente se
encarga de evaluar y corrige o propone mejorías esto se repetirá hasta obtener un producto
que cumpla con los requerimientos planeados.

Su uso es ideal para clientes que no tienen claro los requisitos ya que se puede ir presentando
distintos prototipos, también permite gestionar en pequeños ciclos lo que hace que riesgos
 sean más manejables. En cuanto desventajas el hecho de que puede que al no tener los
requisitos definidos pueden aparecer problemas en la arquitectura.

Imagen 5-Representación modelo espiral

 Espiral (Imagen 5): Este es una extensión del modelo de cascada, pero en vez de representar
un proceso secuencial se realiza un proceso en espiral, este modelo se basa en una estrategia
para reducir los riesgos, lo hace enfatizando cada ciclo de trabajo y estudia su riesgo antes
de proceder. Este espiral se divide en cuatro sectores.

a. Definición de objetivos: definición de objetivos específicos, sus respectivas restricciones

y el producto, se identifica la gestión de riesgo y de acuerdo a eso se planean estrategias.
b. Evaluación y reducción de riesgos: Análisis proyectado de riesgos evaluados y se definen
pasos a realizar
c. Desarrollo y validación: Elección de modelo adecuado
d. Planificación: Revisión proyecto y tomar la decisión si se debe continuar o parar eso
depende de que es lo que se quiere.

Imagen 6- Representación modelo espiral

 DRA: Este es el Modelo de Desarrollo Rápido de aplicaciones, que como su nombre lo indica
facilita y crea aplicaciones esto lo hace permitiendo crear sistemas utilizables en poco tiempo
por medio de un enfoque de construcción basado en componentes, para aprovechar al
máximo este modelo se hace necesario tener bien claros los requisitos. Se caracteriza por no
tener un sistema detallado, es desarrollado y utilizado en una serie de incrementos que
incluye una nueva función. Dentro de sus fases esta:

- Modelado de gestión
- Modelado de datos
 - Modelado de procesos
- Generación de aplicaciones
- Pruebas de entrega

Tiene ventajas como sus entregables pueden ser pasados fácilmente a otra plataforma, su
desarrollo tiene mayor nivel de abstracción, mayor flexibilidad, menor codificación, posibles
menos fallas, posible menor costo y tiene desventajas como que tiene inconvenientes si el
proyecto es grande, progreso más difícil de medir, menos eficiente y menor precisión
científica.

Imagen 7-Representación modelo en V

 En V: Es una representación gráfica del ciclo de vida en donde la parte izquierda de V
representa las especificaciones del sistema y la parte de la derecha de la V representa donde
se comprueba el sistema y la parte de abajo donde se encuentran ambas es la corriente de
desarrollo.

Imagen 8- Representación modelo por prototipos

 Por prototipos (Imagen 8): este tipo de modelo es más factible utilizarlo como una técnica
que se puede implementar en los otros modelos, ya que este le ayudara a mejorar la
comprensión de lo que se debe hacer y mejorar comprensión de los requerimientos que no
son claros. Entonces la idea es reunirse con más participantes y se define objetivo general,
identifican los requerimientos. Se planea una iteración para el prototipo y se lleva a cabo el
 modelado el cual se centra en la parte visible, se entrega y vuelve a hacer evaluado. Lo ideal
es que sirva para mecanismo de identificación de software.

II) Metodologías de Desarrollo de Software:

 RUP (Proceso Unificado de Rational): En este se define claramente quien, como, cuando y
que debe hacerse en el proyecto. Es iterativo e incremental donde quedan proyectos
divididos en mini proyectos, es una implementación del Desarrollo en espiral y consta de las
siguientes 4 fases:

El inicio en donde se define el alcance del proyecto y sus riesgos, se produce un plan de fases
y de iteraciones posteriores, en la elaboración se seleccionan casos que permiten la
arquitectura adecuada, se diseña solución preliminar se hace primer análisis, la construcción
es completar la funcionalidad del sistema y la transición es asegurar que el software esté
disponible para los usuarios finales.

Es el proceso más general de los existentes, es un método muy pesado, su grado de

complejidad puede resultar no adecuado.

Imagen 9-Metodología RUP

 PMI (Project Management Institute): Organización internacional sin fines de lucro

relacionada con la gestión de proyectos, tiene como objetivos formular estándares
profesionales es Gestión de proyectos, que a través de la investigación se genere
conocimiento, promueve la gestión de proyectos como profesión. Consta de diferentes
etapas: Iniciación, planificación, ejecución, seguimiento y control, por último, se encuentra
el cierre.

Imagen 10- PMI etapas

 XP (Programación extrema): Toma los principios y practicas llevándolos al extremo, su
objetivo es reducir el ciclo de vida del software. Se definen cuatro variables de desarrollo de
software: costo, tiempo, calidad y alcance. Se caracteriza por: tener un desarrollo iterativo e
incremental, se realizan pruebas unitarias continuas, programación en parejas, corrección de
todos los errores, integración del equipo de programación con el cliente, refactorización del
código, propiedad del código compartida y su simplicidad.

Imagen 11- Metodología XP

 CMMI (Integración del Modelo de Madurez de Capacidades): Presenta un meta modelo de
dos formas diferentes, el primero como un modelo continuo y el segundo como un modelo
de etapas. Se caracteriza por tener una clasificación con los siguientes niveles: nivel 0
(incompleto o inmaduro), nivel 1 (realizado o básico), nivel 2 (Administrado o gestionado),
nivel 3 (definido o establecido), nivel 4 (administrado cuantitativamente o predecible) y nivel
5 (optimizado).

Nivel 5: Su enfoque es mejora de proceso continua, se lleva a cabo por medio de la

organización donde se mejora continuamente los procesos para así cumplir los objetivos,
también se lleva a cabo un análisis causal y resolución.
Nivel 4: Su enfoque es gestionar cuantitativamente los procesos, su área de proceso es el
desempeño de proceso organizacional y la administración del proyecto cuantitativa.
Nivel 3: Utiliza procesos definidos basados en estándares, sus áreas de proceso son:
desarrollo de requisitos, solución técnica, integración de producto, verificación, validación,
enfoque en proceso organizacional, definición de proceso organizacional, capacitación
organizacional, administración de proyectos integrada, administración de proveedor
integrada, gestión de riesgo, análisis de decisión y resolución, entorno organizacional para
integración, formación de equipo integrado.
Nivel 2: Los productos resultantes se establecen, controlan y mantienen mediante la
administración básica del proyecto, sus áreas de proceso son: gestión de requisitos,
planificación de proyecto, monitoreo y control del proyecto, administración de acuerdo con
proveedor, medición y análisis, aseguramiento de calidad de proceso y producto,
administración de configuración.
Nivel 1: La organización implementa y alcanza los objetivos de los procesos.
Nivel 0: La organización no tiene una implementación efectiva de los procesos.
 Imagen 12- Metodología CMMI

RMM (Metodología de Administración de Relaciones): Se caracteriza por el modelo E-R

(Entidad-Relación) y el modelo RMDM (Relationship Management Data Model) basado en el
HMD1, se define como un proceso de análisis diseño y desarrollo hipermedia2. Se recomienda
utilizar esta metodología para estructuras regulares (clases de objetos bien definidas, y con
claras relaciones entre esas clases). Estos objetos se definen por medio de entidades,
atributos y relaciones asociativas, también se introduce el concepto de slice (trozo) el cual es
un trozo de atributos agrupados con la capacidad de subdividir la información (modelar). La
navegación se modeliza con la ayuda de primitivas de acceso, enlaces estructurales
(unidireccional y bidireccional) que permiten especificar la navegación entre slices, y visita
guiada condicional, índice condicional y agrupación, que permiten especificar la navegación
entre entidades. Esta metodología consta de varias etapas:

Imagen 13

Primera etapa: Los objetos del dominio se representan con ayuda del modelo E-R.
Segunda etapa: Se determina presentación del contenido y su modo de acceso
Tercera etapa: Se definen los caminos, en esta parte es posible definir estructuras de acceso
de alto nivel lo que permite dotar a la aplicación de niveles diferentes de trozos de
información.
Cuarta etapa: definir el protocolo de conversión de elementos del diagrama.
Quinta etapa: concepción del interfaz usuario
Sexta etapa: construcción del sistema y test

 SCRUM: Son congruentes con manifiesto ágil se utiliza la iteración, sirve para las siguientes
votaciones estructurales: requerimientos, análisis, diseño, evolución y entrega. Se basa en
realizar entregas parciales y regulares del producto final, es recomendado para proyectos
donde se tenga un entorno complejo y se haga necesario la obtención de datos de forma
rápida, sus requisitos son poco definidos y la innovación, competitividad, flexibilidad y

1
Modelo de Diseño de Hipermedia
2
Su nombre viene de hipertexto y multimedia, lo cual quieres decir que no solo trabaja texto, sino que
tiene imágenes, audio, vídeo, etc. (multimedia).
 productividad son fundamentales. SCRUM consiste en ejecutar bloques temporales (cortos
y fijos) y cada uno de estos proporcionara un resultado, un incremento en el producto final.
Consta de tres etapas: planificación de la iteración, ejecución de la iteración e inspección y
adaptación.

|
Imagen 14- Flujo proceso Scrum

Sprint: Unida de trabajo para alcanzar un requerimiento definido por el retraso en este tiempo
no se introducen cambios.

Retraso: lista prioridades del proyecto que dan al cliente un valor de negocio, a este si es posible
introducirle los cambios.

 EUP (Enterprise Unified Process)

 AUP (Proceso Unificado Ágil): Anteriormente eran conocidas como metodologías livianas
buscan enfocarse en la gente y dejar a un lado los métodos tradicionales tortuosos, es una
versión simplificada del proceso RUP. Aplica TDD que desarrollo dirigido por pruebas, modelo
ágil, gestión de cambios ágil y refactorización de base de datos para mejor productividad, es
iterativo e incremental.

Imagen 15-Metodología AUP

3. LENGUAJE DE MODELAMIENTO UNIFICADO (UML):

El Lenguaje de Modelamiento Unificado (UML) es “un lenguaje estándar para escribir diseños
de software. El UML puede usarse para visualizar, especificar, construir y documentar los
artefactos de un sistema de software intensivo” el objetivo del lenguaje modelado es hacer una
representación abstracta de la realidad con un propósito determinado, se pretende capturar
partes esenciales del sistema, es decir que es un lenguaje el cual se usa para especificar,
visualizar y documentar los diferentes sistemas de software, también el modelado de negocios
y almacenamiento de datos.

Dentro de sus principales características se encuentra que: Esta basado en Booch, OMT y OOSE,
se puede describir un sistema en diferentes niveles de abstracción, fragmenta el proyecto en el
número de diagramas que representan las diferentes vistas del proyecto y juntos representan
la arquitectura del mismo, ofrece vocabulario y reglas para crear y leer modelos, es
independiente al proceso de desarrollo, es capaz de cubrir las distintas vistas de la arquitectura
de un sistema.

En UML se pueden encontrar algunas ventajas: se facilita la comunicación ya que UML es

estándar, se basa en un modelo (meta modelo) con semántica bien definida, es fácil de aprender
y utilizar porque tiene una notación grafica concisa, puede utilizarse para modelar sistemas
software en diversos dominios, es fácilmente extensible. Aunque también tiene algunas
desventajas como: no tiene una metodología, no cubre todas las necesidades de un proyecto de
software, faltan ejemplos elaborados.

En 1994 Grady Booch y Jim Rumbaugh de Rational Corporation comienzan a unir sus métodos,
en 1995 Ivar Jacobson y su compañía Objectory se incorporan a Rational para poder seguir el
proceso de unificación, Jacobson aporta el método OOSE (OOSE: Object- Oriented Software
Engineering); esta fusión de notaciones termino convirtiéndose en el mencionado UML. En
1997, UML 1.0 se envía al Object Management Group3, esta versión de UML se revisó y dio como
resultado UML 1.1. Actualmente el estándar es UML 2.0 (es un estándar ISO), esta versión
contiene 13 diferentes diagramas para el modelado de software. Cabe destacar que para el
proceso de creación de UML también participaron otras empresas como Microsoft, Hewlett-
Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.

I) Arquitectura de Software UML (vistas):

Imagen 16- Vistas Arquitecturales (Philippe Krutchen)

 Vista de casos de uso (Use case view): A esta arquitectura le corresponden los siguientes
diagramas: estático4 y dinámico5, la funcionalidad que captura es como se percibe por los
usuarios finales, analistas y encargados de pruebas, se basa en casos de usos, no se
especifica la organización real del sistema.

3
Empresa sin fines de lucro involucrada en especificaciones de mantenimiento para su empleo en la
industria de la computación
4
Diagramas de caso de uso
5
Diagramas de interacción, de estados y de actividades
  Vista de Diseño (Logical View): A esta arquitectura le corresponden los siguientes diagramas:
estático6 y dinámico7, lo elementos que lo conforman dan soporte a los requisitos funcionales
del sistema, además interfaces y colaboraciones que describen el sistema.
 Vista de Interacción (Process view): A esta arquitectura le corresponden los mismos
diagramas de la vista de diseño, captura el flujo de control entre las diversas partes del
sistema, incluyendo los posibles mecanismos de concurrencia y sincronización, comprende
requisitos no funcionales como el rendimiento, escalabilidad y capacidad de procesamiento.
 Vista de Implementación (Development View): A esta arquitectura le corresponden los
siguientes diagramas: estático8 y dinámico9, captura los artefactos que se utilizan para
ensamblar y poner en producción el sistema software real, la arquitectura física del sistema
está definida por esta vista, su objetivo este en: configurar las distintas versiones de los
archivos físicos, hacer correspondencia entre clases y ficheros de código fuente, también
hace correspondencia entre componentes lógicos y artefactos físicos.
 Vista de Despliegue (Physical View): A esta arquitectura le corresponden los siguientes
diagramas: estático10 y dinámico11, captura las características de instalación y ejecución del
sistema, su ocupación principal distribuir las partes que forman el sistema real de software.

II) Descripción y ejemplos de los diferentes diagramas UML

[15]: Como se mencionó anteriormente en la versión actual
de UML hay 13 tipos de diagramas, estos se distribuyen de la
siguiente forma:

 Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema

modelado:

- Diagrama de clases: Sirve para visualizar las relaciones las relaciones entre clases las
cuales pueden ser asociativas, de herencia, de uso y de consentimiento. Se caracteriza
por:
Las clases se dibujan como rectángulos, se muestra el nombre de la clase, atributos
y operaciones en diferentes compartimentos.
Las relaciones entre clases se dibujan como las líneas que conectan rectángulos de
clases.

Imagen 17- Diagrama de clase

6
Diagramas de clases y de objetos. También son útiles los diagramas de estructura compuesta de clases.
7
Diagramas de interacción, de estados y de actividades.
8
Diagramas de componentes (especialmente la versión de artefactos) y de estructura compuesta.
9
Diagramas de interacción, de estados y de actividades.
10
Diagramas de despliegue
11
Diagramas de interacción, de estados y de actividades
 - Diagrama de objetos: modelan las instancias de elementos contenidos en los diagramas
de clases. Se caracteriza por:
Utilizan un subconjunto de los elementos de un diagrama de clase.
No muestran la multiplicidad ni los roles
Puede considerarse un caso especial de diagrama de clases.

Imagen 18-Diagrama de objeto

- Diagrama estructura compuesta: muestra la estructura interna de un clasificador,

incluyendo sus puntos de interacción a otras partes del sistema. Se caracteriza por:
Es un conjunto de elementos interconectados que colaboran en tiempo de
ejecución para lograr algún propósito.

Imagen 19-Representación estructura compuesta

- Diagrama de componentes: Muestra dependencias entre los componentes12 donde cada

componente ofrece algunas interfaces y utiliza otras. Los componentes se pueden
sustituir por otros componentes que realicen las mismas interfaces, si las dependencias
se hacen a través de interfaces. Se caracteriza por:
Mostrar la organización y las dependencias entre un conjunto de componentes.
Se representa como un grafo de componentes software unidos por medio de
relaciones de dependencia (generalmente de compilación).
Los diagramas de componentes se utilizan para modelar código fuente, versiones
ejecutables, bases de datos físicas.

Imagen 20- Diagrama de componentes

- Diagrama de despliegue: Muestran las relaciones físicas entre los componentes físicos y
lógicos del sistema final (hardware y software). Se caracteriza por:

12
Un componente es una unidad física de implementación con interfaces bien definidas pensada para
ser utilizada como parte reemplazable del sistema
 Los nodos se representan como un prisma.
Los componentes con una caja rectangular con dos protuberancias del lado
izquierdo.
Representa la creación de redes de sistemas de complejidad arbitraria.
Describe la topología del sistema, tiempo de ejecución, estructura del hardware y
el software

Imagen 21- Diagrama de despliegue

- Diagrama de paquetes: muestra como un sistema está dividido en agrupaciones lógicas

mostrando las dependencias entre esas agrupaciones. Se caracterizan por:
Son buenos elementos de gestión
Cada paquete se puede asignar a un individuo o a un equipo de desarrollo

Imagen 22-Diagrama paquetes

 Diagramas de Funcionamiento enfatizan en lo que debe suceder en el sistema modelado:

- Diagrama de actividades: se pueden utilizar para modelar actividades de software, éste

diagrama es provechoso para entender el comportamiento. Se caracterizan por:
Contiene bifurcaciones, así como divisiones de control en hilos concurrentes.
Soportan actividades tanto secuenciales como paralelas.
La ejecución paralela se representa por medio de iconos de fork/espera
Siempre están asociados a una clase, a una operación o a un caso de uso.

Imagen 23-Diagrama de actividades

 - Diagrama de casos de uso: es una unidad coherente de funcionalidad, expresada como
transacción entre los actores y el sistema. Su propósito es enumerar a los actores y los
casos de uso, y demostrar que actores participan en cada caso de uso. Se caracteriza por:
Describir el comportamiento del sistema al afrontar una tarea

Imagen 25-Simbología de diagrama de caso de uso

Imagen 24-Diagrama de casos de uso

- Diagrama de estados: Describe el comportamiento dinámico de los objetos en cierto

tiempo modelando los ciclos de vida de los objetos de cada clase. Se caracteriza por:
Describe el comportamiento de las clases y el dinámico de los casos de uso.
Son útiles para entender los mecanismos de control
Describe la respuesta de una instancia de la clase

Imagen 26-Diagrama de estados

 Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza

sobre el flujo de control y de datos entre los elementos del sistema modelado:

- Diagrama de secuencia: contiene detalles de implementación del escenario, incluyendo

los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre
los objetos

Imagen 27-Diagrama de secuencia

- Diagrama de colaboración: presenta una alternativa al diagrama de secuencia para
modelar interacciones entre objetos en el sistema.

Imagen 28-Diagrama de colaboración

- Diagrama de ciclo de tiempo: son una representación especial de interacción que se

enfoca en el tiempo de los mensajes enviados entre objetos.

Imagen 29-Diagrama de ciclo de tiempo

- Diagrama de interacción global: Muestran una interacción, que consiste de un conjunto

de objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre
ellos.

Imagen 30-Diagrama de interacción global

Referencias

[1] R. S. Pressman, Ingeniería del Software Un enfoque sistemático, Mc Graw Hill.

[2] A. López, C. Quijada, L. Medina, L. Monsalve y R. Milano, «MODELADO DE SISTEMAS DE

INFORMACIÓN,» [En línea]. Available:
http://www.oocities.org/es/monsalvelaura/fase2/analisis.html.

[3] I. Sommerville, Ingeniería del Software, Séptima ed., Pearson, 2005.

[4] F. S. Vacas, Complejidad y Tecnologías de la Información, Madrid, 2009.

[5] H. C. Maceda, «Ingeniería de Software,» Septiembre 2008. [En línea]. Available:

http://www.humbertocervantes.net/cursos/ingsoft/PresentacionCurso.pdf.

[6] A. Weitzenfeld, Ingeniería de Softwareorientada a objetos con UML, Java e Internet,

Thomson, 2005.

[7] I. d. P. Informáticos, «Informatica.uv.es,» 2002. [En línea]. Available:

http://informatica.uv.es/iiguia/2000/IPI/material.htm.

[8] «Metodologias de desarrollo de software,» [En línea]. Available:

https://sites.google.com/site/metdlgsddesarrollodesoftware/home.

[9] M. Ortiz, «Ingeniería de Software-Modelos de Desarrollo de Software,» [En línea].

Available: http://isw-udistrital.blogspot.com.co/.

[10] G. Encinas y F. Apodaca, «Metodologías de Desarrollo de Software,» 2012. [En línea].

Available: https://modelosdesoftware.webnode.es/.

[11] «Ingenieria de sofware,» [En línea]. Available:

http://ingenieriadesoftware.mex.tl/63758_AUP.html.

[12] C. Larman, UML y patrones, Naucalpan de Juárez: Pearson Educación, 2003.

[13] M. J. L. Lapuente, «Modelo RMM,» [En línea]. Available:

http://www.hipertexto.info/documentos/rmm.htm.

[14] J. F. Hiebaum, «Manual del Game Designer,» 6 Abril 2015. [En línea]. Available:
http://manualdelgamedesigner.blogspot.com.co/2015/04/metodo-scrum.html.

[15] F. R. Patricia López, «INGENIERÍA DEL SOFTWARE I,» [En línea]. Available:
https://ocw.unican.es/pluginfile.php/1403/course/section/1792/is1-t02-trans.pdf.