A0248 Ingeniería de Software MAU01

INGENIERA
DE
SOFTWARE
Carol Roxana Rojas Moreno
Cada autor es responsable del contenido de su propio texto.

De esta edicin:
Universidad Continental 2015
Jr. Junn 355, Miraflores, Lima-18
Telfono: 213 2760
Derechos reservados
Primera edicin: abril 2015
Tiraje: 500 ejemplares
Autor: Carol Roxana Rojas Moreno
Fondo Editorial de la Universidad Continental
Todos los derechos reservados.

Esta publicacin no puede ser reproducida, en todo ni en parte, ni registrada en o
trasmitida por un sistema de recuperacin de informacin, en ninguna forma ni por
ningn medio sea mecnico, fotoqumico, electrnico, magntico, electroptico,
por fotocopia, o cualquier otro sin el permiso previo por escrito de la Universidad.
NDICE
INTRODUCCIN
PRESENTACIN DE LA ASIGNATURA
COMPETENCIA DE LA ASIGNATURA
UNIDADES DIDCTICAS
TIEMPO MNIMO DE ESTUDIO
UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE
11
Diagrama de presentacin de la unidad I
11
ORGANIZACIN DE LOS APRENDIZAJES
11
Tema N. 1: El Software y la Ingeniera de Software
12
Definiciones de la ingeniera de software
12
Productos de software
12
Aplicaciones de software

13
Tema N. 2: Ciclo de Vida del Software
17
Ciclo de vida del software
17
Modelos de construccin de software
18
LECTURA SELECCIONADA N. 1
Modelos del proceso del software. Ingeniera del software: Un enfoque prctico.
Pressman, Roger. Pg. 19
21
ACTIVIDAD N. I
22
Tema N. 3: Gestin de Proyectos de Software
23
Componentes de la gestin de proyectos de software
23
Planificacin de proyectos de software
23
Estudio de factibilidad de proyectos
24
Tema N. 4: Mtricas en el Software
28
Factores de calidad de MacCall
28
Mtricas de la calidad del software
30
Qu son los costos de la ingeniera del software? Ingeniera del software.Sommerville, Ian. Pg. 9
36
Control de lectura N. 1
37
Glosario de la unidad I
38
BIBLIOGRAFA DE LA UNIDAD I
38
Autoevaluacin DE LA UNIDAD I
39
UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWARE
41
DIAGRAMA DE PRESENTACIN DE LA UNIDAD ii
41
41
TEMA N. 1: Enfoques de Desarrollo de Software
42
Enfoque estructurado
42
Enfoque orientado a objetos
43
TEMA N. 2: Metodologas de Desarrollo de Software
45
Metodologa tradicional
45
Metodologas giles
46
Metodologas Web
46
Cinco tendencias de metodologas giles para 2014. PMO informtica.
http://www.pmoinformatica.com/2013/12/metodologias-agiles-tendencias-2014.html
48
ACTIVIDAD N. 2
49
TEMA N. 3: Lenguaje de Modelamiento Unificado (UML)
50
Conceptos de UML
50
Diagramas de estructura y comportamiento
50
TEMA N. 4: Rational Unified Process (RUP-Proceso Unificado)
61
Caractersticas
61
Fases y flujos de trabajo
61
El proceso unificado es iterativo e incremental. El proceso unificado de desarrollo de software.
Jacobson, Ivar. Pg. 6
74
Tarea Acadmica N. 1
75
Glosario de la unidad II
BIBLIOGRAFA DE LA UNIDAD II
76
76
Autoevaluacin DE LA UNIDAD Ii
77
UNIDAD III: RUP Y UML NEGOCIO Y REQUERIMIENTOS
79
Diagrama de Presentacin de la Unidad III
79
79
Tema N. 1: Flujo de Trabajo de RUP: Modelado del Negocio
80
Evaluacin del negocio
81
Pictogrfico situacional y pictogrfico solucionador
81
Reglas del negocio
82
Diagramas UML: Diagrama de casos de uso del negocio y diagrama de objetos del negocio
82
Punto de vista de los usuarios del sistema acerca de los procesos. Anlisis de Sistemas, Diseo y
Mtodos.Whitten, Jeffrey., Bentley, Lonnie. Pg. 33
92
ACTIVIDAD N. 3
93
Tema N. 2: Flujo de Trabajo de RUP: Modelado de Requerimientos
94
Estimacin del proyecto
94
Diagrama UML: Diagrama de casos de uso de requerimientos, plantillas, diagrama de actividades

de requerimiento
94
La importancia de los requisitos. Programacin UML 2. Arlow, Jim & Neustadt, Ila. Pg. 33
104
Control de lectura N. 2
Glosario de la unidad III
BIBLIOGRAFA DE LA UNIDAD III
105
106
106
Autoevaluacin DE LA UNIDAD IiI
107
UNIDAD IV: RUP Y UML ANLISIS, DISEO E IMPLEMENTACIN
109
Diagrama de Presentacin de la Unidad Iv
109
109
Tema N. 1: Flujo de Trabajo de RUP: Modelado de Anlisis
110
Diagrama UML: Diagrama de clases y estereotipos de clase
110
Diagrama UML: Diagrama de secuencia, diagrama de colaboracin
116
Tema N. 2: Flujo de Trabajo de RUP: Modelado de Diseo
123
Diagrama UML: Subsistemas e interfaces, modelo arquitectnico
123
Diagrama UML: Diagrama de estados
127
Tipos de interfaz de usuario. Anlisis y diseo de sistema. Kendall, kenneth & kendall, Julie. Pg. 497
132
ACTIVIDAD N. 4
134
Tema N. 3: Flujo de Trabajo de RUP: Modelado de Implementacin
135
Diagrama UML: Diagrama de componentes
135
Diagrama UML: Diagrama de despliegue
137
Tema N. 4: Transformacin al Modelo de Datos
138
Clases persistentes
138
Generacin del modelo de datos
139
Dominio y atributo. Tecnologa y diseo de base de datos. Piattini, M., Marcos, E. y Calero, C. Pg.164
143
Tarea Acadmica N. 2
Glosario de la unidad IV
BIBLIOGRAFA DE LA UNIDAD IV
144
145
145
Autoevaluacin DE LA UNIDAD IV
146
ANEXO: claves de las Autoevaluaciones
148
INTRODUCCIN
a presente asignatura se desarrolla en

modalidad virtual y este Manual autoformativo
es un material didctico importante para su
aprendizaje.
La asignatura tiene como finalidad proporcionar al
estudiante los conocimientos necesarios acerca de
modelos de procesos de un software, as como de
elementos para la gestin y factores de calidad en
proyectos de software. Veremos al final un caso de
estudio prctico donde se presenta un modelo de
proceso de desarrollo de software llamado Proceso
Unificado y se emplea el Lenguaje de Modelamiento
Unificado como representacin, en el desarrollo de
de dicho caso prctico.
El presente material para la asignatura de Ingeniera
de Software consta de cuatro unidades: Unidad I:
Fundamentos de ingeniera de software, en el cual se
desarrollan los conceptos de ingeniera de software,
ciclos de vida del software, gestin de proyectos y
mtricas en el software. Unidad II: Fundamentos
para el modelamiento de software, aqu se
revisan conceptos y caractersticas de enfoques y

metodologas de desarrollo de software, lenguaje
de modelado y proceso unificado. Unidad III: RUP
y UML - Negocio y requerimientos: desarrollando el
flujo de trabajo de modelado del negocio y modelado
de requerimientos. Unidad IV: RUP y UML Anlisis,
diseo e implementacin, desarrollando el flujo de
trabajo de anlisis y diseo; el flujo de trabajo de
implementacin y la transformacin a un modelo de
datos.
Es recomendable que el estudiante desarrolle
una permanente lectura de estudio, as como
la investigacin en otros textos y va internet y
el desarrollo del modelo de construccin de un
software de un caso real de estudio. El contenido
del material se complementar con las lecciones por
videoclase. Agradecemos a quienes con sus aportes
y sugerencias han contribuido a mejorar la presente
edicin, que solo tiene el valor de una introduccin
al conocimiento de los conceptos y modelamiento de
software.
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Actividades Autoevaluacin
MANUAL AUTOFORMATIVO
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
PRESENTACIN DE LA ASIGNATURA
Diagrama
Objetivos
Inicio
COMPETENCIA DE LA ASIGNATURA
Desarrolla un modelamiento de software, compara los modelos de proceso de
construccinActividades
de softwareAutoevaluacin
y diferencia su uso aplicando los conceptos para la gestin
Desarrollo
dede
contenidos
proyectos de software y tcnicas de control de calidad para software con el uso de
factores y mtricas de calidad estndares, valorando su uso como buenas prcticas
para la construccin del software.
Diferencia los tipos de metodologa a aplicar en la construccin de un software
utilizando las metodologas tradicionales, las metodologas giles y las metodologas
web,
con actitud
crtica Bibliografa
para determinar el uso de alguna de ellas y modelar
Lecturas
Glosario
seleccionadas
la construccin de un software utilizando el proceso Rational Unified Process y la
notacin Unified Language Modeling en la herramienta Rational Rose, con creatividad
en la propuesta de solucin para el modelo de software.
Recordatorio
Anotaciones
UNIDADES DIDCTICAS
UNIDAD I
UNIDAD II
UNIDAD III
UNIDAD IV
Fundamentos
de ingeniera de
software
Fundamentos para
el modelamiento de
software
RUP y UML negocio

y requerimientos
RUP y UML
anlisis, diseo e
implementacin
TIEMPO MNIMO DE ESTUDIO

UNIDAD I
UNIDAD II
UNIDAD III
UNIDAD IV
1. y 2. semana
3. y 3. semana
4. y 5. semana
6. y 7.a semana
16 horas
16 horas
16 horas
16 horas
Bibliografa
10
Desarrollo
de contenidos
Diagrama
Desarrollo
de contenidos
Diagrama
Lecturas
seleccionadas
Objetivos
Inicio
Actividades
Glosario
Recordatorio
Anotaciones
Autoevaluacin
DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

Objetivos
Glosario
Inicio
Bibliografa
LECTURAS
SELECCIONADAS
Actividades
ACTIVIDADES
Autoevaluacin
Anotaciones
AUTOEVALUACIN
Lecturas
seleccionadas
Lecturas
seleccionadas
CONTENIDOS
Desarrollo
de contenidos
Recordatorio
Glosario
BIBLIOGRAFA
Bibliografa

Diagrama
Recordatorio
INGENIERA
DE SOFTWARE
Objetivos
Anotaciones
Inicio
CONOCIMIENTOS
PROCEDIMIENTOS
Tema N. 1: El software y la 1. I dentifica y analizar los

modelos de construccin
ingeniera de software
de software.
1. Definiciones de la
Desarrollo
de contenidos
ingeniera de software.
2. Productos
de software.
Glosario
Bibliografa
Lecturas
seleccionadas
2. E
jemplifica las aplicaciones de software.
3. R
ecopila informacin de
3. Aplicaciones de software.
situacin organizacional
Tema N. 2: Ciclo de vida del
para el modelamiento de
software
software, como proyecto
Recordatorio
Anotaciones
1. Ciclo de
vida del software.
de software en equipo.
2. Modelos de construccin de 4. I dentifica y describe los
software.
componentes de la gestin de software.
Lectura seleccionada N. 1
labora el cronograma
Modelos del proceso del 5. E
del proyecto de software
software. Ingeniera del sofen equipo.
tware: Un enfoque prctico.
Pressman, Roger. Pg. 19. 6. E
labora el estudio de
factibilidad econmica
Tema N. 3: Gestin de prodel proyecto de software
yectos de software
en equipo.
1. Componentes de la gestin
de proyectos de software.
2.
Planificacin de proyectos Actividad N. 1
de software.
Elabora un cuadro compa3.
Estudio de factibilidad de rativo de los modelos de
Software: Definicin, fases,
proyectos.
representacin, ventajas y
Tema N. 4: Mtricas en el sofdesventajas.
tware
1.
Factores de calidad de
Control de Lectura N. 1
MacCall.
2.
Mtricas de la calidad del Cuestionario de los Temas
N.1, 2, 3 y 4, adems de
software.
las actividades asignadas y
Lectura Seleccionada N. 2
autoevaluaciones.
Qu son los costos de la ingeniera del software? Ingeniera
del Software. Sommerville,
Ian. Pg. 9.
Autoevaluacin de la
unidad I
ACTITUDES
1. Asume con responsabilidad sus actividades acadmicas
asignadas.
2. Realiza con honestidad las evaluaciones
asignadas.
Bibliografa
11
12
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
TEMA N. 1: EL SOFTWARE Y LA INGENIERA DE SOFTWARE

Se ha preguntado cuales han sido los procesos o tareas que permitieron la creacin de la aplicacin de software que est usando en este momento: procesador de
textos, hojas de clculo, etc.?
Este proceso de creacin, va acompaado de herramientas y tcnicas estandarizadas que concluyen con el producto final: software.
1 Definiciones de la Ingeniera de Software
De acuerdo a diferentes autores (Pressman, Roger & Sommerville, Ian) la Ingeniera de Software es una disciplina de la Ingeniera que concierne a todos los aspectos
de la produccin del software.
Abarca un conjunto de tres elementos claves que facilitan al gestor a controlar el
proceso de desarrollo de software para construir software de alta calidad:
a. Los mtodos de la ingeniera de software. Suministran el cmo construir tcnicamente el software. Los mtodos abarcan un amplio espectro de tareas que
incluyen: planificacin y estimacin de proyectos, anlisis de los requerimientos
del sistema y del software, diseo de procedimientos algortmicos, codificacin,
prueba y mantenimiento.
b. Las herramientas de ingeniera de software. Suministran un soporte automtico
o semiautomtico para los mtodos. Las herramientas de ingeniera de software
son los mtodos necesarios para desarrollar el sistema. (Ejemplo Rational Rose).
c. Los procedimientos de la ingeniera de software. Une a los mtodos y herramientas, facilita un desarrollo racional y oportuno del software de computadoras. Los procedimientos definen la secuencia en la que se aplican los mtodos,
las entregas que se requieren y los controles que ayuden asegurar la calidad.
Objetivos de la Ingeniera de software
En la construccin y desarrollo de proyectos se aplican mtodos y tcnicas para resolver los problemas, y la informtica aporta herramientas y procedimientos sobre
los que se apoya la ingeniera del software.
Mejorar la calidad de los productos de software
Aumentar la productividad y trabajo de los ingenieros del software.
Facilitar el control del proceso de desarrollo de software.
Suministrar a los desarrolladores las bases para construir software de alta calidad
en forma eficiente.
Definir una disciplina que garantice la produccin y el mantenimiento de los
productos de software desarrollados en el plazo fijado y dentro del costo estimado.
El Software
Se entiende por software al programa de cmputo desarrollado y su documentacin asociada. Es decir, el software es un conjunto de instrucciones escritas en una
herramienta de desarrollo, la cual ser interpretada por la computadora de acuerdo a las reglas de sintaxis del lenguaje utilizado.
Ejemplo de software. Programas, archivos de configuracin, documentacin de la
estructura del sistema, manuales de instalacin y uso, sitios-web con informacin y
actualizaciones.
2 Productos de Software
a. Productos genricos
Productos que son producidos por una organizacin (controla las especificaciones)
Desarrollo
de contenidos
para ser vendidos al mercado. Un ejemplo vemos en la Figura 1.
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
Ejemplo: sistemas gestores de bases de datos, procesadores de texto, paquetes grficos, etc.
Recordatorio
Figura 1 . Ejemplo de producto genrico de software

Fuente: http://www2.sunat.gob.pe/pdt/
b. Productos hechos a medida

Sistemas que son desarrollados por pedido de un cliente (controla las especificaciones), por un desarrollador especfico. Un ejemplo lo vemos en la Figura 2.
Ejemplo: aplicaciones de negocio, sistemas de control de trfico areo, control de
procesos de fabricacin, etc.
Figura 2 . Ejemplo de producto software hecho a medida

Fuente:https://dinamicait.wordpress.com/2010/09/02/desarrollo-de-software-hecho-a-la-medida/
3 Aplicaciones de Software
a. Software de Sistemas. Conjunto de programas que han sido escritos para servir
a otros programas. Ejm. compiladores, editores, utilidades de manejo de perifricos, etc., mostrados en la Figura 3.
Anotaciones
Bibliografa
13
14
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 3. Ejemplo de software de sistemas

Fuente: http://mind42.com/public/7471e61c-60bf-41af-b3b3-f254a887ea09
b. Software de Tiempo Real. Coordina, analiza, controla sucesos del mundo real,
conforme ocurren. Ejm. Control de procesos: temperatura de un foco, considere un ejemplo en la Figura 4.
Figura 4. Ejemplo de producto genrico de software

Fuente: http://antisec-security.blogspot.com/2012/10/sistemas-scada-parte-i-bueno-antes-de.html
c. Software de gestin: Ayudan a la organizacin y acceden a una o ms bases de

datos que contienen informacin comercial. Ejm. Ventas, planillas, inventarios
y los ms usados, como se muestra el ejemplo en la Figura 5.
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 5. Ejemplo de software de gestin

Fuente: https://elmundodelarenta.wordpress.com/2013/05/24/caracteristicas-de-un-software-de-gestion-inmobiliaria/
d. Software de ingeniera y cientfico. Se caracteriza por los algoritmos y manejo de

nmeros. Ejm. astronoma, biologa molecular. Un ejemplo de software de reconocimiento de ADN en la Figura 6.
Figura 6 . Ejemplo de software ingeniera y cientfico

Fuente: hhttp://www.dnabaser.com/lands/secuenciacion%20y%20analisis%20de%20ADN.html
e. Software empotrado. Tambin conocido como embebido, reside en memoria

de solo lectura y controla productos y sistemas de mercados industriales y de
consumo. Ejm. Funciones digitales de un auto: sistemas de frenado o como el
ejemplo de una refrigeradora inteligente, segn vemos en la Figura 7.
Bibliografa
15
16
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 7. Ejemplo de software empotrado

Fuente: http://m.eltiempo.com/tecnosfera/novedades-tecnologia/el-internet-de-las-cosas-las-maquinasconquistan-la-red/14010188/1
f. Software de computadores personales. Son de uso habitual. Ejemplo: procesamiento de textos, hojas de clculo, grficos y multimedia, gestin de base de
datos, etc., tal como vemos en la Figura 8.
Figura 8 . Ejemplo de Software de computadores personales

Fuente: http://guadalupequintanillaperez.blogspot.com/
g. Software basado en web. Incorpora instrucciones CGI, Java, HTML, como las
tecnologas usadas para el almacenamiento en la Nube, como se muestra en la
Figura 9.
Figura 9 Ejemplo de software en web

Fuente: http://www.infochannel.com.mx/pivotal-nuevacompania-de-software-basado-en-web-de-emc-y-vmware
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
h. Software de Inteligencia Artificial. Sistemas expertos, reconocimiento de patrones (imgenes y audios), etc. En la Figura 10 se muestra un ejemplo de un sistema experto para medicina.
Figura 10. Ejemplo software sistema experto

Fuente:http://scielo.sld.cu/scielo.php?pid=S1684-18592012000200010&script=sci_arttext
TEMA N. 2: CICLO DE VIDA DEL SOFTWARE

Si observa cada producto o servicio que hace uso en sus quehaceres, se dar cuenta
que dicho producto o servicio ha pasado por un conjunto de etapas que permitieron su elaboracin.
En esta seccin veremos los ciclos de vida de un producto denominado software,
proporcionndonos los conceptos necesarios para determinar el tipo de ciclo de
vida a utilizar en el modelamiento de software.
1 Ciclo de Vida Clsico del Software
Se usa mucho el trmino de paradigma de software, que se define como un conjunto de procedimientos y tcnicas que permiten la construccin de un software.1
Existen varios modelos de ciclo de vida disponibles:
Ciclo de vida de Cascada Pura
Padre de todos los modelos de ciclo de vida.
Un proyecto progresa a travs de una secuencia ordenada de pasos partiendo
del concepto inicial del software hasta la prueba.

Al final de cada etapa se realiza una revisin para determinar si se est
preparado para pasar a la siguiente etapa.
Es dirigido por documentos que pasan de una etapa a otra.
Las etapas son discontinuas, no se solapan.
Tambin llamado lineal secuencial
1 Pressman, Roger. (2005). Ingeniera del software: Un enfoque prctico (quinta edicin).
Bibliografa
17
18
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 11. Ciclo de vida de Cascada

Fuente: http://ciclodevidacascadapura.blogspot.com/2009/06/ciclo-de-vida-tipo-cascada-pura.html
En la Figura 11 se grafican la etapas que definen al ciclo de vida clsico y que es

reconocido y aceptado por la comunidad desarrolladora.
2 Modelos de Construccin de Software
Existen modelos de proceso de software (Paradigmas de la ingeniera de software.
Pressman, Roger. Ingeniera de Software. 2002).
a. Modelo lineal secuencial. Sugiere un enfoque sistemtico, secuencial, para el
desarrollo del software que comienza en un nivel de sistemas y progresa con el
anlisis, diseo, codificacin, pruebas y mantenimiento, tal como se muestra en
la Figura 12.
Figura 12. Modelo lineal secuencial

Fuente: Pressman Roger. Ingeniera de software (quinta edicin)
b. Modelo de construccin de prototipos. Define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada,
proceso o salida. Si observamos la figura 13, el prototipo lo evala el cliente/
usuario y se utiliza para refinar los requisitos del software a desarrollar.
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura13. Modelo de construccin de prototipos

Fuente: Pressman, Roger. Ingeniera de software (quinta edicin)
c. Modelo DRA (Desarrollo Rpido de Aplicacin). Es un modelo de proceso del

desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto (de 60 a 90 das si se comprenden bien los requisitos), tal
como se observa en la figura 14.
Figura 14. Modelo DRA

d. Modelos evolutivos del proceso de software, que a su vez se clasifican en:

Incremental
Espiral
Desarrollo concurrente
Basado en componentes
INGENIERA
DE SOFTWARE
Bibliografa
19
20
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Cada uno de ellos considera un conjunto de etapas y tcnicas de desarrollo.

A continuacin en las figuras 15 y 16, se muestran ejemplos de los modelos.
Figura 15. Modelos evolutivos: incremental

Fuente: Pressman, Roger. Ingeniera de Software (quinta edicin)
Figura 16 Modelos evolutivos: espiral

La eleccin de un paradigma para la ingeniera de software se lleva a cabo de acuerdo a varios aspectos: la naturaleza del proyecto y de la aplicacin, los mtodos, las
herramientas a usar, los controles y las entregas requeridas.
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Lecturas
seleccionadas
Glosario
Bibliografa
MODELOS DEL PROCESO DEL SOFTWARE

Pressman,
Roger. Ingeniera del Software: Un enfoque prctico (quinta edicin).
Anotaciones
Pg. 19
Recordatorio
Para resolver los problemas reales de una industria, un ingeniero del software o un
equipo de ingenieros debe incorporar una estrategia de desarrollo que acompae
al proceso, mtodos y capas de herramientas descritos en la seccin 2.1.1 y las fases
genricas discutidas en la seccin 2.1.2.
Esta estrategia a menudo se llama Modelo de proceso o Paradigma de ingeniera del software : se selecciona un modelo de proceso para la ingeniera del software segn la
naturaleza del proyecto y de la aplicacin, los mtodos y herramientas a utilizarse y
los controles y entregas que se requieren.
En un documento intrigante sobre la naturaleza del proceso del software L.B.S.
Raccon [RAC95] utiliza fractales como base de estudio de la verdadera naturaleza
del proceso del software.
Todo el desarrollo del software se puede caracterizar como un bucle de resolucin
de problemas (figura 17), en el que se encuentran cuatro etapas distintas:
1. Statu quo
2. Definicin de problemas,
3. Desarrollo tcnico
4. Integracin de soluciones
Statu quo. Representa el actual de sucesos [RAC95].
Definicin del problemas. Identifica el problema especfico a resolverse.
Desarrollo tcnico. Resuelve el problema a travs de la aplicacin de alguna
tecnologa.
Integracin de soluciones. Ofrece los resultados (por ejemplo: documentos, programas, datos, nueva funcin comercial, nuevo producto) a los que solicitan la solucin en primer lugar.
Las fases y los pasos genricos de ingeniera del software definidos en la seccin
2.1.2 se divide fcilmente en estas etapas.
En realidad, es difcil compartimentar actividades de manera tan ntida como la fig.
18 da a entender, porque existen interferencias entre las etapas.
Aunque esta visin simplificada lleva a una idea muy importante: con independencia del modelo de proceso que se seleccione para un proyecto de software, todas
las etapas (statu quo, definicin de problemas, desarrollo tcnico e integracin
de soluciones) coexisten simultneamente en algn nivel de detalle. Dada la naturaleza recursiva de la fig. 18, las cuatro etapas tratadas anteriormente se aplican
igualmente al anlisis de una aplicacin completa y a la generacin de un pequeo
segmento de cdigo.
Raccon [RAC95] sugiere un Modelo de caos que describe El desarrollo del software como
una extensin desde el usuario hasta el desarrollador y la tecnologa. Conforme progresa
el trabajo hacia un sistema completo, las etapas descritas anteriormente se aplican
recursivamente a las necesidades del usuario y a la especificacin tcnica del desarrollador del software.
En las secciones siguientes, se tratan diferentes modelos de proceso para la ingeniera del software. Cada una representa un intento de ordenar una actividad inherentemente catica.
Es importante recordar que cada uno de los modelos se ha caracterizado de manera que ayude (con esperanza) al control y a la coordinacin de un proyecto de
software real.
Bibliografa
21
22
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Y a pesar de eso, en el fondo, todos los modelos exhiben caractersticas del Modelo
de caos.
Figura 17. Fases de un bucle de resolucin de problemas

