Ingeniería de Software

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 7
PRESENTACIN DE LA ASIGNATURA 9
COMPETENCIA DE LA ASIGNATURA 9
UNIDADES DIDCTICAS 9
TIEMPO MNIMO DE ESTUDIO 9
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

1 Definiciones de la ingeniera de software 12
2 Productos de software 12
3 Aplicaciones de software
13
Tema N. 2: Ciclo de Vida del Software 17

1 Ciclo de vida del software 17
2 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

1 Componentes de la gestin de proyectos de software 23
2 Planificacin de proyectos de software 23
3 Estudio de factibilidad de proyectos 24
Tema N. 4: Mtricas en el Software 28

1 Factores de calidad de MacCall 28
2 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

TEMA N. 1: Enfoques de Desarrollo de Software 42
1 Enfoque estructurado 42
2 Enfoque orientado a objetos 43
TEMA N. 2: Metodologas de Desarrollo de Software 45

1 Metodologa tradicional 45
2 Metodologas giles 46
3 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
1 Conceptos de UML 50
2 Diagramas de estructura y comportamiento 50
TEMA N. 4: Rational Unified Process (RUP-Proceso Unificado) 61

1 Caractersticas 61
2 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 76
BIBLIOGRAFA DE LA UNIDAD II 76
Autoevaluacin DE LA UNIDAD Ii 77
UNIDAD III: RUP Y UML NEGOCIO Y REQUERIMIENTOS 79

Diagrama de Presentacin de la Unidad III 79
Tema N. 1: Flujo de Trabajo de RUP: Modelado del Negocio 80

1 Evaluacin del negocio 81
2 Pictogrfico situacional y pictogrfico solucionador 81
3 Reglas del negocio 82
4 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

1 Estimacin del proyecto 94
2 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 105
Glosario de la unidad III 106
BIBLIOGRAFA DE LA UNIDAD III 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
Tema N. 1: Flujo de Trabajo de RUP: Modelado de Anlisis 110

1 Diagrama UML: Diagrama de clases y estereotipos de clase 110
2 Diagrama UML: Diagrama de secuencia, diagrama de colaboracin 116
Tema N. 2: Flujo de Trabajo de RUP: Modelado de Diseo 123

1 Diagrama UML: Subsistemas e interfaces, modelo arquitectnico 123
2 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

1 Diagrama UML: Diagrama de componentes 135
2 Diagrama UML: Diagrama de despliegue 137
Tema N. 4: Transformacin al Modelo de Datos 138

1 Clases persistentes 138
2 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 144
Glosario de la unidad IV 145
BIBLIOGRAFA DE LA UNIDAD IV 145
Autoevaluacin DE LA UNIDAD IV 146
ANEXO: claves de las Autoevaluaciones 148
INTRODUCCIN
L
a presente asignatura se desarrolla en revisan conceptos y caractersticas de enfoques y
modalidad virtual y este Manual autoformativo metodologas de desarrollo de software, lenguaje
es un material didctico importante para su de modelado y proceso unificado. Unidad III: RUP
aprendizaje. y UML - Negocio y requerimientos: desarrollando el
La asignatura tiene como finalidad proporcionar al flujo de trabajo de modelado del negocio y modelado
estudiante los conocimientos necesarios acerca de de requerimientos. Unidad IV: RUP y UML Anlisis,
modelos de procesos de un software, as como de diseo e implementacin, desarrollando el flujo de
elementos para la gestin y factores de calidad en trabajo de anlisis y diseo; el flujo de trabajo de
proyectos de software. Veremos al final un caso de implementacin y la transformacin a un modelo de
estudio prctico donde se presenta un modelo de datos.
proceso de desarrollo de software llamado Proceso Es recomendable que el estudiante desarrolle
Unificado y se emplea el Lenguaje de Modelamiento una permanente lectura de estudio, as como
Unificado como representacin, en el desarrollo de la investigacin en otros textos y va internet y
de dicho caso prctico. el desarrollo del modelo de construccin de un
El presente material para la asignatura de Ingeniera software de un caso real de estudio. El contenido
de Software consta de cuatro unidades: Unidad I: del material se complementar con las lecciones por
Fundamentos de ingeniera de software, en el cual se videoclase. Agradecemos a quienes con sus aportes
desarrollan los conceptos de ingeniera de software, y sugerencias han contribuido a mejorar la presente
ciclos de vida del software, gestin de proyectos y edicin, que solo tiene el valor de una introduccin
mtricas en el software. Unidad II: Fundamentos al conocimiento de los conceptos y modelamiento de
para el modelamiento de software, aqu se software.
8
INGENIERA DE SOFTWARE
Desarrollo
de contenidos
Actividades Autoevaluacin
MANUAL AUTOFORMATIVO
9
Lecturas Glosario Bibliografa

seleccionadas
PRESENTACIN DE LA ASIGNATURA
Recordatorio Anotaciones
Diagrama Objetivos Inicio
COMPETENCIA DE LA ASIGNATURA
Desarrolla un modelamiento de software, compara los modelos de proceso de

construccinActividades
Desarrollo de softwareAutoevaluacin
y diferencia su uso aplicando los conceptos para la gestin
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
Lecturas crtica Bibliografa
Glosario para determinar el uso de alguna de ellas y modelar
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.
UNIDADES DIDCTICAS
UNIDAD I UNIDAD II UNIDAD III UNIDAD IV
Fundamentos Fundamentos para RUP y UML negocio RUP y UML

de ingeniera de el modelamiento de y requerimientos anlisis, diseo e
software software implementacin
TIEMPO MNIMO DE ESTUDIO

UNIDAD I UNIDAD II UNIDAD III UNIDAD IV
1. y 2. semana
a a
3. y 3. semana
a a
4. y 5. semana
a a
6. y 7.a semana
a
16 horas 16 horas 16 horas 16 horas

10
Desarrollo
de contenidos
11
Diagrama Objetivos Inicio Lecturas Glosario Bibliografa

seleccionadas
Desarrollo
UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE
de contenidos
DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

Diagrama
Lecturas Objetivos
Glosario Inicio
Bibliografa
seleccionadas
LECTURAS
CONTENIDOS ACTIVIDADES
SELECCIONADAS
Desarrollo Actividades Autoevaluacin
de contenidos
AUTOEVALUACIN BIBLIOGRAFA
seleccionadas
ORGANIZACIN DE LOS APRENDIZAJES

CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES

Tema N. 1: El software y la 1. I dentifica y analizar los 1. Asume con respon-
DesarrolloActividades Autoevaluacin
ingeniera de software
de contenidos modelos de construccin sabilidad sus activi-
1. Definiciones de la de software. dades acadmicas
ingeniera de software. 2. E
jemplifica las aplicacio- asignadas.
2. Productos de software. nes de software. 2. Realiza con honesti-
seleccionadas
3. R
ecopila informacin de dad las evaluaciones
3. Aplicaciones de software.
situacin organizacional asignadas.
Tema N. 2: Ciclo de vida del para el modelamiento de
software software, como proyecto
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 ges-
Lectura seleccionada N. 1 tin de software.
Modelos del proceso del 5. E labora el cronograma
software. Ingeniera del sof- del proyecto de software
tware: Un enfoque prctico. en equipo.
Pressman, Roger. Pg. 19. 6. E labora el estudio de
Tema N. 3: Gestin de pro- factibilidad econmica
yectos de software del proyecto 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 compa-
3. Estudio de factibilidad de rativo de los modelos de
proyectos. Software: Definicin, fases,
representacin, ventajas y
Tema N. 4: Mtricas en el sof-
desventajas.
tware
1.
Factores de calidad de
MacCall. Control de Lectura N. 1
Mtricas de la calidad del Cuestionario de los Temas
2.
software. N.1, 2, 3 y 4, adems de
las actividades asignadas y
Lectura Seleccionada N. 2
autoevaluaciones.
Qu son los costos de la inge-
niera del software? Ingeniera
del Software. Sommerville,
Ian. Pg. 9.
Autoevaluacin de la
unidad I
ollo
nidos 12
Actividades Autoevaluacin UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWARE
as Glosario Bibliografa
nadas
TEMA N. 1: EL SOFTWARE Y LA INGENIERA DE SOFTWARE
Se ha preguntado cuales han sido los procesos o tareas que permitieron la crea-
torio Anotaciones
cin 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 estandariza-
das que concluyen con el producto final: software.
1 Definiciones de la Ingeniera de Software

