Libro Ingenieria SW Ok

UNIVERSIDAD PERUANA LOS ANDES
FACULTAD DE INGENIERÍA
EDUCACIÓN A DISTANCIA
INGENIERÍA DE SOFTWARE
INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

Ing. Wagner Enoc Vicente Ramos
HUANCAYO - PERÚ
2011
TABLA DE CONVERSIONES
Copyright 2011 UNIVERSIDAD PERUANA LOS ANDES
Dirección de Educación a Distancia

Huancayo
Impresión Digital a cargo de

PERU GRAPH SRL
Jr. Arequipa Nº 377 - Huancayo
Ing. Wagner E. Vicente Ramos 2

PRESENTACIÓN
El software de computadora es el producto que los ingenieros de
software construyen y después mantienen en el largo plazo. En los pasados
50 años, el software ha evolucionado desde una herramienta para la
solución de problemas especializados y el análisis de información, hasta
convertirse en una industria por sí mismo; siendo el desarrollo más
significativo la aparición de UML como estándar para la descripción de
sistemas orientados a objetos.
En la actualidad esta industria del software se ha convertido en un

factor dominante en la economía del mundo industrialziado, donde el
programador solitario de la era inicial ha sido sustituido por equipos de
especialistas en software, en los que cada uno enfoca una parte de la
tecnología requerida para desarrollar una aplicación compleja. Nuestros
servicios e infraestructuras nacionales – energía, comunicaciones y
transporte – dependen de sistemas informáticos grandes, complejos y
fiables. En la construcción de sistemas software se mezclan muchas
tecnologías – J2EE, .NET, EJB, SAP, BPEL4WS, SOAP, CBSE.
El presente texto trata de cubrir los aspectos más importantes de la

Ingeniería del software como disciplina. Es así que en la primera unidad se
tratan aspectos generales de la Ingeniería del software para introducir al
lector en el tema, posteriormente se tratan las diversas metodologías de
proceso de desarrollo de software eligiendo a RUP como guía para el
desarrollo de proyectos de software.
EL AUTOR.

TABLA DE CONTENIDOS
UNIDAD ACADÉMICA Nº 01
INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE
1.1. ¿QUÉ ES INGENIERÍA DE SOFTWARE? ............................................. 7
1.2. LA EVOLUCIÓN DEL SOFTWARE .......................................................... 9
1.3. CATEGORÍAS DEL DESARROLLO DE SOFTWARE ........................ 10
1.4. MITOS DEL SOFTWARE ........................................................................ 11
1.5. INDUSTRIA DEL SOFTWARE EN EL PERÚ ....................................... 13
PROCESO DEL DESARROLLO DEL SOFTWARE
2.1. CAPAS DE LA INGENIERÍA DEL SOFTWARE ................................... 19
2.2. MARCO DE TRABAJO PARA EL PROCESO ...................................... 20
2.3. CICLO DE VIDA DEL SOFTWARE ........................................................ 23
2.3.1. Elementos Del Ciclo De Vida....................................................... 23
2.3.2. Fases genéricas en el ciclo de vida del SW .............................. 25
2.4. PROCESO DEL CICLO DE VIDA DEL SOFTWARE SEGÚN NTP-
ISO/IEC 12207 - 2008 .............................................................................. 25
2.4.1. Procesos Principales..................................................................... 26
2.4.2. Procesos de Soporte ..................................................................... 26
2.4.3. Procesos Generales ...................................................................... 27
2.5. PROCESO DEL DESARROLLO DE SOFTWARE SEGÚN NTP-
ISO/IEC 12207 - 2008 .............................................................................. 27
2.6. MODELOS DEL CICLO DE VIDA DEL DESARROLLO DE
SOFTWARE ............................................................................................... 27
METODOLOGÍAS PARA EL DESARROLLO DE SOFTWARE
3.1. ¿QUÉ ES LA METODOLOGÍA DE DESARROLLO DE SW? ............ 40
3.2. PUNTOS PRIMORDIALES QUE DEBE TENER UNA
METODOLOGÍA ........................................................................................ 41
3.3. EVOLUCIÓN DE LAS METODOLOGÍAS DE SOFTWARE ............... 42

3.4. CLASIFICACIÓN DE LAS METODOLOGÍAS DE SOFTWARE ........ 43
3.5. ¿QUÉ METODOLOGÍA DEBO UTILIZAR? .......................................... 46
MODELADO DEL NEGOCIO CON RUP Y UML
4.1. MODELADO DEL PROCESO DE NEGOCIOS .................................... 60
4.2. TIPOS DE ENFOQUES DEL MODELADO DE NEGOCIO ................ 61
4.3. ¿PORQUÉ MODELAR NEGOCIO ANTES DE MODELAR EL
SISTEMA? .................................................................................................. 62
4.4. EL MODELADO DE NEGOCIO ORIENTADO A OBJETOS .............. 65
4.5. RUP Y EL MODELADO DE NEGOCIO ................................................. 66
4.6. MODELADO DEL NEGOCIO DEL SISTEMA DE ALMACEN ........... 81
4.7. DOCUMENTACIÓN HASTA EL MODELO DE NEGOCIOS .............. 94
INGENIERÍA DE REQUERIMIENTOS CON RUP Y UML
5.1. FLUJO DE TRABAJO DE REQUISITOS .............................................. 98
5.2. CARACTERÍSTICAS DE LOS REQUERIMIENTOS. .......................... 99
5.3. DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS ........... 100
5.4. IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS: ...... 100
5.5. PROCESO DE INGENIERÍA DE REQUERIMIENTOS ..................... 101
5.6. HERRAMIENTAS PARA LA RECOLECCIÓN DE
REQUERIMIENTOS ............................................................................... 102
5.7. ACTIVIDADES PARA OBTENER REQUERIMIENTOS ................... 102
5.8. MODELADO DE REQUERIMIENTOS A PARTIR DEL MODELO
DE NEGOCIOS........................................................................................ 103
5.9. DOCUMENTACIÓN DE REQUERIMIENTOS CON RUP Y UML ... 112
ANÁLISIS Y DISEÑO DEL SOFWARE CON RUP Y UML
6.1. PROCESO DE ANÁLISIS Y DISEÑO DE RUP ................................. 115
6.2. ANÁLISIS DEL SISTEMA ...................................................................... 117
6.3. DISEÑO DEL SISTEMA ......................................................................... 133
6.4. DOCUMENTACIÓN DEL ANÁLISIS Y DISEÑO DEL SISTEMA
CON RUP Y UML .................................................................................... 137

RATIONAL UNIFIED PROCESS (RUP): CASO PRÁCTICO
7.1. DISCIPLINAS Y ARTEFACTOS: MODELO DEL NEGOCIO … 140
7.2. DISCIPLINAS Y ARTEFACTOS: MODELADO DE
REQUERIMIENTOS ……………………………………………… 148
7.3. DISCIPLINAS Y ARTEFACTOS: MODELADO DE ANÁLISIS
Y DISEÑO …………………………………………………………. 152
IMPLEMENTACIÓN ………………………………………………. 161
7.5. DISCIPLINAS Y ARTEFACTOS: DESPLIEGUE ……………… 162
PRUEBAS Y MANTENIMIENTO DE SOFTWARE
8.1. DEFINICIONES ……………………………………………………. 166
8.2. ¿QUÉ SON LAS PRUEBAS DE SOFTWARE? ……………….. 167
8.3. ¿POR QUÉ PROBAR EL SOFTWARE A DESARROLLAR? … 168
8.4. ¿QUÉ SON LAS PRUEBAS DE SOFTWARE? ……………….. 168
8.5. ¿QUÉ VENTAJAS TIENE LA CREACIÓN DE PRUEBAS
PARA EL DESARROLLO DE SOFTWARE? ………………….. 168
8.6. PROCESO DE PRUEBAS DE RUP ……………………………. 170
8.7. ROLES Y ACTIVIDADES PRESENTES EN EL PROCESO
DE PRUEBAS ……………………………………………………… 170
8.8. ETAPAS DEL WORKFLOW DE PRUEBAS …………………… 171
8.9. ARTEFACTOS DE PRUEBAS …………………………………… 171
8.10. HERRAMIENTAS …………………………………………………. 172

UNIDAD ACADÉMICA N° 01:
La ingeniería de software es, por definición, un tipo de ingeniería y

por lo tanto; tiene el mismo conjunto de responsabilidades sociales que
todas las otras ingenierías.
Durante la historia de la computación, una gran parte del trabajo
de los profesionales de software se ha considerado como “desarrollo” que
requiere aptitudes de lenguajes de programación, pero muy poco de la
disciplina de ingeniería. El Consejo de acreditación de Ingeniería y
tecnología (ABET, Accreditation Board for Engineering and Technology)
define la ingeniería como “La profesión en la que el conocimiento de las
ciencias naturales y matemáticas obtenido con el estudio, la experiencia y la
práctica se aplica con juicio para desarrollar formas de utilizar, de modo
económico, los materiales y fuerzas de la naturaleza para beneficio de la
humanidad”
Esta industria sin chimeneas es joven en el Perú, la cual ha
presentado un interesante desempeño en los últimos 6 años al presentar
una tasa de crecimiento promedio anual del 15% y elevar la apuesta de
parte de los empresarios por el mercado internacional. El año 2009 se
facturó por US$ 167 millones.
En este capítulo presentamos una vista de alto nivel de la
ingeniería del software y como como ha evolucionado a través del tiempo.
Al finalizar el estudio de la presente unidad temática el estudiante:

1. Conceptua el término de ingeniería de software.
2. Describe la evolución de la ingeniería del software.
3. Identifica y diferencia las categorías del desarrollo de software.
4. Analiza el impacto de los Mitos del software.
5. Describe el desarrollo de la Industria del Software en el Perú.
1.1. ¿QUÉ ES INGENIERÍA DE SOFTWARE?

La primera discusión formal relativa a la ingeniería de software se
llevó a cabo en 1968 en la primera conferencia sobre desarrollo de
software patrocinada por el Comité de Ciencia de la OTAN celebrada
en Garmisch, Alemania. En esta conferencia Fritz Bauer define la
Ingeniería del software como el “establecimiento y uso de principios
sólidos de la ingeniería para obtener económicamente un software
confiable y que funcione de modo eficiente en maquinas reales”.
A partir del cual las organizaciones internacionales de software
más releventas y autores de renombre han sumado otras ideas a esta
definición.

 Bohem, 1976
Ingeniería de software es la aplicación práctica del conocimiento
científico al diseño y construcción de programas de computadora
y a la documentación asociada requerida para desarrollar, operar
y mantenerlos. Se conoce también como Desarrollo de Software o
Producción de Software
 IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) 1993
Ingeniería de software es la aplicación de un enfoque sistemático,
disciplinado y cuantificable hacia el desarrollo, operación y
mantenimiento del software; es decir, la aplicación de ingeniería al
software.
 ACM (Association for Computing Machinery - primera sociedad
científica y educativa acerca de la Computación)
La ingeniería de software es la disciplina del desarrollo y
mantenimiento de sistemas computacionales que se comportan
de manera confiable y eficiente y que su costo de desarrollo y
mantenimiento puede ser pagado.
 Roger S. Pressman. Autor de Ingeniería del Software un Enfoque
Práctico – sexta edición 2007.
La Ingeniería del software es una disciplina que integra al
proceso, los métodos y las herramientas para el desarrollo del
software de computadora.
Ingeniería de software
es
el conjunto
de
Principios Métodos Técnicas
para
Desarrollar Mantener
Software
de
Calidad

1.2. LA EVOLUCIÓN DEL SOFTWARE
Primera Generación Segunda Generación Tercera Generación Cuarta Generación
1950 1960 1970 1980 1990 2011
Primera generación del Software Segunda generación del Software

(1950 – 1965) (1965 – 1975)
 El software estaba en su infancia.  Aparece la multiprogramación y los
 El software era un añadido. sistemas multiusuario.
 Existían pocos métodos para la  Establecimiento del software como
programación. producto y la llegada de las casas de
 No se tenía una planificación para el software.
desarrollo del software.  El software se desarrollaba para ser
 Los programadores trataban de hacer comercializado.
las cosas bien.  Se empezó a distribuir software para
 El software se diseñaba a medida. grandes computadoras y
 El software era desarrollado y utilizado minicomputadores.
por la misma persona u organización  Comenzó a extenderse las bibliotecas de
(entorno personalizado) software.
 El diseño de software era realizado en  El mantenimiento de software comenzó a
la mente de alguien y no existía absorber recursos en una gran medida.
documentación  Comenzó una crisis del software porque
la naturaleza personalizada de los
programas hizo imposible su
mantenimiento.
Tercera generación del Software Cuarta generación del Software

(1975 – 1990) (1990 – Actualidad)
 Complejidad alta en los sistemas  Impacto colectivo del software.
informáticos.  Sistemas operativos operativos
 Sistemas distribuidos. sofisticados , en redes globales y locales.
 Incorporación de “inteligencia”.  Entorno cliente/cliente servidor.
 Ejecución de funciones concurrentes.  Superautopista de información y una
 Desarrollo de software para redes y conexión del ciberespacio.
comunicaciones.  La industria del software es la cuna de la
 Planificación en el proceso del economía.
desarrollo de software.  Tecnologías orientadas a objetos.
 Técnicas de cuarta generación para el
desarrollo de software.
 Software de redes neuronales.
 Sistemas expertos e inteligencia artificial.
 Programación de realidad virtual y
sistemas multimedia.
 Algoritmos genéticos.

1.3. CATEGORÍAS DEL DESARROLLO DE SOFTWARE
En la actualidad existen siste grandes categorías del software de
computadora que presentan retos contínuos para los ingenieros de
software.
1.3.1. Software de Sistemas
El software de sistemas es una colección de programas escritos
para servir a otros programas. Algunos programas de sistemas
(como los compiladores, editores y utilerías para ladministración
de archivos) procesan estructuras de información complejas
pero determinadas. Otras aplicaciones de sistemas (por ejemplo,
componentes del sistema operativo, controladores, software de
red, procesadores para telecomunicaciones) procesan datos
indeterminados. En cada caso, el área de software de sistemas
se caracteriza por una interacción muy intensa con el hardware
de computadora; utilización por múltiples usuarios; operación
concurrente que requiere la gestión de itinerarios, de
compartición de recursos, y de procesos sofisticados;
estructuras de datos complejas y múltiples de interfaces
externas.
1.3.2. Software de Aplicación
El software de aplicación consiste en programas independientes
que resuelven una necesidad de negocios específica. Las
aplicaciones en esta área procesan datos empresariales o
técnicos de forma que facilitan las operaciones de negocios o la
toma de decisiones técnicas o de gestión. Además del
procesamiento de datos convencionales, el software de
aplicaciones se utiliza para controlar las funciones de negocios
en tiempo real (por ejemplo, el procesamiento de transacciones
en los puntos de venta y el control de procesos de manufactura
en tiempo real).
1.3.3. Software científico y de ingeniería
El software científico y de ingeniería, que se caracterizaba por
algoritmos “devoradores de números”, abarca desde la
astronomía hasta la vulcanología, desde el análisis de la tensión
automotriz hasta la dinámica orbital de los transbordadores
espacioales, y desde la biología molecular hasta la manufactura
automatizada. Sin embargo, las aplicaciones modernas dentro
del área científica y de ingeniería se alejan en la actualidad de
losalgoritmos numéricos convencionales. El diseño asistido por
computadora, la simulación de sistemas y otras aplicaciones
interactivas han comenzado a tomar características de software
en tiempo real e incluso de software de sistemas.
1.3.4. Software emportado
El software emportado reside dentro de la memoria de sólo
lectura del sistema y con él se implementan y controlan
características y funciones para el usuario final y el sistema
mismo. El software incrustado puede desempeñar funciones
limitadas y curiosas (como el control del tecklado de un horno de
microondas) o proporcionar capacidades de control y
funcionamiento significativas (por ejemplo, las funciones digitales

de un automóvil, como el control de combustible, el despliegue
de datos en el tablero, los sistemas de frenado, etcétera).
1.3.5. Software de línea de productos
El software de línea de productos, diseñado para proporcionar
una capacidad específica y la utilización de muchos clientes
diferentes, se puede enfocar en un nicho de mercado limitado
(como en los productos para el control de inventarios) o dirigirse
hacia los mercados masivos (por ejemplo, aplicaciones de
procesadores de palabras, hojas de cálculo, gráficas por
computadora, multimedia, entretenimiento, manejo de bases de
datos, administración de personal y finanzas en los negocios).
1.3.6. Aplicaciones basadas en Web
Las “WebApps” engloban un espectro amplio de aplicaciones.
En su forma más simple, las Webapps son apenas un poco más
que un conjunto de archivos de hipertextos ligados que presenta
información mediante texto y algunas gráficas. Sin embargo, a
medida que el comercio electrónico y las aplicaciones B2B
adquieren mayor importancia, las webApps evolucionan hacia
ambientes computacionales sofisticados que no sólo
proporcionan características, funciones de cómputo y contenidos
independientes al usuario final, sino están integrados con base
de datos corporativas y aplicaciones de negocios.
1.3.7. Software de inteligencia artificial
Este software utiliza algoritmos no numéricos en la resolución de
problemas complejos que es imposible abordar por medio de un
análisis directo. Las aplicaciones dentro de esta área incluyen la
robótica, los sistemas expertos, el reconocimiento de patrones
(imagen y voz), las redes neuronales artificiales, la
comprobación de teoremas y los juegos en computadora.
1.4. MITOS DEL SOFTWARE

Los mitos del software son creencias acerca del software y de los
procesos empleados para construirlo.
En la actualidad, la mayoría de los profesionales reconocidos en
ingeniería del software identifican los mitos en su real dimensión:
actitudes equivocadas que han causado problemas serios a los
administradores y al personal técnico por igual. Sin embargo, las
antiguas actitudes y viejos hábitos son difíciles de modificar, por lo que
aún subsisten creencias falsas sobre el software.
1.4.1. Mitos de la administración
Los administradores con responsabilidades sobre el software, al
igual que sus pares en la mayoría de las disciplinas, a menudo
están bajo presión por mantener los presupuestos, evitar que los
itinerarios se extiendan y mejorar la calidad.
Mito: Ya se tiene un libro lleno de estándares y
procedimientos para la construcción de software.
¿Esto proporcionará a mi gente todo el
conocimientonecesario?

Realidad: Tal vez sea verdad que el libro de estándares
existe, pero ¿se usa? ¿el libro refleja la práctica
moderna de la ingeniería del software? ¿es
adaptable?
1.4.2. Mitos del cliente

El cliente que solicita un software de computadora puede ser la
persona del escritorio de al lado, un grupo técnico en el piso de
abajo, el departamento de ventas, o una compañía externa. En
muchos casos, el cliente cree en mitos acerca del software
porque los profesionales y administradores del software hacen
muy poco para corregir la desinformación. Los mitos conducen a
expectativas falsas (del cliente) y en definitiva a insatisfacción
con el desarrollador.
Mito: Un enunciado general de los objetivos es
suficiente para comenzar a escribir programas; los
detalles se pueden afinar después.
Realidad: A pesar de que no siempre es factible que el
enunciado de los requerimientos sea
comprensible y estable, un enunciado ambiguo de
los objetivos es la receta perfecta para el
desastre. Los requerimientos precisos se
desarrollan sólo mediante la comunicación
contínua y efectiva entre el cliente y el
desarrollador.
1.4.3. Mitos del desarrollador

Los mitos que aún subsisten entre los programadores del
software, que consideran la programación como una forma de
arte; por ello, las viejas formas y actitudes son difíciles de
eliminar.
Mito: Una vez que el programa ha sido escrito y puesto
a funcionar, el trabajo está terminado.
Realidad: Alguien dijo alguna vez que entre más rápido se
comience a escribir código, más tiempo pasará
para que el programa esté terminado. Los datos
de la industria indican que entre 60 y 80 por ciento
de todo el esfuerzo aplicado en el software se
realizará después de que el sistema haya sido
entregado al cliente por primera vez.
Mito: La ingeniería del software obligará a emprender la
creación de una documentación voluminosa e
innecesaria y de manera invariable tornará más
lentp el proceso.
Realidad: La ingeniería del software no se refiere a la
elaboración de documentos. Está relacionada con
la creación de calidad. Una mejor calidad conduce
a la reducción de los trabajos redundantes.

1.5. INDUSTRIA DEL SOFTWARE EN EL PERÚ
El sector del software peruano es joven, las 300 empresas que lo
componen tienen un promedio de 16 años. El 63% son microempresas
y 27% son pequeñas empresas, realidad muy similar a la de otros
países de Latinoamérica.
Este sector en los últimos años ha mostrado un importante dinamismo

al presentar una tasa de crecimiento del 15% promedio anual en el
periodo 2003-2009, pasando de US$ 85 millones a US$ 167 millones
de ventas totales. Esta facturación no incluye a las de empresas
multinacionales extranjeras instaladas en nuestro país.

El Perú cuenta con un importante capital humano capaz de llevar
adelante el desarrollo de la industria, por ello genera 6,000 empleos
directos altamente calificados, además tiene un efecto multiplicador al
crear 9,000 puestos de trabajo indirectos, producto de la proveeduría al
sector como son las ventas de las computadoras, instalaciones,
cableado, entre otros.
Actualmente, las soluciones peruanas están en 17 mercados de

Latinoamérica, Estados Unidos de Norteamérica (clientes hispanos) y
Europa. El mayor destino de exportación es Estados Unidos debido a la
contratación de servicios outsourcing y desarrollos a medidas, le sigue
en importancia los países miembros de la CAN a donde llegan
soluciones más especializadas, tal como lo podemos apreciar en el
gráfico.
Esta salida al mercado internacional se ha logrado justamente por la

presencia de empresas peruanas de software con experiencia y con
estándares de calidad reconocidos en el exterior como son: ISO 9000 y
CMMI.
La ubicación geográfica del Perú genera oportunidades para el
mercado norteamericano, permitiendo el desarrollo de actividades de
Off shore y Outsourcing. Otro factor relevante es la competitividad de
costes, al tener estructuras de costes diferenciadas la oferta peruanas
se convierte en una interesante alternativa, lo que además permite
complementar la producción con otros países de la región, generando
una oferta más atractiva para terceros mercados.
El aprovechamiento del mercado internacional ha sido posible por parte
de las empresas de software, al disponer del manejo de lenguajes de
programación y de administradores de base de datos más utilizados en
el exterior.

La industria peruana de software está basada principalmente en el
aprovechamiento de una de las mayores áreas de aplicación del
software: el procesamiento de información comercial, que abarca
desde sistemas administrativos contables genéricos hasta sistemas
integrados de gestión (ERPs) especializados por sectores verticales.

Es importante destacar la especialización de las empresas peruanas de
software en el desarrollo de aplicativos. En algunos casos aplicativos
genéricos (segmento horizontal), como los ERPs, y en otros,
específicos (segmento vertical) para nichos de mercado bien
identificados, como: la banca, minería, legal, salud, turismo,
medioambiente, entre otros.
ACTIVIDAD 1
1. Explique los Tipos de licencia de software

2. Elabore un cuadro comparativo entre software libre y software propietario
En este capitulo se explica de una manera sencilla los conceptos

fundamentales relacionados a la ingeniería del software. Así mismo se
describe le evolución del software, las categorías, los mitos y el estado
situacional de la industria del software en el Perú.
 Braude, Eric J.. Ingeniería de Software: una perspectiva orientada a

objetos. 1ra edición. Editorial Alfaomega. Mexico 2008.
 Roger S. Pressman. Ingeniería del Software un enfoque práctico. 6ta
edición. Editorial McGrawHill. 2005
 Ian Sommerville. Ingeniería del Software. 7ma edición. Editorial Pearson.
Madrid 2005.
 Marc Gibert Ginestá, Álvaro Peña González. Ingeniería del software en
Entorno de Software Libre. 1ra edición. Universitat Oberta de Catalunya.
Barcelona 2005.
 Salvador Sánchez, Miguel Ángel Sicilia, Daniel Rodríguez. Ingenieria de
software: un enfoque desde la guía swebok. 1ra edición. Editorial
Garceta. 2004.

1. Explique la diferencia entre ingeniería de sistemas e ingeniería del

software.
2. Explique la diferencia entre programación e ingeniería de software.
3. Investigue y explique sobre la crisis del software y sus consecuencias.
4. Describir algunos ejemplos (positivos y negativos) que indiquen el

impacto del software en la sociedad actual.
5. A medida que la presencia del software se vuelve más generalizado, los

riesgos al público (debido a las fallas en los programas) representan una
preocupación significativa y creciente. Desarrollar un escenario
catastrófico realista en el que la falla de un programa de computadora
podría producir un gran daño (ya sea económico o humano).
6. Mediante un organizador clasifique los organismos nacionales e