Figura 18 Fases dentro de las fases del bucle de resolucin de problemas

Diagrama
Objetivos
Desarrollo
de contenidos
Actividades
Inicio
ACTIVIDAD N. 1
Autoevaluacin
Esta actividad puede consultarla en su Aula virtual.
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Bibliografa
Desarrollo
de contenidos
TEMA N. 3: GESTIN DE PROYECTOS DE SOFTWARE
Lecturas
seleccionadas
Cuando requiere de la creacin de un producto o servicio, usted piensa inmediaRecordatorio

tamente en identificar sus costos, tiempos y otros recursos que son necesarios para
analizar si su producto o servicio le ser rentable, por lo que empricamente est
haciendo uso de los principios de la gestin de un proyecto.
1 Componentes de la Gestin de Proyectos de Software
Se puede definir a todo proyecto como el esfuerzo temporal realizado con la finalidad de crear un producto o servicio nico. (Gua PMBOK , quinta edicin. 2013).
La gestin de proyectos es la aplicacin de los conocimientos, habilidades, herramientas y tcnicas a las actividades del proyecto, con el propsito de encontrar y
superar las necesidades y expectativas del mismo.2
La fig. 19 nos muestra el grupo de procesos que nos proporciona la gua PMBOK
para la gestin de proyectos.
Figura 19. Grupos de procesos de gestin de proyectos: PMBOK

Fuente: Fundamentos para la gestin de proyectos PMBOK (quinta edicin)
Variables del proyecto de software

Personas. Forma de organizar al personal (tiene un gran efecto sobre la eficiencia
con la que trabajen en el proyecto).
Proceso. Habrn tantas metodologas de gestin como metodologas tcnicas del
proyecto.
Producto. Concepto de producto que tiene el cliente y la creatividad del equipo.
Tecnologa. Seleccin de herramientas efectivas de desarrollo rpido.
2 Planificacin de Proyectos de software

Serie de decisiones para definir cmo se va a desarrollar el proyecto (Definicin del
problema, metas y objetivos; descomposicin en tareas (WBS), definicin del plan
de desarrollo, puesta en marcha del proyecto, etc.)
Figura 20. Duracin de las tareas y dependencias

Fuente: Rojas Moreno, Carol Roxana
2 Project Management Institute. (2013). Gua del PMBOK (quinta edicin).
INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
23
24
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
3 Estudio de Factibilidad de Proyectos

3.1 Factibilidad econmica
Determinamos el flujo de caja de acuerdo a los costos y beneficios.
Desarrollemos un ejemplo:
A. Fijemos los costos

Calculemos costos de personal

Personal
Asesor
Desarrollador
Cantidad
1
2
TOTAL ($)
Costo ($)
400.00
3200.00
3600
Calculemos costos de tecnologa

Hardware
Cantidad
Equipo
Computadora Pentium IV
2
Computadora Centrino Do 1
Impresora Lexmark 1020 Color 1
Mes
6
2
2
Costo/Mes ($)
Costo ($)
28.50
342.00
28.50
171.00
17.60
35.20
TOTAL ($)
Software
Software
Windows 8
Windows Vista
SQL Server 2013
Visual Studio 2013
Microsoft Office 2013
Meses
6
6
5
3
5
TOTAL ($)
Costo ($)
40.00
35.00
40.00
40.00
40.00
195.00
Total de costos de tecnologa

Hardware + Software = 548.20 + 195= 743.20
Calculemos costos de suministros
Materiales
Papel A4 80 gr (millar)
Papel Borrador (millar)
CD (caja)
Cartucho de Tinta
Cantidad
2
1
1
2
TOTAL ($)
Costo ($)
20.00
15.00
5.00
20.00
55.00
Calculemos costos de instalacin

Materiales
Capacitacin de personal
Instalacin del software
Pruebas del sistema
TOTAL ($)
Costo ($)
150.00
150.00
100.00
500.00
Calculemos Otros Costos Varios

Tarea
Internet
Fotocopiado
Movilidad
TOTAL ($)
Costo ($)
30.00
25.00
50.00
105.00
Desarrollo
de contenidos
Lecturas
seleccionadas
Calculemos costos de mantenimiento

Tarea
Mantenimiento
Software
Ao 0
0.00
Ao 1
600.00
Ao 2
600.00
Ao 3
600.00
Ao 4
600.00
Recordatorio
Beneficios tangibles

Calculemos los beneficios de reduccin de pago de horas extras de trabajo
Personal
Contador
Administrador
Gerente de ventas
Gerente general
Horas /Mes
5
4
3
2
Costo/Mes ($)
10.00
20.00
25.00
30.00
TOTAL ($)
TOTAL AO ($)
Costo ($)
50.00
80.00
75.00
60.00
265.00
3180.00
Calculemos los beneficios de reduccin de costos de materiales

Materiales
Costo ($)
Papel Bond
3.50
Papel Oficio
3.00
tiles de Escritorio
15.00
TOTAL ($)
21.50
TOTAL AO ($)
258.00
Total de beneficio tangible: 3180.00 + 258.00 = 3438.00
Beneficios intangibles
- La informacin solicitada sea ms oportuna y confiable.
- Los reportes sean entendibles y con mejor presentacin.
- Mejora en la toma de decisiones.
Tabla 1. Ejemplo de flujo de Caja
Descripcin
Costos
a. Personal
3600.00
b. Tecnologa
743.20
c. Suministros
55.00
d. Instalacin
400.00
e. Varios
105.00
f. Mantenimiento
Total de costos
Beneficios
a. Reduccin de
pago horas extras.
4903.20
0.00
0.00
600.00
600.00
3438.00
258.00
600.00
600.00
3438.00
258.00
600.00
600.00
3438.00
258.00
600.00
600.00
3438.00
258.00
600.00
600.00
3438.00
258.00
0.00
(4903.20)
3696.00
3096.00
3696.00
3096.00
3696.00
3096.00
3696.00
3096.00
3696.00
3096.00
b. Reduccin de
costos materiales.
Total de beneficios
Flujo de Caja
econmico
Glosario
Ao 5
600.00
B. Determinemos los beneficios
INGENIERA
DE SOFTWARE
Los datos obtenidos en la tabla 1 ayudan al anlisis de rentabilidad del proyecto

para determinar su aceptacin.
Anotaciones
Bibliografa
25
26
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
De acuerdo a los datos del flujo de caja econmico se obtuvo el anlisis de rentabilidad del proyecto reflejados, segn Sapag y Sapag (Preparacin y evaluacin de
proyectos, 2008):
- Valor Actual Neto (VAN)
Es la diferencia entre todos los ingresos y egresos expresados en moneda actual.
El VAN es expresado de la siguiente forma: VAN = VPB - VPC
Donde VPC, Valor Presente de los Costos y VPB, Valor Presente de los Beneficios.

VPC = I+E
n
(1+i) -1
i(1 + i)n

VPB = Y
n
(1+i) -1
i(1 + in
Donde
I Es la inversin inicial en el momento cero de la evaluacin.
E Es el flujo de egresos del proyecto.
Y Es el flujo de ingresos del proyecto.
i Es la tasa de inters efectiva anual.
n Periodo en aos.
Para determinar la aceptacin del proyecto, se deben considerar:
VAN > 0
Significa que se recupera la inversin y puede lograr un ingreso adicional, por lo
que se considera el proyecto como aceptado.
VAN = 0
Significa que los beneficios son iguales a los costos y se deben analizar otras variables, por lo que se considera el proyecto como postergado.
VAN < 0
Significa que los beneficios son menores que los costos, por lo que se considera el
proyecto como rechazado.
Segn el Flujo de Caja el Valor Actual Neto (VAN) = 4760.93
El VAN > 0, significa que se recupera la inversin y puede lograr un ingreso
adicional, por lo que se considera el Proyecto como Aceptado.
- Relacin Beneficio/Costo (B/C)
Es la relacin de los Beneficios sobre los Costos asociados al proyecto.
B/C es expresado de la siguiente forma: B/C = VPB / VPC
Desarrollo
de contenidos
Adems, para determinar la aceptacin del proyecto, se deben considerar las

siguientes restricciones:
B/C > 1
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Significa que el valor bruto de los beneficios son superiores a los costos, por lo que
se considera el proyecto como aceptado.
B/C = 1
Significa que el valor bruto de los beneficios son iguales a los costos incurridos, por
lo que es indiferente la aceptacin o el rechazo del proyecto.
B/C < 1
Significa que el valor bruto de los beneficios son menores a los costos, por lo que se
considera el proyecto como rechazado.
Relacin Beneficio-Costo (B/C) = 3696 / 600=6.16
El B/C > 1, el Proyecto como Aceptado.
- Tasa Interna de Retorno (TIR)
Evala el proyecto en funcin de una nica tasa de rendimiento por perodo con
la cual el Valor Presente de los Beneficios (VPB) son exactamente iguales al Valor
Presente de los Costos (VPC).
Es decir, es la tasa ms alta que un inversionista podra pagar sin perder dinero.
Esta tasa de descuento hace que el Valor Actual Neto se igual a cero, entonces el
TIR se expresa de la siguiente forma: VAN = VPB - VPC = 0
Dejando a la tasa de inters efectiva anual (i) como nica variable.
Para determinar la aceptacin del proyecto se deben considerar las siguientes
restricciones:
TIR > i
Significa que el inters equivalente sobre el capital es superior al inters mnimo
aceptable, por lo que se considera el proyecto como aceptado.
TIR = i
Significa que el inters equivalente sobre el capital es igual al inters mnimo
aceptable, por lo que se considera el proyecto como indiferente.
TIR < i
Significa que el inters equivalente sobre el capital es menor al inters mnimo
aceptable, por lo que se considera el proyecto como rechazado.
Tasa de Inters de Retorno (TIR) = 56% . El TIR > i, Significa que el proyecto como
Aceptado.
Bibliografa
27
28
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
TEMA N. 4: MTRICAS EN EL SOFTWARE

En ms de una ocasin, usted ha sido requerido en una encuesta para evaluar, es
decir, medir el servicio de un terminal de venta o de atencin del cliente, considerando indicadores propuestos en las referidas encuestas para determinar la calidad
de atencin o servicio.
1 Factores de Calidad de McCall
Gilb[GIL88] ha sugerido definiciones y medidas para la calidad (Pressman, Roger,
2002):
Correccin. Hasta dnde satisface un programa su especificacin y logra los objetivos de la misin del cliente.
Fiabilidad. Hasta dnde se puede esperar que un programa lleve a cabo su funcin
pretendida con la exactitud requerida.
Eficiencia. La cantidad de recursos informticos y cdigo necesario para que un
programa realice su funcin.
Integridad. Hasta dnde se puede controlar el acceso al software o a los datos por
personas no autorizadas.
Usabilidad. El esfuerzo necesario para aprender, operar, preparar los datos de entrada e interpretar las salidas de un programa.
Facilidad de mantenimiento. El esfuerzo necesario para localizar y arreglar un error
en un programa.
Flexibilidad. El esfuerzo necesario para modificar un programa operativo.
Facilidad de prueba. El esfuerzo necesario para probar un programa para
asegurarse de que realiza su funcin pretendida.
Portabilidad. El esfuerzo necesario para transferir el programa de un entorno de
sistema hardware y/o software a otro.
Reusabilidad. Hasta dnde se puede volver a emplear un programa (o partes de un
programa) en otras aplicaciones, en relacin al empaquetamiento y alcance de las
funciones que realiza el programa.
Interoperatibilidad. El esfuerzo necesario para acoplar un sistema con otro.
Luego, es necesario definir las mtricas que afecten a los factores de calidad; sin
embargo, muchas de las mtricas de McCall pueden medirse solamente de manera
subjetiva por lo que las mtricas pueden ir en forma de lista de comprobacin para
puntuar atributos especficos del software.
El esquema de puntuacin propuesto por McCall es una escala de 0 (bajo) al 10
(alto), emplendose las siguientes mtricas en el esquema de puntuacin:
Facilidad de Auditora. La facilidad con la que se puede comprobar el cumplimiento de los estndares.
Exactitud. La exactitud de los clculos y del control.
Estandarizacin de comunicaciones. El grado de empleo de estndares de interfaces, protocolos y anchos de banda.
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Complexin. El grado con que se ha logrado la implementacin total de una

funcin.
Concisin. Lo compacto que es el programa en trminos de lneas de cdigo.
Consistencia. El empleo de un diseo uniforme y de tcnicas de documentacin a
lo largo del proyecto de desarrollo de software.
Estandarizacin de datos. El empleo de estructuras y tipos de datos estndares a lo
largo del programa.
Tolerancia al error. El dao causado cuando un programa encuentra un error.
Eficiencia de ejecucin. El rendimiento del funcionamiento de un programa.
Capacidad de expansin. El grado con que se puede emplear el diseo
arquitectnico, de datos o procedimental.
Generalidad. La amplitud de aplicacin potencial de los componentes del
programa.
Independencia del hardware. El grado donde se desacopla el software del hardware
donde opera.
Instrumentacin. El grado con que el programa vigila su propio funcionamiento e
identifican los errores que ocurren.
Modularidad. La independencia funcional de componentes del programa.
Operatividad. La facilidad de operacin de un programa.
Seguridad. La disponibilidad de mecanismos que controlan o protegen los
programas y los datos.
Autodocumentacin. El grado en que el cdigo fuente proporciona
documentacin significativa.
Simplicidad. El grado de facilidad con que se puede entender un programa.
Independencia del sistema software. El grado de independencia del programa respecto a las caractersticas del lenguaje de programacin no estndar, caractersticas
del sistema operativo y otras restricciones del entorno.
Trazabilidad. La capacidad de seguir una representacin del diseo o un
componente real del programa hasta los requisitos.
Formacin. El grado en que ayuda el software a manejar el sistema a los nuevos
usuarios
Bibliografa
29
30
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
2 Mtricas de Calidad del Software

Anotaciones
Las Mtricas del software estn relacionadas con el desarrollo del software como
funcionalidad, complejidad, eficiencia. (Pressman, Roger, 2002)
Mtricas tcnicas. Se centran en las caractersticas de software por ejemplo: la complejidad lgica y el grado de modularidad. Mide la estructura del sistema, el cmo
est hecho.
Mtricas de calidad. Proporcionan una indicacin de cmo se ajusta el software a
los requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para que
mi sistema se adapte a los requisitos que me pide el cliente.
Mtricas de productividad. Se centran en el rendimiento del proceso de la ingeniera del software. Es decir qu tan productivo va a ser el software que voy a disear.
Mtricas orientadas a la persona. Proporcionan medidas e informacin sobre la
forma que la gente desarrolla el software de computadoras y sobre todo el punto de
vista humano de la efectividad de las herramientas y mtodos. Son las medidas que
voy a hacer de mi personal que va har el sistema.
Mtricas orientadas al tamao. Es para saber en que tiempo voy a terminar el
software y cuntas personas voy a necesitar. Son medidas directas al software y el
proceso por el cual se desarrolla.
Mtricas orientadas a la funcin. Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas, las lneas de cdigo (LDC),
las mtricas orientadas a la funcin, se centran en la funcionalidad o utilidad del
programa.
A. Orientadas al tamao
Si una organizacin de software mantiene registros sencillos, se puede crear una
tabla de datos orientados al tamao.
Se considera los siguientes indicadores:
PRODUCTIVIDAD =
CALIDAD =
LDC
Personal * Meses
LDC
Errores
DOCUMENTACION =
COSTO =
Pginas
LDC
NuevosSoles
LDC
Desarrollemos un ejemplo de clculo de estos indicadores, dada la informacin de

un proyecto de software:
Proyecto
Costo
168,000
LDC (lneas
de cdigo)
13,000
Pginas Documentacin
365
Errores
detectados
30
Cant. De
Personal
3
Clculo de Indicadores
- ndice de Productividad = 13,000 / (3 * 12) = 361.1 LDC por persona mensual
- ndice de Calidad = 13,000 / 30 = 433.3 LDC para cometer un error
- ndice de Documentacin = 365 / 13,000 = 0.02 Pginas por cada LDC
- ndice de Costos = 168,000 / 13,000 = 12.9 Soles por una LDC
Desarrollo
de contenidos
Lecturas
seleccionadas
B. Orientadas a la funcin
INGENIERA
DE SOFTWARE
Glosario
Sirve para medir la funcionalidad que entrega un sistema. Un punto de funcin

se define como una funcin comercial de usuario final, (Pressman, Roger. 2005).
Por ejemplo, tenemos un ejemplo de las medidas de punto de funcin:
Recordatorio
- N
mero de Entradas Externas (EE). Originada en un usuario o desde otra aplicacin. Pueden ser pantallas, formularios, cuadros de dilogo, controles o mensajes, a travs de los cuales un usuario final o cualquier otro programa pueda
aadir, borrar o cambiar datos del programa. Esto incluye cualquier entrada
que tenga un formato nico o un solo procesamiento.
Tabla 2. Ejemplo de Nmero de Entradas Externas
Fuente:https://unpocodejava.wordpress.com/2010/10/14/
estimacion-del-esfuerzo-basado-en-puntos-de-funcion-ajustados-3/
0 o 1 fichero
2 o 3 ficheros
4 o ms ficheros
1-5 tems de datos

Simple (4)
Simple (4)
Medio (5)
6-9 tems de datos

Simple (4)
Medio (5)
Complejo (7)
20 o ms tems de datos
Medio (5)
Complejo (7)
Complejo (7)
- N
mero de Salidas Externas (SE). Se deriva del interior de la aplicacin y proporciona informacin al usuario. Pueden ser pantallas, informes, grficos o
mensajes que el programa genera para el usuario final o cualquier otro programa. Esto incluye cualquier salida que tenga un formato diferente o requiera un
procesamiento diferente a otros tipos de salida.
Tabla 3. Ejemplo de Nmero de Salidas Externas
Fuente: https://unpocodejava.wordpress.com/2010/10/14/
0 o 1 fichero
2 ficheros
3 o ms ficheros
1-4 tems de datos 5-15 tems de datos 16 o ms tems de datos

Simple (3)
Simple (3)
Medio (4)
Simple (3)
Medio (4)
Complejo (6)
Medio (4)
Complejo (6)
Complejo (6)
- N
mero de Consultas Externas (CE). Combinaciones de entrada/salida, cada
entrada genera una salida simple e inmediata. Generalmente las consultas recuperan datos directamente de una base de datos, mientras que las salidas pueden
procesar, combinar o resumir datos complejos.
Tabla 4. Ejemplo de Nmero de Consultas Externas
Parte Salida
0 o 1 fichero
2 O 3 ficheros
4 o ms ficheros

Simple (4)
Simple (4)
Medio (5)
Simple (4)
Medio (5)
Complejo (7)
Medio (5)
Complejo (7)
Complejo (7)
Tabla 5. Ejemplo de Nmero de Consultas Internas

Parte Entrada
0 o 1 fichero
2 ficheros
3 o ms ficheros

Simple (3)
Simple (3)
Medio (4)
Simple (3)
Medio (4)
Complejo (6)
Medio (4)
Complejo (6)
Complejo (6)
Anotaciones
Bibliografa
31
32
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
- Nmero de Archivos Lgicos Internos (ALI). Agrupamiento lgico de datos en

las aplicaciones, mediante una EE. Es el nico archivo plano o de una sola tabla
en una base de datos relacional.
Tabla N 6 Ejemplo de Nmero Archivos Lgicos Internos
1-19 tems de datos

1 formato/relacin de registro
lgico
2-5 formatos/relaciones de registro lgico
6 o ms formatos/ relaciones de
registro lgico
Simple (7)
20-50 tems de
datos
Simple (7)
Simple (7)
Medio (10)
Complejo (15)
Medio (10)
Complejo (15)
Complejo (15)
Medio (10)
- N
umero de Archivos de Interfaz Externo (AIE). Agrupamiento lgico de datos
externo a la aplicacin y que podran usarse en la aplicacin. (Archivos controlados por otros programas, con los que el programa va a interactuar.)
Tabla 7. Ejemplo de Nmero de Interfaz Externo
1-19 tems de datos

1 formato/relacin de registro
lgico
2-5 formatos/relaciones de registro lgico
6 o ms formatos/ relaciones de
registro lgico
Simple (5)
20-50 tems de
datos
Simple (5)
Simple (5)
Medio (7)
Complejo (10)
Medio (7)
Complejo (10)
Complejo (10)
Medio (7)
Se elabora el cuadro de conteo:

Tabla 8. Ejemplo de cuadro de conteo
Fuente: http://es.slideshare.net/OliverCenteno/mtrica-v3-y-rup
Valor de dominio
Cuenta
Factor de complejidad
Simple
Media
Compleja
Nmero de entradas
Nmero de salidas
Nmero de consultas
Nmero de archivos
Nmero de interfaces
Cuenta total
Total
Desarrollo
de contenidos
Para luego aplicar los factores de ajuste:
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Tabla 9 Ejemplo de Tabla de Factores de Ajuste

Fuente: http://es.slideshare.net/OliverCenteno/mtrica-v3-y-rup
Factores de Ajuste (Fi)

Valor
1. Comunicacin de Datos. Los datos o informacin de control que la aplicacin utiliza se enva o recibe a travs de las facilidades de comunicacin.
0
Aplicacin es batch exclusivamente
1-2 Impresin o entrada de datos remota

3-5 Teleproceso (TP) interactivo
3
TP interface a un proceso batch
5
La aplicacin es interactiva, predominantemente
2. Funcin Distribuida. "Distribuida" significa que los componentes (o los datos) de la aplicacin estn distribuidos en dos o ms procesadores diferentes
(esto tambin incrementa el factor anterior).
0
a aplicacin no ayuda a la trasferencia de datos o a la funcin de proceL

samiento entre los componentes del sistema.
La aplicacin prepara datos para el usuario final de otro procesador
2-4 L
os datos se preparan para trasferencia, se trasfieren y se procesan en otro
componente del sistema.
5
as funciones de procesamiento se realizan dinmicamente en el compoL

nente ms apropiado del sistema.
3. Rendimiento. Referido a la importancia de respuesta dentro de todo el sistema.
0-3 A
nlisis y diseo de las consideraciones del rendimiento son estndar. No
se precisan requerimientos especiales por parte del usuario.
4
n la fase de diseo se incluyen tareas del anlisis del rendimiento para

E
cumplir los requerimientos del usuario.
dems se utilizan herramientas de anlisis del rendimiento en el diseo,

A
desarrollo e instalacin.
4. Configuracin utilizada masivamente. Referente a la importancia del entorno. Esto es, si hay restricciones de memoria o del hardware.
0-3 La aplicacin corre en una mquina estndar sin restricciones de operacin
4
estricciones de operacin requieren caractersticas especficas de la apliR

cacin en el procesador central.
dems hay restricciones especficas a la aplicacin en los componentes

A
distribuidos del sistema.
5. Tasas de transaccin. Una alta llegada de transacciones provoca problemas
ms all de los de la caracterstica 3.
0-3
as tasas son tales que las consideraciones de anlisis de rendimiento son

L
estndares.
n la fase de diseo se incluyen tareas de anlisis de rendimiento para

E
verificar las altas tasas de transacciones.
5
Adems, se utilizan herramientas de anlisis del rendimiento
6. Entrada online de datos.
0-2
Hasta el 15% de las transacciones tienen entrada interactiva
3-4
15% al 30% tienen entrada interactiva
5
30% al 50% tienen entrada interactiva
7. Diseo para la eficiencia de usuario final.
0-3
No se especifican requerimientos especiales
Se incluyen tareas de diseo para la consideracin de factores humanos
dems se utilizan herramientas especiales o de prototipado para proA

mover la eficiencia.
Bibliografa
33
34
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
8. Actualizacin online.
0
Anotaciones
Nada
1-2 A
ctualizacin online de los ficheros de control. El volumen de actualizacin es bajo y la recuperacin fcil.
3
Actualizacin online de la mayora de los ficheros internos lgicos
Adems es esencial la proteccin contra la prdida de datos
5 Adems se considera el coste de recuperacin de volmenes elevados.

9. Complejidad del procesamiento. Esto es, complejidad interna ms all de la
media en lo referente a la entrada, salida o lgica de procesamiento.
Qu caractersticas tiene la aplicacin?
Mucho procesamiento matemtico y/o lgico
Procesamiento complejo de las entradas
Procesamiento complejo de las salidas
Muchas excepciones de procesamiento, muchas transacciones incompletas
y mucho reprocesamiento de las transacciones.
Muchas excepciones de procesamiento, muchas transacciones incompletas
y mucho reprocesamiento de las transacciones.
Procesamiento de seguridad y/o control sensitivo
0
No se aplica nada de esto
Se aplica alguna cosa
Se aplican dos cosas
Se aplican tres cosas
Se aplican cuatro cosas
5 Se aplica todo.
10. Utilizable en otras aplicaciones. El cdigo se disea para que sea compartido o utilizable por otras aplicaciones (no confundir con 13).
0-1 U
na aplicacin local que responde a las necesidades de una organizacin
usuaria.
2-3 L
a aplicacin utiliza o produce mdulos comunes que consideran ms
necesidades que las del usuario.
4-5 A
dems, la aplicacin se "empaquet" y document con el propsito de
fcil reutilizacin.
11. Facilidad de Instalacin.
0-1 N
o se requieren por parte del usuario facilidades especiales de conversin
e instalacin.
2-3 L
os requerimientos de conversin e instalacin fueron descritos por el
usuario y se proporcionaron guas de conversin e instalacin.
4-5 A
dems se proporcionaron y probaron herramientas de conversin e instalacin.
12. Facilidad de operacin.
0 N
o se especifican por parte del usuario consideraciones especficas de operacin.
1-2 S
e requieren, proporcionan y prueban procesos especficos de arranque,
backup y recuperacin.
3-4 A
dems la aplicacin minimiza la necesidad de actividades manuales, tales
como instalacin de cintas y papel.
5 La aplicacin se disea para operacin sin atencin.
13. Puestos mltiples.
0
El usuario no requiere la consideracin de ms de un puesto
1-3 Se incluyeron necesidades de varios puestos en el diseo

4-5 S
e proporciona documentacin y plan de apoyo para soportar la aplicacin en varios lugares.
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
14. Facilidad de Cambio. Esfuerzo especfico de diseo para facilitar cambios

futuros.
0
o hay requerimientos especiales del usuario para minimizar o facilitar el

N
cambio.
1-3 Se proporciona capacidad de consulta flexible

4-5 D
atos importantes de control se mantienen en tablas que son actualizadas
por el usuario a travs de procesos online interactivos.
(Fi)
Entonces el Punto de Funcin es: PF = conteo total x [0.65 + 0.01 x (Fi)]
Bibliografa
35
36
Inicio
UNIDAD I:Objetivos
FUNDAMENTOS
DE INGENIERA DE SOFTWARE
ollo
nidos
Actividades
Autoevaluacin
Diagrama
as
nadas
Glosario
Bibliografa
Desarrollo
de contenidos
torio
Actividades
Autoevaluacin
Anotaciones
Lecturas
seleccionadas
Glosario
Bibliografa
QU SON LOS COSTOS DE LA INGENIERA DEL SOFTWARE?

Sommerville, Ian. Ingeniera del Software. Pg. 9
Recordatorio
Anotaciones
No existe una respuesta sencilla a esta pregunta, ya que la distribucin de costos a

travs de las diferentes actividades en el proceso del software depende del proceso
utilizado y del tipo de software que se vaya a desarrollar.
Por ejemplo, el software de tiempo real normalmente requiere de una validacin y
pruebas ms extensas que los sistemas basados en web. Sin embargo, cada uno de
los diferentes enfoques genricos al desarrollo de software tiene un perfil de distribucin de costos diferente a travs de las actividades del proceso del software. Si se
considera que el que el costo total de desarrollo de un sistema de software complejo
es de 100 unidades de costo, la figura muestra como se gastan estas en las diferentes
actividades del proceso.
En el enfoque en cascada, los costos de especificacin, diseo, implementacin e
integracin se miden de forma separada. Observe que la integracin y pruebas del
sistema son las actividades de desarrollo ms caras.
Normalmente, este supone alrededor del 40% del costo del desarrollo total, pero
para algunos sistemas crticos es probable que sea al menos el 50% de los costos de
desarrollo del sistema.
Si el software se desarrolla utilizando un enfoque iterativo, no existe divisin entre
la especificacin, el diseo y el desarrollo. En este enfoque, los costos de la especificacin se reducen debido a que solo se produce la especificacin de alto nivel
antes que el desarrollo.
La especificacin, el diseo, la implementacin, la integracin y las pruebas se llevan a cabo en paralelo dentro de una actividad de desarrollo. Sin embargo, an se
necesita una actividad independiente de pruebas del sistema una vez que la implementacin inicial est completa.
La ingeniera del software basada en componentes solo ha sido ampliamente utilizada durante un corto perodo de tiempo. En este enfoque, no tenemos figuras
exactas para los costos de las diferentes actividades del desarrollo de software. Sin
embargo, sabemos que los costos de desarrollo se reducen en relacin a los costos
de integracin y pruebas. Los costos de integracin y pruebas se incrementan porque tenemos que asegurarnos de que los componentes que utilizamos cumplen
realmente su especificacin y funcionan como se espera con otros componentes.
Adems de los costos de desarrollo, existen costos asociados a cambios que se le
hacen al software una vez que est en uso. Los costos de evolucin varan drsticamente dependiendo del tipo de sistema. Para sistemas software de larga vida, tales
como sistemas de orden y de control que pueden ser usados durante 10 aos o mas,
estos costos exceden a los de desarrollo por un factor de 3 o 4 (como se muestra en
la barra inferior de la figura), sin embargo, los sistemas de negocio ms pequeos
tienen una vida mucho ms corta y correspondientemente, costos de evolucin ms
reducidos.
Esta distribucin de costos se cumple para el software personalizado, el cual es
especificado por un cliente y desarrollado por un contratista. Para productos de
software que se venden (mayormente) para las PC, el perfil del costo es diferente.
Estos productos comnmente se desarrollan a partir de una especificacin inicial
utilizando un enfoque de desarrollo evolutivo. Los costos de la especificacin son
relativamente bajos. Sin embargo, debido que se pretende utilizarlos en diferentes
configuraciones, deben ser probados a fondo.
Los costos de evolucin para productos de software genricos son difciles de estimar. En muchos casos, existe poca evolucin de un producto. Una vez que una
versin de producto se entrega, se inicia el trabajo para entregar la siguiente y por
razones de mercadotecnia, esta se presenta como un producto nuevo (pero compatible) ms que como una versin modificada de un producto que el usuario ya
adquiri. Por lo tanto, los costos de evolucin no se consideran de forma separada
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
como el caso del software personalizado, sino que son sencillamente los costos de
desarrollo para la siguiente versin del sistema.
Modelo en cascada
0
25
50
75
Especificacin
Diseo
Desarrollo
25
50
100
Integracin y pruebas
Desarrollo iterativo
0
Especificacin
75
Desarrollo
100
Integracin y pruebas
Costos de desarrollo y evolucin para software de larga vida.

0
100
Desarrollo del sistema
200
Evolucin del sistema
Figura. Distribucin de costos de las actividades

de la ingeniera del software
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
CONTROL DE LECTURA N. 1
Glosario
Bibliografa
Recordatorio
Anotaciones
300
400
Bibliografa
37
38
UNIDAD I: Inicio
FUNDAMENTOS DE INGENIERA DE SOFTWARE
ollo
nidos
Actividades
Autoevaluacin
Diagrama
Objetivos
as
nadas
Glosario
Bibliografa
Desarrollo
de contenidos
Actividades
Lecturas
seleccionadas
Glosario
torio
Autoevaluacin
GLOSARIO DE LA UNIDAD I
Anotaciones
Bibliografa
Calidad. Es el grado en que se cumplen los requerimientos del software dados por
el cliente, de acuerdo a los estndares de desarrollo de software.
Recordatorio
Indicador. Dato que permite evaluar las mtricas de calidad del software.
Anotaciones
Operando. Variable con valor, que forman parte de la instruccin en la codificacin

de software.
Operador. Smbolo que permite operar o calcular y que forman parte de la instruccin en la codificacin de software
Paradigma. Modelo que incluye conceptos, procedimientos y tcnicas para desarrollar un software.
PMI. Project Management Institute, organizacin internacional que certifica en gestin de proyectos.
Sintaxis. Orden correcto de escribir smbolos segn un lenguaje de programacin,
de tal manera que proporcione un significado.
Transaccin. Procesamiento o algoritmo codificado y que es parte de los requisitos
funcionales del software.
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
BIBLIOGRAFA DE LA UNIDAD I
Pressman, Roger.(2005). Ingeniera del software: un enfoque prctico (quinta edicin). Espaa: Editorial McGraw-Hill. Biblioteca UC: 005.1 / P85 2009.
Recordatorio
Anotaciones
Project Management Institute. (2013). Gua del PMBOK (quinta edicin). Estados
Unidos de Norteamrica: Project Management Institute, Inc.
Sapag-Chain, Nassir & Sapag-Chain, Reinaldo. (2008). Preparacin y evaluacin de
proyectos (quinta edicin). Colombia: Editorial McGraw-Hill.
Sommerville, Ian. (2008). Ingeniera del software (stima edicin). Espaa: Editorial
Pearson. Biblioteca UC: 005.1 / S67 2008.
Desarrollo
de contenidos
Objetivos
Inicio
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
AUTOEVALUACIN DE LA UNIDAD I
1. La aplicacin web de matrculas de un colegio, es un ejemplo de:

Glosario
a) Producto genrico y software de sistemas
b) Producto hecho a medida y software de gestin
Bibliografa
c) Producto hecho a medida y software de computadores personales
Anotaciones
d) Producto genrico y software empotrado
e) Producto genrico y software de inteligencia artificial
2. Uno de los tres elementos claves que facilitan el control del desarrollo de
software y que indica el cmo construirlo, es:
a) Herramientas

