a0248 ingeniería de software mau01

8/15/2019 A0248 Ingeniería de Software MAU01

http://slidepdf.com/reader/full/a0248-ingenieria-de-software-mau01 1/148

INGENIERÍADE

SOFTWARE

Carol Roxana Rojas Moreno



Cada autor es responsable del contenido de su propio texto.

De esta edición:

© Universidad Continental 2015

Jr. Junín 355, Miraflores, Lima-18

Teléfono: 213 2760

Derechos reservados

Primera edición: abril 2015

Tiraje: 500 ejemplares

Autor: Carol Roxana Rojas Moreno

Fondo Editorial de la Universidad Continental

Todos los derechos reservados.

Esta publicación no puede ser reproducida, en todo ni en parte, ni registrada en otrasmitida por un sistema de recuperación de información, en ninguna forma ni porningún medio sea mecánico, fotoquímico, electrónico, magnético, electroóptico,por fotocopia, o cualquier otro sin el permiso previo por escrito de la Universidad.



INTRODUCCIÓN 7

PRESENTACIÓN DE LA ASIGNATURA 9

COMPETENCIA DE LA ASIGNATURA 9

UNIDADES DIDÁCTICAS 9

TIEMPO MÍNIMO DE ESTUDIO 9

UNIDAD I: FUNDAMENTOS DE INGENIERÍA DE SOFTWARE 11

DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD I 11

ORGANIZACIÓN DE LOS APRENDIZAJES 11

TEMA N.° 1: EL SOFTWARE Y LA INGENIERÍA DE SOFTWARE 121 Definiciones de la ingeniería 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 construcción de software 18

LECTURA SELECCIONADA N.º 1

Modelos del proceso del software. Ingeniería del software: Un enfoque práctico.Pressman, Roger. Pág. 19 21

ACTIVIDAD N.º I 22

TEMA N.° 3: GESTIÓN DE PROYECTOS DE SOFTWARE 231 Componentes de la gestión de proyectos de software 23

2 Planificación de proyectos de software 23

3 Estudio de factibilidad de proyectos 24

TEMA N.° 4: MÉTRICAS EN EL SOFTWARE 281 Factores de calidad de MacCall 28

2 Métricas de la calidad del software 30


¿Qué son los costos de la ingeniería del software? Ingeniería del software.Sommerville, Ian. Pág. 9 36

CONTROL DE LECTURA N.º 1 37

GLOSARIO DE LA UNIDAD I 38

BIBLIOGRAFÍA DE LA UNIDAD I 38

AUTOEVALUACIÓN DE LA UNIDAD I 39

UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWARE 41

ÍNDICE



DIAGRAMA DE PRESENTACIÓN 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: METODOLOGÍAS DE DESARROLLO DE SOFTWARE 45

1 Metodología tradicional 45

2 Metodologías ágiles 46

3 Metodologías Web 46


Cinco tendencias de metodologías ágiles para 2014. PMO informática.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 Características 61

2 Fases y flujos de trabajo 61

LECTURA SELECCIONADA N.º 2El proceso unificado es iterativo e incremental. El proceso unificado de desarrollo de software.

Jacobson, Ivar. Pág. 6 74

TAREA ACADÉMICA N.° 1 75

GLOSARIO DE LA UNIDAD II 76

BIBLIOGRAFÍA DE LA UNIDAD II 76

AUTOEVALUACIÓN DE LA UNIDAD II 77

UNIDAD III: RUP Y UML – NEGOCIO Y REQUERIMIENTOS 79

DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD III 79


TEMA N.° 1: FLUJO DE TRABAJO DE RUP: MODELADO DEL NEGOCIO 801 Evaluación del negocio 81

2 Pictográfico situacional y pictográfico 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. Análisis de Sistemas, Diseño yMétodos.Whitten, Jeffrey., Bentley, Lonnie. Pág. 33 92



ACTIVIDAD N.º 3 93

TEMA N.° 2: FLUJO DE TRABAJO DE RUP: MODELADO DE REQUERIMIENTOS 941 Estimación del proyecto 94

2 Diagrama UML: Diagrama de casos de uso de requerimientos, plantillas, diagrama de actividadesde requerimiento 94


La importancia de los requisitos. Programación UML 2. Arlow, Jim & Neustadt, Ila. Pág. 33 104

CONTROL DE LECTURA N.° 2 105

GLOSARIO DE LA UNIDAD III 106

BIBLIOGRAFÍA DE LA UNIDAD III 106

AUTOEVALUACIÓN DE LA UNIDAD III 107

UNIDAD IV: RUP Y UML – ANÁLISIS, DISEÑO E IMPLEMENTACIÓN 109

DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD IV 109


TEMA N.° 1: FLUJO DE TRABAJO DE RUP: MODELADO DE ANÁLISIS 1101 Diagrama UML: Diagrama de clases y estereotipos de clase 110

2 Diagrama UML: Diagrama de secuencia, diagrama de colaboración 116

TEMA N.° 2: FLUJO DE TRABAJO DE RUP: MODELADO DE DISEÑO 1231 Diagrama UML: Subsistemas e interfaces, modelo arquitectónico 123

2 Diagrama UML: Diagrama de estados 127


Tipos de interfaz de usuario. Análisis y diseño de sistema. Kendall, kenneth & kendall, Julie. Pág. 497 132

ACTIVIDAD N.º 4 134

TEMA N.° 3: FLUJO DE TRABAJO DE RUP: MODELADO DE IMPLEMENTACIÓN 1351 Diagrama UML: Diagrama de componentes 135

2 Diagrama UML: Diagrama de despliegue 137

TEMA N.° 4: TRANSFORMACIÓN AL MODELO DE DATOS 1381 Clases persistentes 138

2 Generación del modelo de datos 139


Dominio y atributo. Tecnología y diseño de base de datos. Piattini, M., Marcos, E. y Calero, C. Pág.164 143

TAREA ACADÉMICA N.° 2 144

GLOSARIO DE LA UNIDAD IV 145

BIBLIOGRAFÍA DE LA UNIDAD IV 145

AUTOEVALUACIÓN DE LA UNIDAD IV 146

ANEXO: CLAVES DE LAS AUTOEVALUACIONES 148



8



INGENIERÍA DE SOFTWARE

MANUAL AUTOFORMATIVO9ll

l

ll l

COMPETENCIA DE LA ASIGNATURA

Desarrolla un modelamiento de software, compara los modelos de proceso deconstrucción de software y diferencia su uso aplicando los conceptos para la gestiónde proyectos de software y técnicas de control de calidad para software con el uso defactores y métricas de calidad estándares, valorando su uso como buenas prácticaspara la construcción del software.

Diferencia los tipos de metodología a aplicar en la construcción de un softwareutilizando las metodologías tradicionales, las metodologías ágiles y las metodologías

web, con actitud crítica para determinar el uso de alguna de ellas y modelarla construcción de un software utilizando el proceso Rational Unified Process y lanotación Unified Language Modeling en la herramienta Rational Rose , con creatividad

en la propuesta de solución para el modelo de software.

UNIDADES DIDÁCTICAS

UNIDAD I UNIDAD II UNIDAD III UNIDAD IV

Fundamentosde ingeniería de

software

Fundamentos parael modelamiento de

software

RUP y UML negocio y requerimientos

RUP y UMLanálisis, diseño eimplementación

TIEMPO MÍNIMO DE ESTUDIO

UNIDAD I UNIDAD II UNIDAD III UNIDAD IV

1.a y 2.a semana

16 horas

3.a y 3.a semana

16 horas

4.a y 5.a semana

16 horas

6.a y 7.a semana

16 horas

PRESENTACIÓN DE LA ASIGNATURA



10





l

ll lI

ll

l

ll l

UNIDAD I: FUNDAMENTOS DE INGENIERÍA DE SOFTWARE

I

ll

l

ll l

DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD I

CONTENIDOS

AUTOEVALUACIÓN

LECTURASSELECCIONADAS

BIBLIOGRAFÍA

ACTIVIDADES

I

ll

l

ll l

ORGANIZACIÓN DE LOS APRENDIZAJES

CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES

Tema N.° 1: El software y laingeniería de software

1. Definiciones de laingeniería de software.

2. Productos de software.

3. Aplicaciones de software.

Tema N.° 2: Ciclo de vida delsoftware

1. Ciclo de vida del software.

2. Modelos de construcción desoftware.

Lectura seleccionada N.º 1

Modelos del proceso delsoftware. Ingeniería del sof-tware: Un enfoque práctico.Pressman, Roger. Pág. 19.

Tema N.º 3: Gestión de proyectos de software

1. Componentes de la gestiónde proyectos de software.

2. Planificación de proyectosde software.

3. Estudio de factibilidad deproyectos.

Tema N.º 4: Métricas en el sof-tware

1. Factores de calidad deMacCall.

2. Métricas de la calidad delsoftware.

Lectura Seleccionada N.º 2

¿Qué son los costos de la inge-niería del software? Ingenieríadel Software. Sommerville,

Ian. Pág. 9. Autoevaluación de launidad I

1. Identifica y analizar losmodelos de construcciónde software.

2. Ejemplifica las aplicacio-nes de software.

3. Recopila información desituación organizacionalpara el modelamiento desoftware, como proyectode software en equipo.

4. Identifica y describe loscomponentes de la ges-tión de software.

5. Elabora el cronogramadel proyecto de softwareen equipo.

6. Elabora el estudio defactibilidad económicadel proyecto de softwareen equipo.

Actividad N.° 1

Elabora un cuadro compa-

rativo de los modelos deSoftware: Definición, fases,representación, ventajas ydesventajas.

Control de Lectura N.º 1

Cuestionario de los TemasN.°1, 2, 3 y 4, además delas actividades asignadas yautoevaluaciones.

1. Asume con respon-sabilidad sus activi-dades académicasasignadas.

2. Realiza con honesti-dad las evaluacionesasignadas.



12 l

l l


TEMA N.° 1: EL SOFTWARE Y LA INGENIERÍA DE SOFTWARE

¿Se ha preguntado cuales han sido los procesos o tareas que permitieron la crea-ción de la aplicación de software que está usando en este momento: procesador detextos, hojas de cálculo, etc.?

Este proceso de creación, va acompañado de herramientas y técnicas estandariza-das que concluyen con el producto final: software.

1 DEFINICIONES DE LA INGENIERÍA DE SOFTWAREDe acuerdo a diferentes autores (Pressman, Roger & Sommerville, Ian) “la Ingenie-ría de Software es una disciplina de la Ingeniería que concierne a todos los aspectosde la producción del software.

Abarca un conjunto de tres elementos claves que facilitan al gestor a controlar elproceso de desarrollo de software para construir software de alta calidad:

a. Los métodos de la ingeniería de software. Suministran el cómo construir téc-nicamente el software. Los métodos abarcan un amplio espectro de tareas queincluyen: planificación y estimación de proyectos, análisis de los requerimientosdel sistema y del software, diseño de procedimientos algorítmicos, codificación,prueba y mantenimiento.

b. Las herramientas de ingeniería de software. Suministran un soporte automáticoo semiautomático para los métodos. Las herramientas de ingeniería de softwareson los métodos necesarios para desarrollar el sistema. (Ejemplo Rational Rose ).

c. Los procedimientos de la ingeniería de software. Une a los métodos 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 métodos,las entregas que se requieren y los controles que ayuden asegurar la calidad.

Objetivos de la Ingeniería de software

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para re-solver los problemas, y la informática aporta herramientas y procedimientos sobrelos que se apoya la ingeniería 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 calidaden forma eficiente.

• Definir una disciplina que garantice la producción y el mantenimiento de losproductos de software desarrollados en el plazo fijado y dentro del costo esti-

mado.

El Software

Se entiende por software al programa de cómputo desarrollado y su documenta-ción asociada. Es decir, el software es un conjunto de instrucciones escritas en unaherramienta 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 configuración, documentación de laestructura del sistema, manuales de instalación y uso, sitios-web con información yactualizaciones.

2 PRODUCTOS DE SOFTWAREa. Productos genéricos

Productos que son producidos por una organización (controla las especificaciones)





l

ll l


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 genérico 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 específico. Un ejemplo lo vemos en la Figura 2.

Ejemplo: aplicaciones de negocio, sistemas de control de tráfico aéreo, control deprocesos de fabricación, 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.



14 l

l l


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 genérico de software

Fuente: http://antisec-security.blogspot.com/2012/10/sistemas-scada-parte-i-bueno-antes-de.html

c. Software de gestión: Ayudan a la organización y acceden a una o más bases dedatos que contienen información comercial. Ejm. Ventas, planillas, inventarios

y los más usados, como se muestra el ejemplo en la Figura 5.





l

ll l


Figura 5. Ejemplo de software de gestión

Fuente: https://elmundodelarenta.wordpress.com/2013/05/24/caracteristicas-de-un-software-de-ges- tion-inmobiliaria/

d. Software de ingeniería y científico. Se caracteriza por los algoritmos y manejo denúmeros. Ejm. astronomía, biología molecular. Un ejemplo de software de recono-cimiento de ADN en la Figura 6.

Figura 6 . Ejemplo de software ingeniería y científico

Fuente: hhttp://www.dnabaser.com/lands/secuenciacion%20y%20analisis%20de%20ADN.html

e. Software empotrado. También conocido como embebido, reside en memoriade solo lectura y controla productos y sistemas de mercados industriales y de

consumo. Ejm. Funciones digitales de un auto: sistemas de frenado o como elejemplo de una refrigeradora inteligente, según vemos en la Figura 7.



16 l

l l


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 cálculo, gráficos y multimedia, gestión de base dedatos, 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 lastecnologías usadas para el almacenamiento en la Nube, como se muestra en laFigura 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





l

ll l