internacionales ligados a la ingeniería del software. Explique la función
que cumplen.
7. Utilizando un organizador gráfico explique la composición de la industria

del software en Latinoamérica y el Mundo.

Un sistema informático está compuesto por hardware y software. En

cuanto al hardware, su producción se realiza sistemáticamente y la base de
conocimiento para el desarrollo de dicha actividad está claramente definida.
La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra
máquina construida por el hombre. Un proceso de desarrollo de software
tiene como propósito la producción eficaz y eficiente de un producto software
que reúna los requisitos del cliente.
Pero ¿qué es con exactitud un proceso de software desde un punto de
vista técnico? Dentro de este contexto de este libro, un proceso de software
se define como un marco de trabajo para las tareas que se requieren en la
construcción de software de alta calidad. ¿El proceso es sinónimo de
ingeniería del software? La respuesta es sí y no. Un proceso de software
define el enfoque que se adopta mientras el software está en desarrollo.
Pero la ingeniería del software también abarca las tecnologías que requiere
el proceso (métodos técnicos y herramientas automatizadas).

1. Conceptúa y diferencia las capas de la ingeniería del software.
2. Identifica el marco de trabajo para el proceso del software.
3. Describe los elementos y fases del ciclo de vida del software.
4. Identifica los procesos del ciclo de vida del software según la Norma
Técnica Peruana vigente.
5. Diferencia los modelos de ciclos de vida para el desarrollo del software.
2.1. CAPAS DE LA INGENIERÍA DEL SOFTWARE
La ingeniería del software es una tecnología estratificada. Como se

muestra en la figura, cualquier enfoque de la ingeniería (incluido el de
la ingeniería del software) debe estar sustentado en un compromiso
con la calidad- La base que soporta la ingeniería del software es un
enfoqie en la calidad.

Figura : Capas de la Ingeniería de Software.
Dichas capas se describen a continuación:

 Cualquier disciplina de ingeniería (incluida la ingeniería del
software) debe descansar sobre un esfuerzo de organización de
calidad. La gestión total de la calidad y las filosofías similares
fomentan una cultura continua de mejoras de procesos que
conduce al desarrollo de enfoques cada vez más robustos para la
ingeniería del software.
 El fundamento de la ingeniería de software es la capa proceso. El
proceso define un marco de trabajo para un conjunto de áreas
clave, las cuales forman la base del control de gestión de
proyectos de software y establecen el contexto en el cual: se
aplican los métodos técnicos, se producen resultados de trabajo, se
establecen hitos, se asegura la calidad y el cambio se gestiona
adecuadamente.
 Los métodos de la ingeniería de software indican cómo construir
técnicamente el software. Los métodos abarcan una gran gama de
tareas que incluyen análisis de requisitos, diseño, construcción de
programas, pruebas y mantenimiento. Estos métodos dependen de
un conjunto de principios básicos que gobiernan cada área de la
tecnología e incluyen actividades de modelado y otras técnicas
descriptivas.
 Las herramientas de la ingeniería del software proporcionan un
soporte automático o semi-automático para el proceso y los
métodos, a estas herramientas se les llama herramientas CASE
(Computer-Aided Software Engineering).
Dado lo anterior, el objetivo de la ingeniería de software es lograr
productos de software de calidad (tanto en su forma final como
durante su elaboración), mediante un proceso apoyado por métodos y
herramientas.
2.2. MARCO DE TRABAJO PARA EL PROCESO

Un marco de trabajo establece la base para un proceso de software
completo al identificar un número pequeño de actividades del marco de
trabajo aplicables a todos los proyectos de software, sin importar su
tamaño o complejidad.
El proceso de desarrollo de software no es único. No existe un proceso

de software universal que sea efectivo para todos los contextos de

proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar
todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un
conjunto de actividades fundamentales que se encuentran presentes
en todos ellos:
1. Especificación de software: Se debe definir la funcionalidad y
restricciones operacionales que debe cumplir el software.
2. Diseño e Implementación: Se diseña y construye el software de
acuerdo a la especificación.
3. Validación: El software debe validarse, para asegurar que cumpla
con lo que quiere el cliente.
4. Evolución: El software debe evolucionar, para adaptarse a las
necesidades del cliente.
Además de estas actividades fundamentales, Pressman menciona un
conjunto de “actividades protectoras”, que se aplican a lo largo de todo
el proceso del software. Ellas se señalan a continuación:
 Seguimiento y control de proyecto de software.
 Revisiones técnicas formales.
 Garantía de calidad del software.
 Gestión de configuración del software.
 Preparación y producción de documentos.
 Gestión de reutilización.
 Mediciones.
 Gestión de riesgos.
Pressman caracteriza un proceso de desarrollo de software como se
muestra en la Figura 3. Los elementos involucrados se describen a
continuación:
 Un marco común del proceso, definiendo un pequeño número de
actividades del marco de trabajo que son aplicables a todos los
proyectos de software, con independencia del tamaño o
complejidad.
 Un conjunto de tareas, cada uno es una colección de tareas de
ingeniería del software, hitos de proyectos, entregas y productos de
trabajo del software, y puntos de garantía de calidad, que permiten
que las actividades del marco de trabajo se adapten a las
características del proyecto de software y los requisitos del equipo
del proyecto.
 Las actividades de protección, tales como garantía de calidad del
software, gestión de configuración del software y medición, abarcan
el modelo del proceso. Las actividades de protección son
independientes de cualquier actividad del marco de trabajo y
aparecen durante todo el proceso.

Figura 1: Elementos del proceso del software
Otra perspectiva utilizada para determinar los elementos del proceso

de desarrollo de software es establecer las relaciones entre elementos
que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe
hacerlo.
Figura 2: Relación entre elementos del proceso del software

En la Figura 4 se muestran los elementos de un proceso de desarrollo
de software y sus relaciones. Así las interrogantes se responden de la
siguiente forma:
 Quién: Las Personas participantes en el proyecto de desarrollo
desempeñando uno o más Roles específicos.
 Qué: Un Artefacto es producido por un Rol en una de sus
Actividades. Los Artefactos se especifican utilizando Notaciones
específicas. Las Herramientas apoyan la elaboración de Artefactos
soportando ciertas Notaciones.

 Cómo y Cuándo: Las Actividades son una serie de pasos que lleva
a cabo un Rol durante el proceso de desarrollo. El avance del
proyecto está controlado mediante hitos que establecen un
determinado estado de terminación de ciertos Artefactos.
2.3. CICLO DE VIDA DEL SOFTWARE

Todo proyecto de ingeniería tiene unos fines ligados a la obtención de
un producto, proceso o servicio que es necesario generar a través de
diversas actividades. Algunas de estas actividades pueden agruparse
en fases porque globalmente contribuyen a obtener un producto
intermedio, necesario para continuar hacia el producto final y facilitar la
gestión del proyecto.
El ciclo de vida del software es una sucesión de etapas por las que
pasa el software en su desarrollo, desde que se concibe la idea hasta
que el software deja de utilizarse (obsolescencia).
Cada etapa lleva asociada una serie de actividades y tareas que se
deben realizar, y una serie de documentos que serán la salida de cada
una de estas fases y que servirán de entrada a la fase siguiente
Según la norma ISO/IEC Standard 12207:2008: Software life-Cycle
processes propuesta por la ISO (International Organization for
Standardization). El ciclo de vida del software:
“Es un marco de referencia que contiene los procesos, las actividades y
las tareas involucradas en el desarrollo, explotación y mantenimiento
de un producto software, abarcando la vida del sistema desde la
definición de requisitos hasta que se deja de utilizar”
2.3.1. Elementos Del Ciclo De Vida

Un ciclo de vida para un proyecto se compone de fases
sucesivas compuestas por tareas planificables. Según el
modelo de ciclo de vida, la sucesión de fases puede ampliarse
con bucles de realimentación, de manera que lo que
conceptualmente se considera una misma fase se pueda
ejecutar más de una vez a lo largo de un proyecto, recibiendo
en cada pasada de ejecución aportaciones de los resultados
intermedios que se van produciendo (realimentación).
Figura 2.4: Elementos del ciclo de vida

Para un adecuado control de la progresión de las fases de un
proyecto se hace necesario especificar con suficiente
precisión los resultados evaluables, o sea, productos
intermedios que deben resultar de las tareas incluidas en
cada fase. Normalmente estos productos marcan los hitos
entre fases.
A continuación presentamos los distintos elementos que

integran un ciclo de vida:
 Fases. Una fase es un conjunto de actividades
relacionadas con un objetivo en el desarrollo del proyecto.
Se construye agrupando tareas (actividades elementales)
que pueden compartir un tramo determinado del tiempo de
vida de un proyecto. La agrupación temporal de tareas
impone requisitos temporales correspondientes a la
asignación de recursos (humanos, financieros o
materiales).
Otro motivo para descomponer

una fase en subfases menores
puede ser el interés de separar
partes temporales del proyecto
que se subcontraten a otras
organizaciones, requiriendo
distintos procesos de gestión.
Figura 2.5: Descomposición
de fases
Cada fase viene definida por un conjunto de elementos
observables externamente, como son las actividades con
las que se relaciona, los datos de entrada (resultados de la
fase anterior, documentos o productos requeridos para la
fase, experiencias de proyectos anteriores), los datos de
salida (resultados a utilizar por la fase posterior,
experiencia acumulada, pruebas o resultados efectuados) y
la estructura interna de la fase.
Figura 2.6: Esquema general de operación de una fase

 Entregables ("deliverables"). Son los productos intermedios
que generan las fases. Pueden ser materiales
(componentes, equipos) o inmateriales (documentos,
software). Los entregables permiten evaluar la marcha del
proyecto mediante comprobaciones de su adecuación o no
a los requisitos funcionales y de condiciones de realización
previamente establecidos. Cada una de estas evaluaciones
puede servir, además, para la toma de decisiones a lo largo
del desarrollo del proyecto.
2.3.2. Fases genéricas en el ciclo de vida del SW

 Fase de definición ¿Qué?
Tareas:
- Ingeniería de sistemas
- Planificación del proyecto del SW
- Análisis de los requisitos
 Fase de desarrollo ¿Cómo?
Tareas:
- Diseño del SW
- Generación de código
- Prueba del SW
 Fase de mantenimiento. Cambios:
- Corrección
- Adaptación
- Mejora
- Prevención
2.4. PROCESO DEL CICLO DE VIDA DEL SOFTWARE SEGÚN

NTP-ISO/IEC 12207 - 2008
Esta NTP (Norma Técnica Peruana) agrupa las actividades que se
pueden llevar a cabo durante el ciclo de vida del software en cinco
procesos principales, ocho procesos de soporte y cuatro procesos
generales.

2.4.1. Procesos Principales
 Adquisición: Actividades y tareas que el comprador, el
cliente o el usuario realizan para adquirir un sistema, un
servicio o un producto software:
- Preparación y publicación de ofertas
- Selección del suministrador de SW
 Suministro: Actividades y tareas del suministrador:
- Preparar contratos como respuesta a una petición de
un comprador de un producto SW.
- Identificar los recursos necesarios para llevar a cabo
con éxito el desarrollo del producto SW.
 Desarrollo: Actividades y tareas enfocadas a la obtención
de un producto Software
- Análisis
- Diseño
- Codificación
- Pruebas
- Integración
- Implantación
 Explotación: Explotación del SW y soporte operativo a los
usuarios.
 Mantenimiento: Actividades que incluyen modificaciones
del producto, tanto del código como de la documentación,
debido a errores o a la necesidad de mejora o/y
adaptación.
- Migración hacia un nuevo entorno operativo
- Retirada del producto
2.4.2. Procesos de Soporte

Dan soporte al resto de procesos y se aplican durante
cualquier momento del ciclo de vida del SW.
 Documentación: Registrar la información producida por un
proceso o actividad del ciclo de vida:
- Diseñar, editar, distribuir y mantener los documentos
producidos durante el desarrollo del SW.
 Gestión de la Configuración: Actividades que controlan las
modificaciones y versiones de los elementos.
- Registrar las peticiones de cambios e informar de los
estados de éstos.
 Aseguramiento de la calidad: Actividades para asegurar
que los productos cumplen los requisitos especificados y
se ajustan a los planes establecidos
 Verificación: Actividades para determinar el buen
funcionamiento de un producto software.
 Validación: Actividades para determinar si el producto
cumple los requisitos previstos.
 Revisión conjunta: Actividades que permiten determinar el
estado de los productos en una determinada actividad del
ciclo de vida o en una cierta fase del proyecto. Puede ser
una reunión conjunta con el cliente, el grupo de desarrollo

y los clientes potenciales para revisar el trabajo hecho
 Auditorías: Actividades que permiten determinar en unos
momentos determinados si se han conseguido los
objetivos propuestos: requisitos, cumplimiento del
contrato, etc.
 Resolución de problemas: Actividades que permiten
analizar y resolver los problemas o disconformidadescon
los requisitos o con el contrato, que hayan surgido durante
el desarrollo, la explotación, el mantenimiento, o en
cualquier otro momento.
- Disponer de un medio documental que permita
asegurar que todos los problemas se han tratado
2.4.3. Procesos Generales

Se emplean para fortalecer el diseño organizacional:
 Gestión: Actividades de planificación, seguimiento,
control, revisión y evaluación.
 Infraestructura: Actividades para determinar la
infraestructura necesaria para un proceso. Incluye HW,
SW, instalaciones…
 Mejora: Valorar, medir, controlar, evaluar y mejorar todos
los procesos del ciclo de vida.
 Formación: Plan de formación para los empleados.
2.5. PROCESO DEL DESARROLLO DE SOFTWARE SEGÚN NTP-

ISO/IEC 12207 - 2008
El proceso de desarrollo contiene las actividades y tareas del
desarrollador. El proceso contiene las actividades para el
análisis de los requerimientos, diseño, codificación, integración,
pruebas e instalación y aceptación relacionadas con los productos
software. Lista de actividades:
a) Implementación del proceso.
b) Análisis de los requerimientos del sistema.
c) Diseño de la arquitectura del sistema.
d) Análisis de los requerimientos software.
e) Diseño de la arquitectura del software.
f) Diseño detallado del software.
g) Codificación y pruebas del software.
h) Integración del software.
i) Pruebas de calificación del software.
j) Integración del sistema.
k) Pruebas de calificación del sistema.
l) Instalación del software.
m) Apoyo a la aceptación del software.
2.6. MODELOS DEL CICLO DE VIDA DEL DESARROLLO DE

SOFTWARE
Las principales diferencias entre distintos modelos de ciclo de vida
están divididas en tres grandes visiones:
 El alcance del ciclo de vida, que depende de hasta dónde

deseamos llegar con el proyecto: sólo saber si es viable el
desarrollo de un producto, el desarrollo completo o el desarrollo
completo más las actualizaciones y el mantenimiento.
 La cualidad y cantidad de las etapas en que dividiremos el ciclo de
vida: según el ciclo de vida que adoptemos, y el proyecto para el
cual lo adoptemos.
 La estructura y la sucesión de las etapas, si hay realimentación
entre ellas, y si tenemos libertad de repetirlas (iterar).
En los distintos modelos de ciclo de vida mencionaremos la efectividad
del modelo está ne función del riesgo que suponemos aceptar al
elegirlo. Cuando hablamos de riesgo, nos referimos a la probabilidad
que tendremos de volver a retomar una de las etapas anteriores,
perdiendo tiempo, dinero y esfuerzo.
2.6.1. Ciclo de vida lineal

Es el más sencillo de todos los modelos. Consiste en
descomponer la actividad global del proyecto en etapas
separadas que son realizadas de manera lineal, es decir, cada
etapa se realiza una sola vez, a continuación de la etapa anterior
y antes de la etapa siguiente. Con un ciclo de vida lineal es muy
fácil dividir las tareas, y prever los tiempos (sumando linealmente
los de cada etapa).
Las actividades de cada una de las etapas mencionadas deben

ser independientes entre sí, es decir, que es condición primordial
que no haya retroalimentación entre ellas, aunque sí pueden
admitirse ciertos supuestos de realimentación correctiva. Desde
el punto de vista de la gestión, requiere también que se conozca
desde el primer momento, con excesiva rigidez, lo que va a
ocurrir en cada una de las distintas etapas antes de comenzarla.
Esto último minimiza, también, las posiblidades de errores
durante la codificación y reduce al mínimo la necesidad de
requerir informacion del cliente o del usuario.
Se destaca como ventaja la sencillez de su gestión y
administración tanto económica como temporal, ya que se
acomoda perfectamente a proyectos internos de una empresa
para programas muy pequeños de ABM (sistemas que realizan
Altas, Bajas y Modificaciones sobre un conjunto de datos). Tiene
como desventaja que no es apto para Desarrollos que superen
mínimamente requerimientos de retroalimentación entre etapas,
es decir, es muy costoso retomar una etapa anterior al detectar
alguna falla.
Es válido tomar este ciclo de vida cuando algún sector pequeño
de una empresa necesita llevar un registro de datos
acumulativos, sin necesidad de realizar procesos sobre ellos

más que una consulta simple. Es decir, una aplicación que se
dedique exclusivamente a almacenar datos, sea una base de
datos o un archivo plano. Debido a que la realización de las
etapas es muy simple y el código muy sencillo.
2.6.2. Ciclo de vida en cascada puro

Este modelo de ciclo de vida fue propuesto por Winston Royce
en el año 1970. Es un ciclo de vida que admite iteraciones,
contrariamente a la creencia de que es un ciclo de vida
secuencial como el lineal. Después de cada etapa se realiza una
o varias revisiones para comprobar si se puede pasar a la
siguiente. Es un modelo rígido, poco flexible, y con muchas
restricciones. Aunque fue uno de los primeros, y sirvió de base
para el resto de los modelos de ciclo de vida.
Una de sus ventajas, además de su planificación sencilla, es la
de proveer un producto con un elevado grado de calidad sin
necesidad de un personal altamente calificado.
Se pueden considerar como inconvenientes: la necesidad de

contar con todos los requerimientos (o la mayoría) al comienzo
del proyecto, y, si se han cometido errores y no se detectan en la
etapa inmediata siguiente, es costoso y difícil volver atrás para
realizar la correccion posterior.
Además, los resultados no los veremos hasta que no estemos
en las etapas finales del ciclo, por lo que, cualquier error

detectado nos trae retraso y aumenta el costo del desarrollo en
funcion del tiempo que insume la correccion de éstos.
Es un ciclo adecuado para los proyectos en los que se dispone
de todos los requerimientos al comienzo, para el desarrollo de
un producto con funcionalidades conocidas o para proyectos,
que aun siendo muy complejos, se entienden perfectamente
desde el principio.
Fue utilizado en medianos y grandes proyectos hasta principios
de la década de 1990, y a finales de esta década las críticas a
este modelo aumentaron notablemente. Por lo que hoy en día
sólo se lo cita como mero ejemplo bibliográfico.
2.6.3. Ciclo de vida en V

Este ciclo fue diseñado por Alan Davis, y contiene las mismas
etapas que el ciclo de vida en cascada puro. A diferencia de
aquél, a éste se le agregaron dos subetapas de
retroalimentación entre las etapas de análisis y mantenimiento, y
entre las de diseño y prueba.
Las ventajas y desventajas de este modelo son las mismas del

ciclo anterior, con el agregado de los controles cruzados entre
etapas para lograr una mayor corrección.
Podemos utilizar este modelo de ciclo de vida en aplicaciones,
que si bien son simples (pequeñas transacciones sobre bases
de datos por ejemplo), necesitan una confiabilidad muy alta. Un
ejemplo claro en el que no nos podemos permitir el lujo de
cometer errores es una aplicación de facturación, en la que si
bien los procedimientos vistos individualmente son de
codificación e interpretación sencilla, la aplicación en su conjunto
puede tener matices complicados.
2.6.4. Ciclo de vida iterativo

También derivado del ciclo de vida en cascada puro, este
modelo busca reducir el riesgo que surge entre las necesidades
del usuario y el producto final por malos entendidos durante la
etapa de solicitud de requerimientos.

Es la iteración de varios ciclos de vida en cascada. Al final de
cada iteración se le entrega al cliente una versión mejorada o
con mayores funcionalidades del producto. El cliente es quien
luego de cada iteración, evalúa el producto y lo corrige o
propone mejoras. Estas iteraciones se repetirán hasta obtener
un producto que satisfaga al cliente.
Se suele utilizar en proyectos en los que los requerimientos no

están claros de parte del usuario, por lo que se hace necesaria
la creación de distintos prototipos para presentarlos y conseguir
la conformidad del cliente.
Podemos adoptar el modelo mencionado en aplicaciones
medianas a grandes, en las que el usuario o cliente final no
necesita todas las funcionalidades desde el principio del
proyecto. Quizás una empresa que debe migrar sus aplicaciones
hacia otra arquitectura, y desea hacerlo paulatinamente, es un
candidato ideal para este tipo de modelo de ciclo de vida.
2.6.5. Ciclo de vida por prototipos

El uso de programas prototipo no es exclusivo del ciclo de vida
iterativo.
En la práctica los prototipos se utilizan para validar los
requerimientos de los usuarios en cualquier ciclo de vida.
Si no se conoce exactamente cómo desarrollar un determinado
producto o cuáles son las especificaciones de forma precisa,
suele recurrirse a definir especificaciones iniciales para hacer un
prototipo, o sea, un producto parcial y provisional. En este
modelo, el objetivo es lograr un producto intermedio, antes de
realizar el producto final, para conocer mediante el prototipo
cómo responderán las funcionalidades previstas para el producto
final.
Antes de adoptar este modelo de ciclo debemos evaluar si el
esfuerzo por crear un prototipo vale realmente la pena adoptarlo.

Se utiliza mayoritariamente en desarrollos de productos con
innovaciones importantes, o en el uso de tecnologías nuevas o
poco probadas, en las que la incertidumbre sobre los resultados
a obtener, o la ignorancia sobre el comportamiento, impiden
iniciar un proyecto secuencial.
La ventaja de este ciclo se basa en que es el único apto para
desarrollos en los que no se conoce a priori sus especificaciones
o la tecnología a utilizar. Como contrapartida, por este
desconocimiento, tiene la desventaja de ser altamente costoso y
difícil para la administración temporal.
Si deseamos migrar aplicaciones de tecnología para adoptar sus
nuevas funcionalidades o simplemente para estar en la cresta de
la ola, este modelo es ideal. Un claro ejemplo son las llegadas
de Java y la tecnología .NET que si bien contaban con respaldo
y material de ayuda, implantaron nuevas tendencias.
2.6.6. Ciclo de vida evolutivo

Este modelo acepta que los requerimientos del usuario pueden
cambiar en cualquier momento.
La práctica nos demuestra que obtener todos los requerimientos
al comienzo del proyecto es extremadamente difícil, no sólo por
la dificultad del usuario de transmitir su idea, sino porque estos
requerimientos evolucionan durante el desarrollo y de esta
manera, surgen nuevos requerimientos a cumplir. El modelo de
ciclo de vida evolutivo afronta este problema mediante una
iteración de ciclos requerimientos– desarrollo–evaluación.

Resulta ser un modelo muy útil cuando desconocemos la
mayoría de los requerimientos iniciales, o estos requerimientos
no están completos.
Tomemos como ejemplo un sistema centralizado de stock–
ventas–facturación, en el cual hay muchas áreas que utilizarán la
aplicación. Tenemos dos complicaciones: la primera, los
usuarios no conocen de informática, la segunda, no es uno, sino
varios los sectores que nos pueden pedir modificaciones o hacer
nuevas solicitudes.
2.6.7. Ciclo de vida incremental

Este modelo de ciclo de vida se basa en la filosofía de construir
incrementando las funcionalidades del programa.

Se realiza construyendo por modulos que cumplen las diferentes
funciones del sistema. Esto permite ir aumentando gradualmente
las capacidades del software. Este ciclo de vida facilita la tarea
del desarrollo permitiendo a cada miembro del equipo desarrollar
un modulo particular en el caso de que el proyecto sea realizado
por un equipo de programadores.
Es una repetición del ciclo de vida en cascada, aplicándose este
ciclo en cada funcionalidad del programa a construir. Al final de
cada ciclo le entregamos una versión al cliente que contiene una
nueva funcionalidad. Este ciclo de vida nos permite realizar una
entrega al cliente antes de terminar el proyecto.
El modelo de ciclo de vida incremental nos genera algunos