b) Cascada pura
c) Mtodos
d) Lineal secuencial
e) Procedimientos
3.
Es un modelo de desarrollo de software que se basa en el modelo lineal
secuencial, para proyectos de 60 a 90 das de duracin:

a) Construccin de prototipos
b) Incremental
c) Espiral
d) DRA
e) Basado en componentes
4. Es el modelo que le permite al usuario interactuar con la propuesta de software

a desarrollar:

a) Espiral
b) Construccin de prototipos
c) Incremental
d) Basado en componentes
e) DRA
5. Segn PMBOK, la definicin de Proyecto corresponde a:

a) Esfuerzo temporal para crear un producto o servicio
b) Conjunto de procesos para la gestin

c) Conjunto de conocimientos y tcnicas para la gestin
d) Herramienta utilizada para la creacin de productos
e) Serie de decisiones para definir un servicio
6. E
n el anlisis de rentabilidad de un proyecto, se obtiene un Valor Actual Neto
mayor a cero. Eso se interpreta como:
a) Los beneficios son menores que los costos, se rechaza el proyecto

b) El inters de retorno es mayor al aceptable, se posterga el proyecto
c) Los beneficios son iguales que los costos, se posterga el proyecto
d) Los beneficios son mayores que los costos, se acepta el proyecto
e) El inters de retorno es menor al aceptable, se acepta el proyecto
7. La definicin del factor de calidad: Esfuerzo necesario para acoplar un sistema
con otro, corresponde a:

INGENIERA
DE SOFTWARE
a) Flexibilidad
Bibliografa
39
40
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
b) Facilidad de Mantenimiento
c) Fiabilidad
d) Eficiencia
Anotaciones
e) Interoperatibilidad
8. La definicin del factor de calidad: Transferir el programa de un entorno de sistema
hardware y/o software a otro, corresponde a:

a) Usabilidad
b) Portabilidad
c) Facilidad de prueba
d) Reusabilidad
e) Eficiencia
9. La definicin de la mtrica de calidad: capacidad de seguir una representacin del

diseo o un componente real del programa hasta los requisitos, corresponde a:

a) Simplicidad
b) Complecin
c) Consistencia
d) Trazabilidad
e) Instrumentacin
10. Segn los Puntos de Funcin: los informes, grficos o mensajes, corresponde a:

a) Salidas externas
b) Archivos lgicos internos
c) Entradas externas
d) Archivos de interfaz externo
e) Consultas externas
Desarrollo
de contenidos
Diagrama
Desarrollo
de contenidos
Lecturas
seleccionadas
Diagrama
Objetivos
Inicio
Recordatorio
Anotaciones
Autoevaluacin
Glosario
Bibliografa
Objetivos
Inicio
LECTURAS
SELECCIONADAS
CONTENIDOS
Anotaciones
Actividades
Lecturas
seleccionadas
Glosario
Diagrama
Glosario
DIAGRAMA DE PRESENTACIN DE LA UNIDAD II
Recordatorio
Desarrollo
de contenidos
Recordatorio
Lecturas
seleccionadas
UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE

SOFTWARE
Actividades
Autoevaluacin
AUTOEVALUACIN
ACTIVIDADES
BIBLIOGRAFA
Bibliografa

Anotaciones
Objetivos
INGENIERA
DE SOFTWARE
Inicio
CONOCIMIENTOS
Tema N. 1: Enfoques de
desarrollo de software
Desarrollo
de contenidos
1. Enfoque estructurado.
2.
Enfoque orientado
objetos.Glosario
Lecturas
Bibliografa
PROCEDIMIENTOS
1.
Identifica y explica las
tcnicas y fundamentos
del enfoque estructurado
y el enfoque orientado a
a
objetos.
seleccionadas
Tema N. 2: Metodologas
de desarrollo de software
1. Metodologa tradicional.
Recordatorio
Anotaciones
2. Metodologas
giles.
2. Identifica y relaciona la
aplicacin de las metodologas de software, segn
el tipo de situacin organizacional.
3. Define el tipo de enfoque

y la metodologa a usar en
el proyecto de software en
Cinco tendencias de metoequipo.
dologas giles para 2014.
4. Identifica, analiza y expliPMO informtica. http://
ca los flujos de trabajo de
w w w. p m o i n f o r m a t i c a .
RUP y su aplicacin en el
com/2013/12/metodoloproyecto de software en
gias-agiles-tendencias-2014.
equipo.
html
5.
Elabora el cronograma
Tema N. 3: Lenguaje de model proyecto de software
delamiento unificado (UML)
en equipo.
1. Conceptos de UML.
6. Elabora el informe preli2. Diagramas de estructura y
minar del proyecto de sofcomportamiento.
tware en equipo.
Tema N. 4: Rational unified
process (RUP - Proceso UniActividad N. 2
ficado)
Elabora un cuadro compara1. Caractersticas.
tivo de las metodologas de
2. Fases y Flujos de Trabajo. desarrollo de software.
Lectura Seleccionada N. 2
3. Metodologas web
El proceso unificado es iterativo e incremental. El proceso unificado de desarrollo

de software. Jacobson, Ivar.
Pg. 6.
Autoevaluacin de la
unidad II
Tarea acadmica N. 1
Investigacin y presentacin
de los conceptos principales
de los enfoques de desarrollo de software.
ACTITUDES
1.
Asume con responsabilidad sus actividades
acadmicas asignadas.
2. Realiza con honestidad
las evaluaciones asignadas.
Bibliografa
41
42
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
TEMA N. 1: ENFOQUES DE DESARROLLO DE SOFTWARE

Anotaciones
Si recuerda su forma de resolver asuntos cotidianos cuando son de cierta complejidad, seguramente recurre a descomponer su problema de tal forma que lo simplifica para su correcta compresin y anlisis y posteriormente su solucin.
1 Enfoque Estructurado
Este enfoque es un conjunto de conceptos y tcnicas para desarrollar software, cuya caracterstica es la descomponer en mdulos de programa o componentes de
software, para integrarlos en un proyecto ms complejo.1
Este enfoque utiliza algunos conceptos importantes como:
Modularidad. Un problema complejo se separa en partes ms pequeas (mdulos:
procedimientos y funciones), lo ms independientemente posible del resto de la
aplicacin. En la fig. 21 se muestra un ejemplo de modularidad, descomponiendo
en mdulos de programa y siendo invocados luego por el mdulo principal.
Figura 21. Ejemplo de modularidad

Cohesin. La forma en la que agrupamos unidades de software en una unidad mayor.

Ejemplo. Una clase con alta cohesin suele cumplir el principio de nica responsabilidad. En la fig. 22 se muestra un ejemplo con la clase Alumno, que contiene datos y
operaciones que lo definen y le corresponden como entidad.
Figura 22. Ejemplo de cohesin

1 Pressman, Roger. (2005). Ingeniera del software: un enfoque prctico (quinta edicin).
Desarrollo
de contenidos
Lecturas
seleccionadas
Acoplamiento. Grado de dependencia que tienen dos unidades de software. Como

se observa en la fig. 23, el mdulo Calcula depende de que se ejecute el mdulo
factorial, para poder finalizar con su proceso.
Recordatorio
Figura 23. Ejemplo de acoplamiento

2 Enfoque Orientado a Objetos

El paradigma Orientado a Objetos se basa en el concepto de objeto. Un objeto es
aquello que tiene estado (propiedades ms valores) y comportamiento (acciones y
reacciones a mensajes), tal como se muestra el ejemplo de la fig. 24.
Figura 24. Ejemplo de clase y objeto

INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
43
44
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Algunos conceptos principales de este enfoque
Anotaciones
Herencia. La transmisin de atributos y mtodos de una clase a otra. Como vemos

en la fig. 25 la clase Persona hereda sus atributos y mtodos a las clases Persona
Natural y Persona Jurdica y estas a su vez tienen sus propios mtodos y atributos.
Figura 25. Ejemplo de herencia entre clases

Agregacin. Es una relacin entre clases, que indica que una clase (todo) est formada por otras clases (partes), pero no se ve afectada en su funcionamiento si una
de las clases (parte) deja de funcionar. Por ejemplo en la fig. 26, si falta la clase
CDLibro, no afecta el comportamiento o funcionamiento de la clase Libro.
Figura 26. Ejemplo de agregacin entre clases

Composicin. Es una relacin entre clases, que indica que una clase (todo) est formado por otras clases (partes), pero S se ve afectada en su funcionamiento si una
de las clases (parte) deja de funcionar. Observemos la fig. 27 si el Detalle de Factura
donde se encuentra la informacin de los productos y su precio a pagar ya no existiese, la Factura deja detener el comportamiento o valor para lo que fue creado.
Figura 27. Ejemplo de composicin entre clases

Desarrollo
de contenidos
TEMA N. 2: METODOLOGAS DE DESARROLLO DE SOFTWARE
Lecturas
seleccionadas
Previamente, se ha revisado los enfoques de desarrollo de software pero adems,

Recordatorio
cada uno de estos enfoques pueden ser desarrollados usando una metodologa,
que nos indica las tareas y representaciones necesarias para construir el software.
Una metodologa puede seguir uno o varios modelos de ciclo de vida, es decir, el
ciclo de vida indica qu es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cmo hacerlo.
1 Metodologa Tradicional
A partir del detalle del producto que se quiere elaborar (anlisis funcional/tcnico, requerimientos funcionales/tcnicos, etc.), se definen fases/actividades
perfectamente planificadas en el tiempo en base a los recursos disponibles, a
fin de que se cumpla aquello que se haba previsto: calendario, costes y calidad.2
En la fig. 28 se muestra el conjunto de fases de una de estas metodologas.
Ejemplos
Capability Maturity Model (SW-CMM)
Capability Maturity Model Integration for Development (CMMI-DEV)
Big Design Up Front (BDUF)
Cleanroom Software Engineering
Rational Unified Process (RUP)
Essential Unified Process for Software Development (EssUP)
Fusebox Lifecycle Process (FLiP)
Software Process Improvement and Capability dEtermination (SPICE)
Mtrica
Jackson System Development (JSD)
Joint Application Development (JAD)
Open Unified Process (OpenUP- OpenUP/Basic)
Figura 28. Ejemplo de metodologa tradicional

Fuente: http://reconocimientogeneralydeactores.blogspot.com
/2013/03/Reconocimientogeneralydeactores.html
2 Blanco Cuaresma, Sergi.(2008). Metodologas giles de gestin de proyectos. Recuperado de http://www.marblestation.
com/?s=%C3%A1gil
INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
45
46
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
2 Metodologas giles
Anotaciones
Se entiende como Desarrollo gil de software a un paradigma de Desarrollo de

Software basado en procesos giles. Conocidos anteriormente como metodologas
livianas, intentan evitar los tortuosos y burocrticos caminos de las metodologas
tradicionales enfocndose en la gente y los resultados.
Es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto,3 como la
metodologa mostrada en la fig. 29.
Ejemplos
Extreme Programming (XP)
Scrum
Agile Modeling Adaptive Software Development (ASD)
Crystal Clear
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Lean Software Development (LSD)
Agile Unified Process (AUP)
Software Development Rhythms
Agile Documentation
ICONIX Process
Microsoft Solutions Framework (MSF)
Agile Data Method
Figura 29. Ejemplo de metodologa gil

Fuente: http://reconocimientogeneralydeactores.blogspot.com
/2013/03/Reconocimientogeneralydeactores.html
3 Metodologas Web
El actual desarrollo de sitios y aplicaciones Web est caracterizado por cuatro importantes factores:4
1.
Las aplicaciones y sitios Web son cada vez ms complejos en cuanto a grficas,
contenido y funcionalidad.
2. Cada vez hay ms y mejores herramientas de desarrollo.
3. Los tiempos de desarrollo requeridos por las empresas son cada vez ms cortos,
para estar mejor posicionados que la competencia.
4. Las aplicaciones y sitios Web requieren cambios peridicos, tanto de contenido
3 Universidad Unin Bolivariana. (sin fecha). Metodologas giles RUP. Recuperado de http://ingenieriadesoftware.mex.
tl/52788_Rup-Agil.html
4 Bravo Lillo, Cristian y Guerrero, Luis. (sin fecha). Mtricas de funcionalidad: una taxonoma para sistemas web. Universidad de
Chile. Recuperado de http://users.dcc.uchile.cl/~luguerre/papers/WCIS-01.pdf
Desarrollo
de contenidos
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
como de grficas, para mantenerse atractivos a los usuarios, es decir, requieren

un gran esfuerzo en mantenimiento.
Recordatorio
Como se muestra en la fig. 30 la principal caracterstica de estas metodologas es
la
elaboracin del diagrama navegacional.
Ejemplos
Ingeniera Web (IWeb)
Web Site Design Modeling (WSDM)
Web Modeling Language (WebML)
Web Composition Process Model (WCPM)
Web Engineering
Relationship Management Methodology (RMM)
JESSICA
Object Oriented Hypermedia Design Method (OOHDM)
Object-Oriented Hypermedia Method (OO-H)
Web Design Guidelines
UML Based Web Engineering Methodology (UWE)
Figura 30. Ejemplo de metodologa web: diagrama de navegacin

Fuente: http://slideplayer.es/slide/1048095/
Anotaciones
Bibliografa
47
48
ollo
nidos
Actividades
as
nadas
Glosario
torio
Anotaciones
Autoevaluacin

Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Bibliografa
Lecturas
seleccionadas
Glosario
Bibliografa
CINCO TENDENCIAS DE METODOLOGAS GILES PARA 2014
PMOinformtica. Recuperado de http://www.pmoinformatica.com/2013/12/

metodologias-agiles-tendencias-2014.html
Recordatorio
Anotaciones
Se acerca el fin del ao 2013 y todos nos preguntamos qu curso tomar la aplicacin de las metodologas giles en el prximo ao.
Esto fue motivo de discusin recientemente en el grupo de Linkedin Agile and Lean
Software Development, en donde se le pregunt a la audiencia Cules son tus predicciones de 2014 para las metodologas giles?.
A continuacin, PMOinformatica.com, La Oficina de Proyectos de Informtica,
presenta un resumen de las tendencias tratadas en este foro, algunos puntos son:
Crecimiento en la aplicacin de enfoques como Lean y Kanban.
Mayor nfasis en la prctica y menos en los dogmas.
Aplicacin de las metodologas giles en todo el equipo de proyecto, incluyendo
operaciones y reas de Negocio (DevOps).
Ms escalamiento en el uso de Metodologas giles (Agile at a Scale).
Aplicacin de las metodologas giles en reas distintas al Desarrollo de
Software.
Y t?, Cules tendencias en el desarrollo gil consideras ms relevantes para el
2014? Escribe tus comentarios.
A continuacin, cinco tendencias de Metodologas giles para 2014:
1. Crecimiento en la aplicacin de enfoques como Lean y Kanban

V
eremos ms organizaciones aplicando las metodologas giles Esbeltas,
como por ejemplo el Desarrollo de Software Esbelto (Lean Software Development) y Kanban.
Combinacin de ideas como Scrum y Kanban.
Combinacin de las prcticas de Lean Start-Up con el Desarrollo gil.
2. Mayor nfasis en la prctica y menos en los dogmas de las metodologas giles