h. Software de Inteligencia Artificial. Sistemas expertos, reconocimiento de patro-nes (imágenes 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á cuentaque dicho producto o servicio ha pasado por un conjunto de etapas que permitie-ron su elaboración.

En esta sección veremos los ciclos de vida de un producto denominado software,proporcionándonos los conceptos necesarios para determinar el tipo de ciclo de

vida a utilizar en el modelamiento de software.

1 CICLO DE VIDA CLÁSICO DEL SOFTWARESe usa mucho el término de paradigma de software, que se define como un con-

junto de procedimientos y técnicas que permiten la construcción 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 través de una secuencia ordenada de pasos partiendodel concepto inicial del software hasta la prueba.

• Al final de cada etapa se realiza una revisión 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.• También llamado lineal secuencial

1 Pressman, Roger. (2005). Ingeniería del software: Un enfoque práctico (quinta edición).



18 l

l l


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 clásico y que esreconocido y aceptado por la comunidad desarrolladora.

2 MODELOS DE CONSTRUCCIÓN DE SOFTWAREExisten modelos de proceso de software (Paradigmas de la ingeniería de software. Pressman, Roger. Ingeniería de Software. 2002).

a. Modelo lineal secuencial. Sugiere un enfoque sistemático, secuencial, para eldesarrollo del software que comienza en un nivel de sistemas y progresa con elanálisis, diseño, codificación, pruebas y mantenimiento, tal como se muestra enla Figura 12.

Figura 12. Modelo lineal secuencial

Fuente: Pressman Roger. Ingeniería de software (quinta edición)

b. Modelo de construcción 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 evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar.





l

ll l


Figura13. Modelo de construcción de prototipos

Fuente: Pressman, Roger. Ingeniería de software (quinta edición)

c. Modelo DRA (Desarrollo Rápido de Aplicación). Es un modelo de proceso deldesarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo ex-tremadamente corto (de 60 a 90 días si se comprenden bien los requisitos), talcomo 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



20 l

l l


Cada uno de ellos considera un conjunto de etapas y técnicas de desarrollo. A continuación en las figuras 15 y 16, se muestran ejemplos de los modelos.

Figura 15. Modelos evolutivos: incremental

Fuente: Pressman, Roger. Ingeniería de Software (quinta edición)

Figura 16 Modelos evolutivos: espiral


La elección de un paradigma para la ingeniería de software se lleva a cabo de acuer-do a varios aspectos: la naturaleza del proyecto y de la aplicación, los métodos, lasherramientas a usar, los controles y las entregas requeridas.





l

ll l

UNIDAD I: FUNDAMENTOS DE INGENIERÍA DE SOFTWAREI

ll

l

ll l

LECTURA SELECCIONADA N.° 1

MODELOS DEL PROCESO DEL SOFTWARE Pressman, Roger. Ingeniería del Software: Un enfoque práctico (quinta edición).Pág. 19

Para resolver los problemas reales de una industria, un ingeniero del software o unequipo de ingenieros debe incorporar una estrategia de desarrollo que acompañeal proceso, métodos y capas de herramientas descritos en la sección 2.1.1 y las fasesgenéricas discutidas en la sección 2.1.2.

Esta estrategia a menudo se llama Modelo de proceso o Paradigma de ingeniería del software : se selecciona un modelo de proceso para la ingeniería del software según lanaturaleza del proyecto y de la aplicación, los métodos y herramientas a utilizarse ylos 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 naturalezadel proceso del software.

Todo el desarrollo del software se puede caracterizar como un bucle de resoluciónde problemas (figura 17), en el que se encuentran cuatro etapas distintas:

1. Statu quo

2. Definición de problemas,

3. Desarrollo técnico

4. Integración de soluciones

Statu quo. Representa el actual de sucesos [RAC95].

Definición del problemas. Identifica el problema específico a resolverse.

Desarrollo técnico. Resuelve el problema a través de la aplicación de algunatecnología.

Integración de soluciones. Ofrece los resultados (por ejemplo: documentos, pro-gramas, datos, nueva función comercial, nuevo producto) a los que solicitan la so-lución en primer lugar.

Las fases y los pasos genéricos de ingeniería del software definidos en la sección2.1.2 se divide fácilmente en estas etapas.

En realidad, es difícil compartimentar actividades de manera tan nítida como la fig.18 da a entender, porque existen interferencias entre las etapas.

Aunque esta visión simplificada lleva a una idea muy importante: con independen-cia del modelo de proceso que se seleccione para un proyecto de software, todaslas etapas (statu quo, definición de problemas, desarrollo técnico e integración

de soluciones) coexisten simultáneamente en algún nivel de detalle. Dada la na-turaleza recursiva de la fig. 18, las cuatro etapas tratadas anteriormente se aplicanigualmente al análisis de una aplicación completa y a la generación de un pequeñosegmento de código.

Raccon [RAC95] sugiere un Modelo de caos que describe El desarrollo del software comouna extensión desde el usuario hasta el desarrollador y la tecnología . Conforme progresael trabajo hacia un sistema completo, las etapas descritas anteriormente se aplicanrecursivamente a las necesidades del usuario y a la especificación técnica del desa-rrollador del software.

En las secciones siguientes, se tratan diferentes modelos de proceso para la inge-niería del software. Cada una representa un intento de ordenar una actividad inhe-rentemente caótica.

Es importante recordar que cada uno de los modelos se ha caracterizado de ma-

nera que ayude (con esperanza) al control y a la coordinación de un proyecto desoftware real.



22 l

l l


Y a pesar de eso, en el fondo, todos los modelos exhiben características del Modelode caos .

Figura 17. Fases de un bucle de resolución de problemas


Figura 18 Fases dentro de las fases del bucle de resolución de problemas


I

ll

l

ll l

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





l

ll l


TEMA N.º 3: GESTIÓN DE PROYECTOS DE SOFTWARE

Cuando requiere de la creación de un producto o servicio, usted piensa inmedia-tamente en identificar sus costos, tiempos y otros recursos que son necesarios paraanalizar si su producto o servicio le será rentable, por lo que empíricamente estáhaciendo uso de los principios de la gestión de un proyecto.

1 COMPONENTES DE LA GESTIÓN DE PROYECTOS DE SOFTWARESe puede definir a todo proyecto como el esfuerzo temporal realizado con la finali-dad de crear un producto o servicio único. (Guía PMBOK , quinta edición. 2013).

La gestión de proyectos es la aplicación de los conocimientos, habilidades, herra-mientas y técnicas a las actividades del proyecto, con el propósito de encontrar ysuperar las necesidades y expectativas del mismo.2

La fig. 19 nos muestra el grupo de procesos que nos proporciona la guía PMBOKpara la gestión de proyectos.

Figura 19. Grupos de procesos de gestión de proyectos: PMBOK

Fuente: Fundamentos para la gestión de proyectos PMBOK (quinta edición)

Variables del proyecto de software

Personas. Forma de organizar al personal (tiene un gran efecto sobre la eficienciacon la que trabajen en el proyecto).

Proceso. Habrán tantas metodologías de gestión como metodologías técnicas delproyecto.

Producto. Concepto de producto que tiene el cliente y la creatividad del equipo.

Tecnología. Selección de herramientas efectivas de desarrollo rápido.

2 PLANIFICACIÓN DE PROYECTOS DE SOFTWARESerie de decisiones para definir cómo se va a desarrollar el proyecto (Definición delproblema, metas y objetivos; descomposición en tareas (WBS), definición del plande desarrollo, puesta en marcha del proyecto, etc.)

Figura 20. Duración de las tareas y dependencias

Fuente: Rojas Moreno, Carol Roxana

2 Project Management Institute. (2013). Guía del PMBOK ® (quinta edición).



24 l

l l


3 ESTUDIO DE FACTIBILIDAD DE PROYECTOS

3.1 Factibilidad económica

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.00TOTAL ($) 3600

• Calculemos costos de tecnología

Hardware

Equipo Cantidad Mes Costo/Mes ($) Costo ($)

Computadora Pentium IV 2 6 28.50 342.00Computadora Centrino Dúo 1 2 28.50 171.00Impresora Lexmark 1020 Color 1 2 17.60 35.20

TOTAL ($)

Software

Software Meses Costo ($) Windows 8 6 40.00 Windows Vista 6 35.00SQL Server 2013 5 40.00

Visual Studio 2013 3 40.00

Microsoft Office 2013 5 40.00TOTAL ($) 195.00

Total de costos de tecnología

Hardware + Software = 548.20 + 195= 743.20

• Calculemos costos de suministros

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

TOTAL ($) 55.00

• Calculemos costos de instalación

Materiales Costo ($)Capacitación de personal 150.00Instalación del software 150.00Pruebas del sistema 100.00

TOTAL ($) 500.00

• Calculemos Otros Costos Varios

Tarea Costo ($)

Internet 30.00Fotocopiado 25.00Movilidad 50.00

TOTAL ($) 105.00





l

ll l


• Calculemos costos de mantenimiento

Tarea Año 0 Año 1 Año 2 Año 3 Año 4 Año 5MantenimientoSoftware

0.00 600.00 600.00 600.00 600.00 600.00

B. Determinemos los beneficios

Beneficios tangibles

• Calculemos los benecios de reducción de pago de horas extras de trabajo

Personal Horas /Mes Costo/Mes ($) Costo ($)Contador 5 10.00 50.00

Administrador 4 20.00 80.00Gerente de ventas 3 25.00 75.00Gerente general 2 30.00 60.00

TOTAL ($) 265.00

TOTAL AÑO ($) 3180.00

• Calculemos los benecios de reducción de costos de materiales

Materiales Costo ($)Papel Bond 3.50Papel Oficio 3.00Útiles de Escritorio 15.00

TOTAL ($) 21.50TOTAL AÑO ($) 258.00

Total de beneficio tangible: 3180.00 + 258.00 = 3438.00

Beneficios intangibles

- La información solicitada sea más oportuna y confiable.

- Los reportes sean entendibles y con mejor presentación.

- Mejora en la toma de decisiones.

Tabla 1. Ejemplo de flujo de Caja


Descripción 0 1 2 3 4 5

Costosa. Personal

b. Tecnologíac. Suministros

d. Instalación

e. Varios

f. Mantenimiento

3600.00

743.2055.00

400.00

105.00

600.00 600.00 600.00 600.00 600.00Total de costos 4903.20 600.00 600.00 600.00 600.00 600.00Beneficios 0.00 3438.00 3438.00 3438.00 3438.00 3438.00a. Reducción de

pago horas extras.

b. Reducción decostos materiales.

0.00 258.00 258.00 258.00 258.00 258.00

Total de beneficios 0.00 3696.00 3696.00 3696.00 3696.00 3696.00

Flujo de Cajaeconómico (4903.20) 3096.00 3096.00 3096.00 3096.00 3096.00

Los datos obtenidos en la tabla 1 ayudan al análisis de rentabilidad del proyectopara determinar su aceptación.



26 l

l l


De acuerdo a los datos del flujo de caja económico se obtuvo el análisis de renta-bilidad del proyecto reflejados, según Sapag y Sapag (Preparación y evaluación de

proyectos , 2008):

- Valor Actual Neto (VAN)

Es la diferencia entre todos los ingresos y egresos expresados en moneda actual.

El VAN es expresado de la siguiente forma: VAN = VPB - VPC

Donde VPC, Valor Presente de los Costos y VPB, Valor Presente de los Beneficios.

Donde

I Es la inversión inicial en el momento cero de la evaluación.

E Es el flujo de egresos del proyecto.

Y Es el flujo de ingresos del proyecto.

i Es la tasa de interés efectiva anual.

n Periodo en años.

Para determinar la aceptación del proyecto, se deben considerar:

VAN > 0

Significa que se recupera la inversión y puede lograr un ingreso adicional, por loque 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 elproyecto como rechazado.

Según el Flujo de Caja el Valor Actual Neto (VAN) = 4760.93

El VAN > 0, significa que se recupera la inversión y puede lograr un ingresoadicional, por lo que se considera el Proyecto como Aceptado.

- Relación Beneficio/Costo (B/C)

Es la relación de los Beneficios sobre los Costos asociados al proyecto.

B/C es expresado de la siguiente forma: B/C = VPB / VPC

n

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

i(1 + i)n

n

VPB = Y ( 1 + i ) - 1

i(1 + in



28 l

l l


TEMA N.º 4: MÉTRICAS EN EL SOFTWARE

En más de una ocasión, usted ha sido requerido en una encuesta para evaluar, esdecir, medir el servicio de un terminal de venta o de atención del cliente, conside-rando indicadores propuestos en las referidas encuestas para determinar la calidadde atención o servicio.

1 FACTORES DE CALIDAD DE MCCALLGilb[GIL88] ha sugerido definiciones y medidas para la calidad (Pressman, Roger,2002):

Corrección. Hasta dónde satisface un programa su especificación y logra los objetivos de la misión del cliente.

Fiabilidad. Hasta dónde se puede esperar que un programa lleve a cabo su funciónpretendida con la exactitud requerida.

Eficiencia. La cantidad de recursos informáticos y código necesario para que unprograma realice su función.

Integridad. Hasta dónde se puede controlar el acceso al software o a los datos porpersonas 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 erroren un programa.

Flexibilidad. El esfuerzo necesario para modificar un programa operativo.

Facilidad de prueba. El esfuerzo necesario para probar un programa paraasegurarse de que realiza su función pretendida.

Portabilidad. El esfuerzo necesario para transferir el programa de un entorno desistema hardware y/o software a otro.

Reusabilidad. Hasta dónde se puede volver a emplear un programa (o partes de unprograma) en otras aplicaciones, en relación al empaquetamiento y alcance de lasfunciones que realiza el programa.

Interoperatibilidad. El esfuerzo necesario para acoplar un sistema con otro.

Luego, es necesario definir las métricas que afecten a los factores de calidad; sinembargo, muchas de las métricas de McCall pueden medirse solamente de manerasubjetiva por lo que las métricas pueden ir en forma de lista de comprobación para“puntuar” atributos específicos del software.

El esquema de puntuación propuesto por McCall es una escala de 0 (bajo) al 10(alto), empleándose las siguientes métricas en el esquema de puntuación:

Facilidad de Auditoría. La facilidad con la que se puede comprobar el cumplimien-to de los estándares.

Exactitud. La exactitud de los cálculos y del control.

Estandarización de comunicaciones. El grado de empleo de estándares de interfa-ces, protocolos y anchos de banda.



30 l

l l


2 MÉTRICAS DE CALIDAD DEL SOFTWARELas Métricas del software están relacionadas con el desarrollo del software comofuncionalidad, complejidad, eficiencia. (Pressman, Roger, 2002)

Métricas técnicas. Se centran en las características de software por ejemplo: la com-plejidad lógica y el grado de modularidad. Mide la estructura del sistema, el cómoestá hecho.

Métricas de calidad. Proporcionan una indicación de cómo se ajusta el software alos requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para quemi sistema se adapte a los requisitos que me pide el cliente.

Métricas de productividad. Se centran en el rendimiento del proceso de la ingenie-ría del software. Es decir qué tan productivo va a ser el software que voy a diseñar.

Métricas orientadas a la persona. Proporcionan medidas e información sobre laforma que la gente desarrolla el software de computadoras y sobre todo el punto de

vista humano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que va hará el sistema.

Métricas orientadas al tamaño. Es para saber en que tiempo voy a terminar elsoftware y cuántas personas voy a necesitar. Son medidas directas al software y elproceso por el cual se desarrolla.

Métricas orientadas a la función. Son medidas indirectas del software y del pro-ceso por el cual se desarrolla. En lugar de calcularlas, las líneas de código (LDC),las métricas orientadas a la función, se centran en la funcionalidad o utilidad delprograma.

A. Orientadas al tamaño

Si una organización de software mantiene registros sencillos, se puede crear unatabla de datos orientados al tamaño.

Se considera los siguientes indicadores:

Desarrollemos un ejemplo de cálculo de estos indicadores, dada la información deun proyecto de software:

Proyecto Costo LDC (líneasde código)

Páginas Docu-mentación

Erroresdetectados

Cant. DePersonal

A 168,000 13,000 365 30 3

Cálculo 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 Documentación = 365 / 13,000 = 0.02 Páginas por cada LDC

- Índice de Costos = 168,000 / 13,000 = 12.9 Soles por una LDC

Meses Personal

LDC DAD PRODUCTIVI

*=

LDC

Páginas ION DOCUMENTAC =

Errores

LDC

CALIDAD = LDC

s NuevosSole

COSTO =





l

ll l


B. Orientadas a la función

Sirve para medir la funcionalidad que entrega un sistema. Un punto de funciónse define como una función comercial de usuario final, (Pressman, Roger. 2005).

Por ejemplo, tenemos un ejemplo de las medidas de punto de función:

- Número de Entradas Externas (EE). Originada en un usuario o desde otra apli-cación. Pueden ser pantallas, formularios, cuadros de diálogo, controles o men-sajes, a través de los cuales un usuario final o cualquier otro programa puedaañadir, borrar o cambiar datos del programa. Esto incluye cualquier entradaque tenga un formato único o un solo procesamiento.

Tabla 2. Ejemplo de Número 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 más ítems de datos0 o 1 fichero Simple (4) Simple (4) Medio (5)2 o 3 ficheros Simple (4) Medio (5) Complejo (7)

4 o más ficheros Medio (5) Complejo (7) Complejo (7)

- Número de Salidas Externas (SE). Se deriva del interior de la aplicación y pro-porciona información al usuario. Pueden ser pantallas, informes, gráficos omensajes que el programa genera para el usuario final o cualquier otro progra-ma. Esto incluye cualquier salida que tenga un formato diferente o requiera unprocesamiento diferente a otros tipos de salida.

Tabla 3. Ejemplo de Número de Salidas Externas

Fuente: https://unpocodejava.wordpress.com/2010/10/14/


1-4 ítems de datos 5-15 ítems de datos 16 o más ítems de datos0 o 1 fichero Simple (3) Simple (3) Medio (4)

2 ficheros Simple (3) Medio (4) Complejo (6)3 o más ficheros Medio (4) Complejo (6) Complejo (6)

- Número de Consultas Externas (CE). Combinaciones de entrada/salida, cadaentrada genera una salida simple e inmediata. Generalmente las consultas recu-peran datos directamente de una base de datos, mientras que las salidas puedenprocesar, combinar o resumir datos complejos.

Tabla 4. Ejemplo de Número de Consultas Externas


estimacion-del-esfuerzo-basado-en-puntos-de-funcion-ajustados-3/ Parte Salida 1-5 ítems de datos 6-19 ítems de datos 20 o más ítems de datos0 o 1 fichero Simple (4) Simple (4) Medio (5)

2 O 3 ficheros Simple (4) Medio (5) Complejo (7)4 o más ficheros Medio (5) Complejo (7) Complejo (7)

Tabla 5. Ejemplo de Número de Consultas Internas



Parte Entrada 1-5 ítems de datos 5-15 ítems de datos 16 o más ítems de datos0 o 1 fichero Simple (3) Simple (3) Medio (4)

2 ficheros Simple (3) Medio (4) Complejo (6)3 o más ficheros Medio (4) Complejo (6) Complejo (6)



32 l

l l


- Número de Archivos Lógicos Internos (ALI). Agrupamiento lógico de datos enlas aplicaciones, mediante una EE. Es el único archivo plano o de una sola tablaen una base de datos relacional.

Tabla Nº 6 Ejemplo de Número Archivos Lógicos Internos Fuente:https://unpocodejava.wordpress.com/2010/10/14/


1-19 ítems de datos 20-50 ítems dedatos

51 o más ítems de datos

1 formato/rela-ción de registrológico

Simple (7) Simple (7) Medio (10)

2-5 formatos/re-laciones de regis-tro lógico

Simple (7) Medio (10) Complejo (15)

6 o más forma-tos/ relaciones de

registro lógico

Medio (10) Complejo (15) Complejo (15)

- Numero de Archivos de Interfaz Externo (AIE). Agrupamiento lógico de datosexterno a la aplicación y que podrían usarse en la aplicación. (Archivos contro-lados por otros programas, con los que el programa va a interactuar.)

Tabla 7. Ejemplo de Número de Interfaz Externo

Fuente:https://unpocodejava.wordpress.com/2010/10/14/


1-19 ítems de datos 20-50 ítems de

datos

51 o más ítems de datos

1 formato/rela-ción de registrológico

Simple (5) Simple (5) Medio (7)

2-5 formatos/re-laciones de regis-tro lógico

Simple (5) Medio (7) Complejo (10)

6 o más forma-tos/ relaciones deregistro lógico

Medio (7) Complejo (10) Complejo (10)

Se elabora el cuadro de conteo:

Tabla 8. Ejemplo de cuadro de conteo

Fuente: http://es.slideshare.net/OliverCenteno/mtrica-v3-y-rup

Valor de dominio Cuenta Factor de complejidad

TotalSimple Media Compleja

Número de entradasNúmero de salidasNúmero de consultasNúmero de archivosNúmero de interfaces

Cuenta tota l





l

ll l


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

Factores de Ajuste (Fi) Valor1. Comunicación de Datos. Los datos o información de control que la aplica-

ción utiliza se envía o recibe a través de las facilidades de comunicación.

0 Aplicación es batch exclusivamente

1-2 Impresión o entrada de datos remota

3-5 Teleproceso (TP) interactivo

3 TP interface a un proceso batch

5 La aplicación es interactiva, predominantemente2. Función Distribuida. "Distribuida" significa que los componentes (o los da-

tos) de la aplicación están distribuidos en dos o más procesadores diferentes(esto también incrementa el factor anterior).

0 La aplicación no ayuda a la trasferencia de datos o a la función de proce-samiento entre los componentes del sistema.

1 La aplicación prepara datos para el usuario final de otro procesador

2-4 Los datos se preparan para trasferencia, se trasfieren y se procesan en otrocomponente del sistema.

5 Las funciones de procesamiento se realizan dinámicamente en el compo-nente más apropiado del sistema.

3. Rendimiento. Referido a la importancia de respuesta dentro de todo el sis-tema.

0-3 Análisis y diseño de las consideraciones del rendimiento son estándar. Nose precisan requerimientos especiales por parte del usuario.

4 En la fase de diseño se incluyen tareas del análisis del rendimiento paracumplir los requerimientos del usuario.

5 Además se utilizan herramientas de análisis del rendimiento en el diseño,desarrollo e instalación.

4. Configuración utilizada masivamente. Referente a la importancia del entor-no. Esto es, si hay restricciones de memoria o del hardware.

0-3 La aplicación corre en una máquina estándar sin restricciones de operación

4 Restricciones de operación requieren características específicas de la apli-cación en el procesador central.

5 Además hay restricciones específicas a la aplicación en los componentesdistribuidos del sistema.

5. Tasas de transacción. Una alta llegada de transacciones provoca problemasmás allá de los de la característica 3.

0-3 Las tasas son tales que las consideraciones de análisis de rendimiento sonestándares.

4 En la fase de diseño se incluyen tareas de análisis de rendimiento para verificar las altas tasas de transacciones.

5 Además, se utilizan herramientas de análisis del rendimiento6. 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 interactiva7. Diseño para la eficiencia de usuario final.

0-3 No se especifican requerimientos especiales

4 Se incluyen tareas de diseño para la consideración de factores humanos

5 Además se utilizan herramientas especiales o de prototipado para pro-mover la eficiencia.



34 l

l l


8. Actualización online.

0 Nada

1-2 Actualización online de los ficheros de control. El volumen de actualiza-ción es bajo y la recuperación fácil.

3 Actualización online de la mayoría de los ficheros internos lógicos4 Además es esencial la protección contra la pérdida de datos

5 Además se considera el coste de recuperación de volúmenes elevados.9. Complejidad del procesamiento. Esto es, complejidad interna más allá de la

media en lo referente a la entrada, salida o lógica de procesamiento.

¿Qué características tiene la aplicación?

• Mucho procesamiento matemático y/o lógico

• 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 código se diseña para que sea comparti-

do o utilizable por otras aplicaciones (no confundir con 13).

0-1 Una aplicación local que responde a las necesidades de una organizaciónusuaria.

2-3 La aplicación utiliza o produce módulos comunes que consideran másnecesidades que las del usuario.

4-5 Además, la aplicación se "empaquetó" y documentó con el propósito defácil reutilización.

11. Facilidad de Instalación.

0-1 No se requieren por parte del usuario facilidades especiales de conversióne instalación.

2-3 Los requerimientos de conversión e instalación fueron descritos por elusuario y se proporcionaron guías de conversión e instalación.

4-5 Además se proporcionaron y probaron herramientas de conversión e ins-talación.

12. Facilidad de operación.

0 No se especifican por parte del usuario consideraciones específicas de ope-ración.

1-2 Se requieren, proporcionan y prueban procesos específicos de arranque,backup y recuperación.

3-4 Además la aplicación minimiza la necesidad de actividades manuales, talescomo instalación de cintas y papel.

5 La aplicación se diseña para operación sin atención.13. Puestos múltiples.

0 El usuario no requiere la consideración de más de un puesto

1-3 Se incluyeron necesidades de varios puestos en el diseño

4-5 Se proporciona documentación y plan de apoyo para soportar la aplica-ción en varios lugares.





l

ll l


14. Facilidad de Cambio. Esfuerzo específico de diseño para facilitar cambiosfuturos.

0 No hay requerimientos especiales del usuario para minimizar o facilitar elcambio.

1-3 Se proporciona capacidad de consulta flexible

4-5 Datos importantes de control se mantienen en tablas que son actualizadaspor el usuario a través de procesos online interactivos.

€ (Fi)

Entonces el Punto de Función es: PF = conteo total x [0.65 + 0.01 x €(Fi)]



36 l

l l


ll

l

ll l


¿QUÉ SON LOS COSTOS DE LA INGENIERÍA DEL SOFTWARE?Sommerville, Ian. Ingeniería del Software. Pág. 9

No existe una respuesta sencilla a esta pregunta, ya que la distribución de costos através de las diferentes actividades en el proceso del software depende del procesoutilizado y del tipo de software que se vaya a desarrollar.

Por ejemplo, el software de tiempo real normalmente requiere de una validación ypruebas más extensas que los sistemas basados en web. Sin embargo, cada uno delos diferentes enfoques genéricos al desarrollo de software tiene un perfil de distri-bución de costos diferente a través de las actividades del proceso del software. Si seconsidera que el que el costo total de desarrollo de un sistema de software complejoes de 100 unidades de costo, la figura muestra como se gastan estas en las diferentesactividades del proceso.

En el enfoque en cascada, los costos de especificación, diseño, implementación eintegración se miden de forma separada. Observe que la integración y pruebas delsistema son las actividades de desarrollo más caras.

Normalmente, este supone alrededor del 40% del costo del desarrollo total, peropara algunos sistemas críticos es probable que sea al menos el 50% de los costos dedesarrollo del sistema.

Si el software se desarrolla utilizando un enfoque iterativo, no existe división entrela especificación, el diseño y el desarrollo. En este enfoque, los costos de la espe-cificación se reducen debido a que solo se produce la especificación de alto nivelantes que el desarrollo.

La especificación, el diseño, la implementación, la integración y las pruebas se lle- van a cabo en paralelo dentro de una actividad de desarrollo. Sin embargo, aún senecesita una actividad independiente de pruebas del sistema una vez que la imple-

mentación inicial está completa.La ingeniería del software basada en componentes solo ha sido ampliamente uti-lizada durante un corto período de tiempo. En este enfoque, no tenemos figurasexactas para los costos de las diferentes actividades del desarrollo de software. Sinembargo, sabemos que los costos de desarrollo se reducen en relación a los costosde integración y pruebas. Los costos de integración y pruebas se incrementan por-que tenemos que asegurarnos de que los componentes que utilizamos cumplenrealmente su especificación y funcionan como se espera con otros componentes.

Además de los costos de desarrollo, existen costos asociados a cambios que se lehacen al software una vez que esté en uso. Los costos de evolución varían drástica-mente dependiendo del tipo de sistema. Para sistemas software de larga vida, talescomo sistemas de orden y de control que pueden ser usados durante 10 años 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 más pequeñostienen una vida mucho más corta y correspondientemente, costos de evolución másreducidos.

Esta distribución de costos se cumple para el software personalizado, el cual esespecificado por un cliente y desarrollado por un contratista. Para productos desoftware que se venden (mayormente) para las PC, el perfil del costo es diferente.Estos productos comúnmente se desarrollan a partir de una especificación inicialutilizando un enfoque de desarrollo evolutivo. Los costos de la especificación sonrelativamente bajos. Sin embargo, debido que se pretende utilizarlos en diferentesconfiguraciones, deben ser probados a fondo.

Los costos de evolución para productos de software genéricos son difíciles de es-timar. En muchos casos, existe poca evolución de un producto. Una vez que una

versión de producto se entrega, se inicia el trabajo para entregar la siguiente y porrazones de mercadotecnia, esta se presenta como un producto nuevo (pero com-patible) más que como una versión modificada de un producto que el usuario yaadquirió. Por lo tanto, los costos de evolución no se consideran de forma separada



38 l

l l


ll

l

ll l

GLOSARIO DE LA UNIDAD I

Calidad. Es el grado en que se cumplen los requerimientos del software dados por

el cliente, de acuerdo a los estándares de desarrollo de software.Indicador. Dato que permite evaluar las métricas de calidad del software.

Operando. Variable con valor, que forman parte de la instrucción en la codificaciónde software.

Operador. Símbolo que permite operar o calcular y que forman parte de la instruc-ción en la codificación de software

Paradigma. Modelo que incluye conceptos, procedimientos y técnicas para desarro-llar un software.

PMI. Project Management Institute, organización internacional que certifica en ges-tión de proyectos.

Sintaxis. Orden correcto de escribir símbolos según un lenguaje de programación,de tal manera que proporcione un significado.

Transacción. Procesamiento o algoritmo codificado y que es parte de los requisitosfuncionales del software.

I

ll

l

ll l

BIBLIOGRAFÍA DE LA UNIDAD I

Pressman, Roger.(2005). Ingeniería del software: un enfoque práctico (quinta edi-ción). España: Editorial McGraw-Hill. Biblioteca UC: 005.1 / P85 2009.

Project Management Institute. (2013). Guía del PMBOK ® (quinta edición). EstadosUnidos de Norteamérica: Project Management Institute, Inc.

Sapag-Chain, Nassir & Sapag-Chain, Reinaldo. (2008). Preparación y evaluación de proyectos (quinta edición). Colombia: Editorial McGraw-Hill.

Sommerville, Ian. (2008). Ingeniería del software (sétima edición). España: EditorialPearson. Biblioteca UC: 005.1 / S67 2008.





l

ll l


I

l

l

AUTOEVALUACIÓN DE LA UNIDAD I

1. La aplicación web de matrículas de un colegio, es un ejemplo de:

a) Producto genérico y software de sistemas b) Producto hecho a medida y software de gestión