beneficios tales como los que se describen a continuacion:
• Construir un sistema pequeño siempre es menos riesgoso
que construir un sistema grande.
• Como desarrollamos independientemente las funcionalidades,
es más fácil relevar los requerimientos del usuario.
• Si se detecta un error grave, sólo desechamos la última
iteración.
• No es necesario disponer de los requerimientos de todas las
funcionalidades en el comienzo del proyecto y además facilita
la labor del desarrollo con la conocida filosofía de divide y
vencerás.
Este modelo de ciclo de vida no está pensado para cierto tipo de
aplicaciones, sino que está orientado a cierto tipo de usuario o
cliente. Podremos utilizar este modelo de ciclo de vida para casi
cualquier proyecto, pero será verdaderamente útil cuando el
usuario necesite entregas rápidas, aunque sean parciales.
2.6.8. Ciclo de vida en espiral

Este ciclo puede considerarse una variación del modelo con
prototipado, fue diseñado por Boehm en el año 1988. El modelo
se basa en una serie de ciclos repetitivos para ir ganando
madurez en el producto final. Toma los beneficios de los ciclos
de vida incremental y por prototipos, pero se tiene más en
cuenta el concepto de riesgo que aparece debido a las
incertidumbres e ignorancias de los requerimientos
proporcionados al principio del proyecto o que surgirán durante
el desarrollo. A medida que el ciclo se cumple (el avance del
espiral), se van obteniendo prototipos sucesivos que van
ganando la satisfacción del cliente o usuario.
A menudo, la fuente de incertidumbres es el propio cliente o
usuario, que en la mayoría de las oportunidades no sabe con
perfección todas las funcionalidades que debe tener el producto.

En este modelo hay cuatro actividades que envuelven a las
etapas.
• Planificación: Relevamiento de requerimientos iniciales o
luego de una iteración.
• Análisis de riesgo: De acuerdo con el relevamiento de
requerimientos decidimos si continuamos con el desarrollo.
• Implementación: desarrollamos un prototipo basado en los
requerimientos.
• Evaluación: El cliente evalúa el prototipo, si da su
conformidad, termina el proyecto. En caso contrario, incluimos
los nuevos requerimientos solicitados por el cliente en la
siguiente iteración.
La ventaja más notoria de este modelo de desarrollo de software
es que puede comenzarse el proyecto con un alto grado de
incertidumbre, se entiende también como ventaja el bajo riesgo
de retraso en caso de detección de errores, ya que se puede
solucionar en la próxima rama del espiral.
Algunas de las las desventajas son: el costo temporal que suma
cada vuelta del espiral, la dificultad para evaluar los riesgos y la
necesidad de la presencia o la comunicacion continua con el
cliente o usuario.
Se observa que es un modelo adecuado para grandes proyectos
internos de una empresa, en donde no es posible contar con
todos los requerimientos desde el comienzo y el usuario está en
nuestro mismo ambiente laboral.

Podemos citar una aplicación que administre reclamos, pedidos
e incidentes, como ejemplo para utilizar este modelo de ciclo de
vida, en el que los sectores que utilizarán el sistema son
demasiados y con intereses muy diversos como para lograr un
relevamiento exhaustivo y completo de los requerimientos.
2.6.9. Ciclo de vida orientado a objetos

Esta técnica fue presentada en la década del 90, tal vez como
una de las mejores metodologías a seguir para la creación de
productos software.
Puede considerarse como un modelo pleno a seguir, como así
también una alternativa dentro de los modelos anteriores.
Al igual que la filosofía del paradigma de la programación
orientada a objetos, en esta metodología cada funcionalidad, o
requerimiento solicitado por el usuario, es considerado un objeto.
Los objetos están representados por un conjunto de
propiedades, a los cuales denominamos atributos, por otra parte,
al comportamiento que tendrán estos objetos los denominamos
métodos.
Vemos que tanto la filosofía de esta metodología, los términos
utilizados en ella y sus fines, coinciden con la idea de obtener un
concepto de objeto sobre casos de la vida real.
En este modelo se utilizan las llamadas fichas CRC (clase–

responsabilidades–colaboración) como herramienta para obtener
las abstracciones y mecanismos clave de un sistema analizando
los requerimientos del usuario. En la ficha CRC se escribe el
nombre de la clase u objeto, sus responsabilidades (los
métodos) y sus colaboradores (otras clases u objetos de los
cuales necesita). Estas fichas, además, nos ayudan a
confeccionar los denominados casos de uso.
No es correcto suponer que este modelo sólo es útil cuando se
escoge para la implementación un lenguaje con orientación a

objetos. Se puede utilizar independientemente del lenguaje
elegido.
Como mencionamos, es un modelo muy versátil, y por ser uno
de los últimos en aparecer, aprendió mucho de los anteriores.
Las aplicaciones que podemos incluir como ejemplo para su uso
van desde programas de monitoreo de procesos, grandes
sistemas de transacciones sobre base de datos, hasta
procesamiento por lotes.
Luego de ver algunos de los modelos de ciclo de vida más utilizados

surge la pregunta con la respuesta más codiciada: ¿qué modelo de
ciclo de vida elegir? Sabemos que ninguno predomina sobre los otros.
Por ello, debemos elegir el modelo que mejor se adapte al proyecto
que desarrollaremos. Podemos analizar, para guiarnos en nuestra
elección, la complejidad del problema, el tiempo que disponemos para
hacer la entrega final, o si el usuario o cliente desea entregas parciales,
la comunicación que existe entre el equipo de desarrollo y el usuario y,
por último, qué certeza (o incertidumbre) tenemos de que los
requerimientos dados por el usuario son correctos y completos.
ACTIVIDAD 2
A modo de encuesta, pregunte a sus colegas programadores, quién y por
qué ha utilizado un ciclo de vida. Indague sobre los resultados obtenidos.
En este capitulo se explica de una manera sencilla los aspectos

conceptuales relacionados al proceso del desarrollo del software,
considerando la Norma Técnica Peruana ISO/IEC 12207 – 2008 como guía
estandarizada y aceptada en nuestro país.

Bibliografía Recomendada

 Ian Sommerville. Ingeniería del Software. 7ma edición. Editorial Pearson.
Madrid 2005.
 Bernd Bruegge, Allen Dutoit.Ingeniería de Software Orientado a Objetos.
1ra edición, Editorial Pearson. México 2002.
 Marc Gibert Ginestá, Álvaro Peña González. Ingeniería del software en
Entorno de Software Libre. 1ra edición. Universitat Oberta de Catalunya.
Barcelona 2005.
Garceta. 2004.
En el siguiente capitulo se estudian las diferentes metodologías para el

desarrollo delsfotware de acuerdo a la realidad organizacinal, ya sea modo
cliente servidor, sistema informático distribuido, etc.

1. Utilizando Rational Rose elaborar el diagrama de actividades

correspondiente al ciclo de vida del desarrollo de software, considerado
en Norma Técnica Peruana ISO/IEC 12207 – 2008.
2. ¿Cree Ud. que seguir un modelo de ciclo de vida nos garantiza el éxito
del desarrollo? ¿Por que?
3. Proporcionar tres ejemplos de proyectos de software que pudieran

adaptarse al modelo incremental.
4. Proporcionar tres ejemplos de proyectos de software que pudieran

adaptarse al modelo orientado a objetos.
5. Enumere el ciclo de vida y los pasos que seguiría, si debiese

desarrollar una aplicación que monitoree el estado de las redes de una
empresa.
6. Elabore un cuadro comparativo de los diferentes modelos del ciclo de

vida del software en relación a complejidad, tiempo, entrega final,
entregas parciales y requerimientos.

METODOLOGÍAS PARA EL DESARROLLO DE SOFTWARE
Para asegurar el éxito durante el desarrollo de software no es suficiente

contar con notaciones de modelado y herramientas, hace falta un elemento
importante: la metodología de desarrollo, la cual nos provee de una dirección
a seguir para la correcta aplicación de los demás elementos.
Es como un libro de recetas de cocina, en el que se van indicando paso a
paso todas las actividades a realizar para lograr el producto informático
deseado, indicando además qué personas deben participar en el desarrollo
de las actividades y qué papel deben de tener. Además detallan la
información que se debe producir como resultado de una actividad y la
información necesaria para comenzarla.

1. Describe el concepto de metodología.
2. Diferencia las ventajas y desventajas que existe entre las metodologías
tradicionales y ágiles.
3. Identifica los componentes de la metodología RUP, XP y MFS.
3.1. ¿QUÉ ES LA METODOLOGÍA DE DESARROLLO DE SW?

Una metodología es una colección de procedimientos, técnicas,
herramientas y documentos auxiliares que ayudan a los
desarrolladores de software en sus esfuerzos por implementar nuevos
sistemas de información. Una metodología esta formada por fases,
cada una de las cuales se puede dividir en sub fases, que guiarán a los
desarrolladores de sistemas a elegir las técnicas mas apropiadas en
cada momento del proyecto y también a planificarlo, gestionarlo,
controlarlo y evaluarlo.
a. Las herramientas de la ingeniería del software suministran un
soporte automático o semiautomático para los métodos. Hoy
existen herramientas para soportar cada uno de los métodos
mencionados anteriormente. Cuando se integran las herramientas
de forma que la información creada por una herramienta pueda ser
usada por otra, se establece un sistema para el soporte del
desarrollo del software, llamado ingeniería de software asistida por
computadora (del inglés, CASE). CASE combina software,
hardware y bases de datos sobre ingeniería del software (una

estructura de datos que contenga la información relevante sobre el
análisis, diseño, codificación y prueba) para crear un entorno de
ingeniería de software, por ejemplo, análogo al diseño asistido por
computadora, CAD/CAE (de las siglas en inglés) para el hardware.
b. Los procedimientos de la ingeniería de software son el pegamento
que junta las fases de la metodología y las herramientas,
facilitando su desarrollo racional y oportuno del software de
computadora. Los procedimientos definen la secuencia en la que
se aplican los métodos, las entregas (documentos, informes,
formas, etc.) que se requieren, los controles que ayudan a asegurar
la calidad y coordinar los cambios, y las directrices que ayudan a
los gestores del software a evaluar el progreso.
3.2. PUNTOS PRIMORDIALES QUE DEBE TENER UNA

METODOLOGÍA
a. Visión del producto. Todo el mundo debe conocer lo que el equipo
esta tratando de hacer, como debe de ser el producto final, las
bases de la estrategia del producto y cuando el producto será
entregado.
b. Vinculación con el cliente. La metodología se debe encargar de
indicar la manera de gestionar el vínculo entre clientes,
desarrolladores, especificación de requisitos y el personal de
soporte.
c. Establecer un modelo de ciclo de vida. Un modelo de ciclo de vida
como pueden ser el iterativo, secuencial o waterfall, etc. De esta
manera se establecen los pasos en el proceso de desarrollo y se
pueden ubicar los recursos adecuadamente.
d. Gestión de los requisitos. Nivel de detalle que deben tener los
requisitos del producto, siendo recomendable cuanto más alto
mejor.
e. Plan de desarrollo. Un documento con un plan para organizar los
requisitos y cuestiones relacionadas con la calidad. Los ítems de
este plan deben ser lo suficientemente detallados para que los
desarrolladores de software puedan desarrollar sus tareas de
codificación de un modo no ambiguo. Un proceso para añadir y
modificar el documento se debe especificar, como mínimo para
mantener un histórico de los cambios.
f. Integración del proyecto. Una metodología de desarrollo debe
conducir a una organización a determinar como se integrará el
producto fabricado con los existentes y futuros productos de la
compañía.
g. Medidas de progreso del proyecto. Se considera un aspecto crítico
en una metodología. Desarrolladores, manager y los altos cargos
de la organización deben entender el progreso del desarrollo del
equipo de desarrollo. Ellos deben conocer el estado actual del
producto, así como una buena estimación del tiempo que resta
para la finalización del proyecto.
h. Métricas para evaluar la calidad. El responsable de las release del
producto depende de un proceso de para la medida de la calidad,

el cual suele empezar en las primeras etapas de la planificación.
Este proceso no es tan solo para encontrar fallos, produce
indicadores de la robustez del producto y cuanto se aproxima el
producto a las especificaciones iniciales.
i. Maneras de medir el riesgo. Un plan debe tener en cuenta los
posibles problemas que pueden ocurrir durante el proceso de
desarrollo, el impacto de estos problemas y que acciones deberían
ser llevadas a cabo para solucionar o prevenir estos problemas. La
gestión de los riesgos es la responsabilidad diaria de los project
managers y desarrolladores.
j. Como gestionar los cambios. Nuevas ideas y problemas
desembocan en cambios de diseño y especificación aún que ya
hayamos empezado a implementar. Un plan debe contemplar estas
sugerencias para introducirlas en el proyecto, debatirlas e
implementarlas.
k. Establecer una línea de meta. La metodología de desarrollo debe
forzar a una organización a especificar exactamente que esta
siendo construido y que constituye el producto final. Todo el mundo
en la organización debe tener una visión clara del producto final y
entender que significa “terminado”.
3.3. EVOLUCIÓN DE LAS METODOLOGÍAS DE SOFTWARE

El desarrollo de los sistemas tradicionales de ciclo de vida se originó en
la década de 1960 para desarrollar a gran escala funcional de sistemas
de negocio en una época de grandes conglomerados empresariales.
1970s
- Programación estructurada sol desde 1969
- Programación estructurada Jackson desde 1975
1980s
- Structured Systems Analysis and Design Methodology (SSADM)
desde 1980
- Structured Analysis and Design Technique (SADT) desde 1980
- Ingeniería de la información (IE/IEM) desde 1981
1990s
- Rapid application development (RAD) desde 1991.
- Programación orientada a objetos (OOP) a lo largo de la década de
los 90's
- Virtual finite state machine (VFSM) desde 1990s
- Dynamic Systems Development Method desarrollado en UK desde
1995.
- Scrum (desarrollo), en la última parte de los 90's
- Rational Unified Process (RUP) desde 1999.
Nuevo milenio
- Extreme Programming(XP) desde 1999
- Enterprise Unified Process (EUP) extensiones RUP desde 2002
- Constructionist design methodology (CDM) desde 2004 por Kristinn
R. Thórisson
- Agile Unified Process (AUP) desde 2005 por Scott Ambler

3.4. CLASIFICACIÓN DE LAS METODOLOGÍAS DE SOFTWARE
3.4.1. Metodologías Tradicionales
Estas metodologías tradicionales imponen una disciplina de
trabajo sobre el proceso de desarrollo del software, con el fin de
conseguir un software más eficiente. Para ello, se hace énfasis
en la planificación total de todo el trabajo a realizar y una vez
que está todo detallado, comienza el ciclo de desarrollo del
producto software. Se centran especialmente en el control del
proceso, mediante una rigurosa definición de roles, actividades,
artefactos, herramientas y notaciones para el modelado y
documentación detallada. Además, las metodologías
tradicionales no se adaptan adecuadamente a los cambios, por
lo que no son métodos adecuados cuando se trabaja en un
entorno, donde los requisitos no pueden predecirse o bien
pueden variar.
Las principales características que representan a las
metodologías tradicionales son:
 Requisitos fijados a lo largo de todo el proyecto.
 Basadas en los procesos.
 Proyectos muy bien documentados.
 Gestión predictiva de los proyectos.
 No siguen ni los principios, ni las técnicas de las
metodologías ágiles.
Entre las metodologías tradicionales o pesadas podemos citar:

• RUP (Rational Unified Procces)
• MSF CMMI (Microsoft Solution Framework)
• Iconix
3.4.2. Metodologías Ágiles

Esta metodología nace en febrero del 2001 en una reunión
celebrada en UtahEEUU convoado por Kent Beck. En esta
reunión participan un grupo de 17 expertos de la industria del
software, incluyendo algunos de los creadores o impulsores de
metodologías de software. Su objetivo fue esbozar los valores y
principios que deberían permitir a los equipos desarrollar
software rápidamente y respondiendo a los cambios que puedan
surgir a lo largo del proyecto.
La aparición de las metodologías ágiles se debe a las siguientes
causas:
 “Plumbing”. La traducción al castellano sería pesadez,
lentitud de reacción, exceso de documentación, en
definitiva, falta de agilidad de los modelos de desarrollo
existente.
 Las metodologías existentes no cumplieron las
expectativas planteadas inicialmente.
 Explosión de la red y las aplicaciones Web.
 Movimiento open source.
Se pretendía ofrecer una alternativa a los procesos de desarrollo
de software tradicionales, caracterizados por ser rígidos y

dirigidos por la documentación que se genera en cada una de
las actividades desarrolladas.
El punto de partida es fue el Manifiesto Ágil, un documento que
resume la filosofía “ágil”.
Según el Manifiesto se valora:

 Al individuo y las interacciones del equipo de desarrollo sobre
el proceso y las herramientas. La gente es el principal factor
de éxito de un proyecto software. Es más importante construir
un buen equipo que construir el entorno. Muchas veces se
comete el error de construir primero el entorno y esperar que
el equipo se adapte automáticamente. Es mejor crear el
equipo y que éste configure su propio entorno de desarrollo
en base a sus necesidades.
 Desarrollar software que funciona más que conseguir una
buena documentación. La regla a seguir es “no producir
documentos a menos que sean necesarios de forma
inmediata para tomar un decisión importante”. Estos
documentos deben ser cortos y centrarse en lo fundamental.
 La colaboración con el cliente más que la negociación de un
contrato. Se propone que exista una interacción constante
entre el cliente y el equipo de desarrollo. Esta colaboración
entre ambos será la que marque la marcha del proyecto y
asegure su éxito.
 Responder a los cambios más que seguir estrictamente un
plan. La habilidad de responder a los cambios que puedan
surgir a los largo del proyecto (cambios en los requisitos, en la
tecnología, en el equipo, etc.) determina también el éxito o
fracaso del mismo. Por lo tanto, la planificación no debe ser
estricta sino flexible y abierta.
Sus características más relevantes son:

- Poca documentación.
- Simplicidad.
- Análisis como una actividad constante.
- Diseño evolutivo.
- Integraciones.
- Testeos diarios.
Ventajas de las metodologías ágiles:

- Rápida respuesta a cambios de requisitos a lo largo del
desarrollo.
- Entrega continua y en plazos cortos de software funcional.
- Trabajo conjunto entre el cliente y el equipo de desarrollo.
- Minimiza los costos frente a cambios.
- Importancia de la simplicidad, al eliminar el trabajo
innecesario.
- Atención continúa a la excelencia técnica y al buen diseño.
- Mejora continua de los procesos y el equipo de desarrollo.

- Evita malentendidos de requerimientos entre el cliente y el
equipo.
- El equipo de desarrollo no malgasta el tiempo y dinero del
cliente desarrollando soluciones innecesariamente generales
y complejas que en realidad no son un requisito del cliente.
- Cada componente del producto final ha sido probado y
satisface los requerimientos.
Desventajas de las metodologías ágiles.

- Falta de documentación del diseño. El código no puede
tomarse como una documentación. En sistemas de tamaño
grande se necesitar leer los cientos o miles de páginas del
listado de código fuente.
- Problemas derivados de la comunicación oral. Este tipo de
comunicación resulta difícil de preservar cuando pasa el
tiempo y está sujeta a muchas ambigüedades.
- Falta de calidad. Probar el código de forma constante no
genera productos de calidad, sólo revela falta de análisis y
diseño.
- Fuerte dependencia de las personas. Como se evita en lo
posible la documentación y los diseños convencionales, los
proyectos ágiles dependen críticamente de las personas.
- Falta de procesos de revisión del código. Con métodos como
el PSP o TSP se han conseguido reducciones de errores que
oscilan entre el 60 y el 80%. La programación en parejas tiene
resultados del 20 al 40%, que no es mucho frente al 10 y el
25% de un programador.
- Falta de reusabilidad. La falta de documentación hacen difícil
que pueda reutilizarse el código ágil.
- Sobre costos y retrasos derivados de la refactorización
continua. Para un sistema de ciertas proporciones, los costos
y retrasos derivados de la refactorización no pueden
despreciarse.
- Restricciones en cuanto a tamaño de los proyectos
abordables.
- Rigidez. Algunos métodos ágiles son muy rígidos: deben
cumplirse muchas reglas de una forma estricta para garantizar
el éxito del proyecto. Por ejemplo XP exige en realidad mucho
esfuerzo, concentración y orden.
- Cambios. Los modelos de datos son “pesados” y no pueden
cambiarse así como así solo porque el cliente que ira
incorporar más funciones al sistema.
- Problemas derivados del fracaso de los proyectos ágiles. Si
un proyecto ágil fracasa no hay documentación o hay muy
poca; lo mismo ocurre con el diseño. La comprensión del
sistema se queda en las mentes de los desarrolladores.
Entre las metodologías ágiles más destacadas hasta el momento

podemos destacar:
 XP – Extreme Programming.

 Scrum.
 OpenUP.
 MSF Agile
 Crystal Methods.
 Win Win Spiral.
A continuación se detallan algunos casos donde no conviene
usar métodos ágiles.
- Aplicaciones distribuidas. Las pruebas unitarias son

complicadas de aplicar entre componentes. Sería necesario
construir una arquitectura de pruebas para probar
directamente los componentes, que podría ser tan complicada
como el sistema que se desea construir.
- Aplicaciones que requieren seguir un diseño estricto. Por
ejemplo: sistemas operativos, software de
telecomunicaciones.
- Aplicaciones que requieren una documentación exhaustiva.
Por ejemplo: sistemas militares, médicos o industriales.
- Aplicaciones basadas fundamentalmente en interfaces
gráficas de usuario: No es fácil aplicar pruebas unitarias a las
interfaces gráficas.
- Aplicaciones con código heredado. Habría que reescribir todo
el código heredado siguiendo los principios ágiles.
- Proyectos muy grandes. La comunicación entre los miembros
del equipo es difícil de conseguir.
- Aplicaciones donde la escalabilidad o la eficacia sean
importantes. La escalabilidad o la eficacia no son
características que se pueden añadir durante el proceso del
desarrollo del software o que puedan obtenerse
refactorizando: deben considerarse desde un principio.
3.5. ¿QUÉ METODOLOGÍA DEBO UTILIZAR?

Todo desarrollo de software es riesgoso y difícil de controlar, pero si no
llevamos una metodología de por medio, lo que obtenemos es clientes
insatisfechos con el resultado y desarrolladores aún más insatisfechos.
Para dar una idea de qué metodología podemos utilizar y cual se
adapta más a nuestro medio, mencionaré tres de ellas de las que
considero las más importantes, tal como: RUP, XP y MSF.
Proceso Unificado Rational (RUP)

La metodología RUP, llamada así por sus siglas en inglés Rational
Unified Process. Es un producto comercial desarrollado y
comercializado por Rational Software, una compañía de IBM. Es una
metodología orientada a objetos que hace uso del proceso iterativo
incremental.

La estructura del RUP consta de dosdimensiones:
El eje horizontal representa la línea de tiempo y es el aspecto dinámico
del proceso. Se expresa en términos de fases, iteraciones e hitos.
Para el desarrollo del software divide en 04 fases:

 Fase de Inicio
En esta etapa se determina con claridad los alcances del proyecto,
las expectativas iniciales que se tienen de la aplicación y se
especifica su funcionalidad completa trabajando con los usuarios
conocedores del negocio. Se elaborará el documento de visión. Se
trabajará conjuntamente con el personal técnico y usuario final para
realizar la transferencia de conocimiento de la técnica de Análisis
con Casos de Uso y para realizar el Modelo de Casos de Uso de
Alto Nivel.
RESPONSABLE: Consultores Expertos en Análisis de Alto Nivel.
ENTREGABLES: Documento de Visión, Modelo de Casos de Uso
de Alto Nivel, Transferencia al grupo de trabajo de la técnica de
análisis de alto nivel.
META: Definición de alcance del Proyecto.
 Fase de Elaboración
En esta etapa se definirán y documentarán los diferentes escenarios
detallando paso a paso cada uno de los Casos de Uso identificados
en el Modelo de Casos de Uso de Alto Nivel, analizándolos con la
prioridad establecida. Se elaborará el documento de
Especificaciones Suplementarias de Software en donde se
especificarán todos los requerimientos tanto funcionales como no
funcionales que debe cumplir el sistema, al igual que los atributos
que van a determinar la administración y control de cada uno de los
requerimientos. Posteriormente se trabajara en el Análisis y Diseño
de la arquitectura mediante la abstracción de modelos lógicos y

físicos usando el UML. Se utilizará la herramienta de Rational Rose
para generar los modelos de UML. Se analizarán los riesgos
técnicos y se elaborará el Plan de Construcción.
RESPONSABLE: Consultor experto en Arquitectura
ENTREGABLES: Escenarios de los Casos de Uso, Documento con
las especificaciones suplementarias de software. Transferencia al
grupo de trabajo de la técnica de análisis detallado de Casos de Uso
y Análisis de arquitectura. Repositorio de requerimientos manejado
en Requisite Pro. Modelos de Arquitectura en Rational Rose. Lista
de Riesgos y Plan de Construcción.
META: Definición de arquitectura.
 Fase de Construcción