De acuerdo a diferentes autores (Pressman, Roger & Sommerville, Ian) la Ingenie-
ra 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 tc-

nicamente 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 herra-

mientas, facilita un desarrollo racional y oportuno del software de computado-
ras. 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 re-
solver 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 esti-
mado.
El Software
Se entiende por software al programa de cmputo desarrollado y su documenta-
cin asociada. Es decir, el software es un conjunto de instrucciones escritas en una
herramienta de desarrollo, la cual ser interpretada por la computadora de acuer-
do 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)
UNIDAD I: FUNDAMENTOS DE INGENIERA DE SOFTWAREDesarrollo
de contenidos
13

seleccionadas
para ser vendidos al mercado. Un ejemplo vemos en la Figura 1.
Ejemplo: sistemas gestores de bases de datos, procesadores de texto, paquetes gr-
ficos, etc.
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 especificacio-
nes), 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 perif-
ricos, etc., mostrados en la Figura 3.
ollo
nidos 14
nadas
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, conside-
re 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.
de contenidos
15

seleccionadas
Figura 5. Ejemplo de software de gestin

Fuente: https://elmundodelarenta.wordpress.com/2013/05/24/caracteristicas-de-un-software-de-ges-
tion-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 recono-
cimiento 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.
ollo
nidos 16
nadas
torio Anotaciones
Figura 7. Ejemplo de software empotrado

Fuente: http://m.eltiempo.com/tecnosfera/novedades-tecnologia/el-internet-de-las-cosas-las-maquinas-
conquistan-la-red/14010188/1
f. Software de computadores personales. Son de uso habitual. Ejemplo: proce-

samiento 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-nueva-
compania-de-software-basado-en-web-de-emc-y-vmware
de contenidos
17

seleccionadas
h. Software de Inteligencia Artificial. Sistemas expertos, reconocimiento de patro-
nes (imgenes y audios), etc. En la Figura 10 se muestra un ejemplo de un siste-
ma 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 permitie-
ron 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 con-
junto 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).
ollo
nidos 18
nadas
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 gene-

rales 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.
de contenidos
19

seleccionadas
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 ex-
tremadamente 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
ollo
nidos 20
nadas
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.
torio Anotaciones
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 acuer-

do a varios aspectos: la naturaleza del proyecto y de la aplicacin, los mtodos, las
herramientas a usar, los controles y las entregas requeridas.
de contenidos
21

de contenidos Lecturas Glosario Bibliografa
seleccionadas
seleccionadas
MODELOS DEL PROCESO DEL SOFTWARE

Pressman,
Recordatorio Roger. Ingeniera del Software: Un enfoque prctico (quinta edicin).
Anotaciones
Pg. 19
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 sof-
tware : 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, pro-
gramas, datos, nueva funcin comercial, nuevo producto) a los que solicitan la so-
lucin 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 independen-
cia 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 na-
turaleza 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 desa-
rrollador del software.
En las secciones siguientes, se tratan diferentes modelos de proceso para la inge-
niera del software. Cada una representa un intento de ordenar una actividad inhe-
rentemente catica.
Es importante recordar que cada uno de los modelos se ha caracterizado de ma-
nera que ayude (con esperanza) al control y a la coordinacin de un proyecto de
software real.
ollo
nidos 22
nadas
Y a pesar de eso, en el fondo, todos los modelos exhiben caractersticas del Modelo
de caos.
torio Anotaciones
Figura 17. Fases de un bucle de resolucin de problemas

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

ACTIVIDAD N. 1
de contenidos
Esta actividad puede consultarla en su Aula virtual.

seleccionadas
de contenidos
23

seleccionadas
TEMA N. 3: GESTIN DE PROYECTOS DE SOFTWARE

Cuando requiere de la creacin de un producto o servicio, usted piensa inmedia-
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 finali-
dad de crear un producto o servicio nico. (Gua PMBOK , quinta edicin. 2013).
La gestin de proyectos es la aplicacin de los conocimientos, habilidades, herra-
mientas 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).

ollo
nidos 24
nadas
3 Estudio de Factibilidad de Proyectos
3.1 Factibilidad econmica

torio Anotaciones
Determinamos el flujo de caja de acuerdo a los costos y beneficios.
Desarrollemos un ejemplo:
A. Fijemos los costos

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

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

Hardware + Software = 548.20 + 195= 743.20
Calculemos costos de suministros

Materiales Cantidad Costo ($)
Papel A4 80 gr (millar) 2 20.00
Papel Borrador (millar) 1 15.00
CD (caja) 1 5.00
Cartucho de Tinta 2 20.00
TOTAL ($) 55.00
Calculemos costos de instalacin

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

Tarea Costo ($)
Internet 30.00
Fotocopiado 25.00
Movilidad 50.00
TOTAL ($) 105.00
de contenidos
25

seleccionadas
Calculemos costos de mantenimiento
Tarea Ao 0 Ao 1 Ao 2 Ao 3 Ao 4 Ao 5
Mantenimiento 0.00 600.00 600.00 600.00 600.00 600.00
Software Recordatorio Anotaciones
B. Determinemos los beneficios
Beneficios tangibles
Calculemos los beneficios de reduccin de pago de horas extras de trabajo
Personal Horas /Mes Costo/Mes ($) Costo ($)
Contador 5 10.00 50.00
Administrador 4 20.00 80.00
Gerente de ventas 3 25.00 75.00
Gerente general 2 30.00 60.00
TOTAL ($) 265.00
TOTAL AO ($) 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 0 1 2 3 4 5
Costos
a. Personal 3600.00
b. Tecnologa 743.20
c. Suministros 55.00
d. Instalacin 400.00
e. Varios 105.00
f. Mantenimiento 600.00 600.00 600.00 600.00 600.00
Total de costos 4903.20 600.00 600.00 600.00 600.00 600.00
Beneficios 0.00 3438.00 3438.00 3438.00 3438.00 3438.00
a. Reduccin de 0.00 258.00 258.00 258.00 258.00 258.00
pago horas extras.
b. Reduccin de
costos materiales.
Total de beneficios 0.00 3696.00 3696.00 3696.00 3696.00 3696.00
Flujo de Caja (4903.20) 3096.00 3096.00 3096.00 3096.00 3096.00
econmico
Los datos obtenidos en la tabla 1 ayudan al anlisis de rentabilidad del proyecto