M
etodologas giles modificadas y adaptadas a las necesidades de la organizacin.
Coexistencia de las metodologas giles con prcticas predictivas no giles.
L
o que funciona reemplazar a lo que est de moda o es correcto segn la
teora.
U
so de mtricas para demostrar el logro de los objetivos de negocio, satisfaccin de los interesados y que las prcticas aplicadas estn generando valor
para el negocio.
3. A
plicacin de las metodologas giles en todo el equipo de proyecto, incluyendo Operaciones y reas de Negocio (DevOps)

Involucramiento de toda la organizacin (no solo al equipo de desarrollo)

en el aprendizaje y uso de metodologas giles. Esto incluye al rea de negocio, rea de operaciones de software y otras reas de soporte, como por
ejemplo infraestructura de tecnologa y seguridad informtica.
L
os roles de las reas de Negocio, Desarrollo de Software y Operaciones de
Aplicaciones continuarn transformndose y colaborando entre s.
U
tilizacin de metodologas giles en todo el ciclo del proyecto, desde la
concepcin de la idea hasta su implantacin en produccin.
4.- Ms escalamiento en el uso de Metodologas giles (Agile at a Scale)
Desarrollo
de contenidos
Lecturas
seleccionadas
C
olaboracin de mltiples equipos giles en grandes proyectos (Scrum de
Scrum).
M
s equipos de trabajo distribuidos, cuyos integrantes no estn localizados
en las mismas oficinas e instalaciones.
Recordatorio
A
plicacin de metodologas giles en un alcance mayor al de equipos
individuales, en proyectos multidisciplinarios y entre productos.
5. Aplicacin de las metodologas giles en reas distintas al Desarrollo de Software
Diagrama
Desarrollo
de contenidos
O
rganizaciones de desarrollo, como por ejemplo desarrollo de nuevos productos, investigacin y desarrollo, entre otros.
P
royectos de Seguridad Crtica, como por ejemplo rea mdica (Salud),
control en tiempo real en fbricas, industria de control de procesos, seguridad, mbito financiero, industrias altamente reguladas por gobiernos, etc.
Objetivos
Actividades
Inicio
ACTIVIDAD N. 2
Autoevaluacin
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Bibliografa
INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
49
50
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
TEMA N. 3: L ENGUAJE DE MODELAMIENTO UNIFICADO (UML)

Qu entendemos por modelo? Seguro ya tiene una respuesta a la pregunta, pues
hacemos uso de modelos en cada situacin real. Definiremos a un modelo como la
representacin abstrada de la realidad que nos rodea, para su comprensin.
Conceptos de UML
Unified Modeling Language (UML), es una notacin (lenguaje) que representa grficamente construcciones del modelo de objetos, para el desarrollo de un software.
(Arlow, Jim & Neustadt, Ila, 2005)
Diagramas de Estructura y Comportamiento

Se definen dos aspectos en la diagramacin:(Arlow, Jim & Neustadt, Ila, 2005)
Estructura esttica. Describe objetos para modelar y cmo se relacionan.
Comportamiento dinmico. Cmo interactan los objetos.
Estructura esttica de UML
I. Bloques de Construccin. Elementos bsicos de modelado, relaciones y

diagramas.
Elementos. Necesarios para que elabore el modelo, tales como:
De
comportamiento
De agrupacin
Verbos de un
modelo como
interacciones, actividades, mquinas
de estados.
Paquete: Agrupa
elementos del
modelo
semnticamente
relacionados.
Estructurales
Clase, Interfaz,
Colaboracin,
Caso de Uso, Clase
Activa,
Componente,
nodo.
De anotacin
Nota: Se anexa al
modelo para dar
informacin al
modelo.
- Relaciones: Le permitirn mostrar como dos o ms elementos se relacionan

(significativamente) entre s.
Observemos algunos ejemplos:
Tipo de relacin
Semntica
Dependencia
Asociacin
Agregacin
Composicin
Contencin
Generalizacin
Origen depende y es afectado por Destino

Vnculos entre elementos
Destino es parte de Origen
Similar a agregacin, pero ms restringida
Origen contiene a Destino
Origen es una especializacin de destino
Realizacin
Origen garantiza ejecutar el contrato especificado por

destino
- Diagramas. Un repositorio de elementos y relaciones. Son vistas o ventanas del

modelo, no es el modelo en s.
Desarrollo
de contenidos
La fig. 31 muestran los diagramas versin base la versin UML 2.0.
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 31. Diagramas UML 1.5

Fuente: Letelier Torres, Patricio. Desarrollo de software orientado
a objeto usando UML. http://slideplayer.es/slide/94087/
II. Mecanismos comunes. Estrategias para el modelado tales como: Especificaciones, Adornos, Divisiones Comunes, Mecanismos de extensin (amplan la semntica de un elemento, OCL), Estereotipos, Valores Etiquetados.
III. Arquitectura. Estructura organizacional de un sistema, incluida su descomposicin en partes, su conectividad, interaccin, mecanismos y principios directores
que informan al diseo de un sistema (Rumbaugh. Manual de referencia de UML).
- Diagrama de paquetes
Los diagramas de paquetes se usan para reflejar la organizacin de paquetes y sus
elementos. En la fig. 32 se muestra un ejemplo de Diagrama de Paquetes.
- Diagrama de casos de uso
Representa lo que hace el sistema y cmo se relaciona con su entorno.
- Casos de uso. Secuencia de acciones realizadas.
Figura 32. Ejemplo de paquetes

INGENIERA
DE SOFTWARE
Bibliografa
51
52
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
- Relaciones en un Diagrama de Casos de Uso. Existen los siguientes tipos de

relaciones en un Diagrama de Casos de Usos:
Anotaciones
a. Comunicacin (Communicate). Es la nica relacin entre actor y caso de uso.

b. Incluye (Include). Un caso de uso requiere la ejecucin de otro caso de uso.
c. Extiende (Extend). Se ejecuta el caso de uso base, bajo ciertas condiciones.
d. Herencia. Uno o ms actores y casos de uso heredan de caractersticas y
comportamiento comn.
En la fig. 33 se muestra un Diagrama de Casos de uso y sus relaciones.
Figura 33. Ejemplo de diagrama de casos de uso

- Diagrama de clases (diagrama estructural)

Muestra el conjunto de clases y las relaciones existente entre estas (asociacin
simple, herencia, generalizacin, composicin).
Una clase puede tener los siguientes estereotipos:
- Clase entidad (entity). Modelan informacin.
- Clase entorno (boundary). Comunicacin del usuario y del sistema.
- Clase control (control). Coordinan los eventos del sistema.
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
La fig. 34 muestra estereotipo y sus relaciones del Diagrama de Clases.
Figura 34 Ejemplo de diagrama de clases

- Diagrama de objetos
Muestra los objetos y las relaciones entre ellos. Similar al diagrama de clases, pero
con la instancia o instancias de cada clase, tal como se muestra en la fig. 35.
Figura 35. Ejemplo de diagrama de objetos

Bibliografa
53
54
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
- Diagrama de secuencia
Anotaciones
El diagrama muestra el envo de mensajes de los objetos. Como en la fig. 36, se

muestra el objeto (rectangular), la lnea de vida (lnea entrecortada), el foco de
control (rectngulo en la lnea de vida) y los tipos de mensajes.
Figura 36. Ejemplo de tipos de mensajes

La fig. 37 es un ejemplo de Diagrama de secuencia (Ventas de la Farmacia).
Figura 37. Ejemplo de diagrama de secuencia

Desarrollo
de contenidos
- Diagrama de colaboracin (diagrama de comunicacin)
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
Es una diagrama que muestra los mensajes y el orden de colaboracin que debe
darse, como en la fig. 38.
Recordatorio
Figura 38. Ejemplo de diagrama de colaboracin

Anotaciones
Bibliografa
55
56
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
- Diagrama de estados (diagrama de mquina de estados)
Anotaciones
El diagrama de estados modela el comportamiento de una parte del sistema (clase)

a travs del tiempo. Cada estado tiene un nivel de detalle como entry, exit, do; y
una transicin con el detalle de evento (orden para cambiar de un estado a otro),
condicin para realizar la transicin y la accin (actividad que propiamente permite cambiar de un estado a otro), as como si se tiene la misma transicin a diferentes estados o viceversa, se puede utilizar un supraestado para su representacin tal
como en la fig. 39 para el objeto control VerificandoDatos, del caso propuesto de
Ventas de una Farmacia.
Figura 39. Ejemplo de diagrama de estados de una clase

- Diagrama de actividades
Muestra el flujo de actividades de un Caso de Uso. Es similar a un diagrama de flujo
estructurado y est apoyado en la secuencia de pasos dados en las plantillas de cada
caso de uso, ya sea del negocio o del requerimiento.
Actividad. Es un nodo el cual indica una tarea especfica desarrollada por el objeto.
Punto de decisin. Realiza un conjunto de actividades segn una condicin.
Barra de sincronizacin. Permite agrupar actividades concurrentes.
Carriles. Conjunto de actividades que realiza un objeto, tal como observamos en la
fig. 40 usando carriles (swimlanes) y puntos de decisin.
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 40. Ejemplo de diagrama de actividades

Fuente: Rojas Moreno Carol Roxana
- Diagrama de componentes
Permite visualizar las partes de un sistema (para ensamblarse y ejecutables), como
se muestra en la fig. 41.
- Componente. Parte de un sistema (archivos de cdigo fuente, binarios, de configuracin, de instalacin, ejecutables, tablas, etc).
Figura 41. Ejemplo de diagrama de componentes

INGENIERA
DE SOFTWARE
Bibliografa
57
58
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
- Diagrama de despliegue
Modela la topologa de hardware sobre la cual se ejecutar la aplicacin, indicando dnde se
ejecutarn los componentes.
Anotaciones
- Nodos. Es el elemento fsico que representa un recurso computacional.

Tipos de Nodos :
Procesador. Nodos que tienen capacidad de proceso.
Dispositivo. Nodos que representan interfaces con el mundo real.

La fig. 42 muestra un ejemplo de Diagrama de Despliegue con los dispositivos (impresoras,

lectores pticos, hubs, switch) y procesadores conectados (tipos de conectores de red, inalmbrico), del caso propuesto de Ventas de Farmacia.
- Diagrama de estructura compuesta
Similar al diagrama de clase, pero muestra partes y conectores. Es decir, la relacin de composicin de un conjunto de clases son agrupados en una sola clase para su diagramacin.
Desarrollo
de contenidos
Lecturas
seleccionadas
Por ejemplo en la fig. 43 se muestra la relacin de composicin de un auto y barco,

y luego la representacin del diagrama de estructura compuesta en solo dos clases
que contienen las clases que la conforman.
Recordatorio
Figura 43. Ejemplo de diagrama de estructura compuesta

Fuente: http://www.milestone.com.mx/articulos/componiendo
_lo_descompuesto_diagrama_de_estructura_compuesta.htm
- Diagrama de tiempo
Se usa para mostrar el cambio en el estado o valor de uno o ms elementos en el
tiempo, tal como el ejemplo mostrado en la fig. 45.
Figura 45. Ejemplo de diagrama de tiempo

Fuente: Arlow, Jim & Neustadt, Ila. UML 2. 2006.
INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
59
60
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
- Diagrama de vista de interaccin

Es una forma de diagrama de actividad en el cual los nodos representan diagramas de
interaccin, tal como se muestra en la fig. 46.
Anotaciones
Figura 46. Ejemplo de diagrama de vistas de interaccin

Fuente: http://www.sparxsystems.com/resources/
uml2_tutorial/uml2_interactionoverviewdiagram.html
Desarrollo
de contenidos
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
TEMA N. 4: R ATIONAL UNIFIED PROCESS (RUP-PROCESO UNIFICADO)

Recordatorio
Se puede dar cuenta hasta el momento, que se tiene los conceptos de modelado y el
enfoque de desarrollo y lo que falta para iniciar con la construccin de software es el
conjunto de fases o flujos de trabajo, es decir el cmo, dado por el Proceso Unificado,
bajo las especificaciones de la empresa Rational, que es la aceptada y utlizada por la
comunidad de desarrolladores.
1 Caractersticas
RUP es un producto desarrollado y comercializado por Rational Software (IBM) y es un
proceso de desarrollo de software disciplinada: asignar tarea y responsabilidades en una
empresa (quin hace qu, cundo y cmo).
2 Fases y Flujos de Trabajo
RUP es iterativo e incremental: Pequeos proyectos que incorporan incrementalmente nueva funcionalidad y cuyo desarrollo es una iteracin. Mostrado en la fig. 47.
Figura 47. Fases y flujos de RUP

Fuente: http://www.ibm.com/developerworks/rational/library/feb05/krebs/
2.1 FASES DE RUP

I. Inicio. Define el modelo del negocio y el alcance del proyecto, identificando actores y
casos de uso ms esenciales (aproximadamente el 20% del modelo completo).
II. Elaboracin. Analiza el dominio del problema, desarrolla el plan del proyecto. Construye un prototipo de la arquitectura que se convertir en el sistema final.
III. Construccin. Alcanzar la capacidad operacional del producto de forma incremental a travs de las sucesivas iteraciones (requisitos deben ser implementados, integrados y probados en su totalidad.
IV. Transicin. Poner el producto en manos de los usuarios finales, (desarrollar nuevas versiones actualizadas del producto, completar la documentacin, entrenar al
usuario).
Anotaciones
Bibliografa
61
62
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
2.2. Disciplinas (flujos de trabajo) DE RUP

1. Modelado del negocio
Permite llegar a un mejor entendimiento (la estructura y la dinmica) de la organizacin, es decir el problema actual.
Comprende los siguientes diagramas:
Diagrama de Paquetes (DP)
Un diagrama de paquetes es una forma de diagrama de clases. Los paquetes son
susceptibles de generalizaciones. Los procesos (casos de uso) de negocios pueden
modelarse como paquetes.
Modelo Casos de Uso del Negocio (Diagrama de Casos de Uso)
Describe los procesos de negocio de una empresa en trminos de casos de uso del
negocio y actores del negocio que se corresponden con los procesos del negocio y
los clientes, respectivamente.
- Actor (Usuario) del Negocio. Acta con la organizacin:
Clientes, vendedores o socios.
Son representados por los Actores del Negocio.
- Workers. Son los roles dentro de la organizacin y no las posiciones jerrquicas.
Tambin Stakeholders.
- Procesos del Negocio. Representan una abstraccin de alto nivel de las funciones
que se realizan en la organizacin. Representados por los Casos de Uso del Negocio.
En la fig. 48 se observa un ejemplo de Diagrama de Casos de Uso para el negocio

en estudio Ventas de Farmacia.
Figura 48. Diagrama de casos de uso del negocio

Desarrollo
de contenidos
Modelo de Objetos del Negocio
Lecturas
seleccionadas
Describe como cada elemento del negocio es realizado por los trabajadores del
Recordatorio
negocio, durante el proceso
- Entidades del Negocio. Las Cosas que la organizacin maneja (administra) o
produce.
- Los Roles. Los roles que juegan las personas dentro de la organizacin.
Figura 49. Diagrama de objetos del negocio

En la fig. 49 se observa un ejemplo de Diagrama de Objetos y sus relaciones para el

negocio (el contexto es para el caso en estudio Ventas de Farmacia).
INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
63
64
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Modelo del dominio (Diagrama de Clases)

Anotaciones
Un modelo del dominio captura los tipos ms importantes de objetos en el contexto del
sistema. Los objetos del dominio representan las cosas que existen o los eventos que suceden en el entorno en el que trabaja el sistema, mostrados en un ejemplo en la fig. 50.
Figura 50. Diagrama de dominio del negocio

2. Requisitos
Se establece qu tiene que hacer exactamente el sistema que se construya. Provee un mejor
entendimiento de los requisitos del sistema.
Qu es un requisito o requerimiento?
Una condicin o capacidad la cual el sistema debe satisfacer
a. Los requisitos funcionales representan la funcionalidad del sistema.
Se modelan mediante diagramas de Casos de Uso. Ejemplo:
1) Registrar usuario
2) Verificar Producto
3) Calcular pago
4) Modificar Datos Cliente
b.
Los requisitos no funcionales representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad especfica. Ejemplo:
1) Plataforma en donde se ejecuta la aplicacin.
2) Incorporar polticas de hacer copias de seguridad de la base de datos.

3) Plan de contingencia ante la cada del servidor de base de datos, aplicaciones, web,
etc.
4) Portabilidad a otros sistemas operativos.
Desarrollo
de contenidos
Comprende los siguientes diagramas:
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
El Modelo Casos de Uso de los Requerimientos

Modelo del Sistema que comprende los Casos de Uso, Actores y Relaciones.
Actor. Personas, mquinas u otros sistemas que interactan directamente con el

sistema. Los Actores del Negocio y los Workers del Negocio son candidatos a ser
actores.
Caso de Uso. Representa a los requerimientos que sern entregados con el producto de software. Cada una de las transacciones de los Workers del Negocio sobre las
Entidades del Negocio se pueden transformar en Casos de Uso.
Asociaciones.
- Entre Actor y Use Case(Comunicacion)
- Entre actores
Se pueden dar relacin de generalizacin.
Bibliografa
65
66
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 51a. Diagrama casos de uso de requerimiento

En la fig. 51a se observa un ejemplo de Diagrama de Casos de Uso para el requerimiento (el contexto es para el caso en estudio Ventas de Farmacia).
El Modelo de Actividades de los Requerimientos . Se modela las actividades que
realiza cada caso de uso del requerimiento, como el mostrado en la fig. 51b.
Figura 51b. Diagrama de actividades de los requerimientos

Anlisis y diseo
El objetivo de este flujo de trabajo es traducir los requisitos a una especificacin que
describe cmo implementar el sistema. Los objetivos son:
- Transformar los requisitos al diseo del futuro sistema.
- Desarrollar una arquitectura para el sistema.
El modelo del anlisis
Bosquejo del sistema; proporciona una visin resumida de su funcionalidad.
Desarrollo
de contenidos
Diagrama de Clases del Anlisis (DCA)
Lecturas
seleccionadas
Se puede utilizar asociaciones entre objetos: Roles, Multiplicidad, Navegabilidad,

Asociaciones recursivas, Clases asociacin, Asociaciones calificadas, tal como el
ejemplo mostrado en la fig. 52.
Recordatorio
Figura 52. Diagrama de clases del anlisis

INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
67
68
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Diagramas de Secuencia del Anlisis (DSA)

Modelo de interaccin entre objetos, como se muestra en la fig. 53.
Anotaciones
Figura 53. Diagrama de secuencia del anlisis

Desarrollo
de contenidos
Diagramas de Colaboracin (DC)
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
Muestran la colaboracin de Objetos para lograr cierto comportamiento, como el

ejemplo mostrado en la fig. 54.
Recordatorio
Figura 54. Diagrama de colaboracin del anlisis

Diagramas de Actividad (DA)

Muestran el flujo de eventos de un caso de uso y realizado por los objetos del
sistema, como el ejemplo de la fig. 55.
Figura 55. Diagrama de actividades del anlisis

El modelo del diseo

Bosquejo elaborado lo suficiente para asegurarse que el implementador puede producir el conjunto de componentes que satisfagan los requerimientos.
Subsistemas
Es un tipo especial de componente que permite desglosar de manera independiente al sistema, tal como se muestra en la fig. 56.
Anotaciones
Bibliografa
69
70
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 56. Ejemplo de subsistemas

Interfaz
Es una clase que especifica un conjunto de caractersticas pblicas.
Existen dos tipos de interfaces:
- Proporcionada. Conjunto de interfaces realizadas por un clasificador.
- Requerida. Cuando el clasificador o clase requiere de un conjunto de interfaces.
En la fig. 57 se muestra las interfaces que conectan a los subsistemas, quedando,
pendiente una interfaz para conectar con un futuro software de almacn.
Figura 57 Ejemplo de subsistemas

Desarrollo
de contenidos
Lecturas
seleccionadas
Arquitectura
INGENIERA
DE SOFTWARE
Glosario
El sistema se puede organizar por capas. En la fig. 58 se muestra la arquitectura en

tres capas.
Recordatorio
Figura 58. Ejemplo de arquitectura en capas

Modelo de estados
Describen el comportamiento de un sistema travs de todos los estados posibles en
los que puede entrar un objeto y la manera en que cambia el estado. En la fig. 59 se
modela los estados de la clase VerificandoDatos.
Figura 59. Diagrama de estados de una clase

Implementacin
En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems.
El resultado final de este flujo de trabajo es un sistema ejecutable.
Anotaciones
Bibliografa
71
72
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Modelo de Componentes
Anotaciones
Describe los elementos fsicos del sistema y sus relaciones. Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable, segn el ejemplo mostrado en la
fig. 60.
Figura 60. Diagrama de componentes

Modelo de despliegue
Describe la distribucin fsica del sistema (hardware y software) en el sistema final. En la
fig. 61 se muestra un ejemplo de uso de archivos segn el lenguaje de programacin, los
archivos de base de datos segn el gestor de base de datos y las interfaces, que sern ubicadas en los procesadores conectados entre ellos y los dispositivos de ayuda.
Figura 61. Diagrama de componentes

Desarrollo
de contenidos
Pruebas
Lecturas
seleccionadas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que se desarrolla, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Recordatorio
Despliegue
El objetivo de este flujo de trabajo es producir con xito distribuciones del producto y distribuirlo a los usuarios.
Gestin del proyecto
Lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar un
producto que sea acorde a los requisitos de los clientes y los usuarios (guas prcticas para planeacin, contratar personal, ejecutar y monitorear el proyecto).
Configuracin y control de cambios
Mantener la integridad de todos los artefactos que se crean en el proceso, as como
de mantener informacin del proceso evolutivo que han seguido.
ENTORNO
Dar soporte al proyecto con las adecuadas herramientas, procesos y mtodos..
En conclusin, en RUP
No solo la funcionalidad es esencial, tambin el rendimiento y la confiabilidad.
RUP ayuda a planificar, disear, implementar, ejecutar y evaluar pruebas que
verifiquen estas cualidades.
INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
73
74
Objetivos
Inicio
UNIDAD II:
FUNDAMENTOS
PARA EL MODELAMIENTO DE SOFTWARE
ollo
nidos
Actividades
Autoevaluacin
Diagrama
as
nadas
Glosario
Bibliografa
Desarrollo
de contenidos
torio
Actividades
Autoevaluacin
Anotaciones
Lecturas
seleccionadas
Glosario
Bibliografa
EL PROCESO UNIFICADO ES ITERATIVO E INCREMENTAL
Jacobson, Ivar. El proceso unificado de desarrollo de software. Pgs. 6-8
Recordatorio
Anotaciones
El desarrollo de un producto de software comercial supone un gran esfuerzo que

puede durar entre varios meses hasta posiblemente un ao o ms. Es prctico dividir el trabajo en partes ms pequeas o miniproyectos. Cada miniproyecto es una
iteracin que resulta en un incremento.
Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos, al
crecimiento del producto. Para una efectividad mxima, las iteraciones deben estar
controladas; esto es, deben seleccionarse y ejecutarse de una forma planificada. Es
por esto por lo que son miniproyectos.
Los desarrolladores basan la seleccin de lo que se implementar en una iteracin
en dos factores. En primer lugar, la iteracin trata un grupo de casos de uso que juntos amplan la utilidad del producto desarrollado hasta ahora. En segundo lugar, la
iteracin trata los riesgos ms importantes. Las iteraciones sucesivas se construyen
sobre los artefactos de desarrollo tal como quedaron al final de la ltima iteracin.
Al ser miniproyectos, comienzan con los casos de uso y continan a travs del trabajo de desarrollo subsiguiente anlisis, diseo, implementacin y prueba , que
termina convirtiendo en cdigo ejecutable los casos de uso que se desarrollan en la
iteracin. Por supuesto, un incremento no necesariamente es aditivo.
Especialmente en las primeras fases del ciclo de vida, los desarrolladores pueden
tener que reemplazar un diseo superficial por uno ms detallado o sofisticado.
En fases posteriores, los incrementos son tpicamente aditivos. En cada iteracin,
los desarrolladores identifican y especifican los casos de uso relevantes, crean un
diseo utilizando la arquitectura seleccionada como gua, implementan el diseo
mediante componentes, y verifican que los componentes satisfacen los casos de
uso. Si una iteracin cumple con sus objetivos como suele suceder el desarrollo
contina con al siguiente iteracin.
Cuando una iteracin no cumple sus objetivos, los desarrolladores deben revisar
sus decisiones previas y probar con un nuevo enfoque.
Para alcanzar el mayor grado de economa en el desarrollo, un equipo de proyecto
intentar seleccionar soo las iteraciones requeridas para lograr el objetivo del proyecto. Intentar secuenciar las iteraciones en un orden lgico.
Un proyecto con xito se ejecutar de una forma directa, solamente con pequeas
desviaciones del curso que los desarrolladores planificaron inicialmente. Por supuesto, en la medida en que se aaden iteraciones o se altere el orden de las mismas por problemas inesperados, el proceso de desarrollo consumir ms esfuerzo y
tiempo. Uno de los objetivos de la reduccin del riesgo es minimizar los problemas
inesperados.
Son muchos los beneficios de un proceso iterativo controlado:
- L
a iteracin controlada reduce el coste del riesgo a los costes de un solo incremento. Si los desarrolladores tienen que repetir la iteracin, la organizacin
pierde el esfuerzo mal empleado de la iteracin, no el valor del producto entero.
- L
a iteracin controlada reduce el riesgo de no sacar al mercado el producto en
el calendario previsto. Mediante la identificacin de riesgos en fases tempranas
de desarrollo, el tiempo que se gasta en resolverlos se emplea al principio de la
planificacin, cuando la gente est menos presionada por cumplir los plazos.
- E
n el mtodo tradicional, en el cual los problemas complicados se revelan por
primera vez en la prueba del sistema, el tiempo necesario para resolverlos normalmente es mayor que el tiempo que queda en la planificacin y casi siempre
obliga a retrasar la entrega.
ama
rollo
enidos
Desarrollo
de contenidos
Lecturas
seleccionadas
- La iteracin controlada acelera el ritmo del esfuerzo de desarrollo en su totalidad