Se procede a implementar la arquitectura mediante la construcción
de componentes. El mayor esfuerzo se concentra en la generación y
construcción de código y en la ejecución del Plan de Pruebas para
verificación de la calidad de cada componente.
RESPONSABLE: Consultores en implementación de componentes
ENTEGABLES: Componentes desarrollados, Pruebas de
componentes ejecutadas.
META: Producto en versión Beta.
 Fase de Transmisión
Se realizan las pruebas de Sistema e Integrales. Se planifica y
realiza el entrenamiento formal a los usuarios de los distintos
sistemas. Se distribuye el material que se considere necesario. Se
hace entrega oficial de los manuales de usuario. Adicionalmente se
entregará la guía para la adopción paulatina de otras prácticas de
desarrollo de software para proyectos futuros.
RESPONSABLE:Consultor en implementación de componentes
ENTEGABLES: Producto listo para operar, con manuales de usuario
y técnicos, personal capacitado
META: Release del Producto

El eje vertical representa el aspecto estático del proceso. Se describe
en términos de componentes del proceso, disciplinas, actividades,
entregables, y roles.
Compo
Disciplinas Actividades Generales Roles Específicos
nentes
Modelado de Analista de procesos Diseñador de
negocio de negocio. negocio.
Descubrir todos los Detallar un conjunto
casos de uso de de los casos de uso
negocio. de negocio.
Requisitos Analista de sistemas. Especificador de
Descubrir todos los casos de uso.
casos de uso. Detallar un conjunto
de los casos de uso.
Análisis y Arquitectos de Diseñadores.
diseño Software. Detallan el análisis y
Toma decisiones diseño para un
tecnológicas de la conjunto de casos de
solución a nivel uso.
global.
Implementación Integrador. Desarrollador o
Es el propietario del programador.
DESARROLLO
plan de construcción Implementa un

que muestra como se conjunto de clases o
integrarán cada una un conjunto de
de las clases, las operaciones de una
unas con las otras. clase.
Pruebas Gestor de las Diseñador de
pruebas. pruebas.
Asegura que las Implementa las
pruebas han sido pruebas automáticas
realizadas de la iteración.
correctamente. Probador.
Analista de pruebas Ejecuta un test
Selecciona que se va específico.
a probar según lo
estimado.
Diseñador de pruebas
Decide que pruebas
deberían ser
automáticas o
manuales, y crea las
automáticas.
Despliegue o Gestor de la Artista gráfico, escritor
SOPORTE
Implantación implantación. tecnológico y

Supervisa la desarrollador de
implantación de todas material.
las unidades. Crean el material

necesario para
asegurar la correcta
implantación.
Gestión del Gestor del proyecto. Gestor de proyectos.
proyecto Crea los casos de Planifica, monitoriza y
negocio y un plan gestiona los riesgos
general, y toma para una sola
decisiones críticas al iteración.
respecto de que
cosas hacer y cuales
no hacer.
Entorno Ingeniero de Especialista en
procesos. herramientas.
Es el responsable de Crea manuales de
los procesos del uso de herramientas
proyecto. específicas.
Roles, actividades, artefactos y flujos de trabajo

Un proceso de desarrollo de software define quién hace qué, cómo y
cuándo. RUP define cuatro elementos los roles, que responden a la
pregunta ¿Quién?, las actividades que responden a la pregunta
¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los
flujos de trabajo de las disciplinas que responde a la pregunta
¿Cuándo?.
Figura 3: Relación entre roles, actividades, artefactos
Los Roles definen el comportamiento y responsabilidades de un

individuo, o de un grupo de individuos trabajando juntos como un
equipo. Una persona puede desempeñar diversos roles, así como un
mismo rol puede ser representado por varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un conjunto
de actividades como el ser el dueño de un conjunto de artefactos.

Figura 4: Detalle de un workflow mediante roles, actividades y artefactos
RUP define grupos de roles, agrupados por participación en actividades

relacionadas. Estos grupos son:
Analistas:
 Analista de procesos de negocio.
 Diseñador del negocio.
 Analista de sistema.
 Especificador de requisitos.
Desarrolladores:
 Arquitecto de software.
 Diseñador
 Diseñador de interfaz de usuario
 Diseñador de cápsulas.
 Diseñador de base de datos.
 Implementador.
 Integrador.
Gestores:
 Jefe de proyecto
 Jefe de control de cambios.
 Jefe de configuración.
 Jefe de pruebas
 Jefe de despliegue
 Ingeniero de procesos
 Revisor de gestión del proyecto
 Gestor de pruebas.
Apoyo:
 Documentador técnico
 Administrador de sistema
 Especialista en herramientas
 Desarrollador de cursos
 Artista gráfico
Especialista en pruebas:
 Especialista en Pruebas (tester)

 Analista de pruebas
 Diseñador de pruebas
Otros roles:
 Stakeholders.
 Revisor
 Coordinación de revisiones
 Revisor técnico
 Cualquier rol
Una Actividad en concreto es una unidad de trabajo que una persona

que desempeñe un rol puede ser solicitado a que realice. Las
actividades tienen un objetivo concreto, normalmente expresado en
términos de crear o actualizar algún producto.
Un producto o Artefacto es un trozo de información que es producido,

modificado o usado durante el proceso de desarrollo de software. Los
productos son los resultados tangibles del proyecto, las cosas que va
creando y usando hasta obtener el producto final
Un artefacto puede ser cualquiera de los siguientes:
- Un documento, como el documento de la arquitectura del software.
- Un modelo, como el modelo de Casos de Uso o el modelo de
diseño.
- Un elemento del modelo, un elemento que pertenece a un modelo
como una clase, un Caso de Uso o un subsistema.
Ventajas RUP:
 Los usuarios están involucrados continuamente.
 Evaluación en cada fase que permite cambios de objetivos
 Funciona bien en proyectos de innovación.

 Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora
de desarrollar el software.
 Promueve la reusabilidad.
 Seguimiento detallado en cada una de las fases.
 Facilita la construcción de prototipos.
Desventajas RUP:
 Por el grado de complejidad puede no resultar muy adecuado.
 La disminución de riesgos es compleja.
 Excesiva flexibilidad para algunos proyectos.
 Estamos poniendo a nuestro cliente en una situación que puede
ser muy incómoda para él.
 Nuestro cliente deberá ser capaz de describir y entender a un gran
nivel de detalle para poder acordar un alcance del proyecto con él.
Programación Extrema
Extreme Programming (XP) es una metodología de desarrollo de

software eficiente, de bajo riesgo y flexible. De todas las metodologías
ágiles, ésta es la que ha recibido más atención desde que fue dada a
conocer en 1999 a través del libro “Extreme programming Explained”
de Kent Beck. XP está formada por valores, principios y prácticas. XP
es una metodología ágil centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje
de los desarrolladores, y propiciando un buen clima de trabajo. XP se
basa en realimentación continua entre el cliente y el equipo de
desarrollo, comunicación fluida entre todos los participantes,
simplicidad en las soluciones implementadas y coraje para enfrentar los
cambios. XP se define como especialmente adecuada para proyectos
con requisitos imprecisos y muy cambiantes, y donde existe un alto
riesgo técnico.

Características de XP, la metodología se basa en:
 Pruebas Unitarias: se basa en las pruebas realizadas a los
principales procesos, de tal manera que adelantándonos en algo
hacia el futuro, podamos hacer pruebas de las fallas que pudieran
ocurrir. Es como si nos adelantáramos a obtener los posibles
errores.
 Refabricación: se basa en la reutilización de código, para lo cual se
crean patrones o modelos estándares, siendo más flexible al
cambio.
 Programación en pares: una particularidad de esta metodología es
que propone la programación en pares, la cual consiste en que dos
desarrolladores participen en un proyecto en una misma estación de
trabajo. Cada miembro lleva a cabo la acción que el otro no está
haciendo en ese momento. Es como el chofer y el copiloto: mientras
uno conduce, el otro consulta el mapa.
¿Qué es lo que propone XP?

 Empieza en pequeño y añade funcionalidad con retroalimentación
continua
 El manejo del cambio se convierte en parte sustantiva del proceso
 El costo del cambio no depende de la fase o etapa
 No introduce funcionalidades antes que sean necesarias
 El cliente o el usuario se convierte en miembro del equipo
Derechos del Cliente

 Decidir que se implementa
 Saber el estado real y el progreso del proyecto
 Añadir, cambiar o quitar requerimientos en cualquier momento
 Obtener lo máximo de cada semana de trabajo
 Obtener un sistema funcionando cada 3 o 4 meses
Derechos del Desarrollador
 Decidir como se implementan los procesos
 Crear el sistema con la mejor calidad posible
 Pedir al cliente en cualquier momento aclaraciones de los
requerimientos
 Estimar el esfuerzo para implementar el sistema
 Cambiar los requerimientos en base a nuevos descubrimientos
Lo fundamental en este tipo de metodología es:

 La comunicación, entre los usuarios y los desarrolladores
 La simplicidad, al desarrollar y codificar los módulos del sistema
 La retroalimentación, concreta y frecuente del equipo de desarrollo,
el cliente y los usuarios finales
El ciclo de vida de XP esta compuesto de seis fases:

Fase de exploración
Es la fase en la que se define el alcance general del proyecto. En esta
fase, el cliente define lo que necesita mediante la redacción de
sencillas “historias de usuarios”. Los programadores estiman los
tiempos de desarrollo en base a esta información. Debe quedar claro
que las estimaciones realizadas en esta fase son primarias (ya que
estarán basadas en datos de muy alto nivel), y podrían variar cuando
se analicen más en detalle en cada iteración.
Esta fase dura típicamente un par de semanas, y el resultado es una
visión general del sistema, y un plazo total estimado.
Fase de planificación
La planificación es una fase corta, en la que el cliente, los gerentes y el
grupo de desarrolladores acuerdan el orden en que deberán
implementarse las historias de usuario, y, asociadas a éstas, las
entregas. Típicamente esta fase consiste en una o varias reuniones
grupales de planificación. El resultado de esta fase es un Plan de
Entregas, o “Release Plan”, como se detallará en la sección “Reglas y
Practicas”.
Fase de iteraciones
Esta es la fase principal en el ciclo de desarrollo de XP. Las
funcionalidades son desarrolladas en esta fase, generando al final de
cada una un entregable funcional que implementa las historias de
usuario asignadas a la iteración. Como las historias de usuario no
tienen suficiente detalle como para permitir su análisis y desarrollo, al
principio de cada iteración se realizan las tareas necesarias de análisis,
recabando con el cliente todos los datos que sean necesarios. El
cliente, por lo tanto, también debe participar activamente durante esta
fase del ciclo. Las iteraciones son también utilizadas para medir el
progreso del proyecto. Una iteración terminada sin errores es una
medida clara de avance.

Fase de puesta en producción
Si bien al final de cada iteración se entregan módulos funcionales y sin
errores, puede ser deseable por parte del cliente no poner el sistema
en producción hasta tanto no se tenga la funcionalidad completa.
En esta fase no se realizan más desarrollos funcionales, pero pueden
ser necesarias tareas de ajuste (“fine tuning”).
Roles de la Programación Extrema (XP).

- Programador: El programador escribe las pruebas unitarias y
produce el código del sistema.
- Cliente: Escribe las historias de los usuarios y las pruebas
funcionales para validar su implementación. El cliente da una gran
prioridad a las historias de usuarios y decide cual implementar en
cada iteración centrandose en aportar mayor valor al negocio.
- Encargado de Pruebas (Tester): Ayuda al cliente a escribir las

pruebas funcionales. Se encarga de ejecutar las pruebas con
regularidad, difunde los resultados obtenidos al equipo y es el
responsable de las herramientas que dan soporte a las pruebas.
- Encargado de Seguimiento (Tracker): Es el que proporciona la

realimentación al equipo. Realiza el seguimiento del proceso de
cada iteración y verifica el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado en ello para la mejora de
futuras estimaciones.
- Entrenador (Coach): Es el responsable del proceso global. Se

encarga de proveer guias al equipo de forma que se apliquen las
practicas XP y se vaya siguiendo el proceso correctamente.
- Consultor: Es un miembro externo del equipo con un conocimiento

especifico en algún tema que es necesario para el proyecto, en el
que surgan problemas.
- Gestor (Manager o Jefe): Es el vínculo entre clientes y

programadores, ayuda a que el equipo trabaje efectivamente
creando las condiciones adecuadas. Su labor esencial es la de
coordinación.
MICROSOFT SOLUTION FRAMEWORK (MSF)

Esta es una metodología flexible e interrelacionada con una serie de
conceptos, modelos y prácticas de uso, que controlan la planificación,
el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en
los modelos de proceso y de equipo dejando en un segundo plano las
elecciones tecnológicas.

Microsoft Solutions Framework 5.0, abreviado como MSF, es un marco
de trabajo flexible para la planificación de proyectos y gestión del ciclo
de vida de las aplicaciones con Visual Studio 2010, válido para
entornos tradicionales y para entornos ágiles.
Puede usar estas herramientas para obtener los siguientes resultados:

 Planeación y seguimiento: capture lo que es importante para sus
clientes y realice el seguimiento del progreso de su proyecto.
Represente los procesos y supervise su calidad para ayudar a
su equipo a convertir las necesidades del cliente en software
operativo.
 Diseño: diseñe la funcionalidad, sobre activos existentes o
desde el principio, usando los diagramas arquitectónicos para
comunicar la información crítica acerca del software de su
equipo.
 Desarrollo: escriba, realice pruebas unitarias, depure, analice y
genere perfiles de su aplicación mediante herramientas que se
integran con el resto del ciclo de vida de la aplicación para que
su equipo pueda comprender cómo su progreso contribuye al
proyecto.
 Compilación: compile su aplicación mediante el sistema de
compilación integrado para que su equipo pueda asegurarse de
cumplir los requisitos de calidad y ver qué requisitos se han
cumplido en cada compilación.
 Pruebas: ejecute pruebas manuales o automatizadas, incluidas
las pruebas de rendimiento y de esfuerzo. Administre las
pruebas sistemáticamente para que su equipo conozca la
calidad del software en cualquier momento.
 Implementación: implemente en entornos virtuales para habilitar
un desarrollo y unas pruebas más sofisticadas.

Fase Entregable Rol
Envisionamiento Documento de Visión y Analista del Negocio
Alcance.
Planificación Documento del Plan Manager del Proy.
del Proyecto. Arquitecto.
Desarrollo Alcance completado. Desarrollo
Estabilización Versión aprobado. Tester.
Implementación Proyecto puesto en Release Manager
producción.
ACTIVIDAD 3
1. Defina el concepto de metodología y sus elementos.
2. Cuáles son los pasos para desarrollar software a medida.
En este capitulo se explica de una manera sencilla las

metodologías de desarrollo de software con el objetivo de guiar
a los desarrolladores al crear un nuevo software, identificando
que los requisitos de un software a otro son tan variados y
cambiantes, que ha dado lugar a que exista una gran variedad
de metodologías para la creación del software. La elección
dependerá del tipo de sistema a desarrollar.

 Bernd Bruegge, Allen Dutoit.Ingeniería de Software Orientado a Objetos.
1ra edición, Editorial Pearson. México 2002.
Garceta. 2004.
Enlaces Web
 http://users.dsic.upv.es/asignaturas/facultad/lsi/trabajos.html

METODOLOGÍAS PARA EL
DESARROLLO DE SOFTWARE
1. Realice un cuadro comparativo entre las metodologías tradicionales y

ágiles.
2. Qué metodología utilizaría para desarrollar sistemas web J2EE. De un

ejemplo.
3. ¿Qué es SCRUM? Explique su ciclo de vida, sus fases y entregables

para el desarrollo del software.
4. ¿Qué es OpenUP? Explique su ciclo de vida, sus fases y entregables

para el desarrollo del software.
5. Explique las funciones que deben cumpliar cada integrante de la

metodología MSF.
6. Realizar un análisis comparativo entre las metodologías RUP y XP.
7. Qué herramientas informáticas utilizan las cada uno de las

metodologías. De un ejemplo.

El Modelado de Negocios permite analizar el flujo de actividades de

una organización, para estudiar la manera de incorporar mejoras en el
negocio de acuerdo a las nuevas especificaciones o requisitos que se han
generado en el mercado o entorno. El modelado de Negocio es una técnica
que suele aplicarse cuando las empresas necesitan actualizar su estructuras
telemática con proyectos o adaptaciones previamente definidas, sin
embargo, el modelado tiene un objetivo más amplio ya que puede aplicarse
con la intención de estudiar la organización y procurar cambios que se
alineen con sus metas para aumentar las posibilidades de éxitos en el
negocio, ya sea que las propuestas sean automatizados o no.
Existen técnicas, metodologías y herramientas de software que
permiten modelar, documentar y reestructurar esos procesos y flujos de
información utilizando las bondades del modelado RUP mediante el estándar
UML. La finalidad de esta unidad es, precisamente, caracterizar el modelado
de negocio y establecer las ventajas de utilizar el enfoque orientado a
objetos.

1. Describe los conceptos relacionados al modeloado de negocios.
2. Valora la importancia de modelar el negocio antes de modelar el
sistema.
3. Utiliza procedimientos, roles, y diagramas para producir artefactos del
modelado del sistema.
4.1. MODELADO DEL PROCESO DE NEGOCIOS

El Modelado de Negocios según Montilva (2007) se define como
un proceso de representación de uno o más aspectos o elementos de
una empresa, tales como: propósito, estructura, unidades
organizativas, funcionalidad, dinámica, actores con sus respectivas
funciones y lógica de negocios (procesos, filosofía, reglas). Este
proceso permite caracterizar la organización, establecer debilidades,
fortalezas y comprender el entorno en el que va a funcionar un nuevo
sistema y el papel que juega cada actor con respecto al tratamiento,
distribución y actualización de la información.
En el modelado de negocio resalta especialmente el modelado de
los procesos del negocio el cual permiten establecer de manera
específica el flujo de trabajo que la institución sigue para realizar su
funciones, intercomunicaciones e interacciones con clientes y
proveedores, todo esto enmarcado en el tipo de modelo de Negocios.

El modelo de Negocio, por su parte, “es el mecanismo por el cual
un negocio trata de generar ingresos y beneficios; es un resumen de
cómo una compañía planifica servir a susclientes e implica tanto el
concepto de estrategia como el de implementación”. Wikipedia (2010).
Estos modelos pueden ser: de suscripción, marketing multinivel,
monopolístico, subasta, fidelización, publicidad, corretaje, productor,
comunidad, etc.
Es importante diferenciar los diferentes conceptos del modelado
del negocio, tal como se muestra en la figura 4.1, el modelado implica
el análisis del modelo del negocio, su lógica particular y sus
componentes. A nivel práctico el modelado de Negocio, se manifiesta
en el estudio de los procesos de negocios, puesto que generalmente
las especificaciones del Modelo de Negocio, como lo es su filosofía,
visión, misión y políticas y sus diferentes componentes, suelen estar
claramente definidos y documentados. Es por ello, que de aquí en
adelante se hará énfasis en el modelado del proceso del Negocio.
Figura 4.1. Factores del Modelado del Negocio
4.2. TIPOS DE ENFOQUES DEL MODELADO DE NEGOCIO

De acuerdo a las expectativas de cambios y necesidades de las
organizaciones los analistas pueden utilizar diferentes enfoques, entre
los cuales destacan los señalados por Curtis (1992) quien propone
cuatro vistas:
 Vista funcional (qué), la cual representa la dependencia funcional
entre los elementos del proceso.
 Vista dinámica (cuándo, cómo), que proporciona una secuenciación
y control de la información sobre el proceso.
 Vista informacional, que incluye la descripción y relación entre las
entidades que son producidas, consumidas o incluso manipuladas
por los procesos.
 Vista organizacional (quién, dónde) que describe quién desarrolla
cada tarea o función y dónde se desarrolla dentro de la
organización.

4.3. ¿PORQUÉ MODELAR NEGOCIO ANTES DE MODELAR EL
SISTEMA?

4.4. EL MODELADO DE NEGOCIO ORIENTADO A OBJETOS
El modelado de Negocio Orientado a Objetos es aquel que utiliza la
Técnica de Análisis Orientada a Objetos para llevar a cabo el
estudio de los procesos del negocio. Esta técnica se utiliza para
modelar y programar procesos caracterizados como objetos, que
son desarrollados y transformados por actividades. Utiliza los
objetos como bloque esencial de construcción y combina la
estructura de datos (atributos) y funciones (operaciones) en una
sola entidad. La adaptación de la técnica orientada a objetos
posibilita un Modelado de Negocio que toma ventajas propias de
este enfoque, tales como:
 Mejor interacción y comunicación entre los usuarios, analistas y
diseñadores, facilitando un análisis consensuado.
 Facilita la construcción de un acuerdo semántico de la
representación de los elementos de la organización, al
especificar objetos conjuntamente con sus atributos y
métodos.
 Posibilidad de abordar problemas complejos.
 Permite distinguir el todo de sus partes gracias a sus múltiples
vistas.
 Sugiere el análisis desde diferentes puntos de vistas o
enfoques, como el dinámico y el estático.
 La propuesta de automatización a través de software
igualmente orientado a objetos, los cuales se caracterizan por
poseer mayor flexibilidad para reutilización, mantenimiento y
modificaciones.
Existen diversidad de técnicas basadas en la programación

orientada a objetos, pero de todas ellas, la más importante es UML
(Unified Modelling Language) definido por el Object Management
Group (OMG) como un lenguaje gráfico para visualizar, especificar
y documentar cada una de las partes que comprende el desarrollo
de software.

4.5. RUP Y EL MODELADO DE NEGOCIO

4.6. MODELADO DEL NEGOCIO DEL SISTEMA DE ALMACEN
Disciplinas y artefactos: Modelo del Negocio
DISCIPLINA ACTIVIDAD DOCUMENTOS MODELOS DIAGRAMA

 Evaluar el estado  Evaluación del
del negocio estado de la  Diagrama de
 Describir el Organización Casos de Uso del
negocio actual  Plan de Desarrollo de Modelo del Negocio Negocio
 Identificar los Software
procesos del  Reglas del Negocio  Modelo de Objetos
negocio  Especificaciones de del Negocio
 Refinando las casos de uso del
definiciones del Negocio
proceso del  Arquitectura del
negocio· Negocio
Modelado del Negocio  Diseñar las  Visión del Negocio
realizaciones de Modelo del
los procesos del Dominio del
negocio problema
 Refinando roles y Modelo del dominio
responsabilidades
 Explotando
procesos de
automatización
 Desarrollo de un
modelo del
Dominio
Tabla 4-1: Disciplinas y artefactos del modelo del negocio
Artefactos que vamos a realizar en el ejemplo:

Al término del modelo del negocio debemos lograr:
 El diagrama de de Casos de Uso del Negocio (Business Use
Case diagrams).
 Uno o más diagramas de actividad para cada caso de uso del
negocio.
 Un Diagrama de Objetos del Negocio.
 Un diagrama de clases para todo el modelo del negocio. Este
diagrama es también llamado modelo del dominio.
Modelado del Negocio para nuestro Sistema de Almacén

1. Construir 4 Paquetes:
Se recomienda que los dos primeros siempre se creen, mientras
que los dos últimos solo se crean con fines de tener organizado
nuestro modelo:
a) Unidades Organizacionales.- Contendrá los trabajadores del
negocio (bussiness worker) y otras unidades organizacionales
según la jerarquía establecida por el negocio (organigrama de la
empresa).
b) Casos de Uso del Negocio.- Contendrá los casos de uso del
negocio (bussiness use case - procesos que nos permiten
cumplir los objetivos del negocio) así como los trabajadores del
negocio (bussiness worker) y los actores del negocio (bussines
actor).
c) Actores del Negocio.- Que nos permite agrupar en un solo sitio
todos los actores que participan en los casos de uso del negocio.

d) Trabajadores del Negocio.- Permite agrupar los empleados de la
organización.
2. Indentificar las unidades organizacionales

Nuestro software ejemplo va ha correr en un área específica de la
empresa, pero necesitamos establecer el contexto más general
para luego detallar solo lo que nos interesa. Así, nuestro negocio
es una empresa que está dividida en áreas tales como: Producción,
Finanzas, Recursos Humanos, Ventas, Contabilidad y Logística,
estas las podemos obtener directamente desde el organigrama de
la empresa. Usando la notación UML estereotipada para el modelo
del negocio tendremos:

Un modelo del negocio completo sería deseable sin embargo como
nuestro software de Almacén pertenece al área de logística,
entonces solamente vamos a detallar esta.
Si miramos dentro de Logística encontraremos que tiene un jefe de
Logística (que viene a ser un actor del negocio) que maneja a su
vez dos áreas: Compras y Almacén (unidades organizacionales);
esto queda representado por el siguiente diagrama:
Seguimos detallando cada unidad organizacional, como en nuestro

caso deseamos desarrollar un Sistema para el área de Almacén
entonces detallamos esta unidad organizacional.
Para que el modelo de la organización este completo será

necesario que describamos las funciones principales de cada área
así como las funciones de cada business worker.
3. Indentificar los Casos de Uso del Negocio

El diagrama de casos de uso del negocio debe representar los
principales objetivos de la organización, y en nuestro caso
particular los objetivos del área. Veamos según la descripción que
encontramos al construir nuestro modelo organizacional,
tendremos que Almacén tiene como objetivos fundamentales:
Planificar los requerimientos enviados por las diversas áreas de la
empresa, controlar los ingresos y salidas de materiales hacia las
mismas, valorizar los materiales según los datos de compras y
según las políticas aprobadas por Contabilidad, Planificar los
inventarios. Por lo que nuestro Diagrama de Casos de uso de
Negocio del Sistema de Almacén de materiales será:

Los trabajadores del negocio ya han sido identificados cuando
investigamos las unidades organizaciones, mientras que los
actores del negocio se identifican conforme vamos desarrollando
los casos de uso del negocio.
Debemos indicar que algunos autores consideran que solo

debemos mostrar los actores externos pues se dan límites al
sistema y los workers son “actores internos” y están dentro de la
organización.
4. Creamos los paquetes del modelo de objetos del negocio

Para esto vamos a la Vista lógica y encontramos el paquete
Business Object Model, dentro del cual se crean 3 paquetes:
Diagrama de Objetos del Negocio.- Que contendrá dicho diagrama.
Diagrama del Dominio.- El cual contiene las principales entidades
que se encontraron en el negocio.

Realización de los Casos de Uso del Negocio.- Aquí detallamos los
casos de uso del negocio mediante un diagrama de actividad (u
otro).
5. Construimos la realización de los casos de uso del negocio

Los casos de uso del negocio se pueden especificar de diversas
formas como son: pseudocódigo, lenguaje natural, diagramas de
actividades, diagramas de secuencia, diagramas de colaboración,
diagramas de estado, etc.
Sin embargo nosotros utilizaremos los diagramas de actividad pues
son los más indicados para representar procesos (actividades)
mostrando las áreas, personas y objetos en general (carriles) que
llevan a cabo procesos secuenciales o en paralelo (barra de
sincronización) y que objetos fluyen entre procesos (flujo de
objetos), asi también representan decisiones de bifurcación.
Cada uno de los casos de uso tendrá uno o más diagramas de
actividades (o de cualquier otro tipo, según los necesitemos en un
caso específico).
El paquete realización de los casos de uso del negocio contendrá

lo siguiente:
Realizaciones de los casos de uso

6. Para cada realización de los casos de uso del negocio construimos
un diagrama de actividad y un diagrama de clases.
El diagrama de actividad nos va ha permitir especificar como se
lleva a cabo el caso de uso del negocio y si en ese diagrama
incluimos el flujo de objetos, estaremos identificando los objetos
participantes, a partir de lo cual podremos derivar un pequeño
diagrama de objetos para cada realización.

Realización del Casos de Uso Planificar requerimientos
Diagrama de Actividad: Planificar requerimientos
Diagrama de Objetos participantes en Planificar requerimientos

Realización del Casos de Uso Controlar Ingreso de Materiales
Diagrama de Actividad: Controlar Ingreso de Materiales

Diagrama de objetos Controlar Ingreso de Materiales
Realización del Casos de Uso Controlar Salida de Materiales

Diagrama de Actividad: Controlar Salida de Materiales

Diagrama de objetos Controlar Salida de Materiales
Realización del Casos de Uso Valorizar Materiales
Diagrama de Actividad: Valorizar Materiales

Diagrama de Objetos de Valorizar Materiales
Realización del Caso de Uso Planificar Inventarios
Diagrama de Actividad: Planificar Inventarios

Diagrama de Objetos: Planificar Inventarios

7. Unimos los diagramas de objetos de cada caso de uso y
obtenemos nuestro diagrama de Objetos del Negocio
Como ya tenemos identificados los objetos participantes en cada
caso de uso, podemos unirlos en un único diagrama y debemos
refinar este modelo completando detalles como multiplicidad y
otros, asimismo nos daremos cuenta si hay objetos redundantes.
Diagrama de Objetos del Negocio
8. De ser necesario construimos nuestro Modelo del Dominio

En realidad solo es necesario construir uno de los dos modelos: el
modelo del dominio o el modelo de objetos. El modelo del dominio
se construye cuando deseamos efectuar un Modelamiento del
Negocio muy breve y solo identifica las clases más importantes en
nuestra organización para darnos un panorama de la misma. Sin
embargo, cuando se desarrolla un Modelo del Negocio más amplio,
se construye un diagrama de objetos del Negocio. A pesar que se
ha desarrollado un Modelo del Negocio amplio, se incluye aquí un

Modelo del Dominio como ilustración y para que nuestro modelo
resulte completo.
4.7. DOCUMENTACIÓN HASTA EL MODELO DE NEGOCIOS

CAPITULO I
DATOS DE LA ORGANIZACIÓN
1.1. RAZON SOCIAL DE NEGOCIO

1.2. ÁMBITO DE ACCIÓN
1.3. VISIÓN Y MISIÓN
1.3.1. VISIÓN
1.3.2. MISIÓN
1.4. ESTRUCTURA ORGÁNICA DE LA INSTITUCIÓN
1.5. FUNCIONES GENERALES DE LAS PRINCIPALES UNIDADES
ORGÁNICAS
1.6. MANUAL DE ORGANIZACIÓN Y FUNCIONES DEL ÁREA A
SISTEMATIZAR
1.7. ESTUDIO DE FACTIBILIDAD
1.7.1. FACTIBILIDAD TÉCNICA
1.7.2. FACTIBILIDAD OPERATIVA
1.7.3. FACTIBILIDAD ECONÓMICA
1.7.4. ANÁLISIS DE FACTIBILIDAD
1.8. METODOLOGÍA DEL DESARROLLO DEL SISTEMA
1.9. APLICACIONES A UTILIZAR

CAPITULO II
MODELADO DEL NEGOCIO
2.1. DESCRIPCIÓN DE LOS PROCESOS DEL NEGOCIO
2.2. UNIDADES ORGANIZACIONALES
2.3. UNIDAD ORGANIZACIONAL ______ A SISTEMATIZAR
2.3.1. TRABAJADORES Y ACTORES DEL SISTEMA _____
2.3.2. CASOS DE USO DEL NEGOCIO DEL SISTEMA _____
2.3.3. PAQUETES DEL MODELO DE OBJETOS DEL NEGOCIO.
2.4. DIAGRAMA DE CASOS DE USO DEL NEGOCIO DEL SISTEMA
_____
2.5. REALIZACIONES DE LOS CASOS DE USO DEL NEGOCIO DEL
SISTEMA ____
2.5.1. DIAGRAMA GENERAL DE REALIZACIÓN DE LOS
CASOS DE USO DEL NEGOCIO DEL SISTEMA ____
2.5.2. REALIZACIÓN DEL CASO DE CUN 01
a) Diagrama de Actividad del CUN 01
b) Diagrama de Objetos CUN 01
..........
2.6. DIAGRAMA DE OBJETOS DEL NEGOCIO DEL SISTEMA ____
2.7. MODELO DEL DOMINIO DEL SISTEMA ____
2.8. GLOSARIO DE TÉRMINOS DEL NEGOCIO DEL SISTEMA ___
ACTIVIDAD 4
1. Desarrollar el modelo de negocio de un sistema para una empresa del
medio y documentarla de acuerdo a la estructura propuesta.
En este capitulo se explicó de una manera sencilla y práctica el

procedimiento para modelar un negocio mediante RUP-UML con Rational
Rose.
 Booch, G. et al. "El lenguaje unificado de modelado: guía de

usuario", 2ªed., Addison-Wesley, 2006.
Enlaces web:
 http://www.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/
 http://code.google.com/p/farmaciag1/

CASO DE ESTUDIO: Biblioteca

La biblioteca cuenta con socios, que se dan de alta en la biblioteca y a
partir de ese momento pueden tomar prestados libros de la misma. Un
socio está caracterizado por un número de socio, un nombre y una
dirección; además, en cada momento se puede saber el número de
libros que un socio tiene prestados, y si tiene más de cinco libros. Por su
parte, de cada libro se conoce su código, título, autor y si está o no
disponible; además se puede saber en cualquier momento la localización
del libro en la biblioteca, así como la signatura del mismo. Un libro puede
ser cambiado de lugar, y se le puede cambiar igualmente su signatura;
de hecho, siempre que se cambia la signatura de un libro es porque se
cambia de lugar. Los libros se prestan a los socios, y como
consecuencia aparece la noción de préstamo; un préstamo estará
caracterizado, además de por el código del libro prestado y el número de
socio, por la fecha del mismo. Por otra parte también se va a llevar
control de los socios que tengan prestados más de 5 libros, haciendo
que estos socios pasen a especializarse temporalmente en
socios_no_fiables, para controlar que a este tipo de socios no se les
pueda prestar más libros. Los socios que devuelven libros más tarde de
lo establecido, se les penalizará con una multa. La biblioteca adquiere
los libros directamente de las editoriales con las que trabaja. De vez en
cuando, el bibliotecario comprueba el estado de los libros y en caso de
encontrarse en mal estado, es llevado al servicio de restauración para
proceder a su reparación, si es posible, si no, se desecha.
Identifíquese cualquier detalle faltante que usted necesite y realice el
Modelo del Negocio del Sistema de Biblioteca.

INGENIERÍA DE REQUERIMIENTOS
CON RUP Y UML
Lograr una comunicación efectiva entre los usuarios y el equipo de

proyecto y entre los integrantes del equipo, con el objetivo de llegar a un
entendimiento de lo que hay que hacer, es la clave del éxito en la producción
de un software. Durante años muchas aplicaciones han fallado (no se
culminaron o no se usaron) porque existieron incongruencias entre lo que el
usuario quería, lo que verdaderamente necesitaba, lo que interpretaba cada
miembro del equipo de proyecto y lo que realmente se obtiene. Aquí radica
la importancia que en los últimos años se ha dado a la identificación de los
requisitos como punto de partida en el proceso de desarrollo del software.

1. Describe el flujo de trabajo para obtener los requerimientos del
sistema.
2. Analiza y documenta los requerimientos funcionales y no funcionales
del sistema.
3. Analiza y documenta las especificaciones de los requerimientos del
sistema.

5.1. FLUJO DE TRABAJO DE REQUISITOS
El flujo de trabajo de modelamiento del negocio enseña a describir el
negocio actual y a modelar el negocio propuesto, ofrece una visión de
qué es necesario hacer para dar respuesta a la solicitud del usuario.
Debemos recordar que en esta fase el equipo se familiarizará más al
funcionamiento de la empresa, sobre conocer sus procesos.
- Entender la estructura y la dinámica de la organización para la cual
el sistema va ser desarrollado.
- Entender el problema actual en la organización objetivo e identificar
potenciales mejoras.
- Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento común de la organización objetivo.
En relación a los requisitos viene a ser el contrato que se debe cumplir,

de modo que los usuarios finales tienen que comprender y aceptar los
requisitos que especifiquemos.
- Establecer y mantener un acuerdo entre clientes y otros
stakeholders sobre lo que el sistema podría hacer.
- Proveer a los desarrolladores un mejor entendimiento de los
requisitos del sistema.
- Definir el ámbito del sistema.
- Proveer una base para estimar costos y tiempo de desarrollo del
sistema.
- Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.
Durante el proceso de obtención de los requisitos desempeña un papel

esencial el cliente, que se convierte en un miembro más del equipo de
proyecto por lo que el resultado de la captura de requisitos debe ser
escrito en su lenguaje.
Como parte de este modelamiento del sistema, las principales
actividades que se realizan son: Encontrar actores y casos de uso,
Priorizar casos de uso, detallar casos de uso, prototipar la interfaz de
usuario y estructurar el modelo de casos de uso.
Las áreas de esfuerzo del análisis de requisitos son:
 Reconocimiento del problema como lo ve el usuario.
 Evaluación del problema y síntesis de la evaluación: Como
evaluación se entiende a la definición de los datos observables, la
evaluación del flujo y contenido de la información, la definición de las
funciones del software, entender el comportamiento del software
ante eventos, el establecimiento de las características de la interfaz
y el descubrimiento de restricciones adicionales de diseño. Toda
esta evaluación se sintetiza en la definición en detalle de los datos,
funciones y el comportamiento del sistema.
 Modelado: Creación de modelos que ayuden a entender la entidad a
construir.
 Construcción de un prototipo de alto nivel del sistema.
 Revisión por parte del usuario.
 Firma del contrato si las partes están de acuerdo.

Los requisitos se pueden clasificar en: funcionales y no
funcionales.
Los requerimientos funcionales definen las funciones que el sistema
será capaz de realizar. Describen las transformaciones que el sistema
realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características
que de una u otra forma puedan limitar el sistema, como por ejemplo, el
rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento,
seguridad, portabilidad, estándares, etc.
5.2. CARACTERÍSTICAS DE LOS REQUERIMIENTOS.

Las características de un requerimiento son sus propiedades
principales.
 Completo: Cada requerimiento debe describir de manera completa la
funcionalidad que debe cumplir. Debe contener toda la información
necesaria para que el desarrollador diseñe e implemente tal
funcionalidad.
 Correcto: Cada requerimiento debe describir de manera precisa la
funcionalidad que se debe construir. Un requerimiento correcto no
debe entrar en conflicto con otro requerimiento. Sólo los usuarios
más representativos del sistema pueden determinar de manera
precisa si un requerimiento es correcto o no.

 Realizable: Debe ser posible implementar cada requerimiento de
acuerdo a las capacidades y limitaciones del sistema y el medio que
lo rodea. Para garantizar que no se determinen requerimientos no
realizables, se recomienda contar con personal al interior del equipo
de analistas de requerimientos que pueda establecer las limitaciones
técnicas y de costos.
 Necesario: Cada requerimiento debe documentar algo que los
clientes realmente necesiten, algo que sea para conformidad de un
sistema externo con el que se tenga interacción, o para satisfacer un
estándar. Para determinar si un requerimiento es necesario se debe
determinar quien lo propuso, es decir, conocer su origen.
 Priorizable: Es importante asignar una prioridad para cada
requerimiento que indique que tan esencial es el mismo para la
realización del producto. Se pueden perder elementos de juicio para
el desarrollo del sistema si se asigna el mismo grado de prioridad a
todos los requerimientos.
 No Ambiguo: Todos los lectores de un requerimiento deben llegar a
una misma y consistente interpretación del mismo. El lenguaje usado
en su definición, no debe causar confusiones al lector.
 Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de los siguientes
métodos de verificación: inspección, análisis, demostración o
pruebas.
5.3. DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS

- Los requerimientos no son obvios y vienen de muchas fuentes.
- Existen muchos tipos de requerimientos y diferentes niveles de
detalle.
- La cantidad de requerimientos en un proyecto puede ser difícil de
manejar.
- Nunca son iguales.
- Los requerimientos están relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.
- Cada requerimiento tiene propiedades únicas y abarcan áreas
funcionales específicas.
- Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
- Son difíciles de cuantificar, ya que cada conjunto de requerimientos
es particular para cada proyecto.
5.4. IMPORTANCIA DE LA INGENIERÍA DE

REQUERIMIENTOS:
Los principales beneficios que se obtienen de la Ingeniería de
Requerimientos son:
 Permite gestionar las necesidades del proyecto en forma
estructurada: Cada actividad de la IR consiste de una serie de pasos
organizados y bien definidos.

 Mejora la calidad del software: La calidad en el software tiene que
ver con cumplir un conjunto de requerimientos (funcionalidad,
facilidad de uso, confiabilidad, desempeño, etc.).
 Mejora la comunicación entre equipos: La especificación de
requerimientos representa una forma de consenso entre clientes y
desarrolladores.
 Evita rechazos de usuarios finales: La ingeniería de requerimientos
obliga al cliente a considerar sus requerimientos cuidadosamente y
revisarlos dentro del marco del problema, por lo que se le involucra
durante todo el desarrollo del proyecto.
5.5. PROCESO DE INGENIERÍA DE REQUERIMIENTOS

El proceso de Ingeniería de Requerimientos describe de manera
detallada y precisa cada uno de los aspectos del ciclo de vida de un
conjunto de requerimientos. Este proceso presenta dos grandes ramas:
El Desarrollo de requerimientos, y la Administración de requerimientos.
Cada una de estas actividades que conforman el Desarrollo de

Requerimientos consisten en:
 Recolección (Elicitation): Es el Proceso a través del cual los clientes
(compradores y/o usuarios) y el desarrollador (contratista) de un
sistema de software; descubren, revisan, articulan, y entienden las
necesidades de los usuarios del sistema y las restricciones que se
dan sobre el software y el desarrollo delmismo.
 Análisis (Analysis): Es el proceso de analizar las necesidades de los
clientes y los usuarios para llegar a una definición de los
requerimientos de software.
 Especificación (Specification): Consiste en el desarrollo de un
documento que de manera clara y precisa contenga y especifique
cada uno de los requerimientos del sistema de software.
 Verificación (Verification): Es el proceso de asegurar que la
especificación de requerimientos de software sea acorde con los
requerimientos del sistema, conforme a los estándares de
documentación de la fase de requerimientos, y que a su vez este
documento sea una base sólida para la arquitectura y el diseño.

5.6. HERRAMIENTAS PARA LA RECOLECCIÓN DE
REQUERIMIENTOS
5.7. ACTIVIDADES PARA OBTENER REQUERIMIENTOS

5.8. MODELADO DE REQUERIMIENTOS A PARTIR DEL
MODELO DE NEGOCIOS
En ingeniería de software, existen dos tipos de modelos básicos:
 Modelo casos de uso del sistema: El mismo que es pespecificado a
partir de los CUN.
 Modelo conceptual: Es el utilizado en la especificación del sistema,

representa los conceptos más significativos en el dominio del
problema. Nos describe la parte estática del problema, es una
fotografía del mundo real.
Una vez identificados los procesos de negocio de la organización, y

descritos sus flujos de trabajo mediante diagramas de actividades, los
casos de uso se elicitan y estructuran a partir de las actividades de
cada proceso, mientras que las entidades del modelo conceptual se
obtienen de los datos que fluyen entre tales actividades. Además, se
identifican las reglas del negocio y se incluyen en un glosario como
parte de la especificación de los datos y las actividades.

EJEMPLO DE OBTENCIÓN DE REQUERIMIENTOS
CASO: SISTEMA DE GESTIÓN DE UN VIDEO CLUB
Una tienda de alquiler de películas de Huancayo posee alrededor de 5000 DVDs de
vídeos de los que requiere llevar registro.Cada uno de los DVDs tiene un número de
película. Para cada película, se necesita conocer título, duración, director y la
categoría según la siguiente clasificación: drama, acción, suspenso, comedia,guerra y
ciencia-ficción. Existen muchas copias de la mayoría de las películas. Se le asigno a
cada película un identificador específico, y así se puede saber en que DVD se
encuentra esta película. Un DVD puede ser tanto formato VCD o MP4. Siempre se
tiene por lo menos un DVD de cada película que se registra, y cada película es
siempre copiada a un DVD individual y específico. Nuestros clientes al momento de
solicitar en alquiler un DVD de video, frecuentemente nos pregunta por los
protagonistas de la película que quiere alquilar. Así, que se debe llevar el registro de
los actores que aparecen en cada película. No todas las películas tienen actores. A
los clientes les gustaría conocer el nombre real del actor, edad y estado civil.
Solamente se llevan registros de actores que aparecen en las películas de la tienda.
La tienda de Video Club tiene muchos clientes y solamente alquila vídeos a personas
que sean socias del vídeo club. Para que una persona pueda pertenecer al video
club como socio debe afiliarse, para lo cual se le asigna un número que lo identifica y
se deben registrar sus nombres y apellidos, número telefónico, dirección de
residencia. Se necesita llevar el registro de que VDV de vídeo ha alquilado cada socio
en un momento determinado. Un cliente puede alquilar varios DVDs de vídeos
simultáneamente. Necesitamos registrar el histórico de todos los alquileres
realizados. Cada vez que un cliente alquila un video, se debe registrar la fecha de
alquiler, el día que regresará el video. Todos los DVDs de video deben ser
regresados a la tienda a más tardar tres días después de su alquiler, y en caso de no
entregarse a tiempo, se cobrara una multa de S/2.00 por película y día de mora. El
histórico de alquiler de videos se requiere con el fin de analizar el comportamiento del
alquiler de videos. Con el histórico seremos capaces de determinar cuantos DVDs
alquila cada cliente y cuantas veces un cliente ha regresado un DVD tarde.
También necesitamos saber cuantas veces un DVD ha sido usado, y saber cuando
retirar dicho DVD. También podremos analizar las preferencias de nuestros clientes y
conocer el valor en pesos recibido por el concepto de alquiler de videos y multas por
mora.
Diagrama de Casos de Uso del Negocio del Sistema de Gestión de un

Video Club

REQUERIMIENTOS DEL SISTEMA DE GESTIÓN DE UN VIDEO
CLUB
1. Matriz de Procesos vs Requerimientos

Área que
N° CUN CUN Descripción CUN Requerimiento
afecta
El empleado registra
Llevar el registro de
Gestionar las películas
CUN-01 Almacen todos los DVDs de
Películas disponibles en el
Video.
vídeo club.
El empleado realiza
Alquilar vídeos a
altas, bajas,
Gestionar personas que sean
CUN-02 modificaciones de Ventas
Socios socias del vídeo
datos, sanciones a
club.
socios del video club.
El empleado controla
Registrar el
la disponibilidad de
Gestionar histórico de todos
DVDs para su Almacen
CUN-03 Alquileres los alquileres
alquiler y posterior
realizados
devoluciòn.
2. Objetivos del sistema

En este apartado vamos a definir una lista con los diferentes
objetivos que se esperan alcanzar cuando el sistema software a
desarrollar esté en explotación. Serán especificados mediante
una plantilla para objetivos.
OBJ–01 Gestionar las películas
Descripción El sistema deberá gestionar las películas disponibles
en el vídeo club: adquisiciones, retiradas,
disponibilidad, etc.
Estabilidad alta
Comentarios ninguno
OBJ–02 Gestionar los socios

Descripción El sistema deberá gestionar las socios del vídeo–
club: altas, bajas, modificaciones de datos,
sanciones, personas autorizadas, cuentas, etc.
Estabilidad alta
Comentarios ninguno
OBJ–03 Gestionar los alquileres

Descripción El sistema deberá gestionar los alquileres de DVDs:
entregas, devoluciones, devoluciones tardías,
reclamaciones, disponibilidad, etc.
Estabilidad alta
Comentarios ninguno

3. Requisitos funcionales
3.1. Definición de actores
Este apartado contiene los diferentes actores que se han
identificado, especificados mediante la plantilla para actores
de casos de uso.
ACT–01 Socio
Descripción Este actor representa a los socios del vídeo–
club
ACT–02 Empleado del vídeo–club

Descripción Este actor representa a los empleados del
vídeo–club
3.2. Diagramas de casos de uso

En esta sección hemos incluido los diagramas de casos de
uso de nuestro sistema, desarrollados con la herramienta
Rational Rose 7.0.
Diagrama de subsistemas.
Diagrama de casos de uso del subsistema Gestión de

socios

películas

alquileres.

3.3. Especificación de los Requerimientos Funcionales del
Sistema
RF- 01 Alta de socio

Objetivos asociados OBJ–02 Gestionar las socios
Descripción El sistema deberá comportarse tal como se
describe en el siguiente caso de uso cuando
alguien solicite su ingreso como
socio
Precondición El solicitante no es un socio del vídeo–club y
tiene su documentación disponible
Secuencia Normal Paso Acción
1 El empleado del vídeo–club solicita al
sistema comenzar el proceso de alta de
un nuevo socio
2 El sistema solicita los siguientes datos
del nuevo socio: nº del DNI, nombre,
apellidos, fecha de nacimiento, sexo,
dirección y teléfonos de contacto
3 El empleado del vídeo–club solicita los
datos requeridos y la documentación al
nuevo socio
4 El empleado del vídeo–club comprueba
que los datos
del nuevo socio coinciden con los de la
documentación aportada
5 El empleado del vídeo–club
proporciona los datos requeridos y
solicita al sistema que los almacene
6 El sistema almacena los datos
proporcionados, imprime el carnet de
socio e informa al empleado del vídeo
club de que el proceso ha terminado
con éxito
7 El empleado del vídeo–club entrega el
carnet al nuevo
socio
Postcondición El solicitante es socio del vídeo–club y el saldo
de su cuenta es
0
Excepciones Paso Acción
4 Si la documentación aportada no es
correcta, el empleado del vídeo–club
cancela la operación, a continuación
este caso de uso termina