para determinar su aceptacin.
ollo
nidos 26
nadas
De acuerdo a los datos del flujo de caja econmico se obtuvo el anlisis de renta-
bilidad del proyecto reflejados, segn Sapag y Sapag (Preparacin y evaluacin de
proyectos, 2008):
torio Anotaciones
- 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.
n
VPC = I+E (1+i) -1
i(1 + i)n
n
VPB = Y (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 varia-
bles, 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

de contenidos
27

seleccionadas
Adems, para determinar la aceptacin del proyecto, se deben considerar las
siguientes restricciones:
B/C > 1 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.
ollo
nidos 28
nadas
TEMA N. 4: MTRICAS EN EL SOFTWARE

En ms de una ocasin, usted ha sido requerido en una encuesta para evaluar, es
torio Anotaciones
decir, medir el servicio de un terminal de venta o de atencin del cliente, conside-
rando 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 objeti-

vos 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 en-
trada 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 cumplimien-
to de los estndares.
Exactitud. La exactitud de los clculos y del control.
Estandarizacin de comunicaciones. El grado de empleo de estndares de interfa-
ces, protocolos y anchos de banda.
de contenidos
29

seleccionadas
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 res-

pecto 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
ollo
nidos 30
nadas
2 Mtricas de Calidad del Software

Las Mtricas del software estn relacionadas con el desarrollo del software como
torio Anotaciones
funcionalidad, complejidad, eficiencia. (Pressman, Roger, 2002)
Mtricas tcnicas. Se centran en las caractersticas de software por ejemplo: la com-

plejidad 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 ingenie-

ra 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 pro-
ceso 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:
LDC Pginas
PRODUCTIVIDAD = DOCUMENTACION =
Personal * Meses LDC
LDC NuevosSoles
CALIDAD = COSTO =
Errores LDC
Desarrollemos un ejemplo de clculo de estos indicadores, dada la informacin de

un proyecto de software:
Proyecto Costo LDC (lneas Pginas Docu- Errores Cant. De

de cdigo) mentacin detectados Personal
A 168,000 13,000 365 30 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
de contenidos
31

seleccionadas
B. Orientadas a la funcin
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 Anotaciones
- N
mero de Entradas Externas (EE). Originada en un usuario o desde otra apli-
cacin. Pueden ser pantallas, formularios, cuadros de dilogo, controles o men-
sajes, 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/
1-5 tems de datos 6-9 tems de datos 20 o ms tems de datos

0 o 1 fichero Simple (4) Simple (4) Medio (5)
2 o 3 ficheros Simple (4) Medio (5) Complejo (7)
4 o ms ficheros Medio (5) Complejo (7) Complejo (7)
- N
mero de Salidas Externas (SE). Se deriva del interior de la aplicacin y pro-
porciona informacin al usuario. Pueden ser pantallas, informes, grficos o
mensajes que el programa genera para el usuario final o cualquier otro progra-
ma. 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/
1-4 tems de datos 5-15 tems de datos 16 o ms tems de datos

2 ficheros Simple (3) Medio (4) Complejo (6)
- N
mero de Consultas Externas (CE). Combinaciones de entrada/salida, cada
entrada genera una salida simple e inmediata. Generalmente las consultas recu-
peran 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 1-5 tems de datos 6-19 tems de datos 20 o ms tems de datos
2 O 3 ficheros Simple (4) Medio (5) Complejo (7)
Tabla 5. Ejemplo de Nmero de Consultas Internas

Parte Entrada 1-5 tems de datos 5-15 tems de datos 16 o ms tems de datos
2 ficheros Simple (3) Medio (4) Complejo (6)
ollo
nidos 32
nadas
- 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
torio Anotaciones en una base de datos relacional.
Tabla N 6 Ejemplo de Nmero Archivos Lgicos Internos

1-19 tems de datos 20-50 tems de 51 o ms tems de datos

datos
1 formato/rela- Simple (7) Simple (7) Medio (10)
cin de registro
lgico
2-5 formatos/re- Simple (7) Medio (10) Complejo (15)
laciones de regis-
tro lgico
6 o ms forma- Medio (10) Complejo (15) Complejo (15)
tos/ relaciones de
registro lgico
- N
umero de Archivos de Interfaz Externo (AIE). Agrupamiento lgico de datos
externo a la aplicacin y que podran usarse en la aplicacin. (Archivos contro-
lados por otros programas, con los que el programa va a interactuar.)
Tabla 7. Ejemplo de Nmero de Interfaz Externo

1-19 tems de datos 20-50 tems de 51 o ms tems de datos

datos
1 formato/rela- Simple (5) Simple (5) Medio (7)
cin de registro
lgico
2-5 formatos/re- Simple (5) Medio (7) Complejo (10)
laciones de regis-
tro lgico
6 o ms forma- Medio (7) Complejo (10) Complejo (10)
tos/ relaciones de
registro lgico
Se elabora el cuadro de conteo:
Tabla 8. Ejemplo de cuadro de conteo

Fuente: http://es.slideshare.net/OliverCenteno/mtrica-v3-y-rup
Factor de complejidad
Valor de dominio Cuenta Total
Simple Media Compleja
Nmero de entradas
Nmero de salidas
Nmero de consultas
Nmero de archivos
Nmero de interfaces
Cuenta total
de contenidos
33

seleccionadas
Para luego aplicar los factores de ajuste:
Tabla 9 Ejemplo de Tabla de Factores de Ajuste

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

1. Comunicacin de Datos. Los datos o informacin de control que la aplica-
cin 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 da-
tos) 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 proce-
L
samiento entre los componentes del sistema.
1 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 compo-
L
nente ms apropiado del sistema.
3. Rendimiento. Referido a la importancia de respuesta dentro de todo el sis-
tema.
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.
5 dems se utilizan herramientas de anlisis del rendimiento en el diseo,
A
desarrollo e instalacin.
4. Configuracin utilizada masivamente. Referente a la importancia del entor-
no. 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 apli-
R
cacin en el procesador central.
5 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.
4 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
4 Se incluyen tareas de diseo para la consideracin de factores humanos
5 dems se utilizan herramientas especiales o de prototipado para pro-
A
mover la eficiencia.
ollo
nidos 34
nadas
8. Actualizacin online.
0 Nada
1-2 A
ctualizacin online de los ficheros de control. El volumen de actualiza-
torio Anotaciones
cin es bajo y la recuperacin fcil.
3 Actualizacin online de la mayora de los ficheros internos lgicos
4 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
1 Se aplica alguna cosa
2 Se aplican dos cosas
3 Se aplican tres cosas
4 Se aplican cuatro cosas
5 Se aplica todo.
10. Utilizable en otras aplicaciones. El cdigo se disea para que sea comparti-
do 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 ins-
talacin.
12. Facilidad de operacin.
0 N
o se especifican por parte del usuario consideraciones especficas de ope-
racin.
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 aplica-
cin en varios lugares.
de contenidos
35

seleccionadas
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. Recordatorio Anotaciones
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)]

ollo
nidos 36
Actividades Autoevaluacin UNIDAD I:Objetivos
Diagrama
FUNDAMENTOS
Inicio
DE INGENIERA DE SOFTWARE

as Glosario Bibliografa de contenidos
nadas
seleccionadas
torio Anotaciones
QU SON LOS COSTOS DE LA INGENIERA DEL SOFTWARE?

Sommerville, Ian. Ingeniera del Software. Pg. 9
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 distri-
bucin 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 espe-
cificacin 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 lle-
van 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 imple-
mentacin inicial est completa.
La ingeniera del software basada en componentes solo ha sido ampliamente uti-
lizada 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 por-
que 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 drstica-
mente 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 es-
timar. 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 com-
patible) 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
de contenidos
37

seleccionadas
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 100
Especificacin Diseo Desarrollo Integracin y pruebas
Desarrollo iterativo
0 25 50 75 100
Especificacin Desarrollo Integracin y pruebas
Costos de desarrollo y evolucin para software de larga vida.

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

de la ingeniera del software

de contenidos
CONTROL DE LECTURA N. 1
seleccionadas
ollo
nidos 38
Actividades Autoevaluacin Diagrama
UNIDAD I: Inicio
Objetivos
FUNDAMENTOS DE INGENIERA DE SOFTWARE

nadas
GLOSARIO DE LA UNIDAD I
seleccionadas
torio Anotaciones
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 instruc-
cin en la codificacin de software
Paradigma. Modelo que incluye conceptos, procedimientos y tcnicas para desarro-
llar un software.
PMI. Project Management Institute, organizacin internacional que certifica en ges-
tin 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.

de contenidos

BIBLIOGRAFA DE LA UNIDAD I
seleccionadas
Pressman, Roger.(2005). Ingeniera del software: un enfoque prctico (quinta edi-

cin). Espaa: Editorial McGraw-Hill. Biblioteca UC: 005.1 / P85 2009.
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.
de contenidos
39
Objetivos Inicio Lecturas Glosario Bibliografa

seleccionadas
AUTOEVALUACIN DE LA UNIDAD I
s
1. La aplicacin web de matrculas de un colegio, es un ejemplo de:

a) Producto genrico y software de sistemas
s
Glosario

Bibliografa
b) Producto hecho a medida y software de gestin
c) Producto hecho a medida y software de computadores personales
d) Producto genrico y software empotrado
o Anotaciones
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:
a) Flexibilidad
ollo
nidos 40
nadas
b) Facilidad de Mantenimiento
c) Fiabilidad
d) Eficiencia
torio 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
41

seleccionadas
UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE

SOFTWARE
de contenidos
Lecturas
seleccionadas DIAGRAMA DE PRESENTACIN DE LA UNIDAD II
Glosario Bibliografa
LECTURAS
Recordatorio
Desarrollo
de contenidos
Anotaciones
Actividades Autoevaluacin SELECCIONADAS
Lecturas Glosario
AUTOEVALUACIN
Bibliografa
BIBLIOGRAFA
seleccionadas
Recordatorio ORGANIZACIN DE LOS APRENDIZAJES

Anotaciones