debido a que los desarrolladores trabajan de manera ms eficiente para obtener resultados claros a corto plazo, en lugar de tener un calendario largo, que se prolonga
eternamente.
Recordatorio
- La iteracin controlada reconoce una realidad que a menudo se ignora que las
necesidades del usuario y sus correspondientes requisitos no pueden definirse completamente al principio. Tpicamente, se refinan en iteraciones sucesivas. Esta forma
de operar hace ms fcil la adaptacin a los requisitos cambiantes.
Estos conceptos los de desarrollo dirigido por casos de uso, centrado en la arquitectura,
iterativo e incremental son de igual importancia.
La arquitectura proporciona la estructura sobre la cual guiar las iteraciones, mientras que
los casos de uso definen los objetivos y dirigen el trabajo de cada iteracin.
La eliminacin de una de las tres ideas reducir drsticamente el valor del Proceso Unificado. Es como un taburete de tres patas. Sin una de ellas, el taburete se cae.
Ahora que hemos presentado los tres conceptos clave, es el momento de echar un vistazo
al proceso en su totalidad, su ciclo de vida, artefactos, flujos de trabajo, fases e iteraciones.
Objetivos
Actividades
Inicio
TAREA ACADMICA N. 1
Autoevaluacin
uras
onadas
Glosario
atorio
Anotaciones
Bibliografa
INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
75
76
UNIDAD II:Inicio
FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWARE
ollo
nidos
Actividades
Autoevaluacin
Diagrama
Objetivos
as
nadas
Glosario
Bibliografa
Desarrollo
de contenidos
Actividades
Lecturas
seleccionadas
Glosario
torio
Autoevaluacin
GLOSARIO DE LA UNIDAD II
Anotaciones
Bibliografa
Contexto. Porcin de la realidad de una organizacin sobre la cual se realizar el

modelamiento de un software.
Recordatorio
Diagrama. Es un contenedor de los smbolos y relaciones que constituyen un modelo en el desarrollo de software.
Anotaciones
Enfoque. Es un conjunto de principios, conceptos y tcnicas para la construccin

de un software.
Iteracin. Repeticin de una fase o flujo de trabajo de un proceso de desarrollo de
software, para refinar y mejorarlo.
Mensaje. Comunicacin entre objetos en el modelamiento de un sistema. Esta comunicacin puede ser de solicitudes para que otro objeto realice alguna actividad.
Semntica, Significado de un smbolo segn un lenguaje de programacin, proporcionado por el orden en que se escribi.
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
BIBLIOGRAFA DE LA UNIDAD II
Arlow, Jim & Neustadt, Ila. (2005). Programacin UML 2. Espaa: Editorial Anaya.
Recordatorio
Anotaciones
Blanco Cuaresma, Sergi. (2008). Metodologas giles de gestin de proyectos. Disponible

en: http://www.marblestation.com/?s=%C3%A1gil
Bravo Lillo, Cristian y Guerrero, Luis. (sin fecha). Mtricas de funcionalidad: una
taxonoma para sistemas web. Universidad de Chile. Disponible en: http://users.dcc.
uchile.cl/~luguerre/papers/WCIS-01.pdf
Jacobson, Ivar., Booch, Grady., Rumbaugh, James. (2000). El proceso unificado de
desarrollo de software. Espaa: Editorial Addison Wesley. Biblioteca UC: 005.117 / J13
2000.
PMOinformtica. (sin fecha). Cinco tendencias de metodologas giles para 2014. Disponible en: http://www.pmoinformatica.com/2013/12/metodologias-agiles-tendencias-2014.html
Universidad Unin Bolivariana.(sin fecha). Metodologas giles RUP. Disponible en:
http://ingenieriadesoftware.mex.tl/52788_Rup-Agil.html
Desarrollo
de contenidos
Objetivos
Inicio
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
AUTOEVALUACIN DE LA UNIDAD II
1. En el enfoque estructurado, separar el problema en partes ms pequeas e

independientes corresponde a:
Glosario
Anotaciones
a) Cohesin
b) Agregacin
c) Modularidad
Bibliografa
d) Composicin

e) Acoplamiento
2.
En el enfoque estructurado, la dependencia que tienen dos unidades de
software corresponde a:

a) Herencia
b) Acoplamiento
c) Modularidad
d) Cohesin
e) Agregacin
3. E
n el enfoque orientado a objetos, la transmisin de atributos y mtodos de una
clase a otra, corresponde a:

a) Cohesin
b) Composicin
c) Acoplamiento
d) Herencia
e) Objeto
4. En el enfoque orientado a objetos, indicar que una clase (todo) est formado
por otras clases (partes) que afectan su funcionamiento, corresponde a:

a) Clase
b) Agregacin
c) Herencia
d) Composicin
e) Modularidad
5. La metodologa que elabora un Diagrama Navegacional de la informacin, es:

a) Metodologa gil

b) Metodologa XP
c) Metodologa web
d) Metodologa AUP
e) Metodologa tradicional
6. Es una notacin estndar que permite representar a los elementos del software:
a) UML
b) RUP

c) WebML
d) MDA
e) RMM
7. La clase, el caso de uso, el nodo, son elementos que corresponde a:

a) Relaciones del bloque de construccin de UML

INGENIERA
DE SOFTWARE
b) Elementos del bloque de construccin de UML
Bibliografa
77
78
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
c) Adornos de Mecanismos comunes de UML
d) Vista de la Arquitectura de UML
e) Diagramas del Bloque de construccin de UML
Anotaciones
8. E
n UML el diagrama que permite representar los procesos del negocio y los
requerimientos del sistema, es:

a) Diagrama de Paquetes
b) Diagrama de Clases
c) Diagrama de Secuencia
d) Diagrama de Casos de Uso

e) Diagrama de Componentes
9. En UML el diagrama que permite representar los elementos que conforman el
sistema y sus relaciones es:

a) Diagrama de Colaboracin
b) Diagrama de Clases
c) Diagrama de Actividades.

d) Diagrama de Despliegue
e) Diagrama de Estados
10. En UML el diagrama que permite representar la duracin de la clase en un
determinado estado es:

a) Diagrama de Estados
b) Diagrama de Estructura Compuesta
c) Diagrama de Tiempo
d) Diagrama de Colaboracin
e) Diagrama de Despliegue
Desarrollo
de contenidos
Diagrama
Desarrollo
de contenidos
Diagrama
Lecturas
seleccionadas
Objetivos
Inicio
Actividades
Glosario
Recordatorio
Anotaciones
Autoevaluacin
DIAGRAMA DE PRESENTACIN DE LA UNIDAD III

Objetivos
Glosario
Inicio
Bibliografa
LECTURAS
SELECCIONADAS
Actividades
ACTIVIDADES
Autoevaluacin
Anotaciones
AUTOEVALUACIN
Lecturas
seleccionadas
Lecturas
seleccionadas
CONTENIDOS
Desarrollo
de contenidos
Recordatorio
Glosario
BIBLIOGRAFA
Bibliografa

Diagrama
Recordatorio
INGENIERA
DE SOFTWARE
Objetivos
Anotaciones
Inicio
CONOCIMIENTOS
PROCEDIMIENTOS
1. Identifica y analiza los elementos de construccin

de los diagramas para el
negocio.
1. Evaluacin del negocio.
2. P
ictogrfico situacional 2. Elabora los diagramas de
UML para el negocio.
Lecturas
Glosario
Bibliografa
y pictogrfico
Tema N. 1: Flujo de
trabajo
de
RUP:Autoevaluacin
Desarrollo
Actividades
de contenidos
Modelado del negocio
seleccionadas
3. Identifica y describe los

elementos de construc3. Reglas del negocio.
cin de los diagramas
4.
Diagramas UML: Diapara el requerimiento.
Recordatorio
gramaAnotaciones
de casos de uso
4.
Elabora los diagramas

del negocio y diagrama
de UML para el requeride objetos del negocio.
miento y los incorpora en
el Proyecto de software en
equipo.
Whitten, Jeffrey & Bentley,
Lonnie. Punto de vista de Actividad N. 3
los usuarios del sistema
Desarrollo de los diagramas
acerca de los procesos.
Anlisis de sistemas, dise- del negocio, segn casos
propuestos.
o y mtodos. . Pg. 33.
solucionador.
Tema N. 2: Flujo de
Trabajo de RUP: Modelado de requerimientos
Control de Lectura N. 2
Elabora el informe del modelamiento de software, ad1. Estimacin del proyecto. juntando el modelado del
negocio y el modelado de
2. Diagrama UML: Diagra- requerimientos.
ma de casos de uso de requerimientos, plantillas,
diagrama de actividades de requerimiento.
Arlow, Jim & Neustadt,
Ila. La Importancia de los
requisitos. Programacin
UML 2 . Pg. 33.
Autoevaluacin de la
unidad III
ACTITUDES
1.
Asume con responsabilidad sus actividades
acadmicas asignadas.
2. Realiza con honestidad
las evaluaciones asignadas.
Bibliografa
79
80
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
TEMA N. 1: FLUJO DE TRABAJO DE RUP: MODELADO DEL NEGOCIO

A continuacin ver un ejemplo que elabora un modelamiento de software aplicando los flujos de Trabajo (workflow) y las fases del Proceso Unificado con la notacin
UML, considerando la herramienta de modelado Rational Rose.
Iniciamos con el Modelamiento del Negocio, es decir la recopilacin de la informacin actual de la organizacin: sus procesos y restricciones.
Iniciando con rational rose1
1. Clic en Inicio de Programas.
2. En Programas, Seleccionar Rational Rose 2000 Enterprise Edition.
3. Aparecer la interfaz mostrada en la fig. 70 para seleccionar RUP:
Figura 70 . Ventana de Inicio de Rational Rose

4. Seleccionar Rational Unified Process y Clic en el botn OK.

5. Aparecer el siguiente entorno grfico, mostrado en la fig. 71:
Figura 71. Entorno de trabajo de Rational Rose

1 Liza vila, Csar. (2001). Modelando con UML. Per.
Desarrollo
de contenidos
1 Evaluacin del Negocio
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
Se recopila y organiza la informacin de la organizacin y del contexto del negocio

de cuyo proceso o procesos se realizar el modelamiento de software.
Considere para la organizacin:
Recordatorio
a. Razn social, rubro, tiempo en el mercado, organigrama, visin, misin, oportunidades y amenazas, clientes y competidores y objetivos de la organizacin..
b. Describir los procesos que realiza:
Ejemplo para una Bodega. Vender, Comprar, Inventariar, etc.
Ejemplo para un Colegio. Matrculas, Procesamiento de Notas, Control de
Asistencia, Control de Pagos, etc.
c. Describir a los actores que intervienen en los procesos y las actividades que realizan e en los procesos (Ejemplos. Vendedor, cajero, tcnico, administrador, etc.).
Considere un caso de ejemplo
Una farmacia necesita tener un registro de todas las personas que compran sus
productos. Para ello cada vez que solicitan sus productos, el vendedor verifica si
el producto se encuentra en stock disponible. Si no existe el stock o el nombre de
producto, se le informa a la persona y esta puede solicitar otro producto similar
(uno recomendado) o dar por terminado el proceso de solicitud, mientras se va
elaborando un informe del nombre del producto que solicit y no se encuentra en
almacn de la farmacia. En caso de existir, se le informa del precio y se solicita la
cantidad que desea llevar, entregndole una nota de pedido con la descripcin del
producto, cantidad y precio unitario. Con esta nota la persona se dirige a caja, all
le solicitan la nota de pedido y su DNI (para verificar si es un cliente registrado), en
caso de no serlo, se solicitan sus datos personales, registrndolo como cliente (para
posteriores descuentos y promociones). Todo esto es necesario para poder emitir el
Comprobante de Pago (Boleta o Factura). Con el comprobante el cliente solicita
el pedido de productos en el rea de entrega de paquetes.
2 Pictogrfico Situacional y Pictogrfico Solucionador
Para ayudar a la comprensin de la situacin actual de la organizacin y del negocio, se recomienda elabora un cuadro pictogrfico situacional, como el de la fig. 72:
Figura 72. Ejemplo de cuadro pictogrfico situacional

Fuente: Proyecto Grupal en Ingeniera de Software. 2008
2 Arlow, Jim & Neustadt, Ila. (2005). Programacin UML 2.
Anotaciones
Bibliografa
81
82
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
De esta forma se podr elaborar el Pictogrfico Solucionador, es decir con la propuesta de solucin en base al producto final del modelamiento de software. Observemos el ejemplo de la fig. 73.
Figura 73. Ejemplo de cuadro pictogrfico situacional

Fuente: Proyecto Grupal en Ingeniera de Software. 2008
3 Reglas del Negocio

Se debe recopilar y enumerar las restricciones de cada proceso de la organizacin.
Se sugiere describir con ms detalle las restricciones o reglas del negocio del
proceso o procesos del cual se realizar el modelamiento de software.
Ejemplo de reglas de negocio para el proyecto de ventas en ingeniera de software:
1. Para realizar un pedido, el cliente debe adelantar un monto asignado de acuerdo al criterio del gerente.
2. Solamente se ofrece crditos a plazos a las personas que son de de confianza
(cliente regular y no tenga deudas).
3. Los pagos se realizarn en efectivo.
4. Todo producto vendido debe estar registrado en un cuaderno de control.
5. El pago ser puntual a los proveedores para el abastecimiento de productos.
6. El pago del alquiler del local.
7. Lo proveedores tienen que entregar una factura al gerente por la compra del
producto.
8.
Solo el gerente puede acceder al sistema informtico con su respectiva
contrasea.
4 Diagramas UML: Diagrama de Casos de Uso del Negocio
y Diagrama de Objetos del Negocio

Para iniciar el modelamiento se debe crear el diagrama de Paquetes, que permitir
organizar e identificar el proceso o procesos a desarrollar el modelamiento de software. (Romero Moreno, Gesvin. 2004)
I. Creacin de Diagrama de Paquetes
1. En el Business Use Case Model, clic derecho y seleccionar New: Use Case Diagram.
2. Asignarle el nombre de DPaquetesFarmacia, como por ejemplo:
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 74. Ejemplo de creacin de diagrama de casos de uso

3.
Doble clic sobre el nuevo diagrama creado y seleccionar de la caja de
herramientas: package y crear el paquete, en este caso lo llamaremos farmacia.
Figura 75. Ejemplo de creacin de un paquete

4.
En el explorador del modelo, arrastrar los paquetes de Almacn, Compras y
Ventas hacia el paquete Farmacia, de tal forma que tengan la siguiente vista:
Figura 76. Ejemplo de creacin de paquetes para el ejemplo Farmacia

5.
Abrir el DPaquetes y arrastrar hacia el diagrama los paquetes de Almacn, Compras y Ventas, para poder relacionarlos:
Figura 77. Ejemplo de diagrama para paquetes

6.
Crear la relacin de dependencia entre paquetes con Dependcy or instantiates
de la Caja de Herramientas, segn las dependencias que se hayan analizado
como por ejemplo:
Bibliografa
83
84
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 78. Ejemplo de diagrama de paquetes y sus relaciones

7.
Puede abrir cada Paquete y ver el contenido del diagrama de modelo de casos
de uso del negocio de dicho paquete al hace doble clic sobre el.
8.
Si los paquetes se tratan de unidades de negocio, entonces puede modificar el
estereotipo por Organization Units, realizando clic derecho en cada paquete
para abrir la ventana de especificaciones.
II. Creando Diagrama de Modelo de Casos de Uso del Negocio para cada Paquete.
Ejemplo paquete Ventas
a. Modelo de Casos de Uso
1. Clic derecho sobre el paquete Ventas y seleccionar New: Use Case Diagram.
2. Asignarle para nuestro ejemplo, el nombre de MCUVentas:
Figura 79. Ejemplo de creacin de diagrama de casos de uso

b. Actores
1. Clic derecho sobre el MCUVentas para el men emergente y seleccionar New:
Actor, llamado NewClass que se ubicar en el browser.
2.
Luego cambiar el nombre NewClass por el del Actor, segn el modelo que se
est realizando, que puede ser de dos maneras:
2.1 C
lic derecho en NewClass, Rename y cambiar nombre o tambin
2.2 Clic derecho o doble clic en NewClass, luego Open Especification y cambiar
nombre en Name. Luego clic en el botn Aplicar y despus el botn OK.
Figura 80. Ejemplo de creacin de un actor

Desarrollo
de contenidos
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
3. En la ventana de especificaciones de este actor cambiar el estereotipo segn el

comportamiento que tenga en el proceso del negocio:
3.1 Seleccionar Business Worker si es un actor dentro del negocio que hace
algn proceso. Ejemplo: Cajero, Administrador, etc., o tambin:
Recordatorio
3.2 Seleccionar Business Actor si es un actor fuera del negocio que es afectado
o afecta algn proceso. Ejemplo: Cliente, Proveedor, etc.
4. Repita los pasos anteriores para crear otros actores en el mismo paquete Ventas:
Figura 81. Ejemplo de estereotipo de Actor

c. Casos de Uso
1.
Clic derecho sobre el MCUVentas para el men emergente y seleccionar New:
Use Case, llamado NewUseCase que se ubicar en el browser.
2.
Luego Cambiar el nombre NewUseCase por el del Caso de Uso segn el modelo
que se est realizando, que puede ser de dos maneras:
2.1. Clic derecho en NewUseCase, Rename y cambiar nombre o

2.2. Clic derecho doble clic en NewUseCase, luego Open Especification y cambiar nombre en Name y luego clic en el botn Aplicar y despus el botn
OK.
Figura 82. Ejemplo de creacin de casos de uso

3.
En la ventana de especificaciones de este actor, cambiar el estereotipo que
indica que es un proceso del negocio: Business Use Case.
Anotaciones
Bibliografa
85
86
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
4. Repita los pasos anteriores para crear otros Casos de Uso:
Figura 83. Ejemplo de estereotipo de caso de uso

d. Relaciones
1. Para crear la Relacin de Asociacin:
Clic en el icono Unidireccional Association de la Caja de Herramientas.
2.
Clic en un Actor iniciando una comunicacin y arrastrar las Asociacin hasta un
Caso de Uso, como por ejemplo:
Figura 84. Ejemplo de creacin de la relacin de comunicacin

3. Si existiese generalizacin entre actores seleccionar de la caja de herramientas

el icono Generalization y crear la relacin desde actor hijo hacia actor padre,
segn el ejemplo, estamos heredando los roles de un actor padre.
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 85. Ejemplo de generalizacin entre actores

4.
Si existiese generalizacin entre casos de uso seleccionar de la caja de herramientas el icono Generalization y crear la relacin desde caso de uso hijo hacia
caso de uso padre:
Figura 85. Ejemplo de generalizacin entre casos de uso

5. Tambin se pueden especificar si el caso de uso del negocio afecta o esta relacionado con algn objetivo del negocio y/o algn documento del negocio:
Figura 85. Ejemplo de diagrama de casos de uso del negocio

INGENIERA
DE SOFTWARE
Bibliografa
87
88
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
III. Creando Modelo de Objetos del Negocio para cada Paquete

a. Modelo de Objetos
Anotaciones
1. Seleccionar la Vista Logica, Logical View y seleccionar Business Object Model.

2.
Clic derecho sobre el paquete Business Object Model y seleccionar New: Class
Diagram.
3.
Asignarle el nombre de MONVentas y doble clic para abrir el diagrama para
abrir:
Figura 86. Ejemplo de creacin de diagrama de objetos

b. Objetos
1. Clic derecho en el paquete Business Object Model para el men emergente y
seleccionar New: Clase, llamado NewClass que se ubicar en el browser.
2. L
uego Cambiar el nombre NewClass por el de la Clase segn el modelo que se

2.1 Clic derecho en NewClass, Rename y cambiar nombre o:
2.2 Clic derecho doble clic en NewClass, luego Open Especification y cambiar
nombre en Name y luego clic en el botn Aplicar y despus el botn OK.
3. Cambiar el estereotipo del objeto por un Business Entity.

4. Repita los pasos anteriores para crear otras clases:
Figura 87. Ejemplo de objetos del negocio

Desarrollo
de contenidos
Lecturas
seleccionadas
c. Relaciones
INGENIERA
DE SOFTWARE
Glosario
1. Arrastrar los workers y business actors necesarios hacia el Modelo de Objetos del
Negocio:
Recordatorio
Figura 88. Ejemplo de Objetos y Actores del Negocio

2. Seleccionar una relacin de Asociacin entre el Actor y la Clase entidad del

negocio.
3. Abrir la ventana de especificaciones de la relacin e indicar en el nombre de la
relacin, el rol que realiza el actor respecto a la clase entidad:
Figura 89. Ejemplo de Diagrama de Objetos del Negocio

Anotaciones
Bibliografa
89
90
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
IV. Creando Modelo de Dominio para cada Paquete

a. Modelo de Dominio
1. Seleccionar la Vista Logica, Logical View y seleccionar Analysis Model.
2. Clic derecho sobre el paquete Analysis Model y seleccionar New: Class Diagram.
3. Asignarle el nombre de MDominioVentas y doble clic para abrir el diagrama,
segn el ejemplo:
Figura 90. Ejemplo de creacin de Diagrama de Dominio

4. Crear una clase de Dominio, seleccionando Class de la Caja de Herramientas.

Asignarle un nombre a la clase:
Figura 91. Ejemplo de creacin una clase para el dominio

Desarrollo
de contenidos
Lecturas
seleccionadas
5.
Como no hace falta nivel de detalle, entonces se puede prescindir del compartimiento de los atributos y de las operaciones de la clase, haciendo clic derecho
sobre la clase, seleccionar options y luego seleccionar Suppress Attibutes y Suppress Operations:
Recordatorio
Figura 92. Ejemplo de creacin eliminacin de compartimientos

6.
Elaborar las relaciones de asociacin con Unidirectional Association de la caja
de herramientas, entre las clases del dominio y establecer la multiplicidad, quedado nuestro diagrama:
Figura 93. Ejemplo de diagrama de dominio

INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
91
92
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
Anotaciones
PUNTO DE VISTA DE LOS USUARIOS DEL SISTEMA ACERCA