c) Producto hecho a medida y software de computadores personales

d) Producto genérico y software empotrado

e) Producto genérico y software de inteligencia artificial

2. Uno de los tres elementos claves que facilitan el control del desarrollo desoftware y que indica el “cómo” construirlo, es:

a) Herramientas

b) Cascada pura

c) Métodos

d) Lineal secuencial e) Procedimientos

3. Es un modelo de desarrollo de software que se basa en el modelo linealsecuencial, para proyectos de 60 a 90 días de duración:

a) Construcción 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 softwarea desarrollar:

a) Espiral

b) Construcción de prototipos

c) Incremental

d) Basado en componentes

e) DRA

5. Según PMBOK, la definición de Proyecto corresponde a:

a) Esfuerzo temporal para crear un producto o servicio

b) Conjunto de procesos para la gestión

c) Conjunto de conocimientos y técnicas para la gestión d) Herramienta utilizada para la creación de productos

e) Serie de decisiones para definir un servicio

6. En el análisis de rentabilidad de un proyecto, se obtiene un Valor Actual Netomayor a cero. Eso se interpreta como:

a) Los beneficios son menores que los costos, se rechaza el proyecto

b) El interés 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 interés de retorno es menor al aceptable, se acepta el proyecto

7. La definición del factor de calidad: “Esfuerzo necesario para acoplar un sistemacon otro”, corresponde a:

a) Flexibilidad





l

ll lI

ll

l

ll l

UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DESOFTWARE

I

ll

l

ll l

DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD II

CONTENIDOS

AUTOEVALUACIÓN


BIBLIOGRAFÍA

ACTIVIDADES

I

ll

l

ll l



Tema N.° 1: Enfoques dedesarrollo de software

1. Enfoque estructurado.

2. Enfoque orientado aobjetos.

Tema N.° 2: Metodologíasde desarrollo de software

1. Metodología tradicional.2. Metodologías ágiles.

3. Metodologías web


Cinco tendencias de meto-dologías ágiles para 2014.PMO informática. http://

www. pmoinformat ica .com/2013/12/metodolo-gias-agiles-tendencias-2014.html

Tema N.° 3: Lenguaje de mo-delamiento unificado (UML)

1. Conceptos de UML.2. Diagramas de estructura y

comportamiento.

Tema N.º 4: Rational unifiedprocess (RUP - Proceso Uni-ficado)

1. Características.

2. Fases y Flujos de Trabajo.

Lectura Seleccionada N.º 2

El proceso unificado es ite-rativo e incremental. El pro-ceso unificado de desarrollo

de software. Jacobson, Ivar.Pág. 6.

Autoevaluación de launidad II

1. Identifica y explica lastécnicas y fundamentosdel enfoque estructurado

y el enfoque orientado aobjetos.

2. Identifica y relaciona laaplicación de las metodo-logías de software, según

el tipo de situación orga-nizacional.

3. Define el tipo de enfoque y la metodología a usar enel proyecto de software enequipo.

4. Identifica, analiza y expli-ca los flujos de trabajo deRUP y su aplicación en elproyecto de software enequipo.

5. Elabora el cronogramadel proyecto de software

en equipo.6. Elabora el informe preli-minar del proyecto de sof-tware en equipo.