Tema N. 1: Enfoques de 1.
Identifica y explica las 1.
Asume con responsa-
Desarrollo
desarrollo de software
de contenidos tcnicas y fundamentos bilidad sus actividades
1. Enfoque estructurado. del enfoque estructurado acadmicas asignadas.
y el enfoque orientado a 2. Realiza con honestidad
2. Enfoque orientado a objetos.
objetos.Glosario
Lecturas Bibliografa
las evaluaciones asigna-
seleccionadas 2. Identifica y relaciona la das.
Tema N. 2: Metodologas aplicacin de las metodo-
de desarrollo de software logas de software, segn
1. Metodologa tradicional. el tipo de situacin orga-
Recordatorio
Anotaciones
2. Metodologas giles. nizacional.
3. Metodologas web 3. Define el tipo de enfoque
y la metodologa a usar en
Lectura seleccionada N. 1
el proyecto de software en
Cinco tendencias de meto- equipo.
dologas giles para 2014.
4. Identifica, analiza y expli-
PMO 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/metodolo-
proyecto de software en
gias-agiles-tendencias-2014.
equipo.
html
5. Elabora el cronograma
Tema N. 3: Lenguaje de mo-
del proyecto de software
delamiento unificado (UML)
en equipo.
1. Conceptos de UML.
6. Elabora el informe preli-
2. Diagramas de estructura y minar del proyecto de sof-
comportamiento. tware en equipo.
Tema N. 4: Rational unified
process (RUP - Proceso Uni-
Actividad N. 2
ficado)
Elabora un cuadro compara-
1. Caractersticas.
tivo de las metodologas de
2. Fases y Flujos de Trabajo. desarrollo de software.
Lectura Seleccionada N. 2
El proceso unificado es ite- Tarea acadmica N. 1
rativo e incremental. El pro-
Investigacin y presentacin
ceso unificado de desarrollo
de los conceptos principales
de software. Jacobson, Ivar.
de los enfoques de desarro-
Pg. 6.
llo de software.
Autoevaluacin de la
unidad II
ollo
nidos 42
Actividades Autoevaluacin UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWARE
nadas
TEMA N. 1: ENFOQUES DE DESARROLLO DE SOFTWARE

Si recuerda su forma de resolver asuntos cotidianos cuando son de cierta compleji-
dad, seguramente recurre a descomponer su problema de tal forma que lo simplifi-
torio Anotaciones
ca 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, cu-
ya 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 responsabi-
lidad. 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).
UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWAREDesarrollo
de contenidos
43

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 Anotaciones
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

ollo
nidos 44
nadas
Algunos conceptos principales de este enfoque
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
torio Anotaciones 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 for-
mada 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 for-
mado 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 exis-
tiese, la Factura deja detener el comportamiento o valor para lo que fue creado.
Figura 27. Ejemplo de composicin entre clases

de contenidos
45

seleccionadas
TEMA N. 2: METODOLOGAS DE DESARROLLO DE SOFTWARE

Previamente, se ha revisado los enfoques de desarrollo de software pero adems,
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 pro-
yecto pero no cmo hacerlo.
1 Metodologa Tradicional
A partir del detalle del producto que se quiere elaborar (anlisis funcional/tc-
nico, 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
ollo
nidos 46
nadas
2 Metodologas giles
Se entiende como Desarrollo gil de software a un paradigma de Desarrollo de
torio Anotaciones
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 ite-
raciones 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 im-
portantes 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
de contenidos
47

seleccionadas
como de grficas, para mantenerse atractivos a los usuarios, es decir, requieren
un gran esfuerzo en mantenimiento.
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/
ollo
nidos 48
nadas Desarrollo Actividades Autoevaluacin
de contenidos
torio Anotaciones
seleccionadas
CINCO TENDENCIAS DE METODOLOGAS GILES PARA 2014

PMOinformtica. Recuperado de http://www.pmoinformatica.com/2013/12/
metodologias-agiles-tendencias-2014.html
Se acerca el fin del ao 2013 y todos nos preguntamos qu curso tomar la aplica-
cin 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 predic-
ciones 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 Develop-
ment) 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 organi-
zacin.
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, satisfac-
cin 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, incluyen-
do 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 ne-
gocio, 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)

de contenidos
49

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 Anotaciones
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

O
rganizaciones de desarrollo, como por ejemplo desarrollo de nuevos pro-
ductos, 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, seguri-
dad, mbito financiero, industrias altamente reguladas por gobiernos, etc.
ACTIVIDAD N. 2
de contenidos Esta actividad puede consultarla en su Aula virtual.

seleccionadas
ollo
nidos 50
nadas
TEMA N. 3: L ENGUAJE DE MODELAMIENTO UNIFICADO (UML)

Qu entendemos por modelo? Seguro ya tiene una respuesta a la pregunta, pues
torio Anotaciones
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.
1 Conceptos de UML
Unified Modeling Language (UML), es una notacin (lenguaje) que representa grfi-
camente construcciones del modelo de objetos, para el desarrollo de un software.
(Arlow, Jim & Neustadt, Ila, 2005)
2 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
Estructurales De agrupacin De anotacin
comportamiento
Clase, Interfaz, Verbos de un Paquete: Agrupa Nota: Se anexa al
Colaboracin, modelo como elementos del modelo para dar
Caso de Uso, Clase interacciones, acti- modelo informacin al
Activa, vidades, mquinas semnticamente modelo.
Componente, de estados. relacionados.
nodo.
- Relaciones: Le permitirn mostrar como dos o ms elementos se relacionan

(significativamente) entre s.
Observemos algunos ejemplos:
Tipo de relacin Semntica

Dependencia Origen depende y es afectado por Destino
Asociacin Vnculos entre elementos
Agregacin Destino es parte de Origen
Composicin Similar a agregacin, pero ms restringida
Contencin Origen contiene a Destino
Generalizacin 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.
de contenidos
51

seleccionadas
La fig. 31 muestran los diagramas versin base la versin UML 2.0.
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: Especificacio-

nes, Adornos, Divisiones Comunes, Mecanismos de extensin (amplan la semnti-
ca de un elemento, OCL), Estereotipos, Valores Etiquetados.
III. Arquitectura. Estructura organizacional de un sistema, incluida su descompo-
sicin 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

ollo
nidos 52
nadas
- Relaciones en un Diagrama de Casos de Uso. Existen los siguientes tipos de

relaciones en un Diagrama de Casos de Usos:
torio 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.

de contenidos
53

seleccionadas
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

ollo
nidos 54
nadas
- Diagrama de secuencia
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
torio Anotaciones 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

de contenidos
55

seleccionadas
- Diagrama de colaboracin (diagrama de comunicacin)
Es una diagrama que muestra los mensajes y el orden de colaboracin que debe
darse, como en la fig. 38.
Figura 38. Ejemplo de diagrama de colaboracin

ollo
nidos 56
nadas
- Diagrama de estados (diagrama de mquina de estados)
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
torio Anotaciones 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 permi-
te cambiar de un estado a otro), as como si se tiene la misma transicin a diferen-
tes 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.
de contenidos
57

seleccionadas
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 confi-
guracin, de instalacin, ejecutables, tablas, etc).
Figura 41. Ejemplo de diagrama de componentes

ollo
nidos 58
nadas
- Diagrama de despliegue
Modela la topologa de hardware sobre la cual se ejecutar la aplicacin, indicando dnde se
ejecutarn los componentes.
torio 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, ina-
lmbrico), 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 com-
posicin de un conjunto de clases son agrupados en una sola clase para su diagramacin.
de contenidos
59

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 Anotaciones
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.
ollo
nidos 60
nadas
- 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.
torio Anotaciones
Figura 46. Ejemplo de diagrama de vistas de interaccin

Fuente: http://www.sparxsystems.com/resources/
uml2_tutorial/uml2_interactionoverviewdiagram.html
de contenidos
61

seleccionadas
TEMA N. 4: R ATIONAL UNIFIED PROCESS (RUP-PROCESO UNIFICADO)

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 incrementalmen-
te 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. Cons-
truye un prototipo de la arquitectura que se convertir en el sistema final.
III. Construccin. Alcanzar la capacidad operacional del producto de forma incremen-