DE LOS PROCESOS
Recordatorio
Anotaciones
Whitten, Jeffrey & Bentley, Lonnie. Anlisis de sistemas, diseo y mtodos. Pgs. 33-34
Estamos listos para examinar el punto de vista de los usuarios de sistemas acerca de los
procesos. Los usuarios estn preocupados por los procesos del negocio o trabajo, que
debe ser realizado con el fin de proporcionar las respuestas apropiadas a los sucesos
del negocio. Los usuarios de sistemas especifican el proceso del negocio en trminos
de requerimientos de proceso para un nuevo sistema. Los requerimientos de proceso
con frecuencia estn documentados en trminos de actividades, flujos de datos o flujo
de trabajo.
Estos requerimientos de proceso deben ser especificados con precisin, especialmente
si sern automatizados o respaldados por tecnologa de software. Los requerimientos
de proceso del negocio frecuentemente se definen en trminos de polticas y procedimientos del negocio, Los procedimientos son los pasos precisos que se deben seguir al
completar el proceso del negocio.
Considere el siguiente ejemplo: La aprobacin de crdito es una poltica. Establece un
conjunto de reglas para determinar si se extiende o no el crdito a un cliente. La poltica de aprobacin de crdito del cliente generalmente se aplica dentro del contexto de
un procedimiento de revisin de crdito especfica que estableci los pasos correctos
para revisar el crdito contra la poltica de crdito.
Los requerimientos de proceso tambin son especificaciones frecuentemente en trminos de flujo de trabajo. La mayora de las empresas son muy independientes de revisiones y autorizaciones para implementar el flujo de trabajo.
Por ejemplo, una requisicin de compra puede ser iniciada por cualquier empleado,
pero sigue un flujo de trabajo especfico de aprobaciones y revisiones ates de que se
convierta en una transaccin de orden de compra que se ingresa a un sistema de procesamiento de informacin.
Desde luego, estas revisiones y estos balances pueden volverse engorrosos y burocrticos. Los analistas de sistemas y los usuarios buscan un equilibrio apropiado entre revisiones y autorizaciones, servicio y desempeo.
Una vez ms, el desafo en el desarrollo de sistemas es identificar, expresar y analizar los
requerimientos del proceso del negocio exclusivamente en trminos de negocios que
puedan ser entendidos por los usuarios de sistemas. En este texto se ensean de manera
amplia herramientas y tcnicas para el modelado de procesos y la documentacin de
polticas y procedimientos.
Punto de vista de los diseadores del sistema acerca de los procesos
Como fue el caso con el componente del conocimiento, el punto de vista de los diseadores del sistema acerca de los procesos del negocio est restringido por las limitaciones de las tecnologas de desarrollo de aplicacin como Java, Visual Basic.Net, C++,
C#. Algunas veces el analista es capaz de elegir la tecnologa de software; sin embargo,
a menudo las elecciones estn limitadas por estndares de arquitectura de software que
especifican que tecnologa de software y hardware deben utilizarse. En cualquier caso,
el punto de vista de los diseadores es tcnico.
Dado los procesos del negocio desde el punto de vista de los usuarios, el diseador debe
primero determinar qu procesos automatizar y la mejor forma de hacerlo. Se dibujan
modelos para documentar y comunicar cmo son o cmo sern los procesos del negocio seleccionado, implementados con el software y el hardware.
Actualmente muchas empresas adquieren paquetes de aplicacin comercial del anaquel (comercial-off-shelf, COTS) en lugar de construir ese software de manera interna.
De hecho, muchas empresas afirman que el software que puede ser comprado nunca
debe ser construido o que solo el software que proporciona una verdadera ventaja competitiva debe ser construido. En el caso de adquisicin de software, los procesos del
negocio en general deben ser cambiados o adaptados para trabajar con el software.
Desarrollo
de contenidos
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
Por tanto, en este escenario las especificaciones de diseo de procesos de negocio

deben documentar la forma en que el paquete de software ser integrado a la empresa.
En forma alternativa, en el caso de construir software internamente, en generalRecordatorio

los
procesos del negocio son primeramente designados y las especificaciones de procesos del negocio deben entonces ser soportadas con especificaciones de software que
documentan el diseo tcnico de los programas de cmputo que sern escritos.
Usted puede haber encontrado algunas de estas especificaciones de software en un
curso de programacin. Como fue el caso con el conocimiento, algunos de estos
puntos de vista de los procesos pueden entenderse por los usuarios, pero la mayora
no.
La intencin de los diseadores es preparar especificaciones de software que:
1) Satisfagan los requerimientos del proceso del negocio de los usuarios del
sistema, y
2) Proporcionen suficiente detalle y consistencia para comunicar el diseo del
software a los constructores del sistema.
Diagrama
Desarrollo
de contenidos
Objetivos
Actividades
Inicio
ACTIVIDAD N. 3
Autoevaluacin
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Bibliografa
Anotaciones
Bibliografa
93
94
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
TEMA N. 2: FLUJO DE TRABAJO DE RUP: MODELADO DE

REQUERIMIENTOS
En esta etapa, se debe identificar los requisitos del usuario, que sern automatizados y descritos en el modelamiento del software.
Para ello, es necesario realizar la estimacin del proyecto de software para evaluar
su factibilidad identificando los recursos (humanos, de equipo y tecnolgicos) que
posee la organizacin.
1 Estimacin del Proyecto
Considere evaluar el proyecto, indicando en los Costos, si es necesario adquirir
nuevos equipos o tecnologa, as como determinar en los Beneficios, los rubros con
los cuales la organizacin tendra ganancias, reflejados en un flujo de caja como el
que se muestra:
Con esta informacin, realizar el Anlisis de Rentabilidad calculando el Valor Actual Neto (VAN), la relacin Beneficio/Costo, y la Tasa Interna de Retorno (TIR).
2 Diagrama UML: Diagrama de Casos de Uso
de Requerimientos, Plantillas, Diagrama

de Actividades de Requerimiento3
En esta etapa se debe identificar los requisitos del software.
Existen dos tipos de requisitos:
Requisitos Funcionales. Que sern los procesos a modelar en el software.
Requisitos No Funcionales. Atributos que le dan calidad al software.
I. Creacin de Paquetes Para Requerimientos Funcionales del Sistema.
1. Clic en Use Case View del Browser para desplegar el men.
2. C
lic derecho en Use Case Model para el men emergente y seleccionar New:
Package, llamado DCUSistVentas que se ubicar en el browser.
3 Romero Moreno, Gesvin. (2004). UML con Rational Rose. Per: Editorial Megabyte.
Desarrollo
de contenidos
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
3.
Realizar el paso 2 para crear otros paquetes Compras y Almacn si es que son
parte del modelado del sistema:
Recordatorio
Figura94. Ejemplo de creacin del paquete para requerimientos

II. Creacin del Modelo de Casos de Uso de Requerimientos (Requisitos

Funcionales del Sistema)
Ejemplo Paquete DCUSistVentas:
a. Diagrama de Casos de Uso
1. Clic derecho sobre el paquete DCUSistVentas y seleccionar New: Use Case
Diagram.Asignarle el nombre de DCUSistVentas.
Figura 95. Ejemplo de creacin de un diagrama de casos de uso para los requerimientos
Anotaciones
Bibliografa
95
96
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
b. Actores
1. Clic derecho sobre el DCUSistVentas para el men emergente y seleccionar
New: Actor, llamado NewClass que se ubicar en el browser.
Anotaciones
2.
Luego Cambiar el nombre NewClass por el del Actor segn el modelo que se
2.1 Clic derecho en NewClass, Rename y cambiar nombre o
2.2 C
lic derecho doble clic en NewClass, luego Open Especification y cambiar nombre en Name y luego clic en el botn Aplicar y despus el botn
OK.
3. El estereotipo esta por defecto para un actor de requerimientos.
Figura 96. Ejemplo de creacin de actor del requerimiento

4.
Repita los pasos anteriores para crear otros actores en el mismo paquete DCUSistVentas.
c. Casos de Uso
1.
Clic derecho sobre el DCUSistVentas para el men emergente y seleccionar
New: Use Case, llamado NewUseCase que se ubicar en el browser.
2.
Luego Cambiar el nombre NewUseCase por el del Caso de Uso segn el mo-delo que se est realizando, que puede ser de dos maneras:

2.1 Clic derecho en NewUseCase, Rename y cambiar nombre o
2.2 C
lic derecho doble clic en NewUseCase, luego Open Especification y cambiar nombre en Name y luego clic en el botn Aplicar y despus el botn
OK.
3. El estereotipo esta por defecto para un caso de uso de requerimientos:
Figura 97. Ejemplo de creacin de casos de uso de requerimiento

Fuente: Rojas Moreno. Carol Roxana
4. Repita los pasos anteriores para crear otros Casos de Uso.

d. Relaciones
1. Doble clic sobre el diagrama de Casos de uso DCUSistVentas para abrirlo.
2. Arrastrar los actores y casos de uso de requerimientos hacia el diagrama.
Desarrollo
de contenidos
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
3.
Para crear la Relacin de Asociacin: Clic en el icono Unidireccional Association de la Caja de Herramientas.
4.
Clic en un Actor iniciando una comunicacin y arrastrar las Asociacin hasta un
Caso de Uso:
Recordatorio
Figura 98. Ejemplo de relacin entre actor y caso de uso

5. Para crear la relacin Incluye

Clic en el icono Dependency or Instantiates de la Caja de Herramientas.
Clic en el Caso de Uso base y arrastrar la linea de Asociacin hasta el Caso de Uso
incluido.
6. Para crear un estereotipo
Doble clic o clic derecho en la lnea de Asociacin, Open Specification y en el campo Stereotype seleccionar include, clic en el boton Aplicar y luego OK.
7. Repetir el procedimiento por cada Relacin Incluye.
Figura 99. Ejemplo de creacin de relacin incluye

Anotaciones
Bibliografa
97
98
ollo
nidos
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
8. Para crear la relacin Extendida

Clic en el icono Dependency or Instantiates de la Caja de Herramientas.
Anotaciones
Clic en el Caso de Uso extendido y arrastrar la lnea de Asociacin hasta el Caso de

Uso base.
9. Para crear un estereotipo
Doble clic o clic derecho en la lnea de Asociacin, Open Specification y en el campo Stereotype seleccionar extend, clic en el boton Aplicar y luego OK.
10. Repetir el procedimiento por cada Relacin Extendida.
Figura 100. Ejemplo de creacin de relacin extend

11. Si existiese generalizacin entre actores seleccionar de la caja de herramientas

el icono Generalization y crear la relacin desde actor hijo hacia actor padre.
12. Si existiese generalizacin entre casos de uso seleccionar de la caja de herramientas el icono Generalization y crear la relacin desde caso de uso hijo hacia
caso de uso padre.
13. Tambin se pueden relacionar Business Goal y/o Business Document a este tipo
de caso de uso, a travs de la relacin de dependencia, quedando nuestro diagrama:
Figura 101. Ejemplo de creacin de Diagrama de Casos de Uso de Requerimiento

Desarrollo
de contenidos
III. Creacin de las Plantillas para cada Caso de Uso de Requerimientos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
1. Elaboremos el siguiente ejemplo de plantilla para un caso de uso:
2. Insertar el archivo de la plantilla al caso de uso correspondiente:

2.1 Abrir la ventana de especificaciones del caso de uso, seleccionar el frame

Files y luego Insert File para dar la ruta del archivo de la plantilla de casos de
uso.
Figura 102. Ejemplo de insercin de archivo de plantilla

3. Realizar lo mismo para cada caso de uso.

IV. Diagrama de Actividades de cada Caso de Uso de Requerimiento
a. Crear el Diagrama de Actividades
1. C
lic derecho en Use Case View en el Browser seleccionar el paquete ejemplo
DCUSistVentas, y seleccionar un caso de uso ejemplo ActualizarDatos, clic
derecho, New, luego Activity Diagram.
2. Luego Abrir el State/Activity Model para visualizar el Diagrama de Actividades.
Bibliografa
99
ollo
nidos
100
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
3. Luego Cambiar el nombre NewDiagram por el del Diagrama segn el modelo

que se est realizando, Clic derecho en NewDiagram, Rename y cambiar nombre por el de DAActualizarDatos.
4. Doble clic para abrir el diagrama de actividades:
Figura 103. Ejemplo de creacin del Diagrama de Actividad

b. Crear Carriles
1. Clic derecho sobre el Diagrama de Actividades DAActualizarDatos, luego New, y
seleccionar Swimlane.
2. Asignarle un Nombre, mientras se encuentra seleccionado.
3. Arrastrar un carril hacia el Diagrama de Actividades.
Figura 104. Ejemplo de carriles (swimlane)

Desarrollo
de contenidos
Lecturas
seleccionadas
c. Creando Actividades
INGENIERA
DE SOFTWARE
Glosario
1. Clic derecho sobre el Diagrama de Actividades DAActualizarDatos, luego New y

seleccionar Activity.
Recordatorio
3. Doble Clic en el Diagrama de Actividades DAActualizarDatos, para abrirlo, y

arrastrar las actividades dentro de un carril especfico.
4. Se deben crear el estado inicial, el estado final y las actividades por cada carril.
Figura 105. Ejemplo de actividades

d. Creando Barras de Sincronizacin

1. Seleccionar de la Caja de Herramientas el icono Horizontal Synchronization o
Vertical Synchronization, segn se requiera.
2. Arrastrar en el Diagrama de Actividad para separar las actividades.
3. Se realiza esta operacin solo si existen actividades concurrentes.
Figura 106. Ejemplo de creacin de carriles

e. Creando Transiciones
1. Seleccionar de la Caja de Herramientas el icono State Transition.
2. Arrastrar desde la actividad Origen hacia la actividad destino.
3. Si existe barras de Sincronizacin, arrastrar hacia o desde l.
Figura 107. Ejemplo creacin de transiciones

Anotaciones
Bibliografa
101
ollo
nidos
as
nadas
torio
102
Actividades
Autoevaluacin
Glosario
Bibliografa
f. Creando Puntos de Decisin

1. Seleccionar de la Caja de Herramientas el icono Decision.
Anotaciones
2. Arrastrar en la actividad situada para la decisin.

3. Mientras se encuentre seleccionado, asignarle un nombre.
4. Luego, de las transiciones que salen de l, abrir open specification en cada uno.
5. En Detail especificar en Guard Condition, la condicin para ellos.
Figura 108. Ejemplo de creacin de condiciones y puntos de decisin

g. Creando estados
1. Crear los Estados Inicial y Final.
2.
Adems, se pueden indicar los estados en los que se encuentra un objeto dentro
del Diagrama de Actividades.
3. Seleccionar de la Caja de Herramientas de estado.
4. Arrastrar en la actividad situada para el estado.
5. Mientras se encuentre seleccionado, asignarle un nombre.
6. Relacionar con transiciones entre las actividades.
Ejemplo de Estado: Cliente Modificado
Figura 109. Ejemplo de estado en el diagrama de actividades

Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
7. Al finalizar se tiene el siguiente diagrama de actividades:
Figura 110. Ejemplo de Diagrama de Actividades del Requerimiento

8. Realizar el mismo procedimiento para los dems casos de uso de requerimientos.
Bibliografa
103
ollo
nidos
as
nadas
torio
104
Actividades
Autoevaluacin
Glosario
Bibliografa
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Anotaciones
Glosario
Bibliografa
LA IMPORTANCIA DE LOS REQUISITOS

Arlow, Jim & Neustadt, Ila. Programacin UML 2. Pgs.78-80
Recordatorio
Anotaciones
La ingeniera de requisitos es un trmino utilizado para describir las actividades

implicadas en la obtencin, documentacin y mantenimiento de un conjunto de
requisitos para un sistema de software. Trata acerca de descubrir qu necesitan los
grupos de decisin que el sistema haga por ellos.
Segn [Standish Group], requisitos incompletos y la ausencia de implicacin de
usuario eran las dos razones principales citadas para el fracaso del proyecto. Estos
aspectos son fallos en la ingeniera de requisitos.
Puesto que el sistema de software final se basa sobre un conjunto de requisitos, la
ingeniera de requisitos es un factor crtico de xito en proyectos de desarrollo de
software.
Definir Requisitos
Podemos definir un requisito como una especificacin de lo que se debera implementar. Existen bsicamente dos tipos de requisitos:
- Requisitos funcionales. Qu comportamiento debera ofrecer el sistema.
- Requisitos no funcionales. una propiedad especfica o restriccin del sistema.
Los requisitos son (o al menos debieran ser) la base de todos los sistemas.
Son bsicamente una declaracin de lo que debera hacer el sistema. En principio,
los requisitos deberan ser solamente una declaracin de lo que debiera de hacer el
sistema y no de cmo lo debera de hacer.
Esta es un importante distincin, podemos especificar lo que un sistema debera
hacer y qu comportamiento debera mostrar un sistema sin decir necesariamente
nada sobre cmo esta funcionalidad debera estar realizada.
Aunque es realmente atractivo, en teora, separar el qu del cmo, en la prctica, un conjunto de requisitos tender a ser una mezcla de qu y cmo. Esto
es en parte porque a menudo es ms sencillo escribir y entender una descripcin
de implementacin en lugar de una declaracin abstracta del problema y en parte
porque existen restricciones de implementacin que predeterminan el cmo del
sistema.
A pesar del hecho de que el comportamiento del sistema y en ltimo trmino, la
satisfaccin del usuario final se basa sobre la ingeniera de requisitos, muchas empresas no reconocen esto como una disciplina importante.
Como hemos visto, la razn principal de que los proyectos de software fracasen se
debe a problemas en requisitos.
El Modelo de Requisitos
Muchas empresas todava no tienen una nocin formal de requisitos o de un modelo de requisitos. El software se especifica en uno o ms documentos informales de
requisitos, que a menudo se escriben en lenguaje natural y se presentan en cualquier forma y tamao y en varios grados de utilidad.
Para cualquier documento de requisitos, en cualquier forma, las preguntas claves
son, qu utilidad tiene para m? y me ayuda a entender lo que el sistema debera hacer o no?.
Desafortunadamente, muchos de estos documentos informales son solamente de
utilidad limitada.
UP (Proceso Unificado). Tiene un enfoque formal a los requisitos basndose en un
modelo de caso de uso y lo ampliamos aqu con un modelo de requisitos basndose
Desarrollo
de contenidos
en ideas tradicionales de requisitos funcionales y no funcionales.
Lecturas
seleccionadas
Esta extensin se encuentra en relacin directa al enfoque ms sofisticado de la

ingeniera de requisitos en RUP. Nuestro meta modelo de requisitos muestra que el
SRS (Software Requeriments Specification) consta de un modelo de casos de uso
y
Recordatorio
un modelo de requisitos.
El modelo de caso de uso normalmente se crea en una herramienta de modelado
UML como Rational Rose.
El modelo de requisitos se puede crear en texto o en herramientas de ingeniera de
requisitos especiales como RequsitePro (www.ibm.com) o DOORS (www.telelogic.
com) . Le recomendamos que utilice herramientas de ingeniera de requisitos si es
posible.
Requisitos bien formados
UML no proporciona ninguna recomendacin sobre escribir requisitos tradicionales. De hecho, UML trata con requisitos por medio del mecanismo de casos de uso.
Sin embargo, muchos modeladores creen que los casos de uso no son suficientes
y que seguimos necesitando requisitos tradicionales y herramientas de administracin de requisitos.
Recomendamos un formato muy sencillo para indicar requisitos, como en la figura
mostrada. Cada requisito tiene un identificador nico (normalmente un nmero),
una palabra clave (debera) y una declaracin de funcin.
La ventaja de adoptar una estructura uniforme es que herramientas de administracin de requisitos como DOORS pueden analizar los requisitos ms fcilmente.
Figura 111. Formato para indicar requisitos

Fuente: Arlow, Jim & Neustadt, Ila. Programacin UML 2.
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
CONTROL DE LECTURA N. 2
Glosario
Bibliografa
Recordatorio
Anotaciones
INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
105
ollo
nidos
as
nadas
torio
106
UNIDAD III:InicioRUP Y UML NEGOCIO Y REQUERIMIENTOS
Actividades
Autoevaluacin
Diagrama
Objetivos
Glosario
Bibliografa
Desarrollo
de contenidos
Actividades
Lecturas
seleccionadas
Glosario
Autoevaluacin
GLOSARIO DE LA UNIDAD III

Anotaciones
Bibliografa
Herramienta. instrumento de software que permite el modelado de software.

Recordatorio
Modelo de dominio. es un diagrama de clases preliminar, basado en los objetos y

actores del negocio.
Anotaciones
Negocio. rea o reas; proceso o procesos de la organizacin y del cual se desarrollar el modelo de software.
Plantilla. Documento que describe en detalle a un caso de uso y que complementa
al modelo de software.
Poscondicin. Regla de negocio o restriccin como consecuencia de la ejecucin
de un caso de uso.
Precondicin. Regla del negocio o restriccin, necesario antes de ejecutar un caso
de uso.
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
BIBLIOGRAFA DE LA UNIDAD Iii
Arlow, Jim & Neustadt, Ila. (2005). Programacin UML 2. Espaa: Editorial Anaya.
Liza vila, Csar. (2001). Modelando con UML. Per: Editorial RJ.
Recordatorio
Anotaciones
Romero Moreno, Gesvin. (2004). UML con Rational Rose. Per: Editorial Megabyte.
Whitten, Jeffrey & Bentley, Lonnie. (2008). Anlisis de sistemas, diseo y mtodos.
Mxico: Editorial McGraw-Hill. Biblioteca UC: 658.4032 / W54 2008.
Desarrollo
de contenidos
Objetivos
Inicio
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
AUTOEVALUACIN DE LA UNIDAD III
1. E
n el modelado del Negocio, las restricciones que cada proceso de la organizacin puede tener corresponde a:
Glosario
a) Cuadro Pictogrfico
Bibliografa
b) Diagrama de Casos de Uso
Anotaciones
c) Lenguaje de Programacin
d) Diagrama de Clases
e) Reglas del Negocio

2. El diagrama que modela los objetos del negocio como comprobante de pago,
producto, informes, etc., y su relacin con los actores del negocio, corresponde
a:
a) Diagrama de Dominio del Negocio
b) Reglas del Negocio
c) Diagrama de Objetos del Negocio
d) Cuadro Pictogrfico
e) Diagrama de Casos de Uso del Negocio
3. El diagrama de clases preliminar, identificando las primeras clases y sus relaciones en base al diagrama de Objetos, corresponde a:
a)
Diagrama de Dominio del Negocio
b) Diagrama de Casos de Uso del Negocio
c)
Diagrama de Clases

d) Diagrama de Objetos del Negocio
e) Cuadro Pictogrfico
4. E
s un actor que est involucrado en la realizacin del caso de uso del negocio,
es decir es el responsable que el caso de uso se cumpla:

a) Actor del Negocio (Business Actor)
b) Cliente del Negocio
c) Trabajador del Negocio (Business Worker)
d) Usuario del Sistema
e)
Actor del Requerimiento (Actor)
5. E
s una relacin que permite transmitir el rol o responsabilidad que tiene un
actor hacia otros actores:
a)
Composicin

b) Generalizacin
c)
Comunicacin

d) Include
e) Extend
6. L
os requisitos funcionales, es decir lo que el software podr realizar, se modela
a travs de uno de los siguientes diagramas:
a) Diagrama de Casos de Uso del Negocio
b) Diagrama de Actividades del Requerimiento
c) Diagrama del Dominio

INGENIERA
DE SOFTWARE
d) Diagrama de Casos de Uso del Requerimiento
e) Diagrama de Paquetes del Negocio
Bibliografa
107
ollo
nidos
108
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
7. Es una relacin que indica que un caso de uso base, requiere la ejecucin previa
de otro caso de uso:
a) Extend

b) Generalizacin
c)
Include

d) Agregacin
e) Comunicacin
8. E
s una relacin que indica que un caso de uso, se ejecuta si el caso de uso base
lo requiere, es decir su ejecucin es opcional:
a) Composicin
b) Extend
c) Generalizacin
d) Inlcude
e) Comunicacin
9. En el diagrama de actividades, es un elemento que permite separar las actividades que realiza un actor o un objeto:
a) Barra de Sincronizacin
b) Carril de Actividad
c) Flujo de Actividad

d) Estado de Inicio
e) Punto de Decisin
10. En el diagrama de actividades, es un elemento que permite agrupar las tareas
que se pueden realizar en forma paralela, sin importar en que carril se ejecute.
a)
Estado de Inicio

b) Punto de Decisin
c) Estado Final
d) Barra de Sincronizacin
e) Carril de Actividad
Desarrollo
de contenidos
Diagrama
Desarrollo
de contenidos
Diagrama
Lecturas
seleccionadas
Objetivos
Inicio
Actividades
Autoevaluacin
Recordatorio
DIAGRAMA DE PRESENTACIN DE LA UNIDAD IV

Objetivos
Glosario
Inicio
Bibliografa
LECTURAS
SELECCIONADAS
Actividades
ACTIVIDADES
Autoevaluacin
Anotaciones
AUTOEVALUACIN
Lecturas
seleccionadas
Glosario
BIBLIOGRAFA
Bibliografa

Diagrama
Recordatorio
Glosario
CONTENIDOS
Desarrollo
de contenidos
Recordatorio
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Objetivos
Anotaciones
Inicio
CONOCIMIENTOS
PROCEDIMIENTOS
Tema N. 1: Flujo de trabajo 1. Identifica y describe los

elementos de construcde RUP: Modelado de anlisis
cin de los diagramas
1.
Diagrama
UML:
diapara el anlisis y el diseo.
grama de clases y es-
Desarrollo
de contenidos
labora los diagramas de

de
clase. 2. E
Bibliografa
UML
para el anlisis y el
2. Diagrama UML: Diagrama
diseo.
de secuencia, diagrama de
tereotipos
Glosario
Lecturas
seleccionadas
colaboracin.
Tema N.
2: Flujo de trabajo
Recordatorio
Anotaciones
de RUP: Modelado de diseo
3. Identifica y analiza los elementos de construccin