Actividad N.° 2

Elabora un cuadro compara-tivo de las metodologías dedesarrollo de software.

Tarea académica N.º 1

Investigación y presentación

de los conceptos principalesde los enfoques de desarro-llo de software.

1. Asume con responsa-bilidad sus actividadesacadémicas asignadas.

2. Realiza con honestidadlas evaluaciones asigna-das.



42 l

l l

UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWARE

TEMA N.° 1: ENFOQUES DE DESARROLLO DE SOFTWARESi 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-ca para su correcta compresión y análisis y posteriormente su solución.

1 ENFOQUE ESTRUCTURADOEste enfoque es un conjunto de conceptos y técnicas para desarrollar software, cu-

ya característica es la descomponer en módulos de programa o componentes desoftware, para integrarlos en un proyecto más complejo.1

Este enfoque utiliza algunos conceptos importantes como:

Modularidad. Un problema complejo se separa en partes más pequeñas (módulos:procedimientos y funciones), lo más independientemente posible del resto de laaplicación. En la fig. 21 se muestra un ejemplo de modularidad, descomponiendoen módulos de programa y siendo invocados luego por el módulo principal.

Figura 21. Ejemplo de modularidad


Cohesión. La forma en la que agrupamos unidades de software en una unidad mayor.Ejemplo. Una clase con alta cohesión suele cumplir el principio de única responsabi-lidad. En la fig. 22 se muestra un ejemplo con la clase Alumno, que contiene datos yoperaciones que lo definen y le corresponden como entidad.

Figura 22. Ejemplo de cohesión


1 Pressman, Roger. (2005). Ingeniería del software: un enfoque práctico (quinta edición).





l

ll l


Acoplamiento. Grado de dependencia que tienen dos unidades de software. Comose observa en la fig. 23, el módulo Calcula depende de que se ejecute el módulofactorial, para poder finalizar con su proceso.

Figura 23. Ejemplo de acoplamiento


2 ENFOQUE ORIENTADO A OBJETOSEl paradigma Orientado a Objetos se basa en el concepto de objeto. Un objeto esaquello que tiene estado (propiedades más valores) y comportamiento (acciones yreacciones a mensajes), tal como se muestra el ejemplo de la fig. 24.

Figura 24. Ejemplo de clase y objeto Fuente: Rojas Moreno, Carol Roxana



44 l

l l


Algunos conceptos principales de este enfoque

Herencia. La transmisión de atributos y métodos de una clase a otra. Como vemosen la fig. 25 la clase Persona hereda sus atributos y métodos a las clases PersonaNatural y Persona Jurídica y estas a su vez tienen sus propios métodos y atributos.

Figura 25. Ejemplo de herencia entre clases


Agregación. Es una relación entre clases, que indica que una clase (todo) está for-mada por otras clases (partes), pero no se ve afectada en su funcionamiento si unade las clases (parte) deja de funcionar. Por ejemplo en la fig. 26, si falta la claseCDLibro, no afecta el comportamiento o funcionamiento de la clase Libro.

Figura 26. Ejemplo de agregación entre clases


Composición. Es una relación entre clases, que indica que una clase (todo) está for-mado por otras clases (partes), pero SÍ se ve afectada en su funcionamiento si unade las clases (parte) deja de funcionar. Observemos la fig. 27 si el Detalle de Facturadonde se encuentra la información 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 composición entre clases






l

ll l


TEMA N.° 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Previamente, se ha revisado los enfoques de desarrollo de software pero además,cada uno de estos enfoques pueden ser desarrollados usando una metodología,que nos indica las tareas y representaciones necesarias para construir el software.

Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, elciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del pro-

yecto pero no cómo hacerlo.

1 METODOLOGÍA TRADICIONAL A partir del detalle del producto que se quiere elaborar (análisis funcional/téc-nico, requerimientos funcionales/técnicos, etc.), se definen fases/actividadesperfectamente planificadas en el tiempo en base a los recursos disponibles, afin de que se cumpla aquello que se había previsto: calendario, costes y calidad. 2 En la fig. 28 se muestra el conjunto de fases de una de estas metodologías.

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)

• Métrica

• Jackson System Development (JSD)

• Joint Application Development (JAD)

• Open Unified Process (OpenUP- OpenUP/Basic)

Figura 28. Ejemplo de metodología tradicional

Fuente: http://reconocimientogeneralydeactores.blogspot.com/2013/03/Reconocimientogeneralydeactores.html

2 Blanco Cuaresma, Sergi.(2008). Metodologías ágiles de gestión de proyectos. Recuperado de http://www.marblestation.com/?s=%C3%A1gil



46 l

l l


2 METODOLOGÍAS ÁGILESSe entiende como Desarrollo ágil de software a un paradigma de Desarrollo deSoftware basado en procesos ágiles. Conocidos anteriormente como metodologíaslivianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías

tradicionales enfocándose en la gente y los resultados.Es un marco de trabajo conceptual de la ingeniería de software que promueve ite-raciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto, 3 como lametodología 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 metodología ágil

Fuente: http://reconocimientogeneralydeactores.blogspot.com

/2013/03/Reconocimientogeneralydeactores.html

3 METODOLOGÍAS WEBEl actual desarrollo de sitios y aplicaciones Web está caracterizado por cuatro im-portantes factores:4

1. Las aplicaciones y sitios Web son cada vez más complejos en cuanto a gráficas,contenido y funcionalidad.

2. Cada vez hay más y mejores herramientas de desarrollo.

3. Los tiempos de desarrollo requeridos por las empresas son cada vez más cortos,para estar mejor posicionados que la competencia.

4. Las aplicaciones y sitios Web requieren cambios periódicos, tanto de contenido3 Universidad Unión Bolivariana. (sin fecha). Metodologías ágiles RUP . Recuperado de http://ingenieriadesoftware.mex.tl/52788_Rup-Agil.html4 Bravo Lillo, Cristian y Guerrero, Luis. (sin fecha). Métricas de funcionalidad: una taxonomía para sistemas web. Universidad deChile. Recuperado de http://users.dcc.uchile.cl/~luguerre/papers/WCIS-01.pdf



48 l

l l

UNIDAD II: FUNDAMENTOS PARA EL MODELAMIENTO DE SOFTWAREI

ll

l

ll l


CINCO TENDENCIAS DE METODOLOGÍAS ÁGILES PARA 2014PMOinformática. Recuperado de http://www.pmoinformatica.com/2013/12/metodologias-agiles-tendencias-2014.html

Se acerca el fin del año 2013 y todos nos preguntamos qué curso tomará la aplica-ción de las metodologías ágiles en el próximo año.

Esto fue motivo de discusión recientemente en el grupo de Linkedin Agile and LeanSoftware Development, en donde se le preguntó a la audiencia ¿Cuáles son tus predic-ciones de 2014 para las metodologías ágiles?.

A continuación, PMOinformatica.com, La Oficina de Proyectos de Informática,presenta un resumen de las tendencias tratadas en este foro, algunos puntos son:

• Crecimiento en la aplicación de enfoques como Lean y Kanban.

• Mayor énfasis en la práctica y menos en los dogmas.

• Aplicación de las metodologías ágiles en todo el equipo de proyecto, incluyendooperaciones y áreas de Negocio (DevOps).

• Más escalamiento en el uso de Metodologías Ágiles (Agile at a Scale).

• Aplicación de las metodologías ágiles en áreas distintas al Desarrollo deSoftware.

¿Y tú?, ¿Cuáles tendencias en el desarrollo ágil consideras más relevantes para el2014? Escribe tus comentarios.

A continuación, cinco tendencias de Metodologías Ágiles para 2014:

1. Crecimiento en la aplicación de enfoques como Lean y Kanban

• Veremos más organizaciones aplicando las metodologías ágiles “Esbeltas”,como por ejemplo el Desarrollo de Software Esbelto (Lean Software Develop- ment ) y Kanban.

• Combinación de ideas como Scrum y Kanban.

• Combinación de las prácticas de Lean Start-Up con el Desarrollo Ágil.

2. Mayor énfasis en la práctica y menos en los dogmas de las metodologías ágiles

• Metodologías ágiles modifcadas y adaptadas a las necesidades de la organi-zación.

• Coexistencia de las metodologías ágiles con prácticas predictivas no ágiles.

• Lo que funciona reemplazará a lo que está de moda o es correcto según lateoría.

• Uso de métricas para demostrar el logro de los objetivos de negocio, satisfac-ción de los interesados y que las prácticas aplicadas están generando valorpara el negocio.

3. Aplicación de las metodologías ágiles en todo el equipo de proyecto, incluyen-do Operaciones y áreas de Negocio (DevOps)

• Involucramiento de toda la organización (no solo al equipo de desarrollo)en el aprendizaje y uso de metodologías ágiles. Esto incluye al área de ne-gocio, área de operaciones de software y otras áreas de soporte, como porejemplo infraestructura de tecnología y seguridad informática.

• Los roles de las áreas de Negocio, Desarrollo de Software y Operaciones de Aplicaciones continuarán transformándose y colaborando entre sí.

• Utilización de metodologías ágiles en todo el ciclo del proyecto, desde laconcepción de la idea hasta su implantación en producción.

4.- Más escalamiento en el uso de Metodologías Ágiles (Agile at a Scale )





l

ll l


• Colaboración de múltiples equipos ágiles en grandes proyectos (Scrum deScrum).

• Más equipos de trabajo distribuidos, cuyos integrantes no están localizadosen las mismas oficinas e instalaciones.

• Aplicación de metodologías ágiles en un alcance mayor al de equipos

individuales, en proyectos multidisciplinarios y entre productos.

5. Aplicación de las metodologías ágiles en áreas distintas al Desarrollo de Software

• Organizaciones de desarrollo, como por ejemplo desarrollo de nuevos pro-ductos, investigación y desarrollo, entre otros.

• Proyectos de “Seguridad Crítica”, como por ejemplo área médica (Salud),control en tiempo real en fábricas, industria de control de procesos, seguri-dad, ámbito financiero, industrias altamente reguladas por gobiernos, etc.

I

ll l

l l






l

ll l


La fig. 31 muestran los diagramas versión base la versión 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 extensión (amplían la semánti-ca de un elemento, OCL), Estereotipos, Valores Etiquetados.

III. Arquitectura. “Estructura organizacional de un sistema, incluida su descompo-sición en partes, su conectividad, interacción, mecanismos y principios directoresque informan al diseño de un sistema” (Rumbaugh. Manual de referencia de UML ).

- Diagrama de paquetes

Los diagramas de paquetes se usan para reflejar la organización de paquetes y suselementos. En la fig. 32 se muestra un ejemplo de Diagrama de Paquetes.

- Diagrama de casos de uso

Representa lo que hace el sistema y cómo se relaciona con su entorno.

- Casos de uso. Secuencia de acciones realizadas.

Figura 32. Ejemplo de paquetes




52 l

l l


- Relaciones en un Diagrama de Casos de Uso. Existen los siguientes tipos derelaciones en un Diagrama de Casos de Usos:

a. Comunicación (Communicate). Es la única relación entre actor y caso de uso.

b. Incluye (Include). Un caso de uso requiere la ejecución de otro caso de uso.

c. Extiende (Extend). Se ejecuta el caso de uso base, bajo ciertas condiciones.

d. Herencia. Uno o más actores y casos de uso heredan de características ycomportamiento común.

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 (asociaciónsimple, herencia, generalización, composición).

Una clase puede tener los siguientes estereotipos:

- Clase entidad (entity). Modelan información.

- Clase entorno (boundary). Comunicación del usuario y del sistema.

- Clase control (control). Coordinan los eventos del sistema.





l

ll l


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, perocon la instancia o instancias de cada clase, tal como se muestra en la fig. 35.

Figura 35. Ejemplo de diagrama de objetos




54 l

l l


- Diagrama de secuencia

El diagrama muestra el envío de mensajes de los objetos. Como en la fig. 36, semuestra el objeto (rectangular), la línea de vida (línea entrecortada), el foco decontrol (rectángulo en la línea 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




56 l

l l


- Diagrama de estados (diagrama de máquina de estados)

El diagrama de estados modela el comportamiento de una parte del sistema (clase)a través del tiempo. Cada estado tiene un nivel de detalle como entry, exit, do; yuna transición con el detalle de evento (orden para cambiar de un estado a otro),condición para realizar la transición y la acción (actividad que propiamente permi-

te cambiar de un estado a otro), así como si se tiene la misma transición a diferen-tes estados o viceversa, se puede utilizar un supraestado para su representación talcomo 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 flujoestructurado y está apoyado en la secuencia de pasos dados en las plantillas de cadacaso de uso, ya sea del negocio o del requerimiento.

Actividad. Es un nodo el cual indica una tarea específica desarrollada por el objeto.

Punto de decisión. Realiza un conjunto de actividades según una condición.

Barra de sincronización. Permite agrupar actividades concurrentes.

Carriles. Conjunto de actividades que realiza un objeto, tal como observamos en lafig. 40 usando carriles (swimlanes) y puntos de decisión.





l

ll l


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), comose muestra en la fig. 41.

- Componente. Parte de un sistema (archivos de código fuente, binarios, de confi-guración, de instalación, ejecutables, tablas, etc).

Figura 41. Ejemplo de diagrama de componentes




58 l

l l


- Diagrama de despliegue

Modela la topología de hardware sobre la cual se ejecutará la aplicación, indicando dónde seejecutarán los componentes.

- Nodos. Es el elemento físico 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-lámbrico), del caso propuesto de Ventas de Farmacia.

- Diagrama de estructura compuesta

Similar al diagrama de clase, pero muestra partes y conectores. Es decir, la relación de com-posición de un conjunto de clases son agrupados en una sola clase para su diagramación.





l

ll l


Por ejemplo en la fig. 43 se muestra la relación de composición de un auto y barco, y luego la representación del diagrama de estructura compuesta en solo dos clasesque contienen las clases que la conforman.

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 más elementos en eltiempo, tal como el ejemplo mostrado en la fig. 45.

Figura 45. Ejemplo de diagrama de tiempo

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





l

ll l


TEMA N.° 4: RATIONAL UNIFIED PROCESS (RUP-PROCESO UNIFICADO)

Se puede dar cuenta hasta el momento, que se tiene los conceptos de modelado y elenfoque de desarrollo y lo que falta para iniciar con la construcción de software es elconjunto de fases o flujos de trabajo, es decir el “cómo”, dado por el Proceso Unificado,bajo las especificaciones de la empresa Rational, que es la aceptada y utlizada por lacomunidad de desarrolladores.

1 CARACTERÍSTICASRUP es un producto desarrollado y comercializado por Rational Software (IBM) y es unproceso de desarrollo de software disciplinada: asignar tarea y responsabilidades en unaempresa (quién hace qué, cuándo y cómo).

2 FASES Y FLUJOS DE TRABAJORUP es iterativo e incremental: “Pequeños proyectos que incorporan incrementalmen-

te nueva funcionalidad y cuyo desarrollo es una iteración”. 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 ycasos de uso más esenciales (aproximadamente el 20% del modelo completo).

II. Elaboración. 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. Construcción. Alcanzar la capacidad operacional del producto de forma incremen-tal a través de las sucesivas iteraciones (requisitos deben ser implementados, inte-grados y probados en su totalidad.

IV. Transición. Poner el producto en manos de los usuarios finales, (desarrollar nuevas versiones actualizadas del producto, completar la documentación, entrenar alusuario).



62 l

l l


2.2. Disciplinas (flujos de trabajo) DE RUP

1. Modelado del negocio

Permite llegar a un mejor entendimiento (la estructura y la dinámica) de la organi-zación, 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 sonsusceptibles de generalizaciones. Los procesos (casos de uso) de negocios puedenmodelarse como paquetes.

Modelo Casos de Uso del Negocio (Diagrama de Casos de Uso)

Describe los procesos de negocio de una empresa en términos de casos de uso delnegocio y actores del negocio que se corresponden con los procesos del negocio ylos clientes, respectivamente.

- Actor (Usuario) del Negocio. Actúa con la organización:

Clientes, vendedores o socios.

Son representados por los Actores del Negocio.

- Workers. Son los roles dentro de la organización y no las posiciones jerárquicas.También Stakeholders.

- Procesos del Negocio. Representan una abstracción de alto nivel de las funcionesque se realizan en la organización. 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 negocioen estudio Ventas de Farmacia.

Figura 48. Diagrama de casos de uso del negocio




64 l

l l


Modelo del dominio (Diagrama de Clases)

Un modelo del dominio captura los tipos más importantes de objetos en el contexto delsistema. 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. RequisitosSe establece qué tiene que hacer exactamente el sistema que se construya. Provee un mejorentendimiento de los requisitos del sistema.

¿Qué es un requisito o requerimiento?

“Una condición 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 pago4) Modificar Datos Cliente