tal a travs de las sucesivas iteraciones (requisitos deben ser implementados, inte-
grados y probados en su totalidad.
IV. Transicin. Poner el producto en manos de los usuarios finales, (desarrollar nue-
vas versiones actualizadas del producto, completar la documentacin, entrenar al
usuario).
ollo
nidos 62
nadas
2.2. Disciplinas (flujos de trabajo) DE RUP
1. Modelado del negocio

torio Anotaciones
Permite llegar a un mejor entendimiento (la estructura y la dinmica) de la organi-
zacin, 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 Ne-
gocio.
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

de contenidos
63

seleccionadas
Modelo de Objetos del Negocio
Describe como cada elemento del negocio es realizado por los trabajadores del
negocio, durante el proceso Recordatorio Anotaciones
- 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).
ollo
nidos 64
nadas
Modelo del dominio (Diagrama de Clases)

Un modelo del dominio captura los tipos ms importantes de objetos en el contexto del
torio Anotaciones
sistema. Los objetos del dominio representan las cosas que existen o los eventos que su-
ceden 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 siste-
ma, 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.
de contenidos
65

seleccionadas
Comprende los siguientes diagramas:
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 produc-
to 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.
ollo
nidos 66
nadas
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 requeri-
miento (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.
de contenidos
67

seleccionadas
Diagrama de Clases del Anlisis (DCA)
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 Anotaciones
Figura 52. Diagrama de clases del anlisis

ollo
nidos 68
nadas
Diagramas de Secuencia del Anlisis (DSA)
Modelo de interaccin entre objetos, como se muestra en la fig. 53.
torio Anotaciones
Figura 53. Diagrama de secuencia del anlisis


de contenidos
69

seleccionadas
Diagramas de Colaboracin (DC)
Muestran la colaboracin de Objetos para lograr cierto comportamiento, como el
ejemplo mostrado en la fig. 54.
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 pro-
ducir el conjunto de componentes que satisfagan los requerimientos.
Subsistemas
Es un tipo especial de componente que permite desglosar de manera independien-
te al sistema, tal como se muestra en la fig. 56.
ollo
nidos 70
nadas
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

de contenidos
71

seleccionadas
Arquitectura
El sistema se puede organizar por capas. En la fig. 58 se muestra la arquitectura en
tres capas.
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, bi-
narios, ejecutables y dems.
El resultado final de este flujo de trabajo es un sistema ejecutable.
ollo
nidos 72
nadas
Modelo de Componentes
Describe los elementos fsicos del sistema y sus relaciones. Muestran las opciones de rea-
lizacin incluyendo cdigo fuente, binario y ejecutable, segn el ejemplo mostrado en la
torio Anotaciones 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 ubica-
das en los procesadores conectados entre ellos y los dispositivos de ayuda.
Figura 61. Diagrama de componentes

de contenidos
73

seleccionadas
Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que se desa-
rrolla, pero no para aceptar o rechazar el producto al final del proceso de desarro-
llo, sino que debe ir integrado en todo el ciclo de vida. Recordatorio Anotaciones
Despliegue
El objetivo de este flujo de trabajo es producir con xito distribuciones del produc-
to 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 prcti-
cas 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.
ollo
nidos 74
Actividades Autoevaluacin UNIDAD II:
Diagrama
FUNDAMENTOS
Objetivos Inicio
PARA EL MODELAMIENTO DE SOFTWARE

nadas
seleccionadas
torio Anotaciones
EL PROCESO UNIFICADO ES ITERATIVO E INCREMENTAL

Jacobson, Ivar. El proceso unificado de desarrollo de software. Pgs. 6-8
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 divi-
dir 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 jun-
tos 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 tra-
bajo 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 pro-
yecto. 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 su-
puesto, en la medida en que se aaden iteraciones o se altere el orden de las mis-
mas 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 incre-
mento. Si los desarrolladores tienen que repetir la iteracin, la organizacin
pierde el esfuerzo mal empleado de la iteracin, no el valor del producto ente-
ro.
- 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 nor-
malmente es mayor que el tiempo que queda en la planificacin y casi siempre
obliga a retrasar la entrega.
de contenidos
75

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 re-
sultados claros a corto plazo, en lugar de tener un calendario largo, que se prolonga
eternamente. Recordatorio Anotaciones
- La iteracin controlada reconoce una realidad que a menudo se ignora que las
necesidades del usuario y sus correspondientes requisitos no pueden definirse com-
pletamente 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 Unifi-
cado. 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.
ama Objetivos Inicio
TAREA ACADMICA N. 1
rollo Actividades Autoevaluacin
enidos Esta actividad puede consultarla en su Aula virtual.
uras Glosario Bibliografa

onadas
atorio Anotaciones
ollo
nidos 76
UNIDAD II:Inicio
Objetivos
FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWARE

nadas
GLOSARIO DE LA UNIDAD II
seleccionadas
torio Anotaciones
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 mode-
Anotaciones
lo en el desarrollo de software.
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 co-
municacin puede ser de solicitudes para que otro objeto realice alguna actividad.
Semntica, Significado de un smbolo segn un lenguaje de programacin, propor-
cionado por el orden en que se escribi.

de contenidos

BIBLIOGRAFA DE LA UNIDAD II
seleccionadas
Arlow, Jim & Neustadt, Ila. (2005). Programacin UML 2. Espaa: Editorial Anaya.
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. Dis-
ponible en: http://www.pmoinformatica.com/2013/12/metodologias-agiles-ten-
dencias-2014.html
Universidad Unin Bolivariana.(sin fecha). Metodologas giles RUP. Disponible en:
http://ingenieriadesoftware.mex.tl/52788_Rup-Agil.html
de contenidos
77

seleccionadas
AUTOEVALUACIN DE LA UNIDAD II
s
1. En el enfoque estructurado, separar el problema en partes ms pequeas e

independientes corresponde a:
s
Glosario
Bibliografa a) Cohesin
b) Agregacin
c) Modularidad
d) Composicin
o Anotaciones
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
b) Elementos del bloque de construccin de UML
ollo
nidos 78
nadas
c) Adornos de Mecanismos comunes de UML
d) Vista de la Arquitectura de UML
e) Diagramas del Bloque de construccin de UML
torio 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
79

seleccionadas
Desarrollo
UNIDAD III: RUP Y UML NEGOCIO Y REQUERIMIENTOS
de contenidos
DIAGRAMA DE PRESENTACIN DE LA UNIDAD III

Diagrama
Lecturas Objetivos
Glosario Inicio
Bibliografa
seleccionadas
LECTURAS
SELECCIONADAS
de contenidos
seleccionadas

Tema N. 1: Flujo de 1. Identifica y analiza los ele- 1.
Asume con responsa-
trabajo
Desarrollo de RUP:Autoevaluacin
Actividades
mentos de construccin bilidad sus actividades
de contenidos
Modelado del negocio de los diagramas para el acadmicas asignadas.
1. Evaluacin del negocio. negocio. 2. Realiza con honestidad
ictogrfico situacional 2. Elabora los diagramas de
2. P las evaluaciones asigna-
y pictogrfico
Lecturas Glosario Bibliografa UML para el negocio. das.
seleccionadas
solucionador. 3. Identifica y describe los
3. Reglas del negocio. elementos de construc-
cin de los diagramas
4. Diagramas UML: Dia- para el requerimiento.
Recordatorio
gramaAnotaciones
de casos de uso
del negocio y diagrama 4. Elabora los diagramas

de objetos del negocio. de UML para el requeri-
miento y los incorpora en
el Proyecto de software en
Lectura seleccionada N. 1 equipo.
Whitten, Jeffrey & Bentley,
Lonnie. Punto de vista de Actividad N. 3
los usuarios del sistema
acerca de los procesos. Desarrollo de los diagramas
Anlisis de sistemas, dise- del negocio, segn casos
o y mtodos. . Pg. 33. propuestos.
Tema N. 2: Flujo de Control de Lectura N. 2

Trabajo de RUP: Modela- Elabora el informe del mo-
do de requerimientos delamiento de software, ad-
1. Estimacin del proyecto. juntando el modelado del
negocio y el modelado de
2. Diagrama UML: Diagra- requerimientos.
ma de casos de uso de re-
querimientos, plantillas,
diagrama de activida-
des de requerimiento.
Arlow, Jim & Neustadt,
Ila. La Importancia de los
requisitos. Programacin
UML 2 . Pg. 33.
Autoevaluacin de la
unidad III
ollo
nidos 80
Actividades Autoevaluacin UNIDAD III: RUP Y UML NEGOCIO Y REQUERIMIENTOS
nadas
TEMA N. 1: FLUJO DE TRABAJO DE RUP: MODELADO DEL NEGOCIO
A continuacin ver un ejemplo que elabora un modelamiento de software aplican-