de los diagramas para la
implementacin.
1.
Diagrama UML: Subsistemas e interfaces, modelo 4. Elabora los diagramas de
UML para la implemenarquitectnico
tacin y los incorpora en
2. Diagrama UML: Diagrama
el proyecto de software en
de estados.
equipo.
Tipos de Interfaz de usuario Actividad N. 4
Anlisis y diseo de Sistemas
Kendall, Kenneth & Kendall , Desarrollo de los diagramas
del anlisis y diseo, segn
Julie. Pg. 497.
casos propuestos.
Tema N. 3: Flujo de trabajo
de RUP: Modelado de impleTarea acadmica N. 2
mentacin
1. Diagrama UML: Diagrama Elabora el informe completo del modelamiento de
de componentes.
2. Diagrama UML: Diagrama software, adjuntando el modelado del anlisis, diseo e
de despliegue.
implementacin.
Tema N. 4: Transformacin
al modelo de datos
1. Clases persistentes.
2. Generacin del modelo de
datos.
Piattini, Mario., Marcos, Esperanza., Calero, Coral. Dominio y atributo. Tecnologa y
diseo de base de Dato. Pg.
164.
Autoevaluacin de la
unidad IV
ACTITUDES
1.
Asume con responsabilidad sus actividades acadmicas
asignadas.
2. Realiza con honestidad las evaluaciones
asignadas.
Anotaciones
Bibliografa
109
ollo
nidos
110
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
TEMA N. 1: Gestin de las Adquisiciones del proyecto

En esta fase elaboraremos los elementos que conformarn el modelo de software,
las relaciones entre estos para cumplir con los requisitos del software.
1
Diagrama UML: Diagrama de Clases y estereotipos de Clase1

Requerimos crear un paquete para contener las clases que le pertenecen al diseo,
y ms adelante generar el Modelo de Datos. (Romero Moreno, Gesvin. 2004)
I. Creando Paquete ClasesVentas
1. Clic derecho en Logical View para el men emergente y seleccionar New: Package, llamado ClasesVentas que se ubicar en el browser.
Figura 112 Ejemplo de creacin de paquetes para el anlisis

II. Diagrama de Clases

1. Clic derecho sobre el paquete ClasesVentas y seleccionar New: Class Diagram.
2. Asignarle el nombre de DClasesVentas.
Figura 113. Ejemplo de creacin e de Diagrama de Clases del Anlisis

a. Clases de Anlisis
1. Para las clases de anlisis se necesita como mnimo:
Nombre de la clase
Atributos de de la clase
Operaciones de la clase
Visibilidad de Atributos y Operaciones
Estereotipos
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura114. Ejemplo de clase con estereotipo

2. Clic derecho en el paquete ClasesVentas para el men emergente y seleccionar

New : Clase, llamado NewClass que se ubicar en el browser.
3. Luego Cambiar el nombre NewClass por el de la Clase segn el modelo que se

3.1 Clic derecho en NewClass, Rename y cambiar nombre, :
3.2 C
lic derecho doble clic en NewClass, luego Open Especification y cambiar
4. Repita los pasos anteriores para crear otras clases.
Figura 115. Ejmplo de creacin de clase para el anlisis

b. Atributos
1. Para crear los atributos de una clase:

1.1 Clic derecho en una clase y elegir New Attribute, o:
1.2 Clic derecho en la clase y elegir Open Specification y luego Attributes.
INGENIERA
DE SOFTWARE
2. L
uego Cambiar el nombre por el del atributo de la Clase segn el modelo. que
se est realizando, que puede ser de dos maneras:

2.1 Clic derecho en name, Rename y cambiar nombre o
2.2 C
lic derecho doble clic en name, luego Open Especification y cambiar
Bibliografa
111
ollo
nidos
112
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 116. Ejemplo creacin de un atributo de clase

3. Para especificar la Visibilidad del Atributo: Clic derecho doble clic en el atributo, luego Open Especification y seleccionar en Export Control: Public, Protected, Private y luego clic en el botn Aplicar y despus el botn OK.
Figura 117. Ejemplo creacin de detalles de atributo

4. Repita los pasos anteriores para crear los atributos de las otras clases
b. Operaciones
1. Para crear los atributos de una clase:
1.1 Clic derecho en una clase y elegir New Operation o
1.2 Clic derecho en la clase y elegir Open Specification y luego Operations
2. Luego Cambiar el nombre por el de la operacion de la Clase segn el modelo
que se est realizando, que puede ser de dos maneras:
2.1 Clic derecho en name, Rename y cambiar nombre o
2.2 C
lic derecho doble clic en name, luego Open Especification y cambiar nombre en Name y luego clic en el botn Aplicar y despus el botn OK.
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 118 Ejemplo creacin de una operacin para la clase

3. Para especificar la Visibilidad de la Operacin: Clic derecho doble clic en la

operacin, luego Open Especification y seleccionar en Export Control: Public,
Protected, Private y luego clic en el botn Aplicar y despus el botn OK.
4. Tambin se puede especificar los argumentos de la operacin.
Figura 119. Ejemplo creacin de detalles de una operacin

c. Estereotipos de Clase
1. Puede definir los estereotipos de clase: Entidad (Entity), Entorno (Boundary) y
Control (Control) en la ventana de especificaciones de la clase.
Figura 120. Ejemplo de creacin de estereotipo de clase

INGENIERA
DE SOFTWARE
Bibliografa
113
ollo
nidos
as
nadas
torio
114
Actividades
Autoevaluacin
Glosario
Bibliografa
2. Clic en un Clase y arrastrarlo dentro del diagrama.

3. Repita los pasos anteriores para crear los estereotipos de las otras clases.
4. Arrastrar las clases creadas hacia el diagrama DClasesVentas.
Anotaciones
e. Relaciones
1. Para crear la Relacin de Asociacin: Clic en el icono Unidireccional
Association de la Caja de Herramientas.
2. Clic en un Clase iniciando y arrastrar la Relacin hasta otra clase.
Figura 121. Ejemplo de relacin de asociacin

3. Se puede dar nombre y roles a la relacin. Ejemplo. Relacin de asociacin

entre Usuario e IniciaSesion:
Figura 122. Ejemplo de rol en una asociacin

4. Para crear la Relacin de Generalizacin:

Clic en el icono Generalization de la Caja de Herramientas.
5. Clic en un Clase Hija y arrastrar la Relacin hasta la Clase Padre.
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 123. Ejemplo de generalizacin entre clases

6.
Para asignar multiplicidad en una relacin, ingresar al detalle de rol de una de
las clases y seleccionar Multiplicity.
Figura124. Ejemplo de multiplicidad en una relacin

7. Para asignar la composicin entre clases se realiza una relacin de agregacin,

seleccionar de la caja de herramientas Unidireccional Aggregation, arrastrar de
la clase compuesta hacia la clase que compone y luego en la clase compuesta
(Role B Detail), se cambia el valor (Seleccionar By Value).
Figura 124. Ejemplo creacin de relacin de composicin

8. Realizar lo mismo para las dems clases relacionadas.
INGENIERA
DE SOFTWARE
Bibliografa
115
ollo
nidos
116
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
9. Al final el diagrama de clases:
Figura 125. Ejemplo de Diagrama de Clases con estereotipo

2 Diagrama UML: Diagrama de Secuencia /
Diagrama de Colaboracin
En esta fase se modela el comportamiento de los elementos del modelo de software
y las relaciones entre estos para cumplir con los requisitos del software.
I. Realizacin de Casos de Uso
1. Clic en Logical View del Browser para desplegar el men.
2. Clic derecho en Logical View para el men emergente y seleccionar Anlisis
Model, clic derecho, New y seleccionar Use Case Diagram.
3. Dar el nombre a este nuevo diagrama de casos de uso como DCURVentas, doble clic para abrirlo.
Figura 126. Ejemplo de creacin de Diagrama de Casos de Uso de Realizacin

4. Crear un caso de uso, ejemplo IniciarSesion.

5. Abrir la ventana de especificaciones de este caso de uso y cambiar el estereotipo
a use/case realization.
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 127. Ejemplo de creacin de casos de uso de realizacin

6.
Por cada caso de uso de requerimiento, crear el caso de uso que realizar el
algoritmo.
7.
Arrastrar al DCURVentas, los casos de uso de requerimientos del
DCUSistVentas.
8. Establecer la relacin de asociacin y cambiar el estereotipo por realize.
Figura 128. Ejemplo de creacin de relacin realize

9. Realizar el mismo procedimiento para los dems casos de uso.

II. Modelo de Secuencia
a. Crear del Diagrama de Secuencia
1. Seleccione un caso de uso de realizacin, Ejemplo IniciarSesion.
2. Clic derecho, seleccione New: Sequence Diagram.
3. Asignarle el nombre de DSIniciarSesion, doble clic para abrir el diagrama.
INGENIERA
DE SOFTWARE
Bibliografa
117
ollo
nidos
118
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 29. Ejemplo de creacin de Diagrama de Secuencia

b. Crear Objetos y Lneas de Vida

1.
Arrastrar del paquete DCUSistVentas (Use Case Model), al actor del negocio
Usuario, hacia el diagrama de secuencia.
2.
Arrastrar del paquete ClasesVentas (Locical View-Analysis Model), a la clase
boundary IniciarSesionC, hacia el diagrama de secuencia.
3.
Realizar el paso el mismo procedimiento para pasar las clases necesarias al
diagrama de secuencia.
Figura130. Ejemplo de clases en un diagrama de Secuencia

c. Crear Mensajes
1. Para crear un mensaje simple:
1.1 Seleccione de la Caja de Herramientas a Object Message y arrastre de un
objeto a otro, ejemplo del actor Usuario hacia la clase IniciarSesion.
Figura 131. Ejemplo de creacin de mensajes

1.2. Seleccionar el mensaje, doble clic para abrir la ventana de especificaciones,

para seleccionar General y luego en el Name escribir el testo del mensaje.
Ejemplo: Mostrar Interfaz.
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 132. Ejemplo de creacin de mensaje simple

2. Para crear un mensaje sncrono:

2.1 Realizar un mensaje simple entre un objeto emisor y otro receptor, con su respectivo mensaje.
2.2 Seleccionar el mensaje simple, doble clic para abrir la ventana de especificaciones.
2.3 Seleccionar Detail, y elegir Synchronous.
Figura 133. Ejemplo de creacin mensaje sncrono

3. Para crear un mensaje asncrono:

3.1 Realizar un mensaje simple entre un objeto emisor y otro receptor, con su respectivo mensaje.
3.2 Seleccionar el mensaje simple, doble clic para abrir la ventana de especificaciones.
3.3 Seleccionar Detail, y elegir Asynchronous.
Figura 134. Ejemplo de creacin mensaje asncrono

INGENIERA
DE SOFTWARE
Bibliografa
119
ollo
nidos
as
nadas
torio
120
Actividades
Autoevaluacin
Glosario
Bibliografa
4. Para crear un mensaje de retorno:
Anotaciones
4.1 R
ealizar un mensaje simple entre un objeto receptor hacia el emisor con su
respectivo mensaje.
4.2 S
eleccionar el mensaje simple, doble clic para abrir la ventana de
especificaciones.
4.3 Seleccionar Detail y elegir Return.
Figura 135. Ejemplo de creacin de mensaje de retorno

5. Para crear un mensaje recursivo:

5.1 S
eleccione de la Caja de Herramientas a Message to Self y diagrame hacia el
mismo objeto.
Figura 136. Ejemplo de mensaje recursivo

5.2 Seleccionar el mensaje, doble clic para abrir la ventana de especificaciones,

para seleccionar General y luego en el Name escribir el testo del mensaje.
Ejemplo: Comparar.
d. Crear Focos de Control

1. Los focos de control se crean a medida que crea los mensajes entre objetos.
2.
Para tener un foco de control por cada operacin (actividad) que realice el objeto a travs de mensajes, agrupe dichos mensajes en un mismo foco de control.
3. R
ealizar los mismos pasos para crear un diagrama de secuencia por cada caso de
uso de realizacin.
4. El Diagrama de Secuencia final:
Desarrollo
de contenidos
Figura 137. Ejemplo de diagrama de secuencia en el anlisis

III. Modelo de Colaboracin

a. Crear del Diagrama de Colaboracin
1. Seleccione un diagrama de secuencia, Ejem. DSIniciarSesion.
2. Pulsar el botn F5 para crear el respectivo Diagrama de Colaboracin.
3. Dar el nombre de DCIniciarSesion.
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Bibliografa
121
ollo
nidos
122
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
4. Realizar el mismo procedimiento para crear cada diagrama de colaboracin.
Figura 138. Ejemplo de diagrama de colaboracin

Desarrollo
de contenidos
TEMA N. 2: FLUJO DE TRABAJO DE RUP: MODELADO DE DISEO
Lecturas
seleccionadas
Disearemos la arquitectura del software elaborando los subsistemas del software y

Recordatorio
de las interfaces internas de comunicacin, que darn como resultado los prototipos de interfaz, retroalimentados por el usuario.
1 Diagrama UML: Subsistemas e Interfaces, Modelo
Arquitectnico2
Iniciamos con la creacin de los subsistemas que formarn parte del sistema integrado software.
I. Subsistemas
a. Crear Subsistemas
1. En el Design Model, seleccionar Layer para crear un paquete por cada subsistema determinado; ejemplo: AtencinPedido, Facturacin, Gestin-Cliente.
Figura 139. Ejemplo de creacin de paquete para el diseo

2. P
or cada paquete creado, abrir la ventana de especificaciones y cambiar el estereotipo por el subsystem.
Figura 140. Ejemplo de creacin de subsistemas

3. En Layer, clic derecho y seleccionar New, luego Class Diagram, y nombrarlo
DiagramaSubsistemas.
4. Doble clic para abrir el Diagrama y arrastrar los subsistemas creados.
Figura 141. Ejemplo de creacin de subsistemas en el diagrama

INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
123
ollo
nidos
as
nadas
torio
124
Actividades
Autoevaluacin
Glosario
Bibliografa
II. Interfaces
a. Crear Interfaces
Anotaciones
1. En el diagrama de subsistemas, seleccionar de la caja de herramientas.
Figura 142. Ejemplo clase interface

2. C
rear las interfaces proporcionadas por cada subsistema, por ejemplo GestorCliente, GestorFacturacin, GestorPedido.
Figura 143. Ejemplo de subsistemas e interfaces

3. Para relacionar las interfaces con los subsistemas se debe seleccionar Realice.
Figura 144. Ejemplo de relacin realize para los subsistemas

4. Se debe tener en cuenta si son proporcionadas o requeridas.
Figura 145. Ejemplo de subsistemas e interfaces relacionadas

Desarrollo
de contenidos
b. Clases de Diseo
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
1. Clic en Logical View del Browser y seleccionar Layer.

2. Por cada paquete de subsistema crear las respectivas clases con estereotipo.
Figura 146. Ejemplo de creacin de clases para el diseo

3. Crear las clases de diseo, refinando las clases de anlisis con sus respectivos
estereotipos, atributos y operaciones.
4. Para especificar el Tipo de Dato y Valor inicial del atributo (opcional): Clic derecho doble clic en el atributo, luego Open Especification y seleccionar en Type
e Inicial Value.
5.
Para especificar el Tipo de Dato de Retorno de la operacin y Valor inicial del
atributo (opcional): Clic derecho doble clic en la operacin, luego Open Especification y seleccionar en Return Type.
6.
Tambin se puede especificar los argumentos de la operacin, en Detail, clic
derecho para Insert y dar el nombre del argumento y el tipo de dato.
7. Repita los pasos anteriores para las otras clases de diseo.
c. Relaciones de Diseo
2. Clic derecho en Logical View para el men emergente y seleccionar Design
Model y crear el paquete ClasesDisenoVentas.
3. Clic derecho en el paquete creado, New y seleccionar Class Diagram y dar el
nombre de DClasesDiseno, doble clic para abrirlo.
4. Arrastrar las clases del diseo de cada subsistema hacia el diagrama de clases.
5.
Se debe mejorar e incrementar si es necesario las relaciones de asociacin, herencia, agregacin y composicin, garantizando la alta cohesin y el bajo acoplamiento.
d. Realizacin de Casos de Uso
2.
Clic derecho en Logical View para el men emergente y seleccionar Design
Model, luego seleccionar Use Case Realizations, y luego Use Case Name.
3.
En este ltimo paquete, crear los casos de uso de realizacin del diseo para los
casos de uso de anlisis, ejemplo IniciarSesion.
4. Abrir la ventana de especificaciones de este caso de uso y cambiar el estereotipo
a use case realization.
Bibliografa
125
ollo
nidos
126
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 147. Ejemplo de creacin de casos de uso de realizacin del diseo

5.
En el paquete Use Case Realizations crear el diagrama de clases DCUR Ventas, doble
clic para abrirlo.
6.
Arrastrar los casos de uso de realizacin del diseo hacia el diagrama con sus respectivos casos de uso de realizacin del anlisis.
7. Establecer la relacin de asociacin y cambiar el estereotipo por realice.
Figura 148. Ejemplo de creacin relaciones de casos de uso del diseo

8. Realizar el mismo procedimiento para los dems casos de uso del diseo.
e. Diagrama de Secuencia
1. Seleccione un caso de uso de realizacin del Diseno, Ejemplo InicioSesion.
2. Clic derecho, seleccione New: Sequence Diagram.
3. Asignarle el nombre de DSIniciarSesion, doble clic para abrir el diagrama.
4. Considerando las nuevas clases refinadas del diseo, crear el diagrama de secuencia
por cada caso de uso del diseo.
f. Modelo Arquitectnico
1.
Seleccionar Layer, luego New y seleccionar Activity Diagram, darle el nombre de
ModeloArquitectura, doble clic para abrir el diagrama.
2. Crear carriles (swimlanes) de acuerdo a los niveles de capas definidas.
Figura 149. Ejemplo de capas de modelo arquitectnico

Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
3. Crear los objetos segn cada capa, seleccionando la herramienta Object.
Figura 150. Ejemplo de objetos para el modelo arquitectnico

4. Abrir la ventana de especificaciones del objeto creado y seleccionar la clase de

los subsistemas, de la cual es instanciada y segn la capa que se est modelando.
5. Se realizan los mismos pasos para los objetos por cada nivel de capa.
Figura 151. Ejemplo de diagrama arquitectnico del software

2 Diagrama UML: Diagrama de Estados

I. Modelo de Estados
a. Creacin del diagrama de estados
1. Seleccione una clase de diseo de cada subsistema, Ej. UsuarioD.
2. Clic derecho, seleccione New: Statechart Diagram.
3. Asignarle el nombre de DEUsuarioD, doble clic para abrir el diagrama.
Figura 152. Ejemplo de creacin de diagrama de estados

Bibliografa
127
ollo
nidos
as
nadas
torio
128
Actividades
Autoevaluacin
Glosario
Bibliografa
b. Creacin de Estados Inicial y Final

1.
En el Diagrama de Estados, seleccionar de la caja de herramientas a Start State
y a End State y crearlos en el diagrama.
Anotaciones
c. Creacin de estados
1. Clic derecho sobre el Diagrama de Estados, luego New, y seleccionar State.
2.
Asignarle un Nombre, mientras se encuentra seleccionado y arrastrarlo hacia el
diagrama.
Figura 153. Ejemplo de creacin de un estado

3. Crear las Acciones del Estado:

3.1 Clic derecho en el Estado para asignarle una Accin, luego Open Especification y seleccionar Actions.

3.2 Clic derecho y seleccionar Insert y aparecer la accin Entry/.
3.4 Clic derecho en la accin creada para abrir la ventana de especificaciones y

darle un nombre.
Figura 154. Ejemplo de creacin de detalle de un estado

3.5 S
i desea modificar Entry/ por otra accin, solo tiene que hacer clic derecho
en la Accin y elegir Especification.
3.6 E
n Especification, en el Detalle elegir de When la accion deseada, por
ejemplo Do/.
3.7 Luego en Name especificar la accin correspondiente y Aceptar.
Desarrollo
de contenidos
c. Creando las Transiciones
Lecturas
seleccionadas
1. Seleccionar de la Caja de Herramientas el icono State Transition y arrastrar desde el estado Origen hacia el estado destino, desde el estado inicial hacia el primer estado de la clase y entre estados.
Recordatorio
Figura 154. Ejemplo de creacin de transicin de estados

2.
Doble clic sobre la transicin entre los estados del punto 1 para Open
Specification.
3. En General y Event, escribir el evento para esa transicin.
4. Luego en Detail, especificar la Condicin y la Accion para esta transicin.
Figura 155. Ejemplo de detalle de transicin de estados

5. Puede crear estados anidados, arrastrando un estado dentro de otro estado.

6. Pueden existir estados que se relacionen consigo mismos:

6.1 Seleccionar de la Caja de Herramientas el icono Transition to Self.

6.2 Arrastrar desde el estado Origen hacia el mismo estado requerido como
destino.
Figura 156. Ejemplo de Estados anidados

INGENIERA
DE SOFTWARE
Glosario
Anotaciones
Bibliografa
129
ollo
nidos
130
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
6.3 El Diagrama estados queda as:
Figura 157. Ejemplo de diagrama de estados para una clase

d. Diagrama de Actividad
1. Seleccione un caso de uso de realizacin del Diseo, Ejemplo InicioSesion.
2. Clic derecho, seleccione New: Activity Diagram.
3. Asignarle el nombre de DAIniciarSesion, doble clic para abrir el diagrama.
Figura 158. Ejemplo de creacin de diagrama de actividades para el diseo

Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
4. Considerando las nuevas clases refinadas del diseo, crear el diagrama de

actividades por cada caso de uso del diseo.
5. Crear los swimlanes por cada clase.
6. Arrastrar una clase del diseo hacia el campo del nombre de un swimlane.
7. Crear las actividades en cada swimlane.
8. Realizar para cada caso de uso de realizacin del diseo.
Figura 159. Ejemplo de diagrama de actividades del diseo

Bibliografa
131
ollo
nidos
132
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
UNIDAD IV:
RUP Y UML
Objetivos
Inicio ANLISIS, DISEO E IMPLEMENTACIN
Diagrama
Desarrollo
de contenidos
Actividades
Autoevaluacin
Lecturas
seleccionadas
Glosario
Bibliografa
TIPOS DE INTERFAZ DE USUARIO
Kendall, Kenneth & Kendall, Julie. Anlisis y diseo de Sistemas. Pgs. 497-504
Recordatorio
Anotaciones
En esta seccin se describen varios tipos de interfaces de usuario, entre ellas las siguientes: Interfaces de comunicacin natural, interfaces de pregunta y respuesta, mens, formularios, interfaces de lenguaje de comandos, interfaces grficas de usuario (GUI), una
variedad de interfaces web para uso en internet.
La interaccin de usuario tiene dos componentes principales: el lenguaje de presentacin, que es la parte de la computadora/humano de la transaccin y el lenguaje de
accin, que caracteriza la parte humano/computadora. En conjunto, ambos conceptos
cubren la forma y contenido del trmino interfaz del usuario.
Interfaces de lenguaje natural
Las interfaces de lenguaje natural son quiz el sueo e ideal de usuarios inexpertos, debido a que permiten a usuarios interactuar con la computadora en su lenguaje cotidiano
o natural.
No se requieren habilidades especiales de usuarios, quienes interactan con la computadora mediante lenguaje natural.
Las sutilezas e irregularidades que residen en las ambigedades del lenguaje natural producen un problema de programacin sumamente exigente y complejo. Los intentos por
interactuar con lenguaje natural para algunas aplicaciones en las cuales cualquier otro
tipo de interfaz no es factible (por decir, en el caso de un usuario que est incapacitado)
se est obteniendo con algo de xito; sin embargo, estas interfaces normalmente son
caras. Los problemas de implementacin y la demanda extraordinaria en los recursos de
informtica hasta ahora han mantenido las interfaces de lenguaje natural a un mnimo.
Sin embargo, la demanda existe y muchos programadores e investigadores estn trabajando diligentemente en las interfaces de lenguaje natural. Es una rea de crecimiento y,
por lo tanto, merece supervisin continua...
Interfaces de pregunta y respuesta
En una interfaz de pregunta y respuesta, la computadora despliega en pantalla una pregunta para el usuario. Para interactuar, el usuario introduce una respuesta (mediante
pulsaciones del teclado o un clic del ratn) y la computadora despus acta en esa informacin de entrada de acuerdo con su programa, normalmente pasando a la siguiente
pregunta.
Menus
Una interfaz de mens adquiere apropiadamente su nombre de la lista de platillos que
se pueden seleccionar en un restaurante. De forma similar, una interfaz de men proporciona al usuario una lista en pantalla de las selecciones disponibles.
En respuesta al men, un usuario est limitado a las opciones desplegadas. El usuario no
necesita conocer el sistema pero tiene que saber qu tarea se debe realizar. Por ejemplo,
con un men tpico de procesamiento de texto, los usuarios pueden escoger opciones
para editar, copiar o imprimir. Sin embargo, para utilizar el mejor men los usuarios deben saber qu tarea desean desempear.
Los mens no dependen del hardware. Las variaciones abundan. Los mens se establecen para usar el teclado, lpiz ptico o el ratn. Las selecciones se pueden identificar
con un nmero, carta o palabra clave. La consistencia es importante en el diseo de una
interfaz de men
Desarrollo
de contenidos
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
... Los mens de GUI se usan para controlar el software de PC y tienen los siguientes lineamientos:
1. Siempre se despliega la barra de men principal.
Recordatorio
2. El men principal usa palabras simples para los artculos del men. Las opciones
de men principales siempre despliegan mens desplegables secundarios.
3. El men principal debe tener opciones secundarias agrupadas en grupos similares de caractersticas.
4. Los mens desplegables que se presentan cuando se hace clic en un artculo de
men principal con frecuencia consisten en ms de una palabra.
5. Estas opciones secundarias desempean acciones o despliegan artculos de men
adicionales.
6. Los artculos de men en gris no estn disponibles para la actividad actual.
Un men de objeto, tambin llamado men desplegable independiente, se despliega cuando el usuario hace clic en un objeto de la GUI con el botn derecho
del ratn. Estos mens contienen artculos especfico para la actividad actual y la
mayora es funciones duplicadas de artculos de men principales
Interfaces de formulario (formularios de entrada/salida)
Las interfaces de formulario consisten de formularios en pantalla o formularios
que se basan en la Web que despliegan campos que contienen datos o parmetros
que necesitan ser comunicados al usuario. El formulario a menudo es un facsmil
de un formulario impreso que ya es familiar para el usuario. Esta tcnica de interfaz tambin se conoce como mtodo basado en el formulario y en formularios de
entrada/salida
... Hay algunas desventajas con los formularios de entrada/salida. La desventaja
principal es que los usuarios experimentados se podran impacientar con estos formularios y querran formas ms eficaces para introducir datos.
Interfaces de lenguaje de comandos
Una interfaz de lenguaje de comandos permite al usuario controlar la aplicacin
con una serie de pulsaciones del teclado, comandos, frases o alguna secuencia de
estos tres mtodos. Es una interfaz popular que es ms refinada que las discutidas
anteriormente.
Los lenguajes de comandos manipulan a la computadora como una herramienta para permitir al usuario controlar el dilogo. El lenguaje de comandos ofrece al
usuario mayor flexibilidad y control.
Cuando el usuario da una instruccin a la computadora mediante lenguaje de comandos, se ejecuta de inmediato por el sistema. Despus el usuario podra proceder para dar otra instruccin.
Los lenguajes de comandos requieren memorizar las reglas de sintaxis, esto generalmente es un obstculo para los usuarios inexpertos. Los usuarios experimentados tienden a preferir los lenguajes de comandos, posiblemente porque les permite
trabajar ms rpido
Interfaces grficas de usuario
Las interfaces grficas de usuario (GUI) permiten la manipulacin directa de la
representacin grfica en pantalla, la cual se puede realizar con la entrada del teclado, una palanca de juego o el ratn. La manipulacin directa requiere mayor
sofisticacin del sistema que las interfaces vistas anteriormente.
La clave para las GUI es la retro alimentacin constante que proporcionan. La retroalimentacin contnua en el objeto manipulado significa que se pueden hacer
rpidamente los cambios o incluso cancelar operaciones sin incurrir en mensajes
de error
Anotaciones
Bibliografa
133
ollo
nidos
as
nadas
torio
134
Actividades
Autoevaluacin
Glosario
Bibliografa
Otras interfaces de usuario