b. Los requisitos no funcionales representan aquellos atributos que debe exhibir el siste-ma, pero que no son una funcionalidad específica. Ejemplo:

1) Plataforma en donde se ejecuta la aplicación.

2) Incorporar políticas de hacer copias de seguridad de la base de datos.

3) Plan de contingencia ante la caída del servidor de base de datos, aplicaciones, web,etc.

4) Portabilidad a otros sistemas operativos.





l

ll l


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, máquinas u otros sistemas que interactúan directamente con elsistema. Los Actores del Negocio y los Workers del Negocio son candidatos a seractores.

Caso de Uso. Representa a los requerimientos que serán entregados con el produc-to de software. Cada una de las transacciones de los Workers del Negocio sobre lasEntidades del Negocio se pueden transformar en Casos de Uso.

Asociaciones.

- Entre Actor y Use Case(Comunicacion)

- Entre actores

Se pueden dar relación de generalización.



66 l

l l


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 querealiza cada caso de uso del requerimiento, como el mostrado en la fig. 51b.

Figura 51b. Diagrama de actividades de los requerimientos


Análisis y diseño

El objetivo de este flujo de trabajo es traducir los requisitos a una especificación quedescribe cómo implementar el sistema. Los objetivos son:

- Transformar los requisitos al diseño del futuro sistema.

- Desarrollar una arquitectura para el sistema.El modelo del análisis

Bosquejo del sistema; proporciona una visión resumida de su funcionalidad.



68 l

l l


Diagramas de Secuencia del Análisis (DSA)

Modelo de interacción entre objetos, como se muestra en la fig. 53.

Figura 53. Diagrama de secuencia del análisis




70 l

l l


Figura 56. Ejemplo de subsistemas


Interfaz

Es una clase que especifica un conjunto de características públicas.

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 almacén.

Figura 57 Ejemplo de subsistemas






l

ll l


Arquitectura

El sistema se puede organizar por capas. En la fig. 58 se muestra la arquitectura entres capas.

Figura 58. Ejemplo de arquitectura en capas


Modelo de estados

Describen el comportamiento de un sistema través de todos los estados posibles enlos que puede entrar un objeto y la manera en que cambia el estado. En la fig. 59 semodela los estados de la clase VerificandoDatos.

Figura 59. Diagrama de estados de una clase


Implementación

En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, bi-narios, ejecutables y demás.

El resultado final de este flujo de trabajo es un sistema ejecutable.



72 l

l l


Modelo de Componentes

Describe los elementos físicos del sistema y sus relaciones. Muestran las opciones de rea-lización incluyendo código fuente, binario y ejecutable, según el ejemplo mostrado en lafig. 60.

Figura 60. Diagrama de componentes


Modelo de despliegue

Describe la distribución física del sistema (hardware y software) en el sistema final. En lafig. 61 se muestra un ejemplo de uso de archivos según el lenguaje de programación, los

archivos de base de datos según el gestor de base de datos y las interfaces, que serán ubica-das en los procesadores conectados entre ellos y los dispositivos de ayuda.

Figura 61. Diagrama de componentes






l

ll l


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.

DespliegueEl objetivo de este flujo de trabajo es producir con éxito distribuciones del produc-to y distribuirlo a los usuarios.

Gestión del proyecto

Lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar unproducto que sea acorde a los requisitos de los clientes y los usuarios (guías prácti-cas para planeación, contratar personal, ejecutar y monitorear el proyecto).

Configuración y control de cambios

Mantener la integridad de todos los artefactos que se crean en el proceso, así comode mantener información del proceso evolutivo que han seguido.

ENTORNO

Dar soporte al proyecto con las adecuadas herramientas, procesos y métodos..

En conclusión, en RUP

• No solo la funcionalidad es esencial, también el rendimiento y la confiabilidad.

• RUP ayuda a planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen estas cualidades.



74 l

l l


ll

l

ll l


EL PROCESO UNIFICADO ES ITERATIVO E INCREMENTAL Jacobson, Ivar. El proceso unificado de desarrollo de software. Págs. 6-8

El desarrollo de un producto de software comercial supone un gran esfuerzo quepuede durar entre varios meses hasta posiblemente un año o más. Es práctico divi-dir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es unaiteración que resulta en un incremento.

Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos, alcrecimiento del producto. Para una efectividad máxima, las iteraciones deben estarcontroladas; esto es, deben seleccionarse y ejecutarse de una forma planificada. Espor esto por lo que son miniproyectos.

Los desarrolladores basan la selección de lo que se implementará en una iteraciónen dos factores. En primer lugar, la iteración trata un grupo de casos de uso que jun-tos amplían la utilidad del producto desarrollado hasta ahora. En segundo lugar, la

iteración trata los riesgos más importantes. Las iteraciones sucesivas se construyensobre los artefactos de desarrollo tal como quedaron al final de la última iteración.

Al ser miniproyectos, comienzan con los casos de uso y continúan a través del tra-bajo de desarrollo subsiguiente – análisis, diseño, implementación y prueba –, quetermina convirtiendo en código ejecutable los casos de uso que se desarrollan en laiteración. Por supuesto, un incremento no necesariamente es aditivo.

Especialmente en las primeras fases del ciclo de vida, los desarrolladores puedentener que reemplazar un diseño superficial por uno más detallado o sofisticado.En fases posteriores, los incrementos son típicamente aditivos. En cada iteración,los desarrolladores identifican y especifican los casos de uso relevantes, crean undiseño utilizando la arquitectura seleccionada como guía, implementan el diseñomediante componentes, y verifican que los componentes satisfacen los casos deuso. Si una iteración cumple con sus objetivos – como suele suceder – el desarrollo

continúa con al siguiente iteración.Cuando una iteración no cumple sus objetivos, los desarrolladores deben revisarsus decisiones previas y probar con un nuevo enfoque.

Para alcanzar el mayor grado de economía en el desarrollo, un equipo de proyectointentará seleccionar sóoo las iteraciones requeridas para lograr el objetivo del pro-

yecto. Intentará secuenciar las iteraciones en un orden lógico.

Un proyecto con éxito se ejecutará de una forma directa, solamente con pequeñasdesviaciones del curso que los desarrolladores planificaron inicialmente. Por su-puesto, en la medida en que se añaden iteraciones o se altere el orden de las mis-mas por problemas inesperados, el proceso de desarrollo consumirá más esfuerzo ytiempo. Uno de los objetivos de la reducción del riesgo es minimizar los problemasinesperados.

Son muchos los beneficios de un proceso iterativo controlado:- La iteración controlada reduce el coste del riesgo a los costes de un solo incre-

mento. Si los desarrolladores tienen que repetir la iteración, la organizaciónpierde el esfuerzo mal empleado de la iteración, no el valor del producto ente-ro.

- La iteración controlada reduce el riesgo de no sacar al mercado el producto enel calendario previsto. Mediante la identificación de riesgos en fases tempranasde desarrollo, el tiempo que se gasta en resolverlos se emplea al principio de laplanificación, cuando la gente está menos presionada por cumplir los plazos.

- En el método “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 planificación y casi siempreobliga a retrasar la entrega.





l

ll l


- La iteración controlada acelera el ritmo del esfuerzo de desarrollo en su totalidaddebido a que los desarrolladores trabajan de manera más eficiente para obtener re-sultados claros a corto plazo, en lugar de tener un calendario largo, que se prolongaeternamente.

- La iteración controlada reconoce una realidad que a menudo se ignora – que lasnecesidades del usuario y sus correspondientes requisitos no pueden definirse com-pletamente al principio. Típicamente, se refinan en iteraciones sucesivas. Esta formade operar hace más fácil la adaptación 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 quelos casos de uso definen los objetivos y dirigen el trabajo de cada iteración.

La eliminación de una de las tres ideas reducirá drásticamente 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 vistazoal proceso en su totalidad, su ciclo de vida, artefactos, flujos de trabajo, fases e iteraciones.

I

l

l l

TAREA ACADÉMICA N.º 1Esta actividad puede consultarla en su Aula virtual.



76 l

l l


ll

l

ll l

GLOSARIO DE LA UNIDAD II

Contexto. Porción de la realidad de una organización sobre la cual se realizará el

modelamiento de un software.Diagrama. Es un contenedor de los símbolos y relaciones que constituyen un mode-lo en el desarrollo de software.

Enfoque. Es un conjunto de principios, conceptos y técnicas para la construcciónde un software.

Iteración. Repetición de una fase o flujo de trabajo de un proceso de desarrollo desoftware, para refinar y mejorarlo.

Mensaje. Comunicación entre objetos en el modelamiento de un sistema. Esta co-municación puede ser de solicitudes para que otro objeto realice alguna actividad.

Semántica, Significado de un símbolo según un lenguaje de programación, propor-cionado por el orden en que se escribió.

I

ll

l

ll l

BIBLIOGRAFÍA DE LA UNIDAD II

Arlow, Jim & Neustadt, Ila. (2005). Programación UML 2 . España: Editorial Anaya.

Blanco Cuaresma, Sergi. (2008). Metodologías ágiles de gestión de proyectos . Disponibleen: http://www.marblestation.com/?s=%C3%A1gil

Bravo Lillo, Cristian y Guerrero, Luis. (sin fecha). Métricas de funcionalidad: unataxonomía 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 dedesarrollo de software. España: Editorial Addison Wesley. Biblioteca UC: 005.117 / J132000.

PMOinformática. (sin fecha). Cinco tendencias de metodologías ágiles para 2014. Dis-ponible en: http://www.pmoinformatica.com/2013/12/metodologias-agiles-ten-dencias-2014.html

Universidad Unión Bolivariana.(sin fecha). Metodologías ágiles RUP . Disponible en:http://ingenieriadesoftware.mex.tl/52788_Rup-Agil.html



78 l

l l


c) Adornos de Mecanismos comunes de UML

d) Vista de la Arquitectura de UML

e) Diagramas del Bloque de construcción de UML

8. En UML el diagrama que permite representar los procesos del negocio y losrequerimientos 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 elsistema y sus relaciones es:

a) Diagrama de Colaboración

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 duración de la clase en undeterminado estado es:

a) Diagrama de Estados

b) Diagrama de Estructura Compuesta

c) Diagrama de Tiempo

d) Diagrama de Colaboración

e) Diagrama de Despliegue





l

ll lI

ll

l

ll l

UNIDAD III: RUP Y UML – NEGOCIO Y REQUERIMIENTOS

I

ll

l

ll l

DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD III

CONTENIDOS

AUTOEVALUACIÓN


BIBLIOGRAFÍA

ACTIVIDADES

I

ll

l

ll l



Tema N.° 1: Flujo detrabajo de RUP:Modelado del negocio

1. Evaluación del negocio.

2. Pictográfico situacional y pictográficosolucionador.

3. Reglas del negocio.

4. Diagramas UML: Dia-grama de casos de usodel negocio y diagrama

de objetos del negocio.


Whitten, Jeffrey & Bentley,Lonnie. Punto de vista delos usuarios del sistemaacerca de los procesos.

Análisis de sistemas, dise-ño y métodos. . Pág. 33.

Tema N.° 2: Flujo deTrabajo de RUP: Modela-

do de requerimientos1. Estimación del proyecto.

2. Diagrama UML: Diagra-ma de casos de uso de re-querimientos, plantillas,diagrama de activida-des de requerimiento.


Arlow, Jim & Neustadt,Ila. La Importancia de losrequisitos. ProgramaciónUML 2 . Pág. 33.

Autoevaluación de launidad III

1. Identifica y analiza los ele-mentos de construcciónde los diagramas para elnegocio.

2. Elabora los diagramas deUML para el negocio.

3. Identifica y describe loselementos de construc-ción de los diagramaspara el requerimiento.

4. Elabora los diagramas

de UML para el requeri-miento y los incorpora enel Proyecto de software enequipo.

Actividad N.° 3

Desarrollo de los diagramasdel negocio, según casospropuestos.

Control de Lectura N.º 2

Elabora el informe del mo-

delamiento de software, adjuntando el modelado delnegocio y el modelado derequerimientos.

1. Asume con responsa-bilidad sus actividadesacadémicas asignadas.

2. Realiza con honestidadlas evaluaciones asigna-das.



80 l

l l


TEMA N.° 1: FLUJO DE TRABAJO DE RUP: MODELADO DEL NEGOCIO

A continuación verá un ejemplo que elabora un modelamiento de software aplican-do los flujos de Trabajo (workflow) y las fases del Proceso Unificado con la notaciónUML, considerando la herramienta de modelado Rational Rose.

Iniciamos con el Modelamiento del Negocio, es decir la recopilación de la informa-ción actual de la organización: 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 botón OK.

5. Aparecerá el siguiente entorno gráfico, mostrado en la fig. 71:

Figura 71. Entorno de trabajo de Rational Rose


1 Liza Ávila, César. (2001). Modelando con UML . Perú.





l

ll l


1 EVALUACIÓN DEL NEGOCIO2 Se recopila y organiza la información de la organización y del contexto del negociode cuyo proceso o procesos se realizará el modelamiento de software.

Considere para la organización:

a. Razón social, rubro, tiempo en el mercado, organigrama, visión, misión, oportu-nidades y amenazas, clientes y competidores y objetivos de la organización..

b. Describir los procesos que realiza:

Ejemplo para una Bodega. Vender, Comprar, Inventariar, etc.

Ejemplo para un Colegio. Matrículas, 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, técnico, administrador, etc.).

Considere un caso de ejemploUna farmacia necesita tener un registro de todas las personas que compran susproductos. Para ello cada vez que solicitan sus productos, el vendedor verifica siel producto se encuentra en stock disponible. Si no existe el stock o el nombre deproducto, 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 vaelaborando un informe del nombre del producto que solicitó y no se encuentra enalmacén de la farmacia. En caso de existir, se le informa del precio y se solicita lacantidad que desea llevar, entregándole una nota de pedido con la descripción delproducto, 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), encaso de no serlo, se solicitan sus datos personales, registrándolo como cliente (paraposteriores descuentos y promociones). Todo esto es necesario para poder emitir el

Comprobante de Pago (Boleta o Factura). Con el comprobante el cliente solicitael pedido de productos en el área de entrega de paquetes.

2 PICTOGRÁFICO SITUACIONAL Y PICTOGRÁFICO SOLUCIONADOR Para ayudar a la comprensión de la situación actual de la organización y del nego-cio, se recomienda elabora un cuadro pictográfico situacional, como el de la fig. 72:

Figura 72. Ejemplo de cuadro pictográfico situacional

Fuente: Proyecto Grupal en Ingeniería de Software. 2008

2 Arlow, Jim & Neustadt, Ila. (2005). Programación UML 2 .



82 l

l l


De esta forma se podrá elaborar el Pictográfico Solucionador, es decir con la pro-puesta de solución en base al producto final del modelamiento de software. Obser-

vemos el ejemplo de la fig. 73.

Figura 73. Ejemplo de cuadro pictográfico situacional

Fuente: Proyecto Grupal en Ingeniería de Software. 2008

3 REGLAS DEL NEGOCIOSe debe recopilar y enumerar las restricciones de cada proceso de la organización.