torio Anotaciones
do 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 informa-
cin 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.

UNIDAD III: RUP Y UML NEGOCIO Y REQUERIMIENTOSDesarrollo
de contenidos
81

seleccionadas
1 Evaluacin del Negocio 2
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:
a. Razn social, rubro, tiempo en el mercado, organigrama, visin, misin, oportu-

nidades 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 reali-
zan 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 nego-
cio, 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.

ollo
nidos 82
nadas
De esta forma se podr elaborar el Pictogrfico Solucionador, es decir con la pro-
puesta de solucin en base al producto final del modelamiento de software. Obser-
vemos el ejemplo de la fig. 73.
torio Anotaciones
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 acuer-
do 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 sof-
tware. (Romero Moreno, Gesvin. 2004)
I. Creacin de Diagrama de Paquetes

1. En el Business Use Case Model, clic derecho y seleccionar New: Use Case Dia-
gram.
2. Asignarle el nombre de DPaquetesFarmacia, como por ejemplo:
de contenidos
83

seleccionadas
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, Com-
pras 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:
ollo
nidos 84
nadas
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

de contenidos
85

seleccionadas
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 Anotaciones
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 cam-
biar 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.
ollo
nidos 86
nadas
4. Repita los pasos anteriores para crear otros Casos de Uso:
torio Anotaciones
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.
de contenidos
87

seleccionadas
Figura 85. Ejemplo de generalizacin entre actores

4.
Si existiese generalizacin entre casos de uso seleccionar de la caja de herra-
mientas 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 relacio-
nado con algn objetivo del negocio y/o algn documento del negocio:
Figura 85. Ejemplo de diagrama de casos de uso del negocio

ollo
nidos 88
nadas
III. Creando Modelo de Objetos del Negocio para cada Paquete

a. Modelo de Objetos
torio 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

de contenidos
89

seleccionadas
c. Relaciones
1. Arrastrar los workers y business actors necesarios hacia el Modelo de Objetos del
Negocio:
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

ollo
nidos 90
nadas
IV. Creando Modelo de Dominio para cada Paquete
a. Modelo de Dominio
torio Anotaciones
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

de contenidos
91

seleccionadas
5.
Como no hace falta nivel de detalle, entonces se puede prescindir del compar-
timiento de los atributos y de las operaciones de la clase, haciendo clic derecho
sobre la clase, seleccionar options y luego seleccionar Suppress Attibutes y Su-
ppress Operations: Recordatorio Anotaciones
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, que-
dado nuestro diagrama:
Figura 93. Ejemplo de diagrama de dominio

ollo
nidos 92

de contenidos
nadas
seleccionadas
torio Anotaciones
PUNTO DE VISTA DE LOS USUARIOS DEL SISTEMA ACERCA

DE LOS PROCESOS
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 procedi-
mientos 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 polti-
ca 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 trmi-
nos de flujo de trabajo. La mayora de las empresas son muy independientes de revisio-
nes 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 pro-
cesamiento de informacin.
Desde luego, estas revisiones y estos balances pueden volverse engorrosos y burocrti-
cos. Los analistas de sistemas y los usuarios buscan un equilibrio apropiado entre revi-
siones 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 dise-
adores del sistema acerca de los procesos del negocio est restringido por las limita-
ciones 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 nego-
cio seleccionado, implementados con el software y el hardware.
Actualmente muchas empresas adquieren paquetes de aplicacin comercial del ana-
quel (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 com-
petitiva 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.
de contenidos
93

seleccionadas
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 em-
presa.
En forma alternativa, en el caso de construir software internamente, en generalRecordatorio
los Anotaciones
procesos del negocio son primeramente designados y las especificaciones de proce-

sos 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.
ACTIVIDAD N. 3

seleccionadas
ollo
nidos 94
nadas
TEMA N. 2: FLUJO DE TRABAJO DE RUP: MODELADO DE

REQUERIMIENTOS
torio Anotaciones
En esta etapa, se debe identificar los requisitos del usuario, que sern automatiza-
dos 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 Ac-

tual 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.
de contenidos
95

seleccionadas
3.
Realizar el paso 2 para crear otros paquetes Compras y Almacn si es que son
parte del modelado del sistema:
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
ollo
nidos 96
nadas
b. Actores
1. Clic derecho sobre el DCUSistVentas para el men emergente y seleccionar
New: Actor, llamado NewClass que se ubicar en el browser.
torio 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 cam-
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 DCU-
SistVentas.
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-de-
lo 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 cam-
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.
de contenidos
97

seleccionadas
3.
Para crear la Relacin de Asociacin: Clic en el icono Unidireccional Associa-
tion de la Caja de Herramientas.
4.
Clic en un Actor iniciando una comunicacin y arrastrar las Asociacin hasta un
Caso de Uso: Recordatorio Anotaciones
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 cam-
po 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

ollo
nidos 98
nadas
8. Para crear la relacin Extendida
Clic en el icono Dependency or Instantiates de la Caja de Herramientas.
Clic en el Caso de Uso extendido y arrastrar la lnea de Asociacin hasta el Caso de
torio Anotaciones Uso base.
9. Para crear un estereotipo

Doble clic o clic derecho en la lnea de Asociacin, Open Specification y en el cam-
po 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 herra-
mientas 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 dia-
grama:
Figura 101. Ejemplo de creacin de Diagrama de Casos de Uso de Requerimiento

de contenidos
99

seleccionadas
III. Creacin de las Plantillas para cada Caso de Uso de Requerimientos
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.

ollo
nidos 100
nadas
3. Luego Cambiar el nombre NewDiagram por el del Diagrama segn el modelo
que se est realizando, Clic derecho en NewDiagram, Rename y cambiar nom-
bre por el de DAActualizarDatos.
torio Anotaciones
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)

de contenidos
101

seleccionadas
c. Creando Actividades
1. Clic derecho sobre el Diagrama de Actividades DAActualizarDatos, luego New y
seleccionar Activity.
2. Asignarle un Nombre, mientras se encuentra seleccionado. Recordatorio Anotaciones
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

ollo
nidos 102
nadas
f. Creando Puntos de Decisin

1. Seleccionar de la Caja de Herramientas el icono Decision.
torio 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

de contenidos
103

seleccionadas
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.

ollo
nidos 104

de contenidos
nadas
seleccionadas
torio Anotaciones
LA IMPORTANCIA DE LOS REQUISITOS

Arlow, Jim & Neustadt, Ila. Programacin UML 2. Pgs.78-80
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 imple-
mentar. 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 prc-
tica, 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 em-
presas 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 mode-
lo 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 cual-
quier 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 debe-
ra 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
de contenidos
105

seleccionadas
en ideas tradicionales de requisitos funcionales y no funcionales.
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
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 tradiciona-
les. 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 administra-
cin 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 adminis-
tracin de requisitos como DOORS pueden analizar los requisitos ms fcilmente.
Figura 111. Formato para indicar requisitos

Fuente: Arlow, Jim & Neustadt, Ila. Programacin UML 2.

de contenidos
CONTROL DE LECTURA N. 2
seleccionadas
ollo
nidos 106
UNIDAD III:InicioRUP Y UML NEGOCIO Y REQUERIMIENTOS
Objetivos

nadas
GLOSARIO DE LA UNIDAD III

seleccionadas
torio Anotaciones
Herramienta. instrumento de software que permite el modelado de software.

Modelo de dominio. es un diagrama de clases preliminar, basado en los objetos y
Recordatorio actores del negocio.
Anotaciones
Negocio. rea o reas; proceso o procesos de la organizacin y del cual se desarro-

llar 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.

de contenidos

BIBLIOGRAFA DE LA UNIDAD Iii
seleccionadas
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.
de contenidos
107

seleccionadas
AUTOEVALUACIN DE LA UNIDAD III

s
1. E
n el modelado del Negocio, las restricciones que cada proceso de la organiza-
cin puede tener corresponde a:
s
Glosario a) Cuadro Pictogrfico
Bibliografa
b) Diagrama de Casos de Uso