Otras interfaces de usuario, aunque menos comunes que las discutidas anteriormente, estn ganando popularidad. Estas interfaces incluyen dispositivos de indicacin tal como el lpiz ptico, pantallas sensibles al tacto y reconocimiento de voz
y sntesis. Cada una de estas interfaces tiene sus propios atributos especiales que
corresponden de forma nica a aplicaciones particulares.
Anotaciones
El lpiz ptico (un palo puntiagudo que parece pluma) se est volviendo popular
debido al nuevo software de reconocimiento de escritura y a los asistentes digitales
personales (PDA). Los dispositivos Palm y Pocket/PC han sido un xito porque hacen muy bien un nmero limitado de cosas y se venden a un precio bajo. Las computadoras porttiles como stas incluyen un calendario, directorio, agenda y block
de notas. La entrada de datos tambin se facilita con una estacin de acoplamiento
para que pueda sincronizar los datos con su PC
Diagrama
Objetivos
Desarrollo
de contenidos
Actividades
Inicio
ACTIVIDAD N. 4
Autoevaluacin
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Bibliografa
Desarrollo
de contenidos
TEMA N. 3: F LUJO DE TRABAJO DE RUP: MODELADO DE

IMPLEMENTACIN
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
En esta etapa es necesario que usted haga uso de sus conocimientos sobre los lenguajes de programacin, creacin de base de datos y diseo de redes para un efectivo modelamiento.
1
D
iagrama UML: Diagrama de Componentes3
En esta fase modelaremos los archivos lgicos y su dependencia, para lograr la
ejecucin del software.
I. Modelo de Componentes
a. Creando el Diagrama de Componentes.
1. T
eniendo en cuenta las clases con estereotipos, se identifican los principales
componentes del software.
2. Clic derecho en Component View en el Browser seleccionar New, luego Component Diagram llamado NewDiagram que se ubicar en el browser.
3. C
ambiar el nombre NewDiagram segn el modelo que se est realizando, Clic
derecho en NewDiagram, Rename y cambiar nombre por el de Sistema.
Figura 160. Ejemplo de creacin de diagrama de componentes

b. Creando Componentes
1.
Clic derecho en Component View en el Browser seleccionar New, luego Component. llamado NewComponent que se ubicar en el browser.
2. Asignarle un nombre segn el modelo.
3. En la Ventana de Especificaciones, asignarle su estereotipo.
4. Repita estos pasos por cada componente que requiera.
5. Doble Clic sobre el Diagrama de Componentes Ventas para abrirlo.
7. Arrastrar un componente hacia el Diagrama de Componentes.
c. Creando Relaciones
1. Seleccionar de la Caja de Herramientas el icono Dependency.
2. Arrastrar en el Diagrama de Componentes, de uno a otro.
3. Realizar lo mismo para todas las relaciones entre componentes.
INGENIERA
DE SOFTWARE
Bibliografa
135
ollo
nidos
as
nadas
torio
136
Actividades
Autoevaluacin
Glosario
Bibliografa
Anotaciones

d. Asignacin de Clases
1. Por cada componente se asigna la clase o clases correspondientes.
2. Clic derecho en el componente para abrir la ventana de especificaciones.
3. Seleccionar Realizes.
4. Seleccionar una clase, clic derecho y luego Assign.
5. Realizar lo mismo si hubiesen ms clases para el mismo componente.
Figura 162. Ejemplo de asignacin de clase a un componente

Desarrollo
de contenidos
D
iagrama UML: Diagrama de Despliegue
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
En esta fase, se modela los elementos fsicos para lograr la ejecucin del software.
Recordatorio
Modelo de Despliegue
a. Creacin del Diagrama de Despliegue
1. Doble Clic en Deployment View en el Browser para abrir el diagrama.
b. Creando Nodos
1. Seleccionar de la Caja de Herramientas un nodo de tipo procesador llamado

Processor.
2. Arrastrar el icono hacia el Diagrama de Despliegue.
3. Doble Clic para especificar el nombre en Open Specification.
4. Seleccionar de la Caja de Herramientas un nodo de tipo procesador llamado
Device.
5. Arrastrar el icono hacia el Diagrama de Despliegue.
6. Doble Clic para especificar el nombre en Open Specification.
7. Para relacionar, seleccionar de la Caja de Herramientas un relacin llamado
Connection.
Figura 163. Ejemplo de creacin de diagrama de componentes

Anotaciones
Bibliografa
137
ollo
nidos
138
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
TEMA N. 4: T RANSFORMACIN AL MODELO DE DATOS

Para este ltimo tema usted debe revisar sus conocimientos acerca de la creacin
de una base de datos, las claves principales y relaciones entre tablas de un Modelo
Lgico hacia un Modelo Fsico, para identificar y asignar las clases necesarias para
elaborar el modelo de datos para el software.
1
Clases Persistentes 4
Identificamos y asignamos las clases necesarias para elaborar el modelo de datos
para el software.
1. T
ener el modelo de Clases del diseo en un PAQUETE especfico, dentro del
paquete de LOGICAL VIEW, las clases deben ser PERSISTENTES.
2. Para cada clase entidad, clic derecho y seleccionar Open Specification.
3. En Detail, seleccionar Persistent.
Figura 164. Ejemplo de asignacin de la persistencia de una clase

4. Asignando claves candidatas

4.1 Clic derecho en un atributo del modelo de objetos en el navegador.
4.2 Seleccionar Data Modeler > Part of Object Identity.
4.3 Para desasignar clave candidata, repetir los mismo pasos.
Figura 165. Ejemplo de asignacin de clave candidata

Desarrollo
de contenidos
G
eneracin del Modelo de Datos
Lecturas
seleccionadas
INGENIERA
DE SOFTWARE
Glosario
En esta fase se disea el contenedor del Modelo de Datos y el Gestor de Base de

Datos que recepciona al modelo
Recordatorio
a. Adecuar Modelo de Clases a Modelo de Datos

1. Crear la Base de datos

1.1
Clic derecho en Component View y seleciona Data Modeler > New >
Database.
1.2 Darle el nombre de BDVentas.
Figura 166. Ejemplo de creacin del repositorio de datos

1.3 Clic derecho en la base de datos BDVentas y selecciona Open Specification.

1.4 Ingrese el nombre para la nueva base de datos, en Database Specification.
1.5 Selecciona un destino para la BD en Target. Por defecto esta en ANSI SQL92.
2. Transformando el modelo Clases a Modelo de Datos
2.1 Clic derecho en el paquete donde se encuentre el modelo de clases y las
clases.
2.2 Seleccionar Data Modeler > Transform to Data Model.
Figura 167. Ejemplo de transformacin a modelo de datos

Anotaciones
Bibliografa
139
ollo
nidos
140
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
2.1 Al transformar a un modelo de datos se crea automticamente un esquema:
Figura 168. Ejemplo de creacin de un esquema para datos

2.2 Click en la lista de Destination Schema para indicar el nombre del esquema o
entrar un nuevo nombre de esquema en la text box.
2.3 Click the Target Database drop-down list to select an existing database name.
Figura 169. Ejemplo de seleccin de destino de base de datos

3. Crear un Diagrama de Modelo de Datos

3.1 Clic derecho en un schema en el navegador del modelo.
3.2 Seleccionar Data Modeler > New > Data Model Diagram.
Desarrollo
de contenidos
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Figura 170. Ejemplo de creacin del diagrama de modelo de datos

3.3 Clic derecho nuevo modelo de datos del esquema en el navegador y darle el
nombre de MDVentas.

3.4 Doble click en el nuevo diagrama de modelo de datos para abrirlo.
4. Agregar elementos al Diagrama de Modelo de Datos.

4.1 Arrastrar las tablas que se encuentran dentro del esquema hacia el diagrama
de modelo de datos.
Figura 171. Ejemplo de modelo de datos

b. Asignar Modelo de Datos para una base de datos

1. Pasando el modelo de datos al gestor de base de datos.
1.1 Clic derecho en el esquema desde el navegador.

1.2 Seleccionar Data Modeler > Forward Engineer.
INGENIERA
DE SOFTWARE
Bibliografa
141
ollo
nidos
142
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Figura 172. Ejemplo de creacin del modelo a la base de datos

Fuente: Rojas Moreno ,Carol Roxana
1.3 El asistente para Forward Engineering aparece. Sigue las instrucciones del
asistente.
Figura 173. Ejemplo de vista de instrucciones para la base de datos

Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Lecturas
seleccionadas
Glosario
Bibliografa
DOMINIO Y ATRIBUTO
Piattini,
Mario., Marcos, Esperanza., Calero, Coral. Tecnologa y Diseo de base
Anotaciones
de datos. Pgs. 164-166
Recordatorio
Un dominio D es un conjunto finito de valores homogneos y atmicos V1 , V2, Vn,

caracterizado por un nombre; decimos valores homogneos porque son todos del mismo tipo y atmicos por que son indivisibles en lo que al modelo se refiere, es decir, si se
descompusiesen, perderan la semntica a ellos asociada.
Por ejemplo, el dominio de nacionalidades tiene los valores: Espaola, Francesa, Norteamericana, etc. que son todos del mismo tipo y que no son divisibles sin perder su
semntica; as si descompusiramos el valor espaola en las letras E, S, P, etc. se
perdera la semntica, ya que estas letras consideradas aisladamente han dejado de tener
el significado que tiene espaola como valor de la nacionalidad.
Todo dominio ha de tener un nombre, por el cual nos podemos referir a l y un tipo
de dato; as, el tipo de dato del dominio de nacionalidades es una tira de caracteres de
longitud de diez.
Tambin se le puede asociar una unidad de medida, como metros, kilos, etc., y ciertas
restricciones.
Los dominios pueden definirse por intensin o por extensin. Por ejemplo, el dominio
de las edades de las personas activas se puede definir por intensin como entero de
longitud dos comprendido entre 18 y 65, mientras que la definicin del dominio de
nacionalidades por intensin sera muy pobre semnticamente, ya que permitira toda
combinacin de 10 letras aun cuando no constituyesen un nombre vlido de nacionalidad; por ello, sera preferible definir este dominio por extensin con los nombres de las
distintas nacionalidades que admitisemos en nuestra base de datos.
Se podra pensar que un dominio es igual que una relacin de grado 1 (con un nico
atributo).
Sin embargo, esto no es cierto, ya que el dominio contiene todos los posibles valores que
puede tomar un atributo y es esttico (estos valores no varan en el transcurso del tiempo), en cambio la relacin es dinmica por su misma naturaleza; adems de los dominios
desempean un papel importante y caracterstico en ciertas operaciones.
Un atributo A es el papel que tienen un determinado dominio D en una relacin; se dice
que D es el dominio de A y se denota como dom(A).
As, el atributo Nacionalidad de la tabla "autor", definido sobre el dominio Nacionalidades nos indica que dicho dominio tiene el papel de nacionalidad del autor en la referida
tabla.
El universo del discurso de una base de datos relacional representado por U, est compuesto por un conjunto finito y no vaco de atributos, A1, A2, , An, estructurados en
relaciones; cada atributo toma sus valores de un nico dominio (dominio subyacente) y
varios atributos pueden tener el mismo dominio subyacente.
Es muy usual dar el mismo nombre al atributo y al dominio subyacente. En el caso de
que sean varios los atributos de una misma tabla definidos sobre el mismo dominio,
habr que darles nombres distintos, ya que una tabla no puede tener dos atributos con
el mismo nombre.
Adems de los dominios y atributos simples, que acabamos de definir, en los trabajos
posteriores de algunos autores, CODD (1990), DATE (1990), se introduce el concepto
de dominio compuesto.
Bibliografa
143
ollo
nidos
144
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Un dominio compuesto se puede definir como una combinacin de dominios simples a la que se puede aplicar ciertas restricciones de integridad.
Por ejemplo, un usuario puede necesitar manejar, adems de los (tres) dominios
Da, Mes, Ao, un dominio compuesto por ellos denominado Fecha, al que podramos aplicar las adecuadas restricciones de integridad a fin de que no aparecieran
valores no vlidos para la fecha. Algo anlogo ocurre con el nombre y los apellidos,
que segn las aplicaciones, puede ser conveniente tratarlos en conjunto o por separado.
Al igual que es posible definir dominios compuestos, existen tambin atributos
compuestos. As, el atributo Fecha tomara sus valores del dominio compuesto de
igual nombre.
Tanto los atributos compuestos como los dominios compuestos pueden ser tratados, cuando lo precisa el usuario, como piezas nicas de informacin, es decir,
como valores atmicos.
Diagrama
Desarrollo
de contenidos
Objetivos
Actividades
Inicio
TAREA ACADMICA N. 2
Autoevaluacin
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Bibliografa
Diagrama
Objetivos
Inicio
Desarrollo
contenidos
Actividades
Autoevaluacin
Lecturas
eccionadas
Glosario
cordatorio
Objetivos
ctividades
Glosario
notaciones
Desarrollo
de contenidos
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
GLOSARIO DE LA UNIDAD IV
Bibliografa
Estereotipo. Identificador de una clase. Puede tener o no cono y permite distinguir

que tipo de objeto del software se est modelando.
Multiplicidad. Es la cantidad de ocurrencias de un objeto con respecto a otro, similar a
la cardinalidad en una base de datos.
Anotaciones
Realizacin de Casos de Uso. Es el caso de uso que garantiza que un caso de uso del
requerimiento ser realizado en el modelamiento del software o ser postergado para
otra versin.
Swimlane. Tambin llamado carril, permite agrupar las actividades segn el actor o la
clase que lo realiza.
Inicio
Autoevaluacin
Bibliografa
BIBLIOGRAFA DE LA UNIDAD IV
Kendall, Kenneth & Kendall, Julie. (2005). Anlisis y diseo de sistemas. Mxico D.F.:
Editorial Prentice Hall. Biblioteca UC: 004.2 / K41.
Piattini, Mario., Marcos, Esperanza., Calero, Coral. (2007).Tecnologa y diseo de base de
datos. Mxico: Editorial Alfaomega / RaMa. Biblioteca UC: 005.74 / P52 / 2007.
Romero Moreno, Gesvin.(2004). UML con Rational Rose. Per: Editorial Megabyte.
Bibliografa
145
ollo
nidos
146
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
AUTOEVALUACIN DE LA UNIDAD IV
INSTRUCCIONES. Lea cuidadosamente cada uno de los tems o preguntas y

marque la respuesta correcta.
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
Bibliografa
1. En el diagrama de clases, el estereotipo de clase que representa el protocolo de

comunicacin entre el usuario y el software, corresponde a:
a)
Entity
b) Object
c) Control
d) Class
e) Boundary
2. En el diagrama de clases, el estereotipo de clase que ejecuta las acciones ingresadas por un formulario hacia una tabla, corresponde a:
a) Class
b) Control
c) Entity
d) Boundary
e) Object
3. El concepto de encapsulamiento es el resguardo de los atributos y responsabilidades de una clase con respecto a otra, es decir la visibilidad o acceso, por lo que
la visibilidad que permite que slo la clase y alguna otra clase autorizada tenga
el referido acceso, corresponde a:
a) Protegida
b) Dependencia
c)
Pblica
d) Asociacin
e) Privada
4. En el diagrama de secuencia, el tipo de mensaje que no permite que se enve
otros mensajes hasta no tener un mensaje de retorno, corresponde a:
a) Mensaje asncrono
b) Mensaje de retorno
c) Mensaje sncrono
d) Mensaje recursivo
e) Mensaje simple
5.
En el diagrama de secuencia, el elemento que permite agrupar un conjunto de
mensajes correspondiente a una operacin, corresponde a:
a)
Lnea de vida
b)
Foco de control
c) Mensaje sncrono
d) Objeto emisor
e)
Mensaje de retorno
6. En el diagrama de estados, la transicin tiene elementos encargados de ejecutar
el pase de un estado a otro de un clase:
a) Evento
b) Estado de inicio
c) Condicin
Desarrollo
de contenidos
d)
Estado final
INGENIERA
DE SOFTWARE
Lecturas
seleccionadas
Glosario
Recordatorio
Anotaciones
e) Accin
7.
Es un diagrama de UML que modela la dependencia de un archivo o librera
con respecto a otro, y que el software lo requiere para su ejecucin:
a)
Diagrama de despliegue
b) Diagrama de subsistemas
c) Diagrama de componentes
d) Diagrama de actividades
e) Diagrama de secuencia
8.
Es un diagrama de UML que modela los equipos y sus respectivas conexiones
que el software requiere para su ejecucin:
a) Diagrama de Secuencia
b) Diagrama de Despliegue
c) Diagrama de Subsistemas
d) Diagrama de Actividades
e) Diagrama de Componentes
9. En el diagrama de despliegue, es un elemento que representa el equipo que
permite la ejecucin de las transacciones, requeridos por el software:
a) Dispositivo
b) Componente
c) Boundary
d) Estado
e) Procesador
10. Del Diagrama Clases finalizado, con las clases de estereotipo Entity se obtendr
el Modelo de Datos, segn el gestor de base de datos definido, debido a que se
le considerar:

a) Clase Persistente
b) Clase Control
c) Clase Entity

d) Clase Asociacin
e) Clase Boundary
Bibliografa
147
ollo
nidos
148
Actividades
Autoevaluacin
as
nadas
Glosario
Bibliografa
torio
Anotaciones
ANEXO
Diagrama
Objetivos
Inicio
Desarrollo
de contenidos
Actividades
Autoevaluacin
ANEXO: CLAVES DE AUTOEVALUACIONES

AUTOEVALUACIN DE LA UNIDAD II
AUTOEVALUACIN DE LA UNIDAD I
Lecturas
seleccionadas
Recordatorio
Glosario
Anotaciones
Bibliografa
N.
Rpta.
N.
Rpta.
1
2
3
4
5
6
7
8
9
10
b
c
d
b
a
d
e
b
d
a
1
2
3
4
5
6
7
8
9
10
c
b
d
d
c
a
b
d
b
c
AUTOEVALUACIN DE LA UNIDAD III
AUTOEVALUACIN DE LA UNIDAD IV
N.
Rpta.
N.
Rpta.
1
2
3
4
5
6
7
8
9
10
e
c
a
c
b
d
c
b
b
d
1
2
3
4
5
6
7
8
9
10
e
b
a
c
b
e
c
b
e
a

A0248 Ingeniería de Software MAU01

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

A0248 Ingeniería de Software MAU01

Загружено:

Авторское право:

Доступные форматы

INGENIERA

Carol Roxana Rojas Moreno

Cada autor es responsable del contenido de su propio texto.

Todos los derechos reservados.

TIEMPO MNIMO DE ESTUDIO

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

Diagrama de presentacin de la unidad I

ORGANIZACIN DE LOS APRENDIZAJES

Tema N. 1: El Software y la Ingeniera de Software

Definiciones de la ingeniera de software

Tema N. 2: Ciclo de Vida del Software

Ciclo de vida del software

Modelos de construccin de software

Tema N. 3: Gestin de Proyectos de Software

Componentes de la gestin de proyectos de software

Planificacin de proyectos de software

Estudio de factibilidad de proyectos

Tema N. 4: Mtricas en el Software

Factores de calidad de MacCall

Mtricas de la calidad del software

UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWARE

DIAGRAMA DE PRESENTACIN DE LA UNIDAD ii

ORGANIZACIN DE LOS APRENDIZAJES

TEMA N. 1: Enfoques de Desarrollo de Software

Enfoque orientado a objetos

TEMA N. 2: Metodologas de Desarrollo de Software

TEMA N. 3: Lenguaje de Modelamiento Unificado (UML)

Diagramas de estructura y comportamiento

TEMA N. 4: Rational Unified Process (RUP-Proceso Unificado)

Fases y flujos de trabajo

UNIDAD III: RUP Y UML NEGOCIO Y REQUERIMIENTOS

Diagrama de Presentacin de la Unidad III

ORGANIZACIN DE LOS APRENDIZAJES

Tema N. 1: Flujo de Trabajo de RUP: Modelado del Negocio

Evaluacin del negocio

Pictogrfico situacional y pictogrfico solucionador

Reglas del negocio

Tema N. 2: Flujo de Trabajo de RUP: Modelado de Requerimientos

Estimacin del proyecto

Diagrama UML: Diagrama de casos de uso de requerimientos, plantillas, diagrama de actividades

Autoevaluacin DE LA UNIDAD IiI

UNIDAD IV: RUP Y UML ANLISIS, DISEO E IMPLEMENTACIN

Diagrama de Presentacin de la Unidad Iv

ORGANIZACIN DE LOS APRENDIZAJES

Tema N. 1: Flujo de Trabajo de RUP: Modelado de Anlisis

Diagrama UML: Diagrama de clases y estereotipos de clase

Diagrama UML: Diagrama de secuencia, diagrama de colaboracin

Tema N. 2: Flujo de Trabajo de RUP: Modelado de Diseo

Diagrama UML: Subsistemas e interfaces, modelo arquitectnico

Diagrama UML: Diagrama de estados

Tema N. 3: Flujo de Trabajo de RUP: Modelado de Implementacin

Diagrama UML: Diagrama de componentes

Diagrama UML: Diagrama de despliegue

Tema N. 4: Transformacin al Modelo de Datos

Generacin del modelo de datos

ANEXO: claves de las Autoevaluaciones

a presente asignatura se desarrolla en

revisan conceptos y caractersticas de enfoques y

RUP y UML negocio

TIEMPO MNIMO DE ESTUDIO

DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

ORGANIZACIN DE LOS APRENDIZAJES

Tema N. 1: El software y la 1. I dentifica y analizar los

Planificacin de proyectos de software

Estudio de factibilidad de proyectos

Mtricas de la calidad del software

Diagrama UML: Diagrama de casos de uso de requerimientos, plantillas, diagrama de actividades

Diagrama UML: Diagrama de estados

Tema N. 1: El software y la 1. I dentifica y analizar los

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

c. Software de gestin: Ayudan a la organizacin y acceden a una o ms bases de

e. Software empotrado. Tambin conocido como embebido, reside en memoria

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

c. Modelo DRA (Desarrollo Rpido de Aplicacin). Es un modelo de proceso del

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

2 Planificacin de Proyectos de software

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

3 Estudio de Factibilidad de Proyectos

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE

2 Mtricas de Calidad del Software