Se sugiere describir con más detalle las restricciones o reglas del negocio delproceso o procesos del cual se realizará el modelamiento de software.

Ejemplo de reglas de negocio para el proyecto de ventas en ingeniería 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 créditos a plazos a las personas que son de de confianza(cliente regular y no tenga deudas).

3. Los pagos se realizarán 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 delproducto.

8. Solo el gerente puede acceder al sistema informático con su respectivacontraseña.

4 DIAGRAMAS UML: DIAGRAMA DE CASOS DE USO DEL NEGOCIO Y DIAGRAMA DE OBJETOS DEL NEGOCIOPara 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. Creación de Diagrama de Paquetes1. En el Business Use Case Model, clic derecho y seleccionar New: Use Case Dia-gram.

2. Asignarle el nombre de DPaquetesFarmacia, como por ejemplo:





l

ll l


Figura 74. Ejemplo de creación de diagrama de casos de uso


3. Doble clic sobre el nuevo diagrama creado y seleccionar de la caja deherramientas: package y crear el paquete, en este caso lo llamaremos farmacia.

Figura 75. Ejemplo de creación de un paquete


4. En el explorador del modelo, arrastrar los paquetes de Almacén, Compras y Ventas hacia el paquete Farmacia, de tal forma que tengan la siguiente vista:

Figura 76. Ejemplo de creación de paquetes para el ejemplo Farmacia


5. Abrir el DPaquetes y arrastrar hacia el diagrama los paquetes de Almacén, Com-pras y Ventas, para poder relacionarlos:

Figura 77. Ejemplo de diagrama para paquetes


6. Crear la relación de dependencia entre paquetes con Dependcy or instantiatesde la Caja de Herramientas, según las dependencias que se hayan analizadocomo por ejemplo:



84 l

l l


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 elestereotipo por Organization Units, realizando clic derecho en cada paquetepara 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 creación 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, según el modelo que seesté realizando, que puede ser de dos maneras:

2.1 Clic derecho en NewClass, Rename y cambiar nombre o también

2.2 Clic derecho o doble clic en NewClass, luego Open Especification y cambiarnombre en Name. Luego clic en el botón Aplicar y después el botón OK.

Figura 80. Ejemplo de creación de un actor






l

ll l


3. En la ventana de especificaciones de este actor cambiar el estereotipo según elcomportamiento que tenga en el proceso del negocio:

3.1 Seleccionar Business Worker si es un actor dentro del negocio que hacealgún proceso. Ejemplo: Cajero, Administrador, etc., o también:

3.2 Seleccionar Business Actor si es un actor fuera del negocio que es afectado

o afecta algún 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 según el modeloque 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 botón Aplicar y después el botónOK.

Figura 82. Ejemplo de creación de casos de uso


3. En la ventana de especificaciones de este actor, cambiar el estereotipo queindica que es un proceso del negocio: Business Use Case.



86 l

l l


4. Repita los pasos anteriores para crear otros Casos de Uso:

Figura 83. Ejemplo de estereotipo de caso de uso


d. Relaciones

1. Para crear la Relación de Asociación:

Clic en el icono Unidireccional Association de la Caja de Herramientas.

2. Clic en un Actor iniciando una comunicación y arrastrar las Asociación hasta unCaso de Uso, como por ejemplo:

Figura 84. Ejemplo de creación de la relación de comunicación


3. Si existiese generalización entre actores seleccionar de la caja de herramientasel icono Generalization y crear la relación desde actor hijo hacia actor padre,según el ejemplo, estamos heredando los roles de un actor padre.





l

ll l


Figura 85. Ejemplo de generalización entre actores


4. Si existiese generalización entre casos de uso seleccionar de la caja de herra-mientas el icono Generalization y crear la relación desde caso de uso hijo haciacaso de uso padre:

Figura 85. Ejemplo de generalización entre casos de uso


5. También se pueden especificar si el caso de uso del negocio afecta o esta relacio-nado con algún objetivo del negocio y/o algún documento del negocio:

Figura 85. Ejemplo de diagrama de casos de uso del negocio




88 l

l l


III. Creando Modelo de Objetos del Negocio para cada Paquete

a. Modelo de Objetos

1. Seleccionar la Vista Logica, Logical View y seleccionar Business Object Model.

2. Clic derecho sobre el paquete Business Object Model y seleccionar New: ClassDiagram.

3. Asignarle el nombre de MONVentas y doble clic para abrir el diagrama paraabrir:

Figura 86. Ejemplo de creación 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. Luego Cambiar el nombre NewClass por el de la Clase según el modelo que seesté realizando, que puede ser de dos maneras:

2.1 Clic derecho en NewClass, Rename y cambiar nombre o:

2.2 Clic derecho ó doble clic en NewClass, luego Open Especification y cambiarnombre en Name y luego clic en el botón Aplicar y después el botón 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






l

ll l


c. Relaciones

1. Arrastrar los workers y business actors necesarios hacia el Modelo de Objetos delNegocio:

Figura 88. Ejemplo de Objetos y Actores del Negocio


2. Seleccionar una relación de Asociación entre el Actor y la Clase entidad delnegocio.

3. Abrir la ventana de especificaciones de la relación e indicar en el nombre de larelación, el rol que realiza el actor respecto a la clase entidad:

Figura 89. Ejemplo de Diagrama de Objetos del Negocio




90 l

l l


IV. Creando Modelo de Dominio para cada Paquete

a. Modelo de Dominio

1. Seleccionar la Vista Logica, Logical View y seleccionar Analysis Model.

2. Clic derecho sobre el paquete Analysis Model y seleccionar New: Class Diagram.

3. Asignarle el nombre de MDominioVentas y doble clic para abrir el diagrama,según el ejemplo:

Figura 90. Ejemplo de creación 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 creación una clase para el dominio






l

ll l


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 derechosobre la clase, seleccionar options y luego seleccionar Suppress Attibutes y Su-ppress Operations:

Figura 92. Ejemplo de creación eliminación de compartimientos


6. Elaborar las relaciones de asociación con Unidirectional Association de la cajade herramientas, entre las clases del dominio y establecer la multiplicidad, que-dado nuestro diagrama:

Figura 93. Ejemplo de diagrama de dominio




92 l

l l

UNIDAD III: RUP Y UML – NEGOCIO Y REQUERIMIENTOSI

ll

l

ll l


PUNTO DE VISTA DE LOS USUARIOS DEL SISTEMA ACERCADE LOS PROCESOS Whitten, Jeffrey & Bentley, Lonnie. Análisis de sistemas, diseño y métodos. Págs. 33-34

Estamos listos para examinar el punto de vista de los usuarios de sistemas acerca de losprocesos. Los usuarios están preocupados por los procesos del negocio o “trabajo”, quedebe ser realizado con el fin de proporcionar las respuestas apropiadas a los sucesosdel negocio. Los usuarios de sistemas especifican el proceso del negocio en términosde requerimientos de proceso para un nuevo sistema. Los requerimientos de procesocon frecuencia están documentados en términos de actividades, flujos de datos o flujode trabajo.

Estos requerimientos de proceso deben ser especificados con precisión, especialmente

si serán automatizados o respaldados por tecnología de software. Los requerimientosde proceso del negocio frecuentemente se definen en términos de políticas y procedi-mientos del negocio, Los procedimientos son los pasos precisos que se deben seguir alcompletar el proceso del negocio.

Considere el siguiente ejemplo: La aprobación de crédito es una política. Establece unconjunto de reglas para determinar si se extiende o no el crédito a un cliente. La políti-ca de aprobación de crédito del cliente generalmente se aplica dentro del contexto deun procedimiento de revisión de crédito específica que estableció los pasos correctospara revisar el crédito contra la política de crédito.

Los requerimientos de proceso también son especificaciones frecuentemente en térmi-nos de flujo de trabajo. La mayoría de las empresas son muy independientes de revisio-nes y autorizaciones para implementar el flujo de trabajo.

Por ejemplo, una requisición de compra puede ser iniciada por cualquier empleado,

pero sigue un flujo de trabajo específico de aprobaciones y revisiones ates de que seconvierta en una transacción de orden de compra que se ingresa a un sistema de pro-cesamiento de información.

Desde luego, estas revisiones y estos balances pueden volverse engorrosos y burocráti-cos. Los analistas de sistemas y los usuarios buscan un equilibrio apropiado entre revi-siones y autorizaciones, servicio y desempeño.

Una vez más, el desafío en el desarrollo de sistemas es identificar, expresar y analizar losrequerimientos del proceso del negocio exclusivamente en términos de negocios quepuedan ser entendidos por los usuarios de sistemas. En este texto se enseñan de maneraamplia herramientas y técnicas para el modelado de procesos y la documentación depolíticas y procedimientos.

Punto de vista de los diseñadores 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 tecnologías de desarrollo de aplicación como Java, Visual Basic.Net, C++,C#. Algunas veces el analista es capaz de elegir la tecnología de software; sin embargo,a menudo las elecciones están limitadas por estándares de arquitectura de software queespecifican que tecnología de software y hardware deben utilizarse. En cualquier caso,el punto de vista de los diseñadores es técnico.

Dado los procesos del negocio desde el punto de vista de los usuarios, el diseñador debeprimero determinar qué procesos automatizar y la mejor forma de hacerlo. Se dibujanmodelos para documentar y comunicar cómo son o cómo serán los procesos del nego-cio seleccionado, implementados con el software y el hardware.

Actualmente muchas empresas adquieren paquetes de aplicación 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 nuncadebe ser construido o que solo el software que proporciona una verdadera ventaja com-petitiva debe ser construido. En el caso de adquisición de software, los procesos delnegocio en general deben ser cambiados o adaptados para trabajar con el software.





l

ll l


Por tanto, en este escenario las especificaciones de diseño de procesos de negociodeben 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 general losprocesos del negocio son primeramente designados y las especificaciones de proce-

sos del negocio deben entonces ser soportadas con especificaciones de software quedocumentan el diseño técnico de los programas de cómputo que serán escritos.

Usted puede haber encontrado algunas de estas especificaciones de software en uncurso de programación. Como fue el caso con el conocimiento, algunos de estospuntos de vista de los procesos pueden entenderse por los usuarios, pero la mayoríano.

La intención de los diseñadores es preparar especificaciones de software que:

1) Satisfagan los requerimientos del proceso del negocio de los usuarios delsistema, y

2) Proporcionen suficiente detalle y consistencia para comunicar el diseño delsoftware a los constructores del sistema.

I

ll l

l l




94 l

l l


TEMA N.º 2: FLUJO DE TRABAJO DE RUP: MODELADO DEREQUERIMIENTOS

En esta etapa, se debe identificar los requisitos del usuario, que serán automatiza-

dos y descritos en el modelamiento del software.Para ello, es necesario realizar la estimación del proyecto de software para evaluarsu factibilidad identificando los recursos (humanos, de equipo y tecnológicos) queposee la organización.

1 ESTIMACIÓN DEL PROYECTOConsidere evaluar el proyecto, indicando en los Costos, si es necesario adquirirnuevos equipos o tecnología, así como determinar en los Beneficios, los rubros conlos cuales la organización tendría ganancias, reflejados en un flujo de caja como elque se muestra:

Con esta información, realizar el Análisis de Rentabilidad calculando el Valor Ac-tual Neto (VAN), la relación Beneficio/Costo, y la Tasa Interna de Retorno (TIR).

2 DIAGRAMA UML: DIAGRAMA DE CASOS DE USODE 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 serán los procesos a modelar en el software.

Requisitos No Funcionales. Atributos que le dan calidad al software.

I. Creación de Paquetes Para Requerimientos Funcionales del Sistema.

1. Clic en Use Case View del Browser para desplegar el menú.

2. Clic 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.





l

ll l


3. Realizar el paso 2 para crear otros paquetes Compras y Almacén si es que sonparte del modelado del sistema:

Figura94. Ejemplo de creación del paquete para requerimientos


II. Creación del Modelo de Casos de Uso de Requerimientos (RequisitosFuncionales del Sistema)

Ejemplo Paquete DCUSistVentas:

a. Diagrama de Casos de Uso

1. Clic derecho sobre el paquete DCUSistVentas y seleccionar New: Use CaseDiagram.Asignarle el nombre de DCUSistVentas.

Figura 95. Ejemplo de creación de un diagrama de casos de uso para los requerimientos




96 l

l l


b. Actores

1. Clic derecho sobre el DCUSistVentas para el menú emergente y seleccionarNew: Actor, llamado NewClass que se ubicará en el browser.

2. Luego Cambiar el nombre NewClass por el del Actor según el modelo que se

esté realizando, que puede ser de dos maneras: 2.1 Clic derecho en NewClass, Rename y cambiar nombre o

2.2 Clic derecho ó doble clic en NewClass, luego Open Especification y cam-biar nombre en Name y luego clic en el botón Aplicar y después el botónOK.

3. El estereotipo esta por defecto para un actor de requerimientos.

Figura 96. Ejemplo de creación 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 según 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 Clic derecho ó doble clic en NewUseCase, luego Open Especification y cam-biar nombre en Name y luego clic en el botón Aplicar y después el botónOK.

3. El estereotipo esta por defecto para un caso de uso de requerimientos:

Figura 97. Ejemplo de creación 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.





l

ll l


3. Para crear la Relación de Asociación: Clic en el icono Unidireccional Associa-tion de la Caja de Herramientas.

4. Clic en un Actor iniciando una comunicación y arrastrar las Asociación hasta unCaso de Uso:

Figura 98. Ejemplo de relación entre actor y caso de uso


5. Para crear la relación 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 Asociación hasta el Caso de Usoincluido.

6. Para crear un estereotipo

Doble clic o clic derecho en la línea de Asociación, Open Specification y en el cam-po Stereotype seleccionar include, clic en el boton Aplicar y luego OK.

7. Repetir el procedimiento por cada Relación Incluye.

Figura 99. Ejemplo de creación de relación incluye




98 l

l l


8. Para crear la relación Extendida

Clic en el icono Dependency or Instantiates de la Caja de Herramientas.

Clic en el Caso de Uso extendido y arrastrar la línea de Asociación hasta el Caso deUso base.

9. Para crear un estereotipo

Doble clic o clic derecho en la línea de Asociación, Open Specification y en el cam-po Stereotype seleccionar extend, clic en el boton Aplicar y luego OK.

10.Repetir el procedimiento por cada Relación Extendida.

Figura 100. Ejemplo de creación de relación extend


11.Si existiese generalización entre actores seleccionar de la caja de herramientasel icono Generalization y crear la relación desde actor hijo hacia actor padre.

12.Si existiese generalización entre casos de uso seleccionar de la caja de herra-mientas el icono Generalization y crear la relación desde caso de uso hijo haciacaso de uso padre.

13.También se pueden relacionar Business Goal y/o Business Document a este tipode caso de uso, a través de la relación de dependencia, quedando nuestro dia-grama:

Figura 101. Ejemplo de creación de Diagrama de Casos de Uso de Requerimiento




100 l

l l


3. Luego Cambiar el nombre NewDiagram por el del Diagrama según el modeloque se esté realizando, Clic derecho en NewDiagram, Rename y cambiar nom-bre por el de DAActualizarDatos.

4. Doble clic para abrir el diagrama de actividades:

Figura 103. Ejemplo de creación del Diagrama de Actividad


b. Crear Carriles

1. Clic derecho sobre el Diagrama de Actividades DAActualizarDatos, luego New, yseleccionar Swimlane.

2. Asignarle un Nombre, mientras se encuentra seleccionado.

3. Arrastrar un carril hacia el Diagrama de Actividades.

Figura 104. Ejemplo de carriles (swimlane)






l

ll l


c. Creando Actividades

1. Clic derecho sobre el Diagrama de Actividades DAActualizarDatos, luego New yseleccionar Activity.

2. Asignarle un Nombre, mientras se encuentra seleccionado.

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

arrastrar las actividades dentro de un carril específico.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 Sincronización

1. Seleccionar de la Caja de Herramientas el icono Horizontal Synchronization o Vertical Synchronization, según se requiera.