c) Lenguaje de Programacin
d) Diagrama de Clases
o Anotaciones
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 relacio-
nes 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
d) Diagrama de Casos de Uso del Requerimiento
e) Diagrama de Paquetes del Negocio
ollo
nidos 108
nadas
7. Es una relacin que indica que un caso de uso base, requiere la ejecucin previa
de otro caso de uso:
a) Extend
torio Anotaciones 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 activida-

des 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
109

seleccionadas
Desarrollo
UNIDAD IV: RUP Y UML ANLISIS, DISEO E IMPLEMENTACIN
de contenidos
DIAGRAMA DE PRESENTACIN DE LA UNIDAD IV

Diagrama
Lecturas Objetivos
Glosario Inicio
Bibliografa
seleccionadas
LECTURAS
SELECCIONADAS
de contenidos
seleccionadas


Tema N. 1: Flujo de trabajo 1. Identifica y describe los 1.
Asume con respon-
Desarrollo
de RUP: Modelado de anlisis
de contenidos elementos de construc- sabilidad sus activi-
1.
Diagrama UML: dia- cin de los diagramas dades acadmicas
grama de clases y es- para el anlisis y el diseo. asignadas.
tereotipos
Lecturas
de
Glosario
Bibliografa
clase. 2. E
labora los diagramas de 2. Realiza con honesti-
seleccionadas
2. Diagrama UML: Diagrama UML para el anlisis y el dad las evaluaciones
de secuencia, diagrama de diseo. asignadas.
colaboracin. 3. Identifica y analiza los ele-
Tema N. 2: Flujo de trabajo mentos de construccin
de RUP: Modelado de diseo de los diagramas para la
implementacin.
1. Diagrama UML: Subsiste-
mas e interfaces, modelo 4. Elabora los diagramas de
arquitectnico UML para la implemen-
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
Julie. Pg. 497. del anlisis y diseo, segn
casos propuestos.
Tema N. 3: Flujo de trabajo
de RUP: Modelado de imple-
mentacin Tarea acadmica N. 2
1. Diagrama UML: Diagrama Elabora el informe com-
de componentes. pleto del modelamiento de
2. Diagrama UML: Diagrama software, adjuntando el mo-
de despliegue. delado del anlisis, diseo e
implementacin.
Tema N. 4: Transformacin
al modelo de datos
1. Clases persistentes.
2. Generacin del modelo de
datos.
Piattini, Mario., Marcos, Espe-
ranza., Calero, Coral. Domi-
nio y atributo. Tecnologa y
diseo de base de Dato. Pg.
164.
Autoevaluacin de la
unidad IV
ollo
nidos 110
Actividades Autoevaluacin UNIDAD IV: RUP Y UML ANLISIS, DISEO E IMPLEMENTACIN
nadas
TEMA N. 1: Gestin de las Adquisiciones del proyecto

En esta fase elaboraremos los elementos que conformarn el modelo de software,
torio Anotaciones
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: Packa-
ge, 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
UNIDAD IV: RUP Y UML ANLISIS, DISEO E IMPLEMENTACINDesarrollo
de contenidos
111

seleccionadas
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.
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
ollo
nidos 112
nadas
torio Anotaciones
Figura 116. Ejemplo creacin de un atributo de clase

3. Para especificar la Visibilidad del Atributo: Clic derecho doble clic en el atri-
buto, luego Open Especification y seleccionar en Export Control: Public, Pro-
tected, 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 nom-
bre en Name y luego clic en el botn Aplicar y despus el botn OK.
de contenidos
113

seleccionadas
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

ollo
nidos 114
nadas
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.
torio 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.

de contenidos
115

seleccionadas
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.

ollo
nidos 116
nadas
9. Al final el diagrama de clases:
torio Anotaciones
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, do-
ble 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.
de contenidos
117

seleccionadas
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.
ollo
nidos 118
nadas
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.
de contenidos
119

seleccionadas
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 res-
pectivo mensaje.
2.2 Seleccionar el mensaje simple, doble clic para abrir la ventana de especificacio-
nes.
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 res-
pectivo mensaje.
3.2 Seleccionar el mensaje simple, doble clic para abrir la ventana de especificacio-
nes.
3.3 Seleccionar Detail, y elegir Asynchronous.
Figura 134. Ejemplo de creacin mensaje asncrono

ollo
nidos 120
nadas
4. Para crear un mensaje de retorno:
4.1 R
ealizar un mensaje simple entre un objeto receptor hacia el emisor con su
respectivo mensaje.
torio Anotaciones 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 ob-
jeto 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:
de contenidos
121

seleccionadas
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.
ollo
nidos 122
nadas
4. Realizar el mismo procedimiento para crear cada diagrama de colaboracin.
torio Anotaciones
Figura 138. Ejemplo de diagrama de colaboracin

de contenidos
123

seleccionadas
TEMA N. 2: FLUJO DE TRABAJO DE RUP: MODELADO DE DISEO

Disearemos la arquitectura del software elaborando los subsistemas del software y
de las interfaces internas de comunicacin, que darn como resultado los prototi-
pos 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 inte-
grado software.
I. Subsistemas
a. Crear Subsistemas
1. En el Design Model, seleccionar Layer para crear un paquete por cada subsiste-
ma 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 este-
reotipo 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

ollo
nidos 124
nadas
II. Interfaces
a. Crear Interfaces
torio 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 Gestor-
Cliente, 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

de contenidos
125

seleccionadas
b. Clases de Diseo
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 dere-
cho 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 Es-
pecification 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, he-
rencia, agregacin y composicin, garantizando la alta cohesin y el bajo acopla-
miento.
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.
ollo
nidos 126
nadas
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 respecti-
vos 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

de contenidos
127

seleccionadas
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

ollo
nidos 128
nadas
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.
torio 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 Especifica-
tion 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.
de contenidos
129

seleccionadas
c. Creando las Transiciones
1. Seleccionar de la Caja de Herramientas el icono State Transition y arrastrar des-
de el estado Origen hacia el estado destino, desde el estado inicial hacia el pri-
mer estado de la clase y entre estados. Recordatorio Anotaciones
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

ollo
nidos 130
nadas
6.3 El Diagrama estados queda as:
torio Anotaciones
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

de contenidos
131

seleccionadas
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. Recordatorio Anotaciones
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

ollo
nidos 132
Actividades Autoevaluacin UNIDAD IV:
Diagrama RUP Y UML
Objetivos Inicio ANLISIS, DISEO E IMPLEMENTACIN
as Glosario Bibliografa Desarrollo Actividades Autoevaluacin

nadas de contenidos
torio Anotaciones seleccionadas
TIPOS DE INTERFAZ DE USUARIO

Kendall, Kenneth & Kendall, Julie. Anlisis y diseo de Sistemas. Pgs. 497-504
En esta seccin se describen varios tipos de interfaces de usuario, entre ellas las siguien-
tes: Interfaces de comunicacin natural, interfaces de pregunta y respuesta, mens, for-
mularios, 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 presen-
tacin, 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, de-
bido 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 computa-
dora mediante lenguaje natural.
Las sutilezas e irregularidades que residen en las ambigedades del lenguaje natural pro-
ducen 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 traba-
jando 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 pre-
gunta 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 infor-
macin 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 propor-
ciona 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 de-
ben saber qu tarea desean desempear.
Los mens no dependen del hardware. Las variaciones abundan. Los mens se estable-
cen 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
de contenidos
133

seleccionadas
... Los mens de GUI se usan para controlar el software de PC y tienen los siguien-
tes lineamientos:
1. Siempre se despliega la barra de men principal.
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 simila-
res 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 des-
pliega 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 inter-
faz 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 for-
mularios 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 herramien-
ta 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 co-
mandos, se ejecuta de inmediato por el sistema. Despus el usuario podra proce-
der para dar otra instruccin.
Los lenguajes de comandos requieren memorizar las reglas de sintaxis, esto gene-
ralmente es un obstculo para los usuarios inexpertos. Los usuarios experimenta-
dos 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 te-
clado, 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 re-
troalimentacin contnua en el objeto manipulado significa que se pueden hacer
rpidamente los cambios o incluso cancelar operaciones sin incurrir en mensajes
de error
ollo
nidos 134
nadas
Otras interfaces de usuario
Otras interfaces de usuario, aunque menos comunes que las discutidas anterior-
mente, estn ganando popularidad. Estas interfaces incluyen dispositivos de indi-
torio Anotaciones cacin 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.
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 ha-
cen muy bien un nmero limitado de cosas y se venden a un precio bajo. Las com-
putadoras 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
ACTIVIDAD N. 4