5 Si el sistema detecta que el nuevo
socio ya es socio del vídeo–club, el
sistema informa de la situación al
empleado del vídeo–club permitiéndole
modificar los datos proporcionados, a
continuación este caso de uso continúa
5 Si el empleado del vídeo–club solicita
cancelar la operación, el sistema
cancela la operación, a continuación
este caso de uso termina
Rendimiento Paso Cota de tiempo
4 5 segundos
Frecuencia esperada 10 veces/día
Estabilidad alta
Comentarios La frecuencia será mucho mayor durante los
dos primeros meses, probablemente 100
veces/día
....
....
....
RF- 015 Identificación de socio

Objetivos asociados OBJ–02 Gestionar las socios
Descripción El sistema deberá comportarse tal como se
describe en el siguiente caso de uso durante
la realización de los casos de uso:
RF–02 Baja de socio
RF–03 Modificación de datos de un socio
RF–06 Alquiler de cintas de vídeo
Precondición El socio tiene su documentación disponible
Secuencia Normal Paso Acción
1 El sistema solicita que se identifique al
socio
2 El empleado del vídeo–club solicita el
carnet de socio
3 El empleado del vídeo–club
proporciona los datos de identificación
al sistema
4 El sistema muestra los números de
teléfonos que el socio proporcionó
cuando se dio de alta
5 El empleado del vídeo–club solicita al
socio que le confirme alguno de los
números de teléfono registrados en el
sistema
6 El empleado del vídeo–club confirma la
identidad del socio al sistema
Postcondición Ninguna

Excepciones Paso Acción
3 Si el sistema detecta que el supuesto
socio no es socio del vídeo–club, el
sistema comunica al empleado del
vídeo–club la situación, a continuación
este caso de uso aborta
5 Si el socio no conoce ningún número
de teléfono registrado en el sistema y
no puede demostrar su identidad, el
empleado del vídeo–club retiene el
carnet de socio y cancela la operación,
a continuación este caso de uso aborta
5 Si el socio no conoce ningún número
de teléfono registrado pero puede
demostrar su identidad por otros
medios, el empleado del vídeo–club le
recuerda los números de teléfonos que
proporcionó cuando se dio de alta, a
continuación este caso de uso
continúa
Rendimiento Paso Cota de tiempo
-- --
Frecuencia esperada 50 veces/día
Comentarios ninguno
4. Requisitos No funcionales
4.1. Requerimiento del producto
[Si en el modelo de Casos de uso no se incluye esta
información en esta sección se describe el producto
respecto de otros productos relacionados y como opera bajo
ciertas restricciones.
Puede incluir Interfases del sistema, Interfases de usuario,
Interfases de hardware, Interfases de software, Interfases
de comunicación, Memoria, Operaciones, Requerimientos
de adecuación al entorno.]
4.1.1. Interfases de usuario
[Esta sección describe las interfases de usuario que
se deben implementar. Incluye las características
lógicas de cada interfase entre el producto de
software y el usuario que son necesarias para lograr
los requerimientos del software, por ejemplo,
formatos de pantalla, contenido de reportes y
menús, o disponibilidad de teclas de función.]
4.1.2. Interfases con hardware
[Esta sección describe las características de las
interfaces entre el producto de software y los
componentes de hardware del sistema. Incluye
características de configuración, dispositivos que se

deben soportar, como deben ser soportados y
protocolos.]
4.1.3. Interfases con software
[En esta sección se debe especificar el uso de otros
productos de software necesarios (sistema de base
de datos, sistema operativo, librerías o paquetes),
interfases con otros sistemas de aplicación.]
4.1.4. Interfases de comunicación
[En esta sección se describe cualquier interfase de
comunicación con otro sistema o dispositivo como
redes, dispositivos remotos, etc.]
4.1.5. Restricciones de memoria
[En esta sección se deben especificar las
características aplicables y límites en memoria
primaria y secundaria]
4.2. Requerimientos de documentación

[En esta sección se especifica el tipo de documentación que
se requiere, el contenido y formato de la misma.]
4.2.1. Manual de Usuario
[En esta sección describa el propósito y contenido
del Manual de Usuario. Especifique el largo
deseado, nivel de detalle, necesidad de índice,
glosario de términos, tutoriales o manual de
referencia estratégica, etc. Especifique también
restricciones de formato e impresión.]
4.2.2. Ayuda en línea
[En esta sección especifique si el sistema de
software incluye un sistema de ayuda en línea. Si lo
incluye especifique los requerimientos de
organización y presentación del mismo.]
4.2.3. Guías de instalación, configuración y archivo Léame.
[En esta sección especifique si el sistema de
software contendrá instrucciones para instalación y
configuración. Además si se incluirá el típico archivo
Léame, que puede incluir las Novedades de la
versión, discusión de compatibilidad con versiones
anteriores, documentación de errores conocidos y
soluciones alternativas.]
4.2.4. Etiquetado y empaquetado
[El estado del arte de las aplicaciones de hoy
proporciona un aspecto consistente que comienza
con el paquete del producto y se manifiesta a través
de los menús de la instalación, las pantallas del
sistema, los sistemas de ayuda, los diálogos con el
usuario, etc. Esta sección define las necesidades y
tipos de etiquetas a para ser incorporado en el
código, por ejemplo, derechos de propiedad literaria
y avisos patentes, logotipos corporativos, iconos
estandarizados y otros elementos gráficos, etc.]

5.9. DOCUMENTACIÓN DE REQUERIMIENTOS CON RUP Y
UML
CAPITULO III
REQUERIMIENTOS DEL SISTEMA
3.1. MATRIZ DE PROCESOS VS REQUERIMIENTOS
3.2. OBJETIVOS DEL SISTEMA
3.3. REQUISITOS FUNCIONALES
3.3.1. DEFINICIÓN DE ACTORES
3.3.2. DIAGRAMAS DE CASOS DE USO
3.3.2.1. DCU DEL DEL SUBSISTEMA 01
…
3.3.3. ESPECIFICACIÓN DE LOS REQUERIMIENTOS
FUNCIONALES DEL SISTEMA
3.4. REQUISITOS NO FUNCIONALES
3.4.1. REQUERIMIENTO DEL PRODUCTO
3.4.2. REQUERIMIENTOS DE DOCUMENTACIÓN
3.5. PROTOTIPO DE LA INTERFAZ DE USUARIO
ACTIVIDAD 5
1.Realizar la ingeniería de requerimiento del sistema en desarrollo y
documentarla de acuerdo a la estructura propuesta.
El punto de partida en el proceso de desarrollo de un software es la

identificación de los requisitos. En este módulo se indica cómo se
describe lo que el sistema debería hacer utilizando el lenguaje de
clientes y desarrolladores.
 Bruegge y Dutoit. Ingeniería de Software Orientado a Objetos”.

Editorial Pearson. México 2002.
Enlaces web:

INGENIERÍA DE REQUERIMIENTOS CON RUP Y UML
CASO DE ESTUDIO: Gestión de Cursos de Doctorado
Modelar un sistema que ayude al departamento de informática de una
universidad a administrar los cursos de doctorado. El sistema es el siguiente:
- Al final de cada año académico, el Comité de Programa del
departamento de informática determina las asignaturas que estarán
disponibles para los estudiantes de doctorado en el próximo año (Un
estudiante de doctorado puede ser cualquier estudiante ya graduado).
- Cada curso de doctorado se compone como mínimo de 5 asignaturas.
- Al final de cada año académico, el Director de Dpto. asigna tareas a los
miembros de la plantilla de profesorado; en particular, a un profesor se le
asigna dar clase en alguna de las asignaturas de un curso de doctorado
(a estos profesores les llamaremos profesores de doctorado).
- El coordinador del doctorado, teniendo en cuenta esta información,
elabora la guía de los cursos de doctorado. Cada prof. de doctorado
participa en la elaboración de esta guíaproponiendo el temario del curso
para su asignatura. La secretaría del centro, una vez recibida la versión
final de la guía se encarga de su impresión y difusión. Al mismo tiempo,
el coordinado del doctorado se encarga de publicar dicha guía en la
página web del dpto.
- El coordinador del doctorado junto con la secretaría del centro se
encargan de crear una lista con los alumnos matriculados en el curso de
doctorado.
- A cada estudiante de doctorado se le asigna un tutor de doctorado de
entre los profesores de doctorado, que mantendrá su rol hasta que
termine.
- Un estudiante solo puede estar matriculado en un curso de doctorado y
dentro de éste, cómo máximo, se puede matricular de 5 asignaturas
cada año.
- Secretaría finalmente genera las listas de estudiantes matriculados en
cada asignatura y las envía a los profesores de doctorado
correspondientes (aquellos que imparten la asignatura).
Se pide:
Modelar la obtención de requisitos del sistema utilizando la metodologia RUP
y el lenguaje de modelado UML.

ANÁLISIS Y DISEÑO DEL SOFWARE
CON RUP Y UML
Desde la perspectiva de las fases de RUP, en análisis y diseño, la

fase de Incepción se refiere a determinar si el sistema previsto es factible.
En la fase de elaboración se centra en la creación de una arquitectura inicial
para el sistema (Definición de la Arquitectura Candidata). Si la arquitectura
ya existe, se enfocará al perfeccionamiento de la arquitectura (Refinar la
Arquitectura) y analizar el comportamiento y crear elementos que
proporcionan el comportamiento apropiado. (Análisis de Comportamiento).
Después, en el Diseño de Componentes, se producen un conjunto de
componentes que proporcionan el comportamiento apropiado para satisfacer
los requisitos en el sistema. Si el sistema incluye una base de datos, se
realiza el Diseño de la base de datos de manera paralela con el Diseño de
Componentes.

1. Transformar los requerimientos en un modelo de diseño del sistema a
implementar.
2. Definir una arquitectura robusta para el sistema.
3. Adaptar el diseño a un entorno de implementación pensando en la
eficiencia.

6.1. PROCESO DE ANÁLISIS Y DISEÑO DE RUP
En esta actividad se especifica y describe cómo se va a implementar el
sistema, es decir, los diseñadores de software determinan la mejor
solución técnica a partir de los requerimientos de la arquitectura del
sistema más adecuada y el diseño detallado necesario previo a las
actividades de implementación. Algunos puntos que el analista y el
diseñador deben cubrir son los siguientes:
 Analizar los requerimientos del sistema.
 Definir la arquitectura tecnológica, de datos y funcional.
 Definir los patrones de diseño.
 Adaptar el diseño para que sea consistente con el entorno de
implementación y ajustarla para un desempeño esperado.
La arquitectura hardware y software se determinan en esta fase,

describiendo los subsistemas y las interrelaciones entre cada uno de
ellos, ofreciendo el diseño de aquellos componentes que serán
fabricados e indicando cuáles serán integrados acudiendo a los
existentes en el mercado.
En RUP se expresa el Análisis y proceso de Diseño en términos de

Actividades, Roles y Artefactos, tal como se muestra en la siguiente
figura:

Los principales roles involucrados en el Análisis y el Diseño son:
 Arquitecto de software
El arquitecto dirige y coordina las actividades técnicas y artefactos
de todo el proyecto. Él o ella establece la estructura general de las
interfaces entre las principales agrupaciones. En contraste con las
opiniones de los demás roles, el arquitecto considera la amplitud en
lugar de profundidad.
Se encarga de la definición de la arquitectura que guiará el
desarrollo, y de la continua refinación de la misma en cada iteración;
debe construir cualquier prototipo necesario para probar aspectos
riesgosos desde el punto de vista técnico del proyecto; definirá los
lineamientos generales del diseño y la implementación.
 Diseñador
El diseñador define las responsabilidades, las operaciones, atributos
y relaciones de una o varias clases y determina la forma en que
debe ajustarse al entorno de la implementación. Además, el
diseñador puede tener la responsabilidad de uno o más paquetes de
diseño o subsistemas de diseño, incluidas las clases de propiedad
de los paquetes o subsistemas.
Tiene a su cargo la codificación de los componentes en código
fuente en algún lenguaje de programación durante cada iteración;
debe elaborar y ejecutar las pruebas unitarias realizadas sobre el
código desarrollado; es responsable de las clases que ha
desarrollado debiendo documentarlas, actualizarlas ante cambios y
mantenerlas bajo el control de configuración de las mismas mediante
la herramienta utilizada.
Existen roles opcionales que se pueden incluir en las actividades de

Análisis y Diseño:
 Diseñador de base de datos:
El Diseñador de bases de datos es necesario cuando en el diseño
del sistema se incluye una base de datos.
El diseñador de la base de datos define las tablas, índices, vistas,
limitaciones, disparadores, procedimientos almacenados, tablas o
parámetros de almacenamiento, y otras bases de datos específicas
de las construcciones necesarias para almacenar, recuperar y
eliminar la persistencia de objetos. Esta información se mantiene en
el Artefacto: modelo de datos.
 Diseñador de Componentes. (para sistemas de tiempo real):
El diseñador de componentes se centra en garantizar que el sistema
sea capaz de responder a los acontecimientos de manera oportuna,
a través del uso adecuado de las técnicas de diseño.
 Revisor de Arquitectura o mentor:
Es el rol que está íntimamente ligado con el proceso de desarrollo de
software, que conoce todas las prácticas involucradas y entiende el
porqué de la misma. Acompaña y apoya a los equipos de trabajo
mediante revisiones de los artefactos y haciendo recomendaciones
de cómo mejorar los mismos durante todo el ciclo de vida del
sistema.

6.2. ANÁLISIS DEL SISTEMA
Cuando se desarrolla un sistema se debe considerar la importancia de
comprender y comunicar los requerimientos antes de empezar a
programarlo, ya que si no se hace, se puede estar programando un
sistema que no contempla los requerimientos que el cliente quiere o el
sistema no hace lo que tenía pensado el cliente.
El propósito del análisis es analizar los requisitos con mayor
profundidad, utilizando el lenguaje de los desarrolladores para describir
resultados.
En el análisis podemos estructurar los requisitos de tal manera que nos
facilite su comprensión, reparación, modificación.
6.2.1. Los trabajadores y artefactos implicados en el análisis

6.2.2. Flujo de Trabajo del análisis RUP
a) Los arquitectos comienzan la creación del modelo de análisis
identificando los paquetes de análisis principales, las clases
de entidad evidentes y los requisitos comunes.
b) Después los Ing de CU realizan cada CU en términos de las
clases del análisis exponiendo los requisitos de
comportamiento de cada clase.
c) Los Ingenieros de Componentes especifican los requisitos y
los integran dentro de cada clase creando responsabilidades,
atributos y relaciones para cada clase.
Las entradas y los resultados del análisis de un CU.

6.2.3. Artefactos del Análisis RUP
a) Modelo de Análisis:
Representa la estructura global del sistema (subsistemas y/o
capas en el modelo de diseño).
b) Realización de caso de uso

Descripción de cómo se realiza un CU. Esta se expresa en
términos de un diagrama de clases que muestra las clases del
análisis participantes en la realización del CU y diagramas de
interacción que muestran como se lleva a cabo la

colaboración entre las clases para dar cumplimiento al mismo
(tantos diagramas como sean necesarios para abarcar todas
los posibles desenlaces (escenarios ) del CU ).
c) Diagrama de Clases de Análisis

Constituye una vista estática de las clases que conforman el
modelo del análisis y las asociaciones entre las mismas. Es
una vista de la futura composición de clases de software.

Posee las siguientes características:
- Una clase de análisis se centra en el tratamiento de los
requisitos funcionales.
- Una clase de análisis define atributos que son
conceptuales y reconocibles en el dominio del problema.
- Una clase de análisis participa en relaciones.
- La clase de análisis encaja en uno de tres esteriotipo
básico: De interfaz, De control, De entidad.
Clase de Interfaz: representa los elementos que se

desempeñan como interfaz y se encargan de la modelación
de toda la interacción que puede existir entre los actores y el
sistema (usuario – sistema, sistema – sistema).
Representa la abstracción de ventanas formularios, paneles,
interfaz de comunicación, interfaz de impresión, censores,
terminales, APIS.
Clase de Control: representa los elementos que ejercen de
proceso referido a la coordinación, secuenciación,
transacciones y a veces la lógica del negocio. Se emplean a
menudo para encapsular el control referido a un Caso de uso.
Clase de Entidad: representa los elementos que guardan la
información del sistema. Se derivan de una clase de entidad
del negocio o del dominio.

Ejemplo:
Para analizar el CU Realizar Orden de Compra
Realizar Orden de Compra

Cliente Sistema
(from Use Cases) Académico
(f rom Actors)
(f rom Actors)
Primero debemos identificar las clases de análisis:
IU Orden Cliente IU Orden Productos IU Banco
CTRL Orden compra
Productos Clientes
Orden Compra Items Orden
Luego establecemos el Diagrama de Clases del Caso de uso

Realizar Orden de Compra.
Productos
IU Orden Cliente
1..n
Cliente Agencia
0..n
(f rom Actors) CTRL Orden compra
Items Orden
IU Orden Productos
Orden Compra
Sistema IU Banco
Académico
(f rom Actors)
Clientes

Relaciones directas entre clases en los
diagramas de clases
d) Diagramas de Interacción de Análisis

La secuencia de acciones en un caso de uso comienza
cuando un actor invoca el caso de uso. Si consideramos el
interior del sistema un objeto de interfaz recibirá este mensaje
del actor, el cual enviara a su vez un mensaje a algún otro
objeto. El análisis permite mostrar esto con diagramas de
colaboración.
Diagrama de colaboración
Se utilizan para ilustrar la realización de un Caso de Uso
(CU). Muestra como los objetos interactúan para lograr el
comportamiento de un CU o parte de este y de esta forma
definen los roles de los mismos. A diferencia de los diagramas
de secuencia su principal objetivo es mostrar la relación entre
dichos objetos. Estos diagramas tienen una mayor utilidad
cuando se utilizan en interacciones entre un número no muy
grande de objetos, pues en caso contrario el número de
mensajes entre estos crece y el diagrama se hace difícil de
entender; en estos casos los diagramas de secuencia son una
mejor elección.

6.2.4. Actividades del Análisis RUP
Actividad Subactividad
1. Análisis de Casos 1.1. Identificar las clases de análisis
necesarias para la realización del
de Uso. caso de uso.
1.2. Distribuir el comportamiento del
caso de uso entre las clases de
análisis.
1.3. Capturar/asignar requisitos no
funcionales a clases de análisis.
2. Análisis de Clases 2.1. Identificar las responsabilidades
de las clases de análisis
2.2. Identificar atributos y relaciones
de las clases de análisis.
2.3. Capturar requisitos especiales
3. Análisis de 3.1 Paquetes débilmente acoplados
3.2. Elementos cohesionados
Paquetes. 3.3. Clases de interacción
6.2.5. Ejemplo Sistema Cajero Automático
Validar Usuario
Sacar Dinero
Cliente Banco
Ingresar Dinero
(f rom Actors)
Transferencia
1. Análisis de Casos de Uso
1.1. Identificar las clases de análisis necesarias para la
realización del caso de uso.
Caso de Uso Validar Usuario

Caso de Uso Sacar Dinero
Caso de Uso Ingresar Dinero

Caso de Uso Transferencia
1.2. Distribuir el comportamiento del caso de uso entre las

clases de análisis.
Diagrama de colaboración del Caso de Uso Validar

Usuario

Diagrama de Colaboración del Caso de Uso Sacar
Dinero
Diagrama de colaboración del Caso de Uso Ingresar

Dinero

Diagrama de colaboración del Caso de Uso
Transferencia
DIAGRAMA DE CLASES DE ANÁLISIS DE CONTEXTO

2. Análisis de Clases
2.1. Identificar las responsabilidades de las clases de análisis.
Caso de Uso Validar Usuario:
Caso de Uso Sacar Dinero:

Caso de Uso Transferencia
ANÁLISIS DE CLASES

3. Análisis de Paquetes.
El paquete de análisis proporciona un medio para organizar
los artefactos del modelo en piezas manejables y presentarlo
en una arquitectura.
Descripción de la Arquitectura
Arquitectura interfaz de usuario
- UI_AbrirCuenta: Interfaz para que el cliente pueda contratar
una nueva cuenta.
- UI_AltaCliente: Interfaz para que el gestor bancario pueda
dar de alta en el sistema a un nuevo cliente.
- Ui_Transferencia: Interfaz usada por el cliente para realizar
un movimiento de dinero entre una de sus cuentas y otra
cuenta.
- UI_VerCliente: Interfaz para que el gestor bancario pueda
ver la información de un cliente. También encapsula la
interacción con el gestor en los casos de uso “Baja de
Cliente” y “Cancelar Cuenta”.
Arquitectura de control
- Ctrl_AbrirCuenta: realiza el proceso de crear una cuenta y
asociarla al cliente ordenante de la operación.

- Ctrl_AltaCliente: realiza el proceso de dar de alta a un
cliente en el sistema. Debe cerciorarse de que el cliente a
crear no existe ya en el sistema.
- Ctrl_BajaCliente: realiza el proceso de dar de baja a un
cliente en el sistema. Debe cerciorarse de que el cliente a
crear no tiene cuentas contratadas con el banco.
- Ctrl_CancelarCuenta: realiza el proceso de cancelar la
cuenta de un cliente. Esta operación será realizada por un
gestor bancario. En caso de que la cuenta tuviese saldo
negativo, se abortaría la operación.
- Ctrl_Transferencia: realiza el proceso de mover una
cantidad de dinero desde una cuenta a otra. Esta clase de
análisis comprobará que la cuenta origen está contratada
por el ordenante de la operación, y si hay saldo suficiente.
- Ctrl_VerCliente: realiza el proceso de búsqueda de un
cliente indicado por el gestor bancario, para devolver sus
datos personales y la colección de cuentas que tiene
contratadas.
Arquitectura de entidad
- Cliente: Representa la información relevante de un cliente.
- Cuenta: Representa la información necesaria para
gestionar las cuentas bancarias.
6.2.6. COMPARACIÓN DEL MODELO DE CASOS DE USO Y

MODELO DE ANÁLISIS
Modelo de Casos de Uso Modelo de Análisis

Descrito en lenguaje del cliente. Descrito en lenguaje de
desarrollador.
Puede contener redundancia, No debería contener redundancia
inconsistencias entre requisitos. ni inconsistencia.
Define casos de uso que se Define realizaciones de caso de
analizaran con mas detalle en el uso.
modelo de análisis.
Captura la funcionalidad del Esboza como llevar a cabo la
sistema significativa para la funcionalidad dentro del sistema.
arquitectura. Sirve como primera aproximación
al diseño.
Vista externa del sistema. Estructurado por clases y
Estructurado por casos de uso. paquetes usado
Utilizado fundamentalmente como fundamentalmente por los
contrato entre cliente y desarrolladores, para comprender
desarrolladores. como debería darse forma al
sistema.

6.3. DISEÑO DEL SISTEMA
El diseño de sistemas se define como el proceso de aplicar ciertas
técnicas y principios con el propósito general de definir la arquitectura
de hardware y software, componentes, módulos y datos del sistema
para satisfacer ciertos requerimientos.
La Disciplina de Diseño tiene como propósito:

 Adquirir una comprensión de los aspectos relacionados con los
requisitos no funcionales y restricciones relacionadas con los
lenguajes de programación, componentes reutilizables, sistemas
operativos, tecnologías de distribución y concurrencia y tecnologías
de interfaz de usuario.
 Crear una entrada apropiada y un punto de partida para actividades
de implementación, entrando en detalles estructurales (clases,
atributos y relaciones entre clases) y de comportamiento
(operaciones, estados y actividades).
6.3.1. ARTEFACTOS
 Modelo de Diseño
El artefacto Modelo de Diseño está compuesto por:
 Realización de casos de uso

Describe cómo un caso de uso se lleva a cabo en términos
de clases de diseño y sus objetos. Hay una
correspondencia directa entre la Realización de un Caso de
Uso de Diseño y la Realización de un Caso de Uso de
Análisis.

 Diagramas de clases del diseño y diagramas de interacción
(colaboración y/o secuencia) del diseño.
a. Diagrama de Clases del Diseño: que contiene las clases
que participan en el caso de uso, aunque algunas de
ellas puedan participar en varios.
b. Diagrama de Secuencia: que muestra una secuencia
detallada de interacción entre los objetos de diseño. En
algunos casos es posible incluir Subsistemas dentro de
los diagramas. Los diagramas de secuencia visualizan el
intercambio de mensajes entre objetos.
 Modelo de despliegue