2. Arrastrar en el Diagrama de Actividad para separar las actividades.

3. Se realiza esta operación solo si existen actividades concurrentes.

Figura 106. Ejemplo de creación 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 Sincronización, arrastrar hacia o desde él.

Figura 107. Ejemplo creación de transiciones




102 l

l l


f. Creando Puntos de Decisión

1. Seleccionar de la Caja de Herramientas el icono Decision.

2. Arrastrar en la actividad situada para la decisión.

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 condición para ellos.

Figura 108. Ejemplo de creación de condiciones y puntos de decisión


g. Creando estados

1. Crear los Estados Inicial y Final.

2. Además, se pueden indicar los estados en los que se encuentra un objeto dentrodel 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






l

ll l


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 demás casos de uso de requerimientos.



104 l

l l


ll

l

ll l


LA IMPORTANCIA DE LOS REQUISITOS Arlow, Jim & Neustadt, Ila. Programación UML 2. Págs.78-80

La ingeniería de requisitos es un término utilizado para describir las actividadesimplicadas en la obtención, documentación y mantenimiento de un conjunto derequisitos para un sistema de software. Trata acerca de descubrir qué necesitan losgrupos de decisión que el sistema haga por ellos.

Según [Standish Group], requisitos incompletos y la ausencia de implicación deusuario eran las dos razones principales citadas para el fracaso del proyecto. Estosaspectos son fallos en la ingeniería de requisitos.

Puesto que el sistema de software final se basa sobre un conjunto de requisitos, laingeniería de requisitos es un factor crítico de éxito en proyectos de desarrollo desoftware.

Definir Requisitos

Podemos definir un requisito como “una especificación de lo que se debería imple-mentar”. Existen básicamente dos tipos de requisitos:

- Requisitos funcionales. Qué comportamiento debería ofrecer el sistema.

- Requisitos no funcionales. una propiedad específica o restricción del sistema.

Los requisitos son (o al menos debieran ser) la base de todos los sistemas.

Son básicamente una declaración de lo que debería hacer el sistema. En principio,

los requisitos deberían ser solamente una declaración de lo que debiera de hacer elsistema y no de cómo lo debería de hacer.

Esta es un importante distinción, podemos especificar lo que un sistema deberíahacer y qué comportamiento debería mostrar un sistema sin decir necesariamentenada sobre cómo esta funcionalidad debería estar realizada.

Aunque es realmente atractivo, en teoría, separar el “qué” del “cómo”, en la prác-tica, un conjunto de requisitos tenderá a ser una mezcla de “qué” y “cómo”. Estoes en parte porque a menudo es más sencillo escribir y entender una descripciónde implementación en lugar de una declaración abstracta del problema y en parteporque existen restricciones de implementación que predeterminan el “cómo” delsistema.

A pesar del hecho de que el comportamiento del sistema y en último término, lasatisfacción del usuario final se basa sobre la ingeniería de requisitos, muchas em-

presas no reconocen esto como una disciplina importante.Como hemos visto, la razón principal de que los proyectos de software fracasen sedebe a problemas en requisitos.

El Modelo de Requisitos

Muchas empresas todavía no tienen una noción formal de requisitos o de un mode-lo de requisitos. El software se especifica en uno o más “documentos informales derequisitos”, que a menudo se escriben en lenguaje natural y se presentan en cual-quier forma y tamaño y en varios grados de utilidad.

Para cualquier documento de requisitos, en cualquier forma, las preguntas clavesson, “¿qué utilidad tiene para mí?” y “¿me ayuda a entender lo que el sistema debe-ría hacer o no?”.

Desafortunadamente, muchos de estos documentos informales son solamente deutilidad limitada.

UP (Proceso Unificado). Tiene un enfoque formal a los requisitos basándose en unmodelo de caso de uso y lo ampliamos aquí con un modelo de requisitos basándose





l

ll l


en ideas tradicionales de requisitos funcionales y no funcionales.

Esta extensión se encuentra en relación directa al enfoque más sofisticado de laingeniería de requisitos en RUP. Nuestro meta modelo de requisitos muestra que elSRS (Software Requeriments Specification) consta de un modelo de casos de uso yun modelo de requisitos.

El modelo de caso de uso normalmente se crea en una herramienta de modeladoUML como Rational Rose.

El modelo de requisitos se puede crear en texto o en herramientas de ingeniería derequisitos especiales como RequsitePro (www.ibm.com) o DOORS (www.telelogic.com) . Le recomendamos que utilice herramientas de ingeniería de requisitos si esposible.

Requisitos bien formados

UML no proporciona ninguna recomendación 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-ción de requisitos.

Recomendamos un formato muy sencillo para indicar requisitos, como en la figuramostrada. Cada requisito tiene un identificador único (normalmente un número),una palabra clave (debería) y una declaración de función.

La ventaja de adoptar una estructura uniforme es que herramientas de adminis-tración de requisitos como DOORS pueden analizar los requisitos más fácilmente.

Figura 111. Formato para indicar requisitos

Fuente: Arlow, Jim & Neustadt, Ila. Programación UML 2.I

ll

l

ll l

CONTROL DE LECTURA N.º 2Esta actividad puede consultarla en su Aula virtual.



106 l

l l


ll

l

ll l

GLOSARIO DE LA UNIDAD III

Herramienta. Instrumento de software que permite el modelado de software.

Modelo de dominio. Es un diagrama de clases preliminar, basado en los objetos yactores del negocio.

Negocio. Área o áreas; proceso o procesos de la organización y del cual se desarro-llará el modelo de software.

Plantilla. Documento que describe en detalle a un caso de uso y que complementaal modelo de software.

Poscondición. Regla de negocio o restricción como consecuencia de la ejecuciónde un caso de uso.

Precondición. Regla del negocio o restricción, necesario antes de ejecutar un casode uso.

I

ll

l

ll l

BIBLIOGRAFÍA DE LA UNIDAD III

Arlow, Jim & Neustadt, Ila. (2005). Programación UML 2 . España: Editorial Anaya.

Liza Ávila, César. (2001). Modelando con UML . Perú: Editorial RJ.

Romero Moreno, Gesvin. (2004). UML con Rational Rose . Perú: Editorial Megabyte.

Whitten, Jeffrey & Bentley, Lonnie. (2008). Análisis de sistemas, diseño y métodos .México: Editorial McGraw-Hill. Biblioteca UC: 658.4032 / W54 2008.



108 l

l l


7. Es una relación que indica que un caso de uso base, requiere la ejecución previade otro caso de uso:

a) Extend

b) Generalización

c) Include

d) Agregación e) Comunicación

8. Es una relación que indica que un caso de uso, se ejecuta si el caso de uso baselo requiere, es decir su ejecución es opcional:

a) Composición

b) Extend

c) Generalización

d) Inlcude

e) Comunicación

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 Sincronización

b) Carril de Actividad

c) Flujo de Actividad

d) Estado de Inicio

e) Punto de Decisión

10.En el diagrama de actividades, es un elemento que permite agrupar las tareasque se pueden realizar en forma paralela, sin importar en que carril se ejecute.

a) Estado de Inicio

b) Punto de Decisión c) Estado Final

d) Barra de Sincronización

e) Carril de Actividad





l

ll lI

ll

l

ll l

UNIDAD IV: RUP Y UML – ANÁLISIS, DISEÑO E IMPLEMENTACIÓN

I

ll

l

ll l

DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD IV

CONTENIDOS

AUTOEVALUACIÓN


BIBLIOGRAFÍA

ACTIVIDADES

I

ll

l

ll l



Tema N.° 1: Flujo de trabajode RUP: Modelado de análisis

1. Diagrama UML: dia-grama de clases y es-tereotipos de clase.

2. Diagrama UML: Diagramade secuencia, diagrama decolaboración.

Tema N.° 2: Flujo de trabajode RUP: Modelado de diseño

1. Diagrama UML: Subsiste-mas e interfaces, modeloarquitectónico

2. Diagrama UML: Diagramade estados.


Tipos de Interfaz de usuario Análisis y diseño de SistemasKendall, Kenneth & Kendall ,

Julie. Pág. 497.

Tema N.° 3: Flujo de trabajode RUP: Modelado de imple-mentación

1. Diagrama UML: Diagramade componentes.

2. Diagrama UML: Diagramade despliegue.

Tema N.° 4: Transformaciónal modelo de datos

1. Clases persistentes.

2. Generación del modelo dedatos.


Piattini, Mario., Marcos, Espe-ranza., Calero, Coral. Domi-nio y atributo. Tecnología ydiseño de base de Dato. Pág.164.

Autoevaluación de launidad IV

1. Identifica y describe loselementos de construc-ción de los diagramaspara el análisis y el diseño.

2. Elabora los diagramas deUML para el análisis y eldiseño.

3. Identifica y analiza los ele-mentos de construcciónde los diagramas para laimplementación.

4. Elabora los diagramas deUML para la implemen-tación y los incorpora enel proyecto de software enequipo.

Actividad N.° 4

Desarrollo de los diagramasdel análisis y diseño, segúncasos propuestos.

Tarea académica N.º 2

Elabora el informe com-pleto del modelamiento desoftware, adjuntando el mo-delado del análisis, diseño eimplementación.

1. Asume con respon-sabilidad sus activi-dades académicasasignadas.

2. Realiza con honesti-dad las evaluacionesasignadas.





l

ll l


Figura114. Ejemplo de clase con estereotipo


2. Clic derecho en el paquete ClasesVentas para el menú emergente y seleccionarNew : Clase, llamado NewClass que se ubicará en el browser.

3. Luego Cambiar el nombre NewClass por el de la Clase según el modelo que se

esté realizando, que puede ser de dos maneras: 3.1 Clic derecho en NewClass, Rename y cambiar nombre, ó:

3.2 Clic derecho ó doble clic en NewClass, luego Open Especification y cambiarnombre en Name y luego clic en el botón Aplicar y después el botón OK.

4. Repita los pasos anteriores para crear otras clases.

Figura 115. Ejmplo de creación de clase para el análisis


b. Atributos

1. Para crear los atributos de una clase:

1.1Clic derecho en una clase y elegir New Attribute, o:

1.2Clic derecho en la clase y elegir Open Specification y luego Attributes.

2. Luego Cambiar el nombre por el del atributo de la Clase según el modelo. quese esté realizando, que puede ser de dos maneras:

2.1 Clic derecho en name, Rename y cambiar nombre o

2.2 Clic derecho ó doble clic en name, luego Open Especification y cambiarnombre en Name y luego clic en el botón Aplicar y después el botón OK.





l

ll l


Figura 118 Ejemplo creación de una operación para la clase


3. Para especificar la Visibilidad de la Operación: Clic derecho ó doble clic en laoperación, luego Open Especification y seleccionar en Export Control: Public,Protected, Private y luego clic en el botón Aplicar y después el botón OK.

4. También se puede especificar los argumentos de la operación.

Figura 119. Ejemplo creación de detalles de una operación


c. Estereotipos de Clase

1. Puede definir los estereotipos de clase: Entidad (Entity), Entorno (Boundary) yControl (Control) en la ventana de especificaciones de la clase.

Figura 120. Ejemplo de creación de estereotipo de clase




114 l

l l


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.

e. Relaciones

1. Para crear la Relación de Asociación: Clic en el icono Unidireccional Association de la Caja de Herramientas.

2. Clic en un Clase iniciando y arrastrar la Relación hasta otra clase.

Figura 121. Ejemplo de relación de asociación


3. Se puede dar nombre y roles a la relación. Ejemplo. Relación de asociaciónentre Usuario e IniciaSesion:

Figura 122. Ejemplo de rol en una asociación


4. Para crear la Relación de Generalización:

Clic en el icono Generalization de la Caja de Herramientas.

5. Clic en un Clase Hija y arrastrar la Relación hasta la Clase Padre.





l

ll l


Figura 123. Ejemplo de generalización entre clases


6. Para asignar multiplicidad en una relación, ingresar al detalle de rol de una delas clases y seleccionar Multiplicity.

Figura124. Ejemplo de multiplicidad en una relación


7. Para asignar la composición entre clases se realiza una relación de agregación,seleccionar de la caja de herramientas Unidireccional Aggregation, arrastrar dela 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 creación de relación de composición


8. Realizar lo mismo para las demás clases relacionadas.



116 l

l l


9. Al final el diagrama de clases:

Figura 125. Ejemplo de Diagrama de Clases con estereotipo


2 DIAGRAMA UML: DIAGRAMA DE SECUENCIA /

DIAGRAMA DE COLABORACIÓNEn 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. Realización 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 AnálisisModel, 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 creación de Diagrama de Casos de Uso de Realización


4. Crear un caso de uso, ejemplo IniciarSesion.

5. Abrir la ventana de especificaciones de este caso de uso y cambiar el estereotipoa use/case realization.





l

ll l


Figura 127. Ejemplo de creación de casos de uso de realización


6. Por cada caso de uso de requerimiento, crear el caso de uso que realizará elalgoritmo.

7. Arrastrar al DCURVentas, los casos de uso de requerimientos delDCUSistVentas.

8. Establecer la relación de asociación y cambiar el estereotipo por realize.

Figura 128. Ejemplo de creación de relación realize


9. Realizar el mismo procedimiento para los demás casos de uso.

II. Modelo de Secuencia

a. Crear del Diagrama de Secuencia

1. Seleccione un caso de uso de realización, Ejemplo IniciarSesion.

2. Clic derecho, seleccione New: Sequence Diagram.

3. Asignarle el nombre de DSIniciarSesion, doble clic para abrir el diagrama.



118 l

l l


Figura 29. Ejemplo de creación de Diagrama de Secuencia


b. Crear Objetos y Líneas de Vida

1. Arrastrar del paquete DCUSistVentas (Use Case Model), al actor del negocioUsuario, hacia el diagrama de secuencia.

2. Arrastrar del paquete ClasesVentas (Locical View-Analysis Model), a la claseboundary IniciarSesionC, hacia el diagrama de secuencia.

3. Realizar el paso el mismo procedimiento para pasar las clases necesarias aldiagrama 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 unobjeto a otro, ejemplo del actor Usuario hacia la clase IniciarSesion.

Figura 131. Ejemplo de creación 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.



120 l

l l


4. Para crear un mensaje de retorno:

4.1 Realizar un mensaje simple entre un objeto receptor hacia el emisor con surespectivo mensaje.

4.2 Seleccionar el mensaje simple, doble clic para abrir la ventana deespecificaciones.

4.3 Seleccionar Detail y elegir Return.

Figura 135. Ejemplo de creación de mensaje de retorno


5. Para crear un mensaje recursivo:

5.1 Seleccione de la Caja de Herramientas a Message to Self y diagrame hacia elmismo 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 operación (actividad) que realice el objeto a través de mensajes, agrupe dichos mensajes en un mismo foco de control.

3. Realizar los mismos pasos para crear un diagrama de secuencia por cada caso deuso de realización.

4. El Diagrama de Secuencia final:





l

ll l


Figura 137. Ejemplo de diagrama de secuencia en el análisis


III. Modelo de Colaboración

a. Crear del Diagrama de Colaboración

1. Seleccione un diagrama de secuencia, Ejem. DSIniciarSesion.

2. Pulsar el botón F5 para crear el respectivo Diagrama de Colaboración.

3. Dar el nombre de DCIniciarSesion.



122 l

l l


4. Realizar el mismo procedimiento para crear cada diagrama de colaboración.

Figura 138. Ejemplo de diagrama de colaboración




124 l

l l


II. Interfaces

a. Crear Interfaces

1. En el diagrama de subsistemas, seleccionar de la caja de herramientas.

Figura 142. Ejemplo clase interface


2. Crear las interfaces proporcionadas por cada subsistema, por ejemplo Gestor-Cliente, GestorFacturación, GestorPedido.

Figura 143. Ejemplo de subsistemas e interfaces


3. Para relacionar las interfaces con los subsistemas se debe seleccionar Realice.

Figura 144. Ejemplo de relación realize para los subsistemas