seleccionadas
de contenidos
135

seleccionadas
TEMA N. 3: F LUJO DE TRABAJO DE RUP: MODELADO DE

IMPLEMENTACIN Recordatorio Anotaciones
En esta etapa es necesario que usted haga uso de sus conocimientos sobre los len-
guajes de programacin, creacin de base de datos y diseo de redes para un efec-
tivo 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 Compo-
nent 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 Compo-
nent. 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.
6. Asignarle un Nombre, mientras se encuentra seleccionado.
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.
3
Romero Moreno, Gesvin. (2004). UML con Rational Rose. Per: Editorial Megabyte.
ollo
nidos 136
nadas

torio 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

de contenidos
137

seleccionadas
2 D
iagrama UML: Diagrama de Despliegue
En esta fase, se modela los elementos fsicos para lograr la ejecucin del software.
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

ollo
nidos 138
nadas
TEMA N. 4: T RANSFORMACIN AL MODELO DE DATOS

Para este ltimo tema usted debe revisar sus conocimientos acerca de la creacin
torio Anotaciones
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

4
Romero Moreno, Gesvin. (2004). UML con Rational Rose. Per: Editorial Megabyte.
de contenidos
139

seleccionadas
2 G
eneracin del Modelo de Datos
En esta fase se disea el contenedor del Modelo de Datos y el Gestor de Base de
Datos que recepciona al modelo
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

ollo
nidos 140
nadas
2.1 Al transformar a un modelo de datos se crea automticamente un esquema:
torio Anotaciones
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.
de contenidos
141

seleccionadas
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.
ollo
nidos 142
nadas
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

de contenidos
143

de contenidos Lecturas Glosario Bibliografa
seleccionadas
seleccionadas
DOMINIO Y ATRIBUTO
Piattini,
Recordatorio Mario., Marcos, Esperanza., Calero, Coral. Tecnologa y Diseo de base
Anotaciones
de datos. Pgs. 164-166

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 mis-
mo 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, Nor-
teamericana, 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 nacionali-
dad; 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 tiem-
po), 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 Nacionalida-
des 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 com-
puesto 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.
ollo
nidos 144
nadas
Un dominio compuesto se puede definir como una combinacin de dominios sim-

torio Anotaciones ples 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 podra-
mos 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 se-
parado.
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 trata-
dos, cuando lo precisa el usuario, como piezas nicas de informacin, es decir,
como valores atmicos.
TAREA ACADMICA N. 2

seleccionadas
de contenidos
145

contenidos Lecturas Glosario Bibliografa
seleccionadas
GLOSARIO DE LA UNIDAD IV
eccionadas
Estereotipo. Identificador de una clase. Puede tener o no cono y permite distinguir

que tipo de objeto del software se est modelando.
cordatorio Multiplicidad. Es la cantidad de ocurrencias de un objeto con respecto a otro, similar a
Anotaciones
la cardinalidad en una base de datos.

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.
Objetivos Inicio
ctividades Autoevaluacin
Glosario 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.
notaciones
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.
ollo
nidos 146
as Glosario Bibliografa Diagrama Objetivos Inicio

nadas
AUTOEVALUACIN DE LA UNIDAD IV
de contenidos
torio Anotaciones
INSTRUCCIONES. Lea cuidadosamente cada uno de los tems o preguntas y

marque la respuesta correcta.
seleccionadas
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 ingre-
sadas 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 responsabili-

dades 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
de contenidos
147

seleccionadas
d)
Estado final
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
ollo
nidos 148
Actividades Autoevaluacin ANEXO
as Glosario Bibliografa Diagrama Objetivos Inicio

nadas
ANEXO: CLAVES DE AUTOEVALUACIONES

de contenidos
torio Anotaciones
AUTOEVALUACIN DE LA UNIDAD I AUTOEVALUACIN DE LA UNIDAD II
Lecturas Glosario Bibliografa N. Rpta. N. Rpta.

seleccionadas
1 b 1 c
2 c 2 b
3 d 3 d
4 b 4 d
5 a 5 c
6 d 6 a
7 e 7 b
8 b 8 d
9 d 9 b
10 a 10 c
AUTOEVALUACIN DE LA UNIDAD III AUTOEVALUACIN DE LA UNIDAD IV
N. Rpta. N. Rpta.
1 e 1 e
2 c 2 b
3 a 3 a
4 c 4 c
5 b 5 b
6 d 6 e
7 c 7 c
8 b 8 b
9 b 9 e
10 d 10 a

Ingeniería de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingeniería de Software

Cargado por

Copyright:

Formatos disponibles

INGENIERA

Carol Roxana Rojas Moreno

Autor: Carol Roxana Rojas Moreno

Fondo Editorial de la Universidad Continental

Todos los derechos reservados.

Diagrama de presentacin de la unidad I 11

ORGANIZACIN DE LOS APRENDIZAJES 11

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

Tema N. 2: Ciclo de Vida del Software 17

Tema N. 3: Gestin de Proyectos de Software 23

Tema N. 4: Mtricas en el Software 28

UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWARE 41

ORGANIZACIN DE LOS APRENDIZAJES 41

TEMA N. 2: Metodologas de Desarrollo de Software 45

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

UNIDAD III: RUP Y UML NEGOCIO Y REQUERIMIENTOS 79

ORGANIZACIN DE LOS APRENDIZAJES 79

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

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

UNIDAD IV: RUP Y UML ANLISIS, DISEO E IMPLEMENTACIN 109

ORGANIZACIN DE LOS APRENDIZAJES 109

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

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

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

Tema N. 4: Transformacin al Modelo de Datos 138

Lecturas Glosario Bibliografa

Diagrama Objetivos Inicio

Desarrolla un modelamiento de software, compara los modelos de proceso de

UNIDAD I UNIDAD II UNIDAD III UNIDAD IV

Fundamentos Fundamentos para RUP y UML negocio RUP y UML

TIEMPO MNIMO DE ESTUDIO

16 horas 16 horas 16 horas 16 horas

Diagrama Objetivos Inicio Lecturas Glosario Bibliografa

DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

ORGANIZACIN DE LOS APRENDIZAJES

CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES

1 Definiciones de la Ingeniera de Software

a. Los mtodos de la ingeniera de software. Suministran el cmo construir tc-

b. Las herramientas de ingeniera de software. Suministran un soporte automtico

c. Los procedimientos de la ingeniera de software. Une a los mtodos y herra-

Objetivos de la Ingeniera de software

Ejemplo de software. Programas, archivos de configuracin, documentacin de la

Lecturas Glosario Bibliografa

Figura 1 . Ejemplo de producto genrico de software

b. Productos hechos a medida

Figura 2 . Ejemplo de producto software hecho a medida

Figura 3. Ejemplo de software de sistemas

Figura 4. Ejemplo de producto genrico de software

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

Lecturas Glosario Bibliografa

Figura 5. Ejemplo de software de gestin

d. Software de ingeniera y cientfico. Se caracteriza por los algoritmos y manejo de

Figura 6 . Ejemplo de software ingeniera y cientfico

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

Figura 7. Ejemplo de software empotrado

f. Software de computadores personales. Son de uso habitual. Ejemplo: proce-

Figura 8 . Ejemplo de Software de computadores personales

Figura 9 Ejemplo de software en web

Lecturas Glosario Bibliografa

Figura 10. Ejemplo software sistema experto

TEMA N. 2: CICLO DE VIDA DEL SOFTWARE

1 Ciclo de Vida Clsico del Software

Ciclo de vida de Cascada Pura

Figura 11. Ciclo de vida de Cascada

a. Los mtodos de la ingeniera de software. Suministran el cmo construir tc-

b. Las herramientas de ingeniera de software. Suministran un soporte automtico

c. Los procedimientos de la ingeniera de software. Une a los mtodos y herra-

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

f. Software de computadores personales. Son de uso habitual. Ejemplo: proce-

a. Modelo lineal secuencial. Sugiere un enfoque sistemtico, secuencial, para el

b. Modelo de construccin de prototipos. Define un conjunto de objetivos gene-

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

1 Componentes de la Gestin de Proyectos de Software

2 Planificacin de Proyectos de software

1 Factores de Calidad de McCall