Describe la distribución física del sistema en términos de
cómo las funcionalidades se distribuyen entre los nodos de
computación sobre los que se va a instalar el sistema.
- Cada nodo representa un recurso de computación.
- Los nodos tiene relaciones entre ellos que representan
los medios de comunicación que hay entre ellos como
una Intranet o Internet.
- La funcionalidad de un nodo viene representada por los
componentes que se ejecutan en él.
- El modelo de despliegue representa un mapeo claro
entre la arquitectura software y hardware.
Modelo Físico = Modelo de Diseño + Modelo de
Despliegue
 Modelo de Datos
El diseñador de la base de datos es el responsable de la
elaboración de tablas, diccionario de datos, puntos de vista,
restricciones (modelo del negocio), disparadores,
procedimientos almacenados, tablas o parámetros de
almacenamiento, y de la construcción necesaria de otras
bases de datos para almacenar, recuperar y eliminar la
persistencia de objetos. Sin olvidar la administración de
usuarios junto con ello sus privilegios además de cálculo de
la base de datos.

6.3.2. ACTIVIDADES DEL DISEÑO RUP
A. Diseño de realización de CU del sistema
B. Diseño del Diagrama de clases.

Para cada realización de caso de uso del diseño del sistema
se debe:
 Identificar las responsabilidades de las clases de diseño
(papeles en los casos de uso)
 Identificar:
- operaciones
- atributos
- relaciones en las que participa

C. Diseño del Diagrama de Secuencia
D. Diseño de la Arquitectura
Las configuraciones de red suelen tener una gran influencia
sobre la arquitectura del software, incluyendo las clases
activas que se necesitan y la distribución de la funcionalidad
entre los nodos de red:
Las configuraciones de red habituales utilizan un patrón de
tres capas:
- Capa de los clientes (interacción con el usuario)
- Capa de lógica de negocio o de aplicación
- Capa de funcionalidad de base de datos (acceso a datos)

E. Diseño de la Base de Datos
La Base de Datos es el sistema para el almacenaje de datos y
el acceso controlado a los datos almacenados. Ésto es el
elemento más grande que una base de datos soporta. La
base de datos relacional es un estándar soportado por el Data
Modeling UML Profile.
6.4. DOCUMENTACIÓN DEL ANÁLISIS Y DISEÑO DEL

SISTEMA CON RUP Y UML
CAPITULO IV
ANÁLISIS Y DISEÑO DEL SISTEMA
4.1. ANÁLISIS DEL SISTEMA
4.1.1. MODELO DE ANÁLISIS
4.1.2. REALIZACIÓN DE CASOS DE USOS DEL ANÁLISIS
- Diagrama de clases del CU Nº 01
- Diagrama de colaboración CU Nº 01
- Diagrama de colaboración CU Nº 02
…..
4.1.3. DIAGRAMA DE CLASES DE ANÁLISIS DE CONTEXTO
4.1.4. ANÁLISIS DE CLASES
4.1.5. DESCRIPCIÓN DE LA ARQUITECTURA
4.2. DISEÑO DEL SISTEMA
4.2.1. REALIZACIÓN DE CASOS DE USOS DEL DISEÑO

- Diagrama de secuencia CU Nº 01
- Diagrama de secuanica CU Nº 02
…..
4.2.2. DISEÑO DE LA ARQUITECTURA
4.2.3. DISEÑO DE BASE DE DATOS
ACTIVIDAD 6
Realizar el análisis y diseño del sistema en desarrollo y documentarla de
acuerdo a la estructura propuesta.
En esta unidad se especificó y describió cómo se va a implementar el

sistema, es decir, los diseñadores de software determinan la mejor
solución técnica a partir de los requerimientos de la arquitectura del
sistema más adecuada y el diseño detallado necesario previo a las
actividades de implementación
 Bruegge y Dutoit. Ingeniería de Software Orientado a Objetos”.

Editorial Pearson. México 2002.
Enlaces web:
 http://clases3gingsof.wetpaint.com/page/Proceso+de+An%C3%A1lisis+y+Dise
%C3%B1o+de+RUP

ANÁLISIS Y DISEÑO DEL SOFTWARE
CON RUP Y UML
CASO DE ESTUDIO
La Caja Municipal de Empeño es una institución que se dedica a
prestar dinero con garantía de joyas. El cliente se acerca a la ventanilla
con la joya y su documento de identidad, para que sean evaluados por
un tasador quien indica el kilataje y el peso de la joya en gramos,
registrándola en el volante de tasación. Con estos datos el sistema
calcula el importe a ser prestado.
Si el cliente es nuevo se procede a ingresar sus datos, en caso de
estar registrado solo se verifican los datos. Luego se llena el contrato
con los datos del cliente, la descripción de la joyas y el valor del
préstamo, para finalmente firmarlos. Con este documento se dirige a
ventanilla para recibir el monto prestado. Si el cliente no puede
cancelar el importe de la cuota, podrá amortizar pagando como mínimo
el interés correspondiente a ese periodo. Si amortiza la deuda después
de vencido el plazo deberá pagar el interés del préstamo mas un
adicional por concepto de sanción, Si el cliente deja de pagar por un
periodo correspondiente a 2 cuotas sucesivas, entonces las joyas
entran a remate. En caso que el cliente desee amortizar la deuda una
vez fijada la fecha de remate, deberá cancelar los intereses más la
comisión por remate. Al terminar de cancelar toda la deuda las joyas
regresan al poder de su dueño y el contrato queda concluido.
El sistema debe emitir el reporte de los contratos vencidos y cuyas
garantías correspondientes serán rematadas.
Se pide:
- Realizar el análisis y diseño del sistema de préstamo de dinero
considerando la estrutura de documentación.

RATIONAL UNIFIED PROCESS (RUP): CASO

PRÁCTICO
En la presente unidad se pretende mostrar un ejemplo de desarrollo

de software basado en la metodología de desarrollo Rational Unified Process
(RUP). El proyecto trata del desarrollo de un sistema de gestión clínica para
un hospital. El ejemplo esta centrado principalmente en el modelado del
negocio, obtención de requerimientos y el modelo de análisis y diseño por
considerarse la parte substancial del RUP sin desmerecer de ningún modo
las otras actividades concernientes a dicho proceso. Hacia el final de la
unidad se dará una breve guía de cómo continuar con el proceso hasta
llegar a la implementación del sistema y su posterior despliegue.

 Conoce y utiliza RUP
 Conoce los artefactos que se obtendrán como resultado del proceso
 Entiende la diferencia entre el modelo del negocio y la obtención de
requerimientos
 Entiende la diferencia entre el modelo de análisis y diseño del proceso
 Aplica RUP a un caso practico
Modelamiento de un Sistema de Gestión Clínica

Utilizando El Proceso Unificado
7.1. DISCIPLINAS Y ARTEFACTOS: MODELO DEL NEGOCIO

 Evaluar el estado  Evaluación del
del negocio estado de la  Diagrama de Casos
 Describir el negocio Organización
Modelo del Negocio
de Uso del Negocio
actual  Plan de Desarrollo de
 Identificar los Software  Modelo de Objetos del
procesos del  Reglas del Negocio Negocio
negocio  Especificaciones de
 Refinando las casos de uso del
definiciones del Negocio
proceso del  Arquitectura del
negocio· Negocio
Modelado del
Negocio  Diseñar las  Visión del Negocio Modelo del Dominio
realizaciones de los del problema
procesos del
negocio Modelo del dominio
 Refinando roles y
responsabilidades
 Explotando
procesos de
automatización
 Desarrollo de un
modelo del Dominio
Tabla 7-1: Disciplinas y artefactos del modelo del negocio

Artefactos que se obtendrán en el ejemplo:
Al término del modelo del negocio se debe lograr:
 El diagrama de de Casos de Uso del Negocio (Business Use Case
diagrams).
 Uno o más diagramas de actividad para cada caso de uso del
negocio.
 Un Diagrama de Objetos del Negocio.
 Un diagrama de clases para todo el modelo del negocio. Este
diagrama es también llamado modelo del dominio.
Modelado del Negocio para el Sistema de Gestión Clínica
a) Construir 4 Paquetes:
Se recomienda que los dos primeros siempre se creen, mientras que
los dos últimos solo se crean con fines de tener organizado nuestro
modelo:
 Unidades Organizacionales.-
Contendrá los trabajadores del
negocio (bussiness worker) y
otras unidades
organizacionales según la
jerarquía establecida por el
negocio (organigrama de la
empresa).
 Casos de Uso del Negocio.-
Contendrá los casos de uso
del negocio (bussiness use
case - procesos que permiten
cumplir los objetivos del
negocio) así como los
trabajadores del negocio
(bussiness worker) y los
actores del negocio (bussines
actor).
 Actores del Negocio.- Permite
agrupar en un solo sitio todos
los actores que participan en Figura 7.1: Vista de casos de uso
los casos de uso del negocio.
 Trabajadores del Negocio.- Permite agrupar a los empleados de
la organización.
b) Identificar las unidades organizacionales

Nuestro software de gestión clínico de ejemplo va a correr en un área
específica de la empresa, pero necesitamos establecer el contexto
más general para luego detallar solo lo que nos interesa. Así, nuestro
negocio es una empresa que está dividida en áreas tales como:
Producción, Finanzas, Recursos Humanos, Ventas, Contabilidad y
Logística. Estas áreas las podemos obtener directamente desde el

UNIDADES ORGANIZACIONALES
organigrama de la empresa. Usando la notación UML estereotipada
para el modelo del negocio tendremos:
Atención Clinica
Farm acia Laboratorio Caja Contabilidad

Figura 7.2: Unidades organizacionales
Se irá detallando cada unidad organizacional. Para la unidad

organizacional de nuestro interés (atención clínica) tenemos:
Medico_ Enfermera
(from Business Use-Case Model) (from Business Use-Case Model)
Hospitalización
Admision
(from Unidades Organizacionales)
(from Unidades Organizacionales)
Figura 7.3: Actores del negocio con sus respectivas

unidades organizacionales
Para que el modelo de la organización este completo será necesario

que describamos las funciones principales de cada área así como las
funciones de cada business worker.
c) Identificar los Casos de Uso del Negocio

El diagrama de casos de uso del negocio debe representar los
principales objetivos de la organización, y en nuestro caso particular
los objetivos del área. Veamos, según la descripción que
encontramos al construir nuestro modelo organizacional, tenemos que
Atención Clínica tiene como objetivos fundamentales: La admisión de
pacientes, atención de pacientes, hospitalización, servicios de análisis
clínicos y la atención en farmacia. Por lo que nuestro Diagrama de
Casos de uso será:

Diagrama de Casos de Uso del
Negocio
Admisión de Pacientes
Recepcionista (from Business Use-Case Mod...
Atención de Pacientes
(from Business Use-Case Mod...
Medico_
Paciente_
Hospitalización (from Business Use-Case Model)
Enfermera
Servicios de Analisis
Clínicos
Laboratorista_
Atención Farmacia
Farmaceutico_
Figura 7.4: Diagrama de casos de uso del negocio
Los trabajadores del negocio ya han sido identificados cuando

investigamos las unidades organizaciones, mientras que los actores
del negocio se identifican conforme vamos desarrollando los casos de
uso del negocio. Debemos indicar que algunos autores consideran
que solo debemos mostrar los actores externos pues se dan límites al
sistema y los workers son “actores internos” y están dentro de la
organización.
d) Se crean los paquetes del modelo de objetos del negocio

Para esto hay que ubicarse en la Vista lógica y encontrar el paquete
Business Object Model, dentro del cual se crean 3 paquetes:
 Diagrama de Objetos del Negocio: Que contendrá el diagrama de
objetos.
 Diagrama del Dominio: El cual contiene las principales entidades
que se encontraron en el negocio.
 Realización de los Casos de Uso del Negocio: Aquí detallamos los
casos de uso del negocio mediante un diagrama de actividad (u
otro).

Figura 7.5: Vista lógica del negocio
e) Se construye la realización de los casos de uso del negocio

Los casos de uso del negocio se pueden especificar de diversas
formas, como son: pseudocódigo, lenguaje natural, diagramas de
actividades, diagramas de secuencia, diagramas de colaboración,
diagramas de estado, etc. Sin embargo nosotros utilizaremos los
diagramas de actividad pues son los más indicados para representar
procesos (actividades) mostrando las áreas, personas y objetos en
general (carriles) que llevan a cabo procesos secuenciales o en
paralelo (barra de sincronización) y objetos fluyen entre procesos
(flujo de objetos), así también representan decisiones de bifurcación.
Cada uno de los casos de uso tendrá uno o más diagramas de
actividades (o de cualquier otro tipo, según los necesitemos en un
caso específico).
El paquete realización de los casos de uso del negocio contendrá lo
siguiente:
Admisión de Pacientes Realización de Adm is ion de

Pacientes
(from Business Use-Case Model)
Atención de Pacientes Realización de Atención de Pacientes

Hos pitalización Realización de Hospitalización

Figura 7.6: Realizaciones de los casos de uso

f) Para cada realización de los casos de uso del negocio construimos un
diagrama de actividad y un diagrama de clases.
El diagrama de actividad nos va ha permitir especificar como se lleva
a cabo el caso de uso del negocio y si en ese diagrama incluimos el
flujo de objetos, estaremos identificando los objetos participantes, a
partir de lo cual podremos derivar un pequeño diagrama de objetos
para cada realización.
Realización del Caso de Admisión Paciente

Cliente o Paciente Recepcionista
Es Paciente No
Solicita Nuevo
Atención
Registra Ficha Evalua Estado

de Admision de Paciente
Si
Es Emergencia?
Asigna
Consultorio
: Ficha_Admisión/Neg
Registra Orden de
Es grave Hospitalización
: Cita/Neg
Emite Cita de
Atención
: Orden_Hospitalización/Neg
Recibe su Cita o Orden de
Hospitalización
Figura 7.7: Diagrama de Actividad: Admisión Paciente

Diagrama de Objetos participantes: Admisión Pacientes
Recepcionista
Orden_Hospitalización/Neg Cita/Neg
Ficha_Admisión/Neg (from Modelo de Objetos del Negocio) (from Modelo de Objetos del Negocio)
1 1..n
(from Modelo de Objetos del Negocio) 1..n
11
1
Paciente/Neg
(from Modelo de Objetos del Negocio)
Figura 7.8: Diagrama de Objetos: Admisión Paciente
Para efectos de ejemplo en el presente libro solo se mostrará la

realización de casos de uso de Admisión de Pacientes. El lector debe
entender que las realizaciones se hacen por cada caso de uso del
negocio.
g) Se unen los diagramas de objetos de cada caso de uso y así se

obtiene el diagrama de Objetos del Negocio
Como ya tenemos identificados los objetos participantes en cada caso
de uso, podemos unirlos en un único diagrama y debemos refinar este
modelo completando detalles como multiplicidad y otros, asimismo
nos daremos cuenta si hay objetos redundantes.

Modelo de Objetos del
Negocio
Recepcionista
Medico_

Orden_Hospitalización/N
1..n
eg
1..n
1..n 1
Cama/Neg
Ficha_Admisión/Neg
1
1
1..n
Cita/Neg
1..n
Sala/Neg
1..n
Diagnostico/Neg
1
1 1
1..n
1 1
Cirugías
1
Consultorio/Neg Paciente/Neg
Figura 7.9: Modelo de Objetos del Negocio
h) De ser necesario se construye el Modelo del Dominio

En realidad solo es necesario construir uno de los dos modelos: el
modelo del dominio o el modelo de objetos. El modelo del dominio se
construye cuando se desea efectuar un Modelamiento del Negocio
muy breve y solo identifica las clases más importantes en la
organización para brindar un panorama de la misma. Sin embargo,
cuando se desarrolla un Modelo del Negocio más amplio, se
construye un diagrama de objetos del Negocio. A pesar de haber
desarrollado un Modelo del Negocio amplio, se incluye aquí un
Modelo del Dominio como ilustración y para que el modelo resulte
completo.

Modelo Modelo del Dominio del Sistema
del Dominio
Diagnostico/Neg
1..n
1
Cita/Neg Paciente/Neg 1
1..n 1
1 1 1
1..n
Ficha_Admisión/Neg
1..n
1..n
Orden_Hospitalización/Neg 1..n
Cirugías
1..n
1 1
Consultorio/Neg Sala/Neg
1
Cama/Neg
Figura 7.10: Modelo del dominio
7.2. DISCIPLINAS Y ARTEFACTOS: MODELADO DE REQUERIMIENTOS

 Analizar el  Especificación
problema de Casos de
 Conocer las Uso.
necesidades de  Visión.
los stakeholders  Plan de
 Definir el Administración
Requerimiento sistema de Modelo de  Diagrama de
 Administrar el requerimientos requerimiento Casos de Uso
Alcance del
Sistema
 Administrar los
cambios de
Requerimiento.
Tabla 7-2: Disciplinas y artefactos del modelo de requerimientos

Prototipo
Casos de
Uso
Inicial
Requerimientos
Actores Especificación
Caso de Uso
Encontrar
Actores y Detallar
Casos de Uso Casos de Uso
Analist
a
Construir
Modelo de
Casos de Uso
Modelo de Casos de
Uso
Figura 7.10: Proceso de captura de requerimientos
Requerimientos para el Sistema de Gestión Clínica
a) Ir a la Vista de Casos de Uso dentro del Modelo de Casos de Uso y

crear los paquetes
 Actores: Servirá para agrupar todos los actores del modelo de
casos de uso
 Casos de Uso: Servirá para agrupar todos los casos de uso
 Casos de Uso Arquitecturalmente significativos: Es un subconjunto
de casos de uso que influyen fuertemente en la arquitectura.
En la parte derecha del diagrama siguiente, se observa como el
Modelo de Casos de Uso es dependiente del modelo de casos de uso
del negocio, ya que algunos de sus elementos se derivan de este, y
los casos de uso del software deben soportar a los casos de uso del
negocio.
Figura 7.11: Vista de casos de uso. Dependencia entre el

Business use-case model y el use-case model

b) Ir al paquete de Casos de Uso e identificar como organizar los casos
de uso.
En este paso se comienza identificando los casos de uso, sus actores
y relaciones entre ellos. Luego se procede a agruparlos según algún

criterio. Por ejemplo si el sistema involucra varias áreas se debería
crear un paquete para cada área. Si se desea agrupar según alguna
funcionalidad se debe crear un paquete para cada una, o si es un
sistema pequeño no se necesita ningún agrupamiento. En éste caso
se ha optado por agruparlos en los paquetes: Admisión de Pacientes,
Atención de Pacientes, Hospitalización, Atención Farmacia y Servicio
de Análisis Clínico. En la mayoría de casos se empieza sin ningún
paquete y conforme se avance se va agrupando según el criterio del
analista.
Admisión de Atencion de
Pacientes Pacientes
Atenc. Farmacia Hospitalizacion de

Pacientes
Serv icio de
Analisis Clinico
Figura 7.12: Paquetes de casos de uso

c) Construir diagramas de Casos de Uso para cada paquete de Casos
de Uso
Modelo de Casos de Uso de
Admisión de Pacientes
Registrando Serv icio

Registrando Paciente
<<extend>> <<extend>>
Registrando Citas de Atención <<include>>
Recepcionista
(f rom Use-Case Model)

Asignando Consultorio
<<extend>>
Registrando Medico
Administrador
(f rom Use-Case Model)
Figura 7.13: Casos de uso de Admisión pacientes
En la pestaña general de cada caso de uso se puede escribir su

especificación según el formato mostrado. Si la especificación es larga se
puede enlazar un archivo en word que contenga la especificación (Anexo
1).
También puede realizarse una descripción de otros elementos como los
actores.
Figura 7.14: Especificación de casos de uso

d) Ir al paquete de Actores y arrastrar los actores identificados
Todos los actores identificados en los casos de uso deben ser
arrastramos hacia el paquete de actores con el fin de tener una vista
completa de todos los actores, entonces se puede añadir algunas
relaciones de generalización.
e) Identificar los casos de uso arquitecturalmente significativos

A partir de los casos de uso identificados se busca a aquellos que
son más relevantes en el sistema y que influyen en su arquitectura.
f) Construcción de Prototipo
7.3. DISCIPLINAS Y ARTEFACTOS: MODELADO DE ANÁLISIS Y

DISEÑO

 Definir una  Flujo de Eventos  Diagrama de
arquitectura  Especificaciones  Modelo de Colaboración
candidata suplementarias Análisis ·
 Analizar la  Arquitectura del  Diagrama de
Análisis Y Diseño conducta del Software  Modelo del secuencia
Sistema Diseño
 Diseñar  Diagrama de
Componentes Clases
 Refinar la
arquitectura  Diagrama de
 Diseñar la Base de Despliegue
Datos.
Tabla 7-3: Disciplinas y artefactos de análisis y diseño
Prototipo
Avanzado
Modelo de Análisis (opcional)

Modelo de Casos de Uso
Análisis
y Diseño
Modelo de Diseño
Especificación
Suplementaria
Documento de Modelo de Datos

Arquitectura
Figura 7.15: Proceso de análisis y diseño

Estereotipos Principales
Interfaz (GUI) Entidad Control
Modelo de Análisis del Sistema de Gestión Clínica
a) Ir a la Vista Lógica y en el Modelo de Análisis crear los paquetes:

 Paquete Diagrama de Clases del Análisis
 Paquete Realización de los Casos de Uso
Figura 7.16: Paquetes del Modelo de Análisis
b) Ir al Paquete de Realización de Casos de Uso y crear los

paquetes correspondientes.
Para cada paquete del modelo de casos de uso se le crea su
paquete de realizaciones donde justamente se mostrará como
cada caso de uso se enlaza con su realización (la cual esta
especificada mediante un diagrama)

c) Mostrar cada Realización de Casos de Uso
Para mostrar la realización de cada caso de uso utilizamos los
símbolos del UML dependencia y Colaboración, así cada caso de
uso estará enlazado a su correspondiente realización
(colaboración) y dentro de este símbolo construiremos el diagrama
respectivo.
Figura 7.17: Paquetes de las realizaciones de casos de uso
Debe elaborarse realizaciones para cada paquete. Para el ejemplo

solo se mostrara la realización de uno de los paquetes.
Realización del Paquete de Admisión de Pacientes
Registrando Servicio Registrando Medico Registrando Paciente

Registrando Citas de Atención Asignando Consultorio
(from Admisión de Pacientes)
(from Admisión de Pacientes) (from Admisión de Pacientes)
(from Admisión de Pacientes) (from Admisión de Pacientes)
Realizacion de Citas de Atención Realizacion de Asignación Realizacion de Registrando Servicio Realizacion de Registrando Medico Realizacion de Registrando Paciente
Consultorio
Figura 7.18: Realización de casos de uso para Admisión pacientes
A continuación debe elaborarse un diagrama de colaboración por cada

realización de caso de uso. Nuevamente, solo se muestra un diagrama
de colaboración para una sola realización de caso de uso.

Diagrama de Colaboración de Citas de Atención
Elaborar Cita de Atención 9: Nuevo, Grabar, Modificar, Anular
: Verificar Cita_atencion : Ficha_Cita_Atencion

8: Verificar Datos
5: Leer
4: Obtener Servicio
1: Elaborando Cita de Atencion
6: Obtener Consultorio : Servicios

: Buscando Servicio
: Recepcionista : Interfaz de Cita de Atención
7: Leer
2: Obtener Consultorio
: Buscando Consultorio : Consultorio
3: leer
: Buscando Paciente : Paciente
Figura 7.19: Diagrama de colaboración para la realización: Elaborar citas de

Atención
Con cada entidad generada en el diagrama de colaboración se

crea el diagrama de clases para cada realización

Diagrama de Clases de Citas de Atención
1
Servicios
1
1..n
1..n Consultorio
1..n
1
Ficha_Cita_Atencion
1..n
1
Paciente
Figura 7.20: Diagrama de clases de citas de atencion
d) Ir al Paquete de Clases del Análisis y Crear otros paquetes

Según el criterio adoptado podemos crear paquetes agrupando
alguna posible funcionalidad, área, o capas. Para el ejemplo se
crean tres paquetes: interfaz, control y entidad.
Figura 7.21: Diagrama de paquetes del análisis
e) Arrastrar cada clase del Análisis a su respectivo paquete

Diseño del Sistema de Gestión Clínica
a) Ir a la Vista Lógica y dentro de ella a la vista de diseño y crear los

paquetes siguientes:
 Paquete de diseño
 Realización de casos de uso diseño.
Figura 7.22: Diagrama de paquetes del modelo del diseño
b) Construir la realización de los casos de uso diseño