4. Se debe tener en cuenta si son proporcionadas o requeridas.

Figura 145. Ejemplo de subsistemas e interfaces relacionadas






l

ll l


b. Clases de Diseño

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 creación de clases para el diseño


3. Crear las clases de diseño, refinando las clases de análisis con sus respectivosestereotipos, 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 Typee Inicial Value.

5. Para especificar el Tipo de Dato de Retorno de la operación y Valor inicial delatributo (opcional): Clic derecho ó doble clic en la operación, luego Open Es-pecification y seleccionar en Return Type.

6. También se puede especificar los argumentos de la operación, en Detail, clicderecho para Insert y dar el nombre del argumento y el tipo de dato.

7. Repita los pasos anteriores para las otras clases de diseño.

c. Relaciones de Diseño


2. Clic derecho en Logical View para el menú emergente y seleccionar DesignModel y crear el paquete ClasesDisenoVentas.

3. Clic derecho en el paquete creado, New y seleccionar Class Diagram y dar elnombre de DClasesDiseno, doble clic para abrirlo.

4. Arrastrar las clases del diseño de cada subsistema hacia el diagrama de clases.

5. Se debe mejorar e incrementar si es necesario las relaciones de asociación, he-rencia, agregación y composición, garantizando la alta cohesión y el bajo acopla-

miento.

d. Realización de Casos de Uso


2. Clic derecho en Logical View para el menú emergente y seleccionar DesignModel, luego seleccionar Use Case Realizations, y luego Use Case Name.

3. En este último paquete, crear los casos de uso de realización del diseño para loscasos de uso de análisis, ejemplo IniciarSesion.

4. Abrir la ventana de especificaciones de este caso de uso y cambiar el estereotipoa use case realization.



126 l

l l


Figura 147. Ejemplo de creación de casos de uso de realización del diseño


5. En el paquete Use Case Realizations crear el diagrama de clases DCUR Ventas, dobleclic para abrirlo.

6. Arrastrar los casos de uso de realización del diseño hacia el diagrama con sus respecti- vos casos de uso de realización del análisis.

7. Establecer la relación de asociación y cambiar el estereotipo por realice.

Figura 148. Ejemplo de creación relaciones de casos de uso del diseño


8. Realizar el mismo procedimiento para los demás casos de uso del diseño.

e. Diagrama de Secuencia

1. Seleccione un caso de uso de realización 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 diseño, crear el diagrama de secuencia

por cada caso de uso del diseño.

f. Modelo Arquitectónico

1. Seleccionar Layer, luego New y seleccionar Activity Diagram, darle el nombre deModeloArquitectura, 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 arquitectónico




128 l

l l


b. Creación 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.

c. Creación 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 creación de un estado


3. Crear las Acciones del Estado:

3.1 Clic derecho en el Estado para asignarle una Acción, luego Open Especifica-tion y seleccionar Actions.

3.2 Clic derecho y seleccionar Insert y aparecerá la acción Entry/.

3.4 Clic derecho en la acción creada para abrir la ventana de especificaciones ydarle un nombre.

Figura 154. Ejemplo de creación de detalle de un estado


3.5 Si desea modificar Entry/ por otra acción, solo tiene que hacer clic derechoen la Acción y elegir Especification.

3.6 En Especification, en el Detalle elegir de When la accion deseada, porejemplo Do/.

3.7 Luego en Name especificar la acción correspondiente y Aceptar.



130 l

l l


6.3 El Diagrama estados queda así:

Figura 157. Ejemplo de diagrama de estados para una clase


d. Diagrama de Actividad

1. Seleccione un caso de uso de realización del Diseño, 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 creación de diagrama de actividades para el diseño






l

ll l


4. Considerando las nuevas clases refinadas del diseño, crear el diagrama deactividades por cada caso de uso del diseño.

5. Crear los swimlanes por cada clase.

6. Arrastrar una clase del diseño hacia el campo del nombre de un swimlane.

7. Crear las actividades en cada swimlane.8. Realizar para cada caso de uso de realización del diseño.

Figura 159. Ejemplo de diagrama de actividades del diseño




132 l

l l

UNIDAD IV: RUP Y UML – ANÁLISIS, DISEÑO E IMPLEMENTACIÓNI

ll

l

ll l


TIPOS DE INTERFAZ DE USUARIOKendall, Kenneth & Kendall, Julie. Análisis y diseño de Sistemas. Págs. 497-504

En esta sección se describen varios tipos de interfaces de usuario, entre ellas las siguien-tes: Interfaces de comunicación natural, interfaces de pregunta y respuesta, menús, for-mularios, interfaces de lenguaje de comandos, interfaces gráficas de usuario (GUI), una

variedad de interfaces web para uso en internet.

La interacción de usuario tiene dos componentes principales: el lenguaje de presen-tación, que es la parte de la computadora/humano de la transacción y el lenguaje deacción, que caracteriza la parte humano/computadora. En conjunto, ambos conceptoscubren la forma y contenido del término interfaz del usuario.

Interfaces de lenguaje natural“Las interfaces de lenguaje natural son quizá el sueño e ideal de usuarios inexpertos, de-bido a que permiten a usuarios interactuar con la computadora en su lenguaje cotidianoo natural.

No se requieren habilidades especiales de usuarios, quienes interactúan con la computa-dora mediante lenguaje natural.

Las sutilezas e irregularidades que residen en las ambigüedades del lenguaje natural pro-ducen un problema de programación sumamente exigente y complejo. Los intentos porinteractuar con lenguaje natural para algunas aplicaciones en las cuales cualquier otrotipo 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 soncaras. Los problemas de implementación y la demanda extraordinaria en los recursos deinformática hasta ahora han mantenido las interfaces de lenguaje natural a un mínimo.

Sin embargo, la demanda existe y muchos programadores e investigadores están traba- jando diligentemente en las interfaces de lenguaje natural. Es una área de crecimiento y,por lo tanto, merece supervisión 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 (mediantepulsaciones del teclado o un clic del ratón) y la computadora después actúa en esa infor-mación de entrada de acuerdo con su programa, normalmente pasando a la siguientepregunta. …”

Menus

“Una interfaz de menús adquiere apropiadamente su nombre de la lista de platillos quese 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 nonecesita conocer el sistema pero tiene que saber qué tarea se debe realizar. Por ejemplo,con un menú típico de procesamiento de texto, los usuarios pueden escoger opcionespara editar, copiar o imprimir. Sin embargo, para utilizar el mejor menú los usuarios de-ben saber qué tarea desean desempeñar.

Los menús no dependen del hardware. Las variaciones abundan. Los menús se estable-cen para usar el teclado, lápiz óptico o el ratón. Las selecciones se pueden identificarcon un número, carta o palabra clave. La consistencia es importante en el diseño de unainterfaz de menú…”





l

ll l


“... Los menús 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 artículos del menú. Las opcionesde menú principales siempre despliegan menús desplegables secundarios.

3. El menú principal debe tener opciones secundarias agrupadas en grupos simila-res de características.

4. Los menús desplegables que se presentan cuando se hace clic en un artículo demenú principal con frecuencia consisten en más de una palabra.

5. Estas opciones secundarias desempeñan acciones o despliegan artículos de menúadicionales.

6. Los artículos de menú en gris no están disponibles para la actividad actual.

Un menú de objeto, también llamado menú desplegable independiente, se des-pliega cuando el usuario hace clic en un objeto de la GUI con el botón derechodel ratón. Estos menús contienen artículos específico para la actividad actual y lamayoría es funciones duplicadas de artículos de menú principales…”

Interfaces de formulario (formularios de entrada/salida)“Las interfaces de formulario consisten de formularios en pantalla o formulariosque se basan en la Web que despliegan campos que contienen datos o parámetrosque necesitan ser comunicados al usuario. El formulario a menudo es un facsímilde un formulario impreso que ya es familiar para el usuario. Esta técnica de inter-faz también se conoce como método basado en el formulario y en formularios deentrada/salida…”

“... Hay algunas desventajas con los formularios de entrada/salida. La desventajaprincipal es que los usuarios experimentados se podrían impacientar con estos for-mularios y querrían formas más eficaces para introducir datos.”

Interfaces de lenguaje de comandos

“Una interfaz de lenguaje de comandos permite al usuario controlar la aplicacióncon una serie de pulsaciones del teclado, comandos, frases o alguna secuencia deestos tres métodos. Es una interfaz popular que es más refinada que las discutidasanteriormente.

“…Los lenguajes de comandos manipulan a la computadora como una herramien-ta para permitir al usuario controlar el diálogo. El lenguaje de comandos ofrece alusuario mayor flexibilidad y control.

Cuando el usuario da una instrucción a la computadora mediante lenguaje de co-mandos, se ejecuta de inmediato por el sistema. Después el usuario podría proce-der para dar otra instrucción.

Los lenguajes de comandos requieren memorizar las reglas de sintaxis, esto gene-ralmente es un obstáculo para los usuarios inexpertos. Los usuarios experimenta-dos tienden a preferir los lenguajes de comandos, posiblemente porque les permite

trabajar más rápido…”

Interfaces gráficas de usuario

“Las interfaces gráficas de usuario (GUI) permiten la manipulación directa de larepresentación gráfica en pantalla, la cual se puede realizar con la entrada del te-clado, una palanca de juego o el ratón. La manipulación directa requiere mayorsofisticación del sistema que las interfaces vistas anteriormente.

La clave para las GUI es la retro alimentación constante que proporcionan. La re-troalimentación contínua en el objeto manipulado significa que se pueden hacerrápidamente los cambios o incluso cancelar operaciones sin incurrir en mensajesde error…”



134 l

l l


Otras interfaces de usuario

“Otras interfaces de usuario, aunque menos comunes que las discutidas anterior-mente, están ganando popularidad. Estas interfaces incluyen dispositivos de indi-cación tal como el lápiz óptico, pantallas sensibles al tacto y reconocimiento de voz

y síntesis. Cada una de estas interfaces tiene sus propios atributos especiales que

corresponden de forma única a aplicaciones particulares.

El lápiz óptico (un palo puntiagudo que parece pluma) se está volviendo populardebido al nuevo software de reconocimiento de escritura y a los asistentes digitalespersonales (PDA). Los dispositivos Palm y Pocket/PC han sido un éxito porque ha-cen muy bien un número limitado de cosas y se venden a un precio bajo. Las com-putadoras portátiles como éstas incluyen un calendario, directorio, agenda y blockde notas. La entrada de datos también se facilita con una estación de acoplamientopara que pueda sincronizar los datos con su PC…”

I

ll

l

ll l




136 l

l l




d. Asignación 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 más clases para el mismo componente.

Figura 162. Ejemplo de asignación de clase a un componente Fuente: Rojas Moreno, Carol Roxana



138 l

l l


TEMA N.º 4: TRANSFORMACIÓN AL MODELO DE DATOS

Para este último tema usted debe revisar sus conocimientos acerca de la creaciónde una base de datos, las claves principales y relaciones entre tablas de un ModeloLógico hacia un Modelo Físico, para identificar y asignar las clases necesarias paraelaborar el modelo de datos para el software.

1 CLASES PERSISTENTES 4

Identificamos y asignamos las clases necesarias para elaborar el modelo de datospara el software.

1. Tener el modelo de Clases del diseño en un PAQUETE específico, dentro delpaquete 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 asignación 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 asignación de clave candidata


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





l

ll l


2 GENERACIÓN DEL MODELO DE DATOSEn esta fase se diseña el contenedor del Modelo de Datos y el Gestor de Base deDatos 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 creación 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 lasclases.

2.2 Seleccionar Data Modeler > Transform to Data Model.

Figura 167. Ejemplo de transformación a modelo de datos




140 l

l l


2.1 Al transformar a un modelo de datos se crea automáticamente un esquema:

Figura 168. Ejemplo de creación de un esquema para datos


2.2 Click en la lista de Destination Schema para indicar el nombre del esquema oentrar 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 selección 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.





l

ll l


Figura 170. Ejemplo de creación del diagrama de modelo de datos


3.3 Clic derecho nuevo modelo de datos del esquema en el navegador y darle elnombre 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 diagramade 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.





l

ll l

UNIDAD IV: RUP Y UML – ANÁLISIS, DISEÑO E IMPLEMENTACIÓNI

ll

l

ll l


DOMINIO Y ATRIBUTOPiattini, Mario., Marcos, Esperanza., Calero, Coral. Tecnología y Diseño de basede datos. Págs. 164-166

Un dominio D es un conjunto finito de valores homogéneos y atómicos V1 , V2, … Vn,caracterizado por un nombre; decimos valores homogéneos porque son todos del mis-mo tipo y atómicos por que son indivisibles en lo que al modelo se refiere, es decir, si sedescompusiesen, perderían la semántica a ellos asociada.

Por ejemplo, el dominio de nacionalidades tiene los valores: Española, Francesa, Nor-teamericana, etc. que son todos del mismo tipo y que no son divisibles sin perder susemántica; así si descompusiéramos el valor “española” en las letras “E”, “S”, “P”, etc. seperdería la semántica, ya que estas letras consideradas aisladamente han dejado de tenerel significado que tiene “española” como valor de la nacionalidad.

Todo dominio ha de tener un nombre, por el cual nos podemos referir a él y un tipode dato; así, el tipo de dato del dominio de nacionalidades es una tira de caracteres delongitud de diez.

También se le puede asociar una unidad de medida, como metros, kilos, etc., y ciertasrestricciones.

Los dominios pueden definirse por intensión o por extensión. Por ejemplo, el dominiode las edades de las personas activas se puede definir por intensión como entero delongitud dos comprendido entre 18 y 65, mientras que la definición del dominio denacionalidades por intensión sería muy pobre semánticamente, ya que permitiría todacombinación de 10 letras aun cuando no constituyesen un nombre válido de nacionali-dad; por ello, sería preferible definir este dominio por extensión con los nombres de lasdistintas nacionalidades que admitiésemos en nuestra base de datos.

Se podría pensar que un dominio es igual que una relación de grado 1 (con un únicoatributo).

Sin embargo, esto no es cierto, ya que el dominio contiene todos los posibles valores quepuede tomar un atributo y es estático (estos valores no varían en el transcurso del tiem-po), en cambio la relación es dinámica por su misma naturaleza; además de los dominiosdesempeñan un papel importante y característico en ciertas operaciones.

Un atributo A es el papel que tienen un determinado dominio D en una relación; se diceque 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 referidatabla.

El universo del discurso de una base de datos relacional representado por U, está com-puesto por un conjunto finito y no vacío de atributos, A1, A2, …, An, estructurados enrelaciones; 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 deque 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 conel mismo nombre.

Además de los dominios y atributos simples, que acabamos de definir, en los trabajosposteriores de algunos autores, CODD (1990), DATE (1990), se introduce el conceptode dominio compuesto.





l

ll l


d) Estado final

e) Acción

7. Es un diagrama de UML que modela la dependencia de un archivo o libreríacon respecto a otro, y que el software lo requiere para su ejecución:

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 conexionesque el software requiere para su ejecución:

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 quepermite la ejecución 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, según el gestor de base de datos definido, debido a que sele considerará:

a) Clase Persistente

b) Clase Control

c) Clase Entity

d) Clase Asociación

e) Clase Boundary



148 l

l l

ANEXO

I

ll

l

ll l

ANEXO: CLAVES DE AUTOEVALUACIONES

N.º Rpta.

1 b2 c3 d4 b5 a6 d7 e8 b9 d

10 a

N.º Rpta.

1 e2 c3 a4 c5 b6 d7 c

8 b9 b

N.º Rpta.

1 c2 b3 d4 d5 c6 a7 b8 d9 b10 c

N.º Rpta.

1 e2 b3 a4 c5 b6 e7 c

8 b

AUTOEVALUACIÓN DE LA UNIDAD I

AUTOEVALUACIÓN DE LA UNIDAD III

AUTOEVALUACIÓN DE LA UNIDAD II

AUTOEVALUACIÓN DE LA UNIDAD IV

a0248 ingeniería de software mau01

Documents