A partir de los paquetes de la realización de los casos de uso del
análisis construimos los correspondientes paquetes de realización
de casos de uso de diseño.
RD-Admis ion de RD-Atencion

Pacientes Paciente
RD -Hos pitalización RD -Servicio de

Paciente Analis is Clinico
RD -Atencion
Farm acia
Cada uno de estos paquetes contiene los casos de uso de

requerimientos enlazados con sus correspondientes realizaciones
del análisis los que a su vez se enlazan con sus realizaciones del
diseño.

Realización de casos de uso de Admisión de Pacientes
12: Destruir( )
Admisión de Pacientes 11: Guardar( )
10: Crear( )
9: Actualizar Datos( )
: Ficha_Cita_Atencion
: Verificar Cita_atencion
2: Seleccionar Ficha( )
8: leer( )
7: Seleccionar Servicio( )
1: Elaborando Cita del Paciente
: Buscando Servicio : Servicios
5: Seleccionar Consultorio( )
: Recepcionista : Interfaz Atención Paciente
6: Leer( )
3: Seleccionar Paciente( )
: Buscando Consultorio : Consultorio
4: Leer
: Buscando Paciente : Paciente
Figura 7.23: Diagrama de colaboración para la realización de Citas de Atención
: Recepcionis ta : Interfaz Atención Paciente : Bus cando Servicio : Bus cando Paciente: Bus cando Consultorio : Servicios : Paciente : Cons ultorio : Ficha_Cita_Atencion : Verificar Cita_atencion
Elaborando Cita del Paciente
Seleccionar Ficha( )
Seleccionar Paciente( )
Leer
Seleccionar Consultorio( )
Leer( )
Seleccionar Servicio( )
leer( )
Actualizar Datos ( )
Crear( )
Guardar( )
Des truir( )
Figura 7.24: Diagrama de secuencia para la realización de Citas de Atención

Figura 7.24: Diagrama de clases para la realización de Citas de Atención
Debemos hacer una realización del diseño por cada una de las
realizaciones del análisis. Cada realización del diseño se realiza
mediante un diagrama de secuencia (o colaboración) pero indicando
mayor detalle que en el análisis. Luego identificamos los objetos que
participan y obtendremos nuestro diagrama de Clases del Diseño.
c) Construir paquetes del diseño que agruparan a las Clases del Diseño
Como la arquitectura escogida es de tres capas el diseño reflejará
eso.
Figura 7.25: Diagrama de paquetes del diseño

•Componentes
CAPA DE PRESENTACION
CAPA DE NEGOCIO •Reglas del
negocio
Interfas es Logica de l Negoci o
Sis tema del Sistema
Comunicación entre
el usuario y el sistema
CAPA DE DATOS Base de
datos
Datos del
Sistema
d) Arrastrar las Clases del Diseño a sus respectivos paquetes.
e) El Modelo de Datos
Mapeo de la Base de Datos

- Mapeo de Clases a Tablas
- Mapeo de atributos a columnas
- Mapeo de la Herencia en una base de datos relacional
- Mapeo de relaciones de Uno a uno, uno a muchos, muchos a
muchos
- Mapeo de agregaciones y composiciones
- Mapeo de Clase asociación
También podemos realizar el mapeo de varias clases a una

única tabla
Figura 7.26: Diagrama de clases

Modelo físico de la Base de Datos (Hacia el modelo relacional)
 Crear el Componente de Base de Datos
- Vista de Componentes:
- Data Modeler / New/ Database
 Verificar que los Datos sean Persistentes
 En el Paquete de Datos
- Data Modeler/ Transform to Data Model
- Seleccionar el Nombre de la BD y el Schema creado
 En el Schema
- Crear data Model Diagram
- Data Modeler /New/ Datamodel Diagram
Data Model
Object Model
SQL Analizer
DDL (script SQL)

Base de Datos
Figura 7.27: Generación del modelo de datos

IMPLEMENTACIÓN
 Estructurar el
modelo de
implementació
n
 Plan de  Modelo de
Implementación integración Implementació
 Implementació n  Diagrama de
n de Componentes
Componentes  Prototipo del
 Integrar cada Sistema
subsistema
 Integrar el
Sistema
Tabla 7-4: Disciplinas y artefactos del modelo de implementación

Vista de Componentes
Nodo de la Aplicación
Nodo
Presentación
Apli cacion.exe
C lie n te
Bd.dll Aplicacion.dll
C li e nt e .d l l
Nodo de la Base de
datos
Bd.bd
La capa de lógica del negocio: Generación de Código

- Verificar el Modelo
- Crear un componente
- Asignar Clases a Componente
- Generar código
7.5. DISCIPLINAS Y ARTEFACTOS: DESPLIEGUE

 Planificar el Despliegue  Flujo de Eventos  Manual de
 Desarrollar el Material de  Especificaciones Instalación
Soporte suplementarias
 Administrar la aceptación  Arquitectura del  Manual de
de las pruebas Software Usuario
 Producir las unidades de
Desarrollo
 Paquete del producto
Despliegue  Proveer accesos a sitios
descargables
 Evaluar los productos
beta.
Tabla 7-4: Disciplinas y artefactos del modelo de implementación

Vista de despliegue
Sistema Cliente Servidor

en tres Capas Servidor de
datos
Servidor de
Hub
Aplicaciones
Base de
Datos
PC- Cliente
Figura 7.27: Prototipo del sistema

El ejemplo anterior se ha desarrollado con la ayuda de Rational Rose 1.
La elección del lenguaje de programación es libre.
1. Investigue acerca del modelado para aplicaciones web con RUP y

elabore un informe resaltando las actividades necesarias para tal fin
2. Desarrollar un sistema para una empresa del medio donde pueda llevar
a cabo todo el proceso de desarrollo de software con RUP
El Proceso Unificado de Rational (Rational Unified Process en inglés,

habitualmente resumido como RUP) es un proceso de desarrollo de
software y junto con el Lenguaje Unificado de Modelado UML, constituye
la metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos. RUP es en realidad un
refinamiento realizado por Rational Software del más genérico Proceso
Unificado.
[1] JACABOSON, I., BOOCH, G., RUMBAUGH J., El Proceso Unificado de

Desarrollo de Software, Ed. Addison Wesley 2000.
Bibliografía electrónica:
Ejemplo de desarrollo software con RUP:
http://www.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/
Desarrollo basado en RUP con Rational Rose:
http://lml.ls.fi.upm.es/mdp/si/
Tutorial RUP : requisitos, análisis, diseño
http://www.dsi.uclm.es/asignaturas/42541/Practicas/Requisitos.pdf
http://www.dsi.uclm.es/asignaturas/42541/Practicas/Analisis.pdf
http://www.dsi.uclm.es/asignaturas/42541/Practicas/Disenyo.pdf
En la siguiente unidad temática trataremos aspectos relacionados a la

gestión de proyectos de software
1 IBM Rational Rose Enterprise es uno de los productos más completos de la familia Rational Rose.
Todos los productos de Rational Rose dan soporte a Unified Modeling Language (UML),

INGENIERIA DEL SOFTWARE
NOMBRE:___________________________________________________________
APELLIDOS:__________________________________FECHA; ____/_____/______
CIUDAD:_______________________________SEMESTRE:___________________
CASO DE ESTUDIO: Hotel

El dueño de un hotel le pide a usted desarrollar un programa para
consultar sobre las habitaciones disponibles, reservar habitaciones de su
hotel y ofrecer otros servicios asociados.
El hotel posee tres tipos de habitaciones: simple, doble y matrimonial, y
los tipos de clientes pueden ser nacionales o extranjeros. Una reservación
almacena datos del cliente, de la habitación reservada, la fecha de inicio
de hospedaje y el número de días que será ocupada la habitación.
El recepcionista del hotel debe poder hacer las siguientes operaciones:

o Obtener un listado de las habitaciones disponibles de acuerdo a su
tipo.
o Preguntar por el precio de una habitación de acuerdo a su tipo
o Preguntar por el descuento ofrecido a los clientes habituales (es
necesario saber quienes son los clientes habituales y quienes los
esporádicos)
o Obtener listados de otros servicios que ofrece el hotel (lavandería,
cochera, restaurant) y sus respectivos precios
o Preguntar por el precio total del servicio para un cliente dado
o Dibujar en pantalla la foto de un habitación de acuerdo a su tipo
o Reservar una habitación
o Eliminar una reserva
El administrador puede usar el programa para:
o Cambiar el precio de una habitación de acuerdo a su tipo
o Cambiar el precio de otros servicios ofrecidos por el hotel
o Cambiar el valor del descuento ofrecido a los clientes habituales
o Calcular las ganancias que tendrán en un mes especificado
El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de
habitación o clientes y a su vez permitir agregar nuevos servicios y
generar nuevas consultas.
PARA EL CASO:
o Elaborar el modelo del negocio
o Obtener la captura de requerimientos
o Elaborar los modelos de análisis y diseño del sistema

PRUEBAS Y MANTENIMIENTO DE SOFTWARE
Las pruebas de software son un conjunto de técnicas que permiten

determinar la calidad de un producto software. Las pruebas de software se
integran dentro de las diferentes fases del Ciclo del software dentro de la
Ingeniería de software. Así se ejecuta un programa y mediante técnicas
experimentales se trata de descubrir que errores tiene.
La calidad de un sistema software es algo subjetivo que depende del
contexto y del objeto que se pretenda conseguir. Para determinar dicho nivel
de calidad se deben efectuar unas medidas o pruebas que permitan
comprobar el grado de cumplimiento respecto de las especificaciones
iniciales del sistema.
En la presente unidad se pretende que el alumno tome conciencia de la
necesidad de la prueba del software y de lo importante que es realizarla
desde el principio. Así mismo, el alumno deberá convencerse de lo
importante que es la actividad de mantenimiento del software.

 Entiende la necesidad de llevar a cabo pruebas de software durante el
ciclo de vida del software
 Elabora pruebas de software utilizando diversos criterios
 Entiende la importancia del mantenimiento de software
8.1. DEFINICIONES
Las siguientes definiciones son algunas de las recogidas en el
diccionario IEEE en relación a las pruebas [IEEE, 1990], que
complementamos con otras más informales:
 Pruebas (test): “una actividad en la cual un sistema o uno de sus
componentes se ejecuta en circunstancias previamente
especificadas, los resultados se observan y registran y se realiza
una evaluación de algún aspecto”. Para Myers [MYERS, 1979],
probar (o la prueba) es el “proceso de ejecutar un programa con el
fin de encontrar errores”. El nombre “prueba”, además de la actividad
de probar, se puede utilizar para designar “un conjunto de casos y
procedimientos de prueba” [IEEE, 1990].
 Caso de prueba (test case): “un conjunto de entradas, condiciones
de ejecución y resultados esperados desarrollados para un objetivo
particular como, por ejemplo, ejercitar un camino concreto de un
programa o verificar el cumplimiento de un determinado requisito”.
También se puede referir a la documentación en la que se describen
las entradas, condiciones y salidas de un caso de prueba.

 Defecto (defect, fault, “bug”): “un defecto en el software como, por
ejemplo, un proceso, una definición de datos o un paso de
procesamiento incorrectos en un programa”.
 Fallo (failure): «La incapacidad de un sistema o de alguno de sus
componentes para realizar las funciones requeridas dentro de los
requisitos de rendimiento especificados».
 Error (error): tiene varias acepciones:
- La diferencia entre un valor calculado, observado o medido y el
valor verdadero, especificado o teóricamente correcto. Por
ejemplo, una diferencia de dos centímetros entre el valor
calculado y el real.
- Una acción humana que conduce a un resultado incorrecto (una
metedura de pata). Por ejemplo, que el operador o el programador
pulse una tecla equivocada.
La relación entre error, fallo y defecto queda más clara en la Figura 8.1.
Figura 8.1. Relación entre error, defecto y fallo.
8.2. ¿QUÉ SON LAS PRUEBAS DE SOFTWARE?

Las pruebas, vistas desde el marco de un proceso de desarrollo de
software, son los diferentes procesos que se deben realizar durante un
desarrollo, con el objetivo de asegurar que este completo, correcto,
tenga calidad, entre otros factores de gran importancia.
Consisten en llevar a cabo la verificación dinámica de un componente,

programa o sistema, mediante el uso de métodos, técnicas y
herramientas especializadas, las cuales permiten detectar y corregir
errores, problemas e inconsistencias durante el proceso de desarrollo.
Estas, al contrario de lo que muchas personas creen, no se deben

dejar para el final de la etapa de construcción del software. Las
pruebas se deben empezar a realizar desde la misma etapa de análisis
de los requerimientos, ya que desde un principio se puede caer en
malas interpretaciones de las "reglas del negocio", lo que finalmente
tendrá como consecuencia incongruencia entre lo que el cliente quiere
y lo que se ha desarrollado.

8.3. ¿POR QUÉ PROBAR EL SOFTWARE A DESARROLLAR?
Debido a que los procesos serios de desarrollo de software, en la
mayoría de los casos tienden a ser caóticos, es necesario involucrar
procesos de aseguramiento de la calidad, para que se puedan cumplir
de manera correcta los requerimientos que el cliente necesita. Por otro
lado, el costo que implica reparar un defecto que es descubierto en
etapas avanzadas del desarrollo de software, tal como la
implementación, es muy alto, hablando en términos del presupuesto del
proyecto, como también en el cronograma. Por tal razón, se
implementan las pruebas de software desde los comienzos del
desarrollo.
8.4. ¿QUÉ SON LAS PRUEBAS DE SOFTWARE?

Las pruebas, vistas desde el marco de un proceso de desarrollo de
software, son los diferentes procesos que se deben realizar durante un
desarrollo, con el objetivo de asegurar que este completo, correcto,
tenga calidad, entre otros factores de gran importancia.
Consisten en llevar a cabo la verificación dinámica de un componente,

programa o sistema, mediante el uso de métodos, técnicas y
herramientas especializadas, las cuales permiten detectar y corregir
errores, problemas e inconsistencias durante el proceso de desarrollo.
Estas, al contrario de lo que muchas personas creen, no se deben

dejar para el final de la etapa de construcción del software. Las
pruebas se deben empezar a realizar desde la misma etapa de análisis
de los requerimientos, ya que desde un principio se puede caer en
malas interpretaciones de las "reglas del negocio", lo que finalmente
tendrá como consecuencia incongruencia entre lo que el cliente quiere
y lo que se ha desarrollado.
8.5. ¿QUÉ VENTAJAS TIENE LA CREACIÓN DE PRUEBAS PARA EL

DESARROLLO DE SOFTWARE?
Principalmente, las ventajas que trae la realización de pruebas, en un
desarrollo de software son las siguientes:
 Reducen la posibilidad de agregar defectos al software. Si hay que
realizar una adición de características requeridas por el cliente y se
ve que ya no funcionan bien algunas de las cosas que

anteriormente servían, se puede inferir la nueva funcionalidad es la
que contiene defectos, por lo que no hay necesidad realizar
modificaciones a los componentes realizados anteriormente.
 Reducen la posibilidad de encontrar defectos en funcionalidades ya
implementadas.
 Las pruebas son buena documentación. Es preferible ver unas
pequeñas líneas de "Código de prueba", que son concisas y
realmente son fáciles de entender, a revisar línea por línea de
código para poder entender que hace determinado componente de
software.
 Reducen el costo del cambio. Ya que evitan que se descubran los

defectos hasta el final del desarrollo de software.
 Permiten realizar reimplementación. Se puede llegar a necesitar
reimplementar determinada funcionalidad en un sistema, debido a
fallos de seguridad, rendimiento, o simplemente por que no reunía
lo que el cliente esperaba de éste, entonces dada tal situación, las
pruebas que a realizar a dicha funcionalidad van a permitir que se
vuelva a desarrollar de manera segura, ya que la prueba encierra el
criterio de aceptación sobre la funcionalidad, permitiendo de esta
forma que se vuelva a desarrollar algo acorde con la
especificación.
 Restringe las características a implementar. Muchas veces los
programadores pierden tiempo en detalles que la especificación no
pedía. Con las pruebas el programador sabe que tiene que
programar dicha funcionalidad y también probarla, por lo que se
restringe a lo que los diseñadores de las pruebas hayan realizado.
 Hacen que el desarrollo sea más rápido. Ya que a medida que se

agregan características al software, las funcionalidades anteriores
pueden fallar, pero si se han hecho las pruebas pertinentes a las
funcionalidades anteriores, se puede descartar inmediatamente
que existan defectos en éstas, por lo que se puede concentrar
tranquilamente en la funcionalidad nueva.

8.6. PROCESO DE PRUEBAS DE RUP
Las actividades comienzan con el plan de pruebas, este documento
contiene información relacionada con los objetivos, tanto generales
como específicos, así como de la estrategia y los recursos que le serán
destinados.
Es necesario definir que se va a probar, como se va a hacer, de tal

forma que vayamos obteniendo resultados que nos permitan refinar el
proyecto. Rational ofrece su enfoque de pruebas usando RUP para
valorar la calidad del software por medio de los siguientes objetivos:
 Encontrar y documentar los defectos en la calidad del software
 Aconsejando acerca de la calidad percibida en el software
 Proveyendo la validación de los supuestos hechos en las
especificaciones de diseño y los requerimientos a través de
demostraciones concretas
 Validando las funciones del producto de software según fueron
diseñadas
 Validando que los requerimientos hayan sido implementados
apropiadamente.
 Validación del diseño.
8.7. ROLES Y ACTIVIDADES PRESENTES EN EL PROCESO DE

PRUEBAS
Figura 8.2. Roles y Actividades del proceso de pruebas

8.8. ETAPAS DEL WORKFLOW DE PRUEBAS
 Planificar las Pruebas: El principal artefacto producido es el Plan de
Pruebas.
 Diseñar las Pruebas: Los principales artefactos producidos son el
Modelo de Pruebas (Test Model), los Casos de Prueba (Test Case),
los Procedimientos de Prueba (Test Procedures) y el documento de
Análisis de Carga de Trabajo (Workload Analysis Document).
 Implementar las Pruebas: Los principales artefactos producidos son
el Script de la Prueba y el Componente de la Prueba.
 Ejecutar las Pruebas en la etapa de Integración de Pruebas: El
principal artefacto producido es el documento Resultado de Pruebas.
 Ejecutar las Pruebas en la etapa de Pruebas del Sistema: El
principal artefacto producido es el documento Resultado de Pruebas.
 Evaluar las Pruebas: Los principales artefactos producidos son el
Sumario de Evaluación de Pruebas (Test Evaluation Summary) y los
Requerimientos de Cambio (Change Request).
8.9. ARTEFACTOS DE PRUEBAS

Los artefactos presentados en la siguiente tabla son productos finales e
intermedios que son realizados y usados durante el Workflow de
Pruebas de un proyecto.
Los artefactos de Pruebas capturan y comunican información de
pruebas y pueden tomar la forma de un documento, un modelo o un
elemento de modelo.

Artefactos Creado / Revisado Revisar Herramientas
Detalles Usadas
Incep Elab Cons Trans
Caso de X Informal - Test Manager
Pruebas Interno
Plan de X X Formal – Manager
Pruebas / Externo o
Procedimientos Prueba
Interna
Resultados de X X Formal Test Manager
las Pruebas Interno
Script de X X X Informal – Robot,
Pruebas Interno Manual Test
8.10. HERRAMIENTAS
 Robots de Pruebas (Rational Robot)
 Herramientas de Pruebas funcionales (Rational TeamTest, Rational
VisualTest).
 Herramientas de Pruebas de desempeño y confiabilidad (Rational
SiteLoad, Rational QualityArchitect).
 Frameworks de pruebas unitarias (JUnit).
 Elabore un plan de pruebas para el proyecto que viene desarrollando

 Elabore un plan de mantenimiento para el proyecto que viene
desarrollando
 Elija un sistema operativo que Ud. conozca e investigue acerca de los
tipos de prueba que deben soportar antes de salir al mercado.
Las pruebas permiten verificar y validar el software cuando ya está en

forma de código ejecutable.
El mantenimiento permite la mejora y optimización del software
desplegado, así como también la corrección de los defectos
[1] PRESSMAN, Roger S. Ingeniería del Software. Un enfoque práctico. Mc

Graw Hill, Ed. Interamericana de España S.A.U, 2006
[3] DE MILLO, R. Software Testing and Evaluation, Benjamin/Cummings Pub.

1987SOMMERVILLE, I., Ingeniería de Software, Ed. Pearson Educación, 2002

INGENIERIA DEL SOFTWARE
NOMBRE:___________________________________________________________
APELLIDOS:___________________________________FECHA; ____/_____/______
CIUDAD:_______________________________SEMESTRE:____________________
1. ¿Cuáles son los niveles de pruebas para software?

___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
2. ¿Cuáles son los tipos de pruebas para software? Explique

___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
3. ¿Qué tipo de pruebas deben realizarse cuando se modifica un módulo de un

programa?
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
____________________________________________________
4. Si al realizar pruebas de caja negra se encuentran errores ¿Qué acciones deben

llevarse a cabo?
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
__________________________________________________
5. Para que la persona encargada de las pruebas pueda elaborar los casos de prueba
usando la caja negra, el analista debe proporcionarle:
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
____________
6. Para que la persona encargada de las pruebas pueda elaborar los casos de prueba
usando la caja blanca, el analista debe proporcionarle:
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
____________

Libro Ingenieria SW Ok

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro Ingenieria SW Ok

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PERUANA LOS ANDES

INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

Copyright 2011 UNIVERSIDAD PERUANA LOS ANDES

Dirección de Educación a Distancia

Impresión Digital a cargo de

Jr. Arequipa Nº 377 - Huancayo

Ing. Wagner E. Vicente Ramos 2

En la actualidad esta industria del software se ha convertido en un

El presente texto trata de cubrir los aspectos más importantes de la

Ing. Wagner E. Vicente Ramos 3

Ing. Wagner E. Vicente Ramos 4

Ing. Wagner E. Vicente Ramos 5

Ing. Wagner E. Vicente Ramos 6

INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE

La ingeniería de software es, por definición, un tipo de ingeniería y

Al finalizar el estudio de la presente unidad temática el estudiante:

1.1. ¿QUÉ ES INGENIERÍA DE SOFTWARE?

Ing. Wagner E. Vicente Ramos 7

Principios Métodos Técnicas

Ing. Wagner E. Vicente Ramos 8

Primera Generación Segunda Generación Tercera Generación Cuarta Generación

1950 1960 1970 1980 1990 2011

Primera generación del Software Segunda generación del Software

Tercera generación del Software Cuarta generación del Software

Ing. Wagner E. Vicente Ramos 9

Ing. Wagner E. Vicente Ramos 10

1.4. MITOS DEL SOFTWARE

Ing. Wagner E. Vicente Ramos 11

1.4.2. Mitos del cliente

1.4.3. Mitos del desarrollador

Ing. Wagner E. Vicente Ramos 12

Este sector en los últimos años ha mostrado un importante dinamismo

Ing. Wagner E. Vicente Ramos 13

Actualmente, las soluciones peruanas están en 17 mercados de

Esta salida al mercado internacional se ha logrado justamente por la

Ing. Wagner E. Vicente Ramos 14

Ing. Wagner E. Vicente Ramos 15

1. Explique los Tipos de licencia de software

En este capitulo se explica de una manera sencilla los conceptos

 Braude, Eric J.. Ingeniería de Software: una perspectiva orientada a

Ing. Wagner E. Vicente Ramos 17

1. Explique la diferencia entre ingeniería de sistemas e ingeniería del

2. Explique la diferencia entre programación e ingeniería de software.

3. Investigue y explique sobre la crisis del software y sus consecuencias.

4. Describir algunos ejemplos (positivos y negativos) que indiquen el

5. A medida que la presencia del software se vuelve más generalizado, los

6. Mediante un organizador clasifique los organismos nacionales e

7. Utilizando un organizador gráfico explique la composición de la industria

Ing. Wagner E. Vicente Ramos 18

PROCESO DEL DESARROLLO DEL SOFTWARE

Un sistema informático está compuesto por hardware y software. En

Al finalizar el estudio de la presente unidad temática el estudiante:

2.1. CAPAS DE LA INGENIERÍA DEL SOFTWARE

La ingeniería del software es una tecnología estratificada. Como se

Ing. Wagner E. Vicente Ramos 19

Dichas capas se describen a continuación:

2.2. MARCO DE TRABAJO PARA EL PROCESO

El proceso de desarrollo de software no es único. No existe un proceso

Ing. Wagner E. Vicente Ramos 20

Ing. Wagner E. Vicente Ramos 21

Otra perspectiva utilizada para determinar los elementos del proceso

Figura 2: Relación entre elementos del proceso del software

Ing. Wagner E. Vicente Ramos 22