nstituto Tecnolgico Superior de Fresnillo

Academia de Informtica

CURSO DE TITULACION
UNIDAD 1: EL MODELO DEL PROCESO DEL SOFTWARE OBJETIVO O
COMPETENCIA A DESARROLLAR:
Analizar y modelar proyectos de sistemas de informacin aplicando el
paradigma orientado a objetos. Competencias especficas: Conocer el
modelo de proceso de software. Identificar reas de oportunidad en una
organizacin, para la propuesta y diseo de sistemas de informacin.
Analizar diversas alternativas de solucin a partir de la identificacin y
definicin de requerimientos especificados por el cliente. Establecer una
propuesta para el anlisis y diseo de un proyecto de software de acuerdo a
la alternativa de solucin planteada o establecida. Planificar y gestionar
proyectos de sistemas de informacin con base en una metodologa de
desarrollo. Aplicar principios de ingeniera del software en las etapas de
anlisis y diseo de un sistema de informacin. Modelar casos de uso
acorde a los requerimientos del proyecto. Documentar el proyecto.

TEMARIO:
1.1 1.2 1.3 1.4 1.5 Conceptualizacin de tecnologa orientada a objetos.
Metodologas emergentes de desarrollo de software. Mtodos de desarrollo
de software orientado a objetos. El proceso de desarrollo unificado RUP. El
lenguaje de modelado unificado UML.

ACTIVIDADES DE APRENDIZAJE:
Conocer el modelo de proceso de software: Analizar las caractersticas de
los modelos de desarrollo de sistemas de informacin, as como de mtodos
de desarrollo de software orientado a objetos. Buscar en artculos, y libros
especializadosconceptos y ejemplos de mtodos de desarrollo de software
orientado a objetos, y realizar una tabla comparativa. Buscar en artculos, y
libros especializados conceptos, ejemplos y tendencias de UML y RUP, y
realizar una tabla comparativa. contenido de la unidad

TEMA 1.1: CONCEPTUALIZACIN DE TECNOLOGA ORIENTADA A OBJETOS

Tecnologa orientada a objetos

Analisis y Modelado de Sistemas de Informacin

Unidad 1

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica Hoy en

da la tecnologa orientada a objetos ya no se aplica solamente a los
lenguajes de programacin, adems se viene aplicando en el anlisis y
diseo con mucho xito, al igual que en las bases de datos. Es que para
hacer una buena programacin orientada a objetos hay que desarrollar todo
el sistema aplicando esta tecnologa, de ah la importancia del anlisis y el
diseo orientado a objetos. La programacin orientada a objetos es una de
las formas ms populares de programar y viene teniendo gran acogida en el
desarrollo de proyectos de software desde los ltimos aos. Esta acogida se
debe a sus grandes capacidades y ventajas frente a las antiguas formas de
programar. Una Perspectiva Histrica Tradicionalmente, la programacin fue
hecha en una manera secuencial o lineal, es decir una serie de pasos
consecutivos con estructuras consecutivas y bifurcaciones.
Los lenguajes basados en esta forma de programacin ofrecan ventajas al
principio, pero el problema ocurre cuando los sistemas se vuelven complejos.
Estos programas escritos al estilo espaguetti no ofrecen flexibilidad y el
mantener una gran cantidad de lneas de cdigo en slo bloque se vuelve
una tarea complicada. Frente a esta dificultad aparecieron los lenguajes
basados en la programacin estructurada. La idea principal de esta forma de
programacin es separar las partes complejas del programa en mdulos o
segmentos que sean ejecutados conforme se requieran. De esta manera
tenemos un diseo modular, compuesto por mdulos independientes que
puedan comunicarse entre s. Poco a poco este estilo de programacin fue
reemplazando al estilo espaguetti impuesto por la programacin lineal.
Entonces, vemos que la evolucin que se fue dando en la programacin se
orientaba siempre a ir descomponiendo ms el programa. Este tipo de
descomposicin conduce directamente a la programacin orientada a
objetos. Pues la creciente tendencia de crear programas cada vez ms
grandes y complejos llev a los desarrolladores a crear una nueva forma de
programar que les permita crear sistemas de niveles empresariales y con
reglas de negocios muy complejas. Para estas necesidades ya no bastaba la
programacin estructurada ni mucho menos la programacin lineal. Es as
como aparece la programacin orientada a objetos (POO). La POO viene de la
evolucin de la Analisis y Modelado de Sistemas de Informacin Unidad 1 2

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica

programacin estructurada; bsicamente la POO simplifica la programacin
con la nueva filosofa y nuevos conceptos que tiene. La POO se basa en la
dividir el programa en pequeas unidades lgicas de cdigo. A estas
pequeas unidades lgicas
de cdigo se les llama objetos. Los objetos son unidades independientes que
se comunican entre ellos mediante mensajes. Veamos con mayor
detenimiento este tema. Cules son las ventajas de un lenguaje orientado a
objetos?

Fomenta la reutilizacin y extensin del cdigo. Permite crear sistemas ms

complejos. Relacionar el sistema al mundo real. Facilita la creacin de
programas visuales. Construccin de prototipos Agiliza el desarrollo de
software Facilita el trabajo en equipo Facilita el mantenimiento del software

Lo interesante de la POO es que proporciona conceptos y herramientas con

las cuales se modela y representa el mundo real tan fielmente como sea
posible. El modelo Orientado a Objetos Para entender este modelo vamos a
revisar 4 conceptos bsicos:

Objetos Clases Herencia Envo de mensajes

1. Objetos Entender que es un objeto es la clave para entender cualquier

lenguaje orientado a objetos. Existen muchas definiciones que se le ha dado
al Objeto. Primero empecemos entendiendo que es un objeto del mundo real.
Un objeto del mundo real es cualquier cosa que vemos a nuestro alrededor.
Digamos que para leer este artculo lo hacemos a travs del monitor y una
computadora, ambos son objetos, al igual que nuestro telfono celular, un
rbol o un automvil. Analicemos un poco ms a un objeto del mundo real,
como la computadora. No necesitamos ser expertos en hardware para saber
que una computadora est compuesta internamente por varios
componentes: la tarjeta madre, el chip del procesador, un disco duro, una
tarjeta de video, y otras partes
ms. El trabajo en conjunto de todos estos componentes hace operar a una
computadora. Internamente, cada uno de estos componentes puede ser

sumamente complicado y puede ser fabricado por diversas compaas con

diversos mtodos de diseo. Pero nosotros no necesitamos saber cmo
trabajan cada uno de estos componentes, como saber que hace cada uno de
los chips de la tarjeta madre, o cmo funciona internamente el procesador.
Cada componente es una unidad autnoma, y todo lo que necesitamos saber
de adentro es cmo interactan entre s los componentes, saber por ejemplo
si el procesador y las memorias son Analisis y Modelado de Sistemas de
Informacin Unidad 1 3

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica

compatibles con la tarjeta madre, o conocer donde se coloca la tarjeta de
video. Cuando conocemos como interaccionan los componentes entre s,
podremos armar fcilmente una computadora. Que tiene que ver esto con la
programacin? La programacin orientada a objetos trabaja de esta manera.
Todo el programa est construido en base a diferentes componentes
(Objetos), cada uno tiene un rol especfico en el programa y todos los
componentes pueden comunicarse entre ellos de formas predefinidas. Todo
objeto del mundo real tiene 2 componentes: caractersticas y
comportamiento. Por ejemplo, los automviles tienen caractersticas (marca,
modelo, color, velocidad mxima, etc.) y comportamiento (frenar, acelerar,
retroceder, llenar combustible, cambiar llantas, etc.). Los Objetos de
Software, al igual que los objetos del mundo real, tambin tienen
caractersticas y
comportamientos. Un objeto de software mantiene sus caractersticas en una
o ms "variables", e implementa su comportamiento con "mtodos". Un
mtodo es una funcin o subrutina asociada a un objeto.

Para redondear estas ideas, imaginemos que tenemos estacionado en

nuestra cochera un Ford Focus color azul que corre hasta 260 km/h. Si
pasamos ese objeto del mundo real al mundo del software, tendremos un
objeto Automvil con sus caractersticas predeterminadas: Marca = Ford
Modelo = Focus Color = Azul Velocidad Mxima = 260 km/h Cuando a las
caractersticas del objeto le ponemos valores decimos que el objeto tiene
estados. Las variables almacenan los estados de un objeto en un
determinado momento. Definicin terica: Un objeto es una unidad de cdigo
compuesto de variables y mtodos relacionados. 2. Las Clases En el mundo
real, normalmente tenemos muchos objetos del mismo tipo. Por ejemplo,
nuestro telfono celular es slo uno de los miles que hay en el mundo. Si
hablamos en trminos de la programacin orientada a objetos, podemos
decir que nuestro objeto celular es una instancia de una clase conocida como
"celular". Los celulares tienen caractersticas (marca, modelo, sistema
operativo, pantalla, teclado, etc.) y comportamientos (hacer y recibir
llamadas, enviar mensajes multimedia, transmisin de datos, etc.).

Analisis y Modelado de Sistemas de Informacin

Unidad 1

Instituto Tecnolgico Superior de Fresnillo

Academia de Informtica

Cuando se fabrican los celulares, los fabricantes aprovechan el hecho de que

los celulares
comparten esas caractersticas comunes y construyen modelos o plantillas
comunes, para que a partir de esas se puedan crear muchos equipos
celulares del mismo modelo. A ese modelo o plantilla le llamamos CLASE, y a
los equipos que sacamos a partir de ella la llamamos OBJETOS.

Esto mismo se aplica a los objetos de software, se puede tener muchos

objetos del mismo tipo y mismas caractersticas. Definicin terica: La clase
es un modelo o prototipo que define las variables y mtodos comunes a
todos los objetos de cierta clase. Tambin se puede decir que una clase es
una plantilla genrica para un conjunto de objetos de similares
caractersticas. Por otro lado, una instancia de una clase es otra forma de
llamar a un objeto. En realidad no existe diferencia entre un objeto y una
instancia. Slo que el objeto es un trmino ms general, pero los objetos y las
instancias son ambas representacin de una clase. Definicin Terica: Una
instancia es un objeto de una clase en particular. 3. Herencia La herencia es
uno de los conceptos ms cruciales en la POO. La herencia bsicamente
consiste en que una clase puede heredar sus variables y mtodos a varias
subclases (la clase que hereda es llamada superclase o clase padre). Esto
significa que una subclase, aparte de los atributos y mtodos propios, tiene
incorporados los atributos y mtodos heredados de la superclase. De esta
manera se crea una jerarqua de herencia. Por ejemplo, imaginemos que
estamos haciendo el anlisis de un Sistema para una tienda que vende y
repara equipos celulares.

Analisis y Modelado de Sistemas de Informacin

Unidad 1

Instituto Tecnolgico Superior de Fresnillo

Academia de Informtica

En el grfico vemos 2 Clases ms que posiblemente necesitemos para crear

nuestro Sistema. Esas 2 Clases nuevas se construirn a partir de la Clase
Celular existente. De esa forma utilizamos el comportamiento de la
SuperClase. En general, podemos tener una gran jerarqua de Clases tal y
como vemos en el siguiente grfico:

4. Envo de Mensajes Un objeto es intil si est aislado. El medio empleado

para que un objeto interacte con otro son los mensajes. Hablando en
trminos un poco ms tcnicos, los mensajes son invocaciones a los mtodos
de los objetos. Caractersticas asociadas al POO Abstraccin La abstraccin
consiste en captar las caractersticas esenciales de un objeto, as como su
comportamiento. Por ejemplo, volvamos al ejemplo de los automviles, Qu
caractersticas podemos abstraer de los automviles? O lo que es lo mismo
Qu caractersticas semejantes tienen todos los automviles? Todos tendrn
una marca, un modelo, nmero de chasis, peso, llantas, puertas, ventanas,
etc. Y en cuanto a su comportamiento todos los automviles podrn acelerar,
frenar, retroceder, etc. En los lenguajes de programacin orientada a objetos,
el concepto de Clase es la representacin y el mecanismo por el cual se
gestionan las abstracciones. Por ejemplo, en Java tenemos: public class
Automovil { // variables Analisis y Modelado de Sistemas de Informacin
Unidad 1 6

Instituto Tecnolgico Superior de Fresnillo // mtodos } Encapsulamiento

Academia de Informtica

El encapsulamiento
consiste en unir en la Clase las caractersticas y comportamientos, esto es,
las variables y mtodos. Es tener todo esto es una sola entidad. En los
lenguajes estructurados esto era imposible. Es evidente que el
encapsulamiento se logra gracias a la abstraccin y el ocultamiento que
veremos a continuacin. La utilidad del encapsulamiento va por la facilidad
para manejar la complejidad, ya que tendremos a las Clases como cajas
negras donde slo se conoce el comportamiento pero no los detalles internos,
y esto es conveniente porque nos interesar ser conocer qu hace la Clase
pero no ser necesario saber cmo lo hace. Ocultamiento Es la capacidad de
ocultar los detalles internos del comportamiento de una Clase y exponer slo
los detalles que sean necesarios para el resto del sistema. El ocultamiento
permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque
habr cierto comportamiento privado de la Clase que no podr ser accedido
por otras Clases. Y controlar porque daremos ciertos mecanismos para
modificar el estado de nuestra Clase y es en estos mecanismos dnde se
validarn que algunas condiciones se cumplan. En Java el ocultamiento se
logra usando las palabras reservadas: public, private y protected delante de
las variables y mtodos. Anlisis y diseo Orientado a Objetos Para el
desarrollo de software orientado a objetos no basta usar un lenguaje
orientado a objetos. Tambin se necesitar realizar un anlisis y diseo
orientado a objetos. El modelado visual es la clave para realizar el anlisis
OO. Desde los inicios del desarrollo de software OO han existido
diferentes metodologas para hacer esto del modelado, pero sin lugar a duda,
el Lenguaje de Modelado Unificado (UML) puso fin a la guerra de
metodologas. Segn los mismos diseadores del lenguaje UML, ste tiene
como fin modelar cualquier tipo de sistemas (no solamente de software)
usando los conceptos de la orientacin a objetos. Y adems, este lenguaje
debe ser entendible para los humanos y mquinas. Actualmente en la
industria del desarrollo de software tenemos al UML como un estndar para el
modelado de sistemas OO. Fue la empresa Racional que cre estas
definiciones y especificaciones del estndar UML, y lo abri al mercado. La
misma empresa cre uno de los programas ms conocidos hoy en da para
este fin; el Racional Rose, pero tambin existen otros programas como el
Poseidon que trae licencias del tipo community edition que permiten su uso
libremente. El UML consta de todos los elementos y diagramas que permiten

modelar los sistemas en base al paradigma orientado a objetos. Los modelos

orientados a objetos cuando se construyen en forma correcta, son fciles de
comunicar, cambiar, expandir, validar y verificar. Este modelado en UML es
flexible al cambio y permite crear componentes plenamente reutilizables.
Analisis y Modelado de Sistemas de Informacin Unidad 1 7

Instituto Tecnolgico Superior de Fresnillo

Academia de Informtica

TEMA 1.2: METODOLOGAS EMERGENTES DE DESARROLLO DE SOFTWARE

Una metodologa de desarrollo de software se refiere a un framework que es
usado para estructurar, planear y controlar el proceso de desarrollo en
sistemas de informacin. A
lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados
diferencindose por su fortaleza y debilidad. El framework para metodologa
de desarrollo de software consiste en: Una filosofa de desarrollo de
programas de computacin con el enfoque del proceso de desarrollo de
software. Herramientas, modelos y mtodos para asistir al proceso de
desarrollo de software

Estos frameworks son a menudo vinculados a algn tipo de organizacin, que

adems desarrolla, apoya el uso y promueve la metodologa. La metodologa
es a menudo documentada en algn tipo de documentacin formal. Historia
El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la
dcada de 1960 para desarrollar a gran escala funcional de sistemas de
negocio en una poca de grandes conglomerados empresariales. La idea
principal era continuar el desarrollo de los sistemas de informacin en una
muy deliberada, estructurada y metdica, reiterando cada una de las etapas
del ciclo de vida. Los sistemas de informacin en torno a las actividades
resueltas pesadas para el procesamiento de datos y rutinas de clculo.
Metodologas de Desarrollo de Software tiene como objetivo presentar un
conjunto de tcnicas tradicionales y modernas de modelado de sistemas que
permitan desarrollar software de calidad, incluyendo heursticas de
construccin y criterios de comparacin de modelos de sistemas. Para tal fin
se describen, fundamentalmente, herramientas de Anlisis y Diseo
Orientado a Objetos (UML), sus diagramas, especificacin, y criterios de
aplicacin de las mismas. Como complemento se
describirn las metodologas de desarrollo de software que utilizan dichas
herramientas, ciclos de vida asociados y discusin sobre el proceso de
desarrollo de software ms adecuado para las diferentes aplicaciones
ejemplos que se presentarn. Principalmente, se presentar el Proceso
Unificado el cual utiliza un ciclo de vida iterativo e incremental.

Metodologas de desarrollo de software 1970s Analisis y Modelado de

Sistemas de Informacin Unidad 1 8

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica

Programacin estructurada sol desde 1969 Programacin estructurada
Jackson desde 1975 1980s Structured Systems Analysis and Design
Methodology (SSADM) desde 1980 Structured Analysis and Design Technique
(SADT) desde 1980 Ingeniera de la informacin (IE/IEM) desde 1981 1990s
Rapid application development (RAD) desde 1991. Programacin orientada a
objetos (OOP) a lo largo de la dcada 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.
Thrisson Agile Unified Process (AUP) desde 2005 por Scott Ambler Enfoques
de desarrollo de software Cada metodologa de desarrollo de software tiene
ms o menos su propio enfoque para el desarrollo de software. Estos son los
enfoques ms generales, que se desarrollan en varias metodologas
especficas. Estos enfoques son los siguientes: Modelo en cascada:
Framework lineal. Prototipado: Framework iterativo. Incremental:
Combinacin de framework lineal e iterativo. Espiral: Combinacin de
framework lineal e iterativo. RAD: Rapid Application Development, framework
iterativo.

Modelo en cascada Es un proceso secuencial de desarrollo en el que los

pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a
travs de las fases de anlisis de las necesidades, el diseo, implementacin,
pruebas (validacin), la integracin, y mantenimiento. La primera descripcin
formal del modelo de cascada se cita a menudo a un artculo publicado por
Winston Royce W.2 en 1970, aunque Royce no utiliza el trmino "cascada" de
este artculo. Los principios bsicos del modelo de cascada son los siguientes:
El proyecto est dividido en fases secuenciales, con cierta superposicin
y splashback aceptable entre fases. Se hace hincapi en la planificacin, los
horarios, fechas, presupuestos y ejecucin de todo un sistema de una sola
vez. Un estricto control se mantiene durante la vida del proyecto a travs de
la utilizacin de una amplia documentacin escrita, as como a travs de
comentarios y aprobacin / signoff por el usuario y la tecnologa de la
informacin de gestin al final de la mayora de las fases antes de comenzar
la prxima fase.

Analisis y Modelado de Sistemas de Informacin

Unidad 1

Instituto Tecnolgico Superior de Fresnillo Prototipado

Academia de Informtica

El prototipado es el framework de actividades dedicada al

desarrollo de software prototipo, es decir, versiones incompletas del software
a desarrollar. Incremental Provee una estrategia para controlar la complejidad
y los riesgos, desarrollando una parte del producto software reservando el
resto de aspectos para el futuro. Los principios bsicos son: Una serie de
mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo
de desarrollo se han completado para una pequea parte de los sistemas,
antes de proceder a la prxima incremental Se definen los requisitos antes de
proceder con lo evolutivo, se realiza un miniCascada de desarrollo de cada
uno de los incrementos del sistema El concepto inicial de software, anlisis
de las necesidades, y el diseo de la arquitectura y colectiva bsicas se
definen utilizando el enfoque de cascada, seguida por iterativo de prototipos,
que culmina en la instalacin del prototipo final.

Espiral Los principios bsicos son: La atencin se centra en la evaluacin y

reduccin del riesgo del proyecto dividiendo el proyecto en segmentos ms
pequeos y proporcionar ms facilidad de cambio durante el proceso de
desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y con un
peso de la consideracin de la continuacin del proyecto durante todo el ciclo
de vida. Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes
bsicos: (1) determinar objetivos, alternativas, y desencadenantes de la
iteracin; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3)
desarrollar y verificar los resultados de la iteracin, y (4) plan de la prxima
iteracin. Cada ciclo
comienza con la identificacin de los interesados y sus condiciones de
ganancia, y termina con la revisin y examinacin.

Rapid Application Development (RAD) El desarrollo rpido de aplicaciones

(RAD) es una metodologa de desarrollo de software, que implica el desarrollo
interativo y la construccin de prototipos. El desarrollo rpido de aplicaciones
es un trmino originalmente utilizado para describir un proceso de desarrollo
de software introducido por James Martin en 1991. Principios bsicos:
Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en
un sistema de relativamente bajo coste de inversin.

Analisis y Modelado de Sistemas de Informacin

Unidad 1

10

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica Intenta

reducir el riesgos inherente del proyecto partindolo en segmentos ms
pequeos y proporcionar ms facilidad de cambio durante el proceso de
desarrollo. Orientacin dedicada a producir sistemas de alta calidad con
rapidez, principalmente mediante el uso de iteracin por prototipos (en
cualquier etapa de desarrollo), promueve la participacin de los usuarios y el
uso de herramientas de desarrollo computarizadas. Estas herramientas
pueden incluir constructores de Interfaz grfica de usuario (GUI), Computer
Aided Software Engineering (CASE) las herramientas, los sistemas de gestin
de bases de datos (DBMS), lenguajes de programacin de cuarta generacin,
generadores de cdigo, y tcnicas orientada a objetos. Hace especial
hincapi en el cumplimiento de la necesidad
comercial, mientras que la ingeniera tecnolgica o la excelencia es de menor
importancia. Control de proyecto implica el desarrollo de prioridades y la
definicin de los plazos de entrega. Si el proyecto empieza a aplazarse, se
hace hincapi en la reduccin de requisitos para el ajuste, no en el aumento
de la fecha lmite. En general incluye Joint application development (JAD),
donde los usuarios estn intensamente participando en el diseo del sistema,
ya sea a travs de la creacin de consenso estructurado en talleres, o por va
electrnica. La participacin activa de los usuarios es imprescindible.
Iterativamente realiza la produccin de software, en lugar de enfocarse en un
prototipo. Produce la documentacin necesaria para facilitar el futuro
desarrollo y mantenimiento.

Otros enfoques de desarrollo de software Metodologas de desarrollo

Orientado a objetos, Diseo orientado a objetos (OOD) de Grady Booch,

tambin conocido como Anlisis y Diseo Orientado a Objetos (OOAD). El

modelo incluye seis diagramas: de clase, objeto, estado de transicin, la
interaccin, mdulo, y el proceso. Top-down programming, evolucionado en la
dcada de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en
Desarrollo Estructurado. Proceso Unificado, es una metodologa de desarrollo
de software, basado en UML. Organiza el desarrollo de software en cuatro
fases, cada una de ellas con la ejecucin de una o ms iteraciones de
desarrollo de software: creacin, elaboracin, construccin, y las directrices.
Hay una serie de herramientas y productos diseados para facilitar la
aplicacin. Una
de las versiones ms populares es la de Rational Unified Process.

TEMA 1.3: MTODOS DE DESARROLLO DE SOFTWARE ORIENTADO A OBJETOS

El desarrollo de software no es sin dudas una tarea fcil. Como resultado a
este problema ha surgido una alternativa desde hace mucho: la Metodologa.
Las metodologas imponen un proceso disciplinado sobre el desarrollo de
software con el fin de hacerlo ms predecible y eficiente. Lo hacen
desarrollando un proceso detallado con un fuerte nfasis en planificar
inspirado por otras disciplinas de la ingeniera. Las metodologas ingenieriles
han estado presentes durante mucho tiempo. No se han distinguido
precisamente por ser muy exitosas. An menos por su popularidad. La crtica
ms Analisis y Modelado de Sistemas de Informacin Unidad 1 11

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica frecuente

a estas metodologas es que son burocrticas. Hay tanto que hacer para
seguir la metodologa que el ritmo entero del desarrollo se retarda. Hoy en
da existen numerosas propuestas metodolgicas que inciden en distintas
dimensiones del proceso de desarrollo. Un ejemplo de ellas son las
propuestas tradicionales centradas especficamente en el control del proceso.
Estas han demostrado ser efectivas y necesarias en un gran nmero de
proyectos, sobre todo aquellos proyectos de gran tamao (respecto a tiempo
y recursos). Sin embargo la experiencia ha demostrado que las metodologas
tradicionales no ofrecen una buena solucin para proyectos donde el entorno
es voltil y donde los requisitos no se conocen con exactitud, porque no estn
pensadas para trabajar con incertidumbre. Aplicar metodologas tradicionales
nos obliga a forzar a nuestro cliente a que tome la mayora de las decisiones
al principio. Luego el coste de cambio de una decisin tomada puede llegar a
ser muy elevado si aplicamos metodologas tradicionales. Es por ello que
varios problemas como los que a continuacin mencionamos han sido
detectados: Retrasos en la planificacin: llegada la fecha de entregar el
software ste no est disponible. Sistemas deteriorados: el software se ha
creado pero despus de un par de aos el coste de su mantenimiento es tan
complicado que definitivamente se abandona su produccin. Tasa de
defectos: el software se pone en produccin pero los defectos son tantos que
nadie lo usa. Requisitos mal comprendidos: el software no resuelve los
requisitos planificados inicialmente. Cambios de negocio: el problema que
resolva nuestro software ha cambiado y nuestro software no se ha adaptado.
Falsa riqueza: el software hace muchas cosas tcnicamente muy interesantes
y divertidas, pero no resuelven el problema de nuestro cliente, ni hace que
ste gane ms dinero. Cambios de personal: despus de unos aos de
trabajo los programadores comienzan a odiar el proyecto y lo abandonan.
Como respuesta a los problemas aplicando metodologas tradicionales
surgieron otras metodologas que tratan de adaptarse a la realidad del
desarrollo de software. El encanto de estas metodologas giles es su
reaccin ante la burocracia de las metodologas monumentales. Estos nuevos
mtodos buscan un justo medio entre ningn proceso y demasiado proceso,
proporcionando simplemente suficiente proceso para que el esfuerzo valga la
pena. El resultado de todo esto es que los mtodos giles cambian
significativamente algunos de los nfasis de los mtodos ingenieriles. La
diferencia inmediata es que son menos orientados al documento, exigiendo
una cantidad ms pequea de documentacin para una tarea dada. De
muchas maneras son ms bien orientados al cdigo: siguiendo un camino
que dice que la parte importante de la documentacin es el cdigo fuente.
Una metodologa de desarrollo de software Orientado a Objetos consta de

Conceptos y diagramas Unidad 1 12

Analisis y Modelado de Sistemas de Informacin


Instituto Tecnolgico Superior de Fresnillo Etapas y definicin de entregas en
cada una de ellas Actividades y recomendaciones

Academia de Informtica

Una metodologa de desarrollo de software Orientada a Objetos basada en

UML Se presenta a continuacin un resumen de las principales etapas y
actividades basadas en UML. Esta metodologa es extractada de las
metodologas existentes, en particular

Object Oriented Design

Objectory

Object Modeling Technique

Anlisis de Requerimientos Grady Booch Anlisis de Dominio Diseo Anlisis

de Object-Oriented Software Requerimientos Enginnering Anlisis de
Robustez Ivar Jacobson A Use Case Driven Approach Diseo Addison-Wesley
Implementacin 1992 Pruebas Object Oriented Modeling Anlisis James
Rumbaugh and Design Diseo del Sistema et. al. Prentice Hall Diseo de
Objetos 1991 Implementacin

Object Oriented Design with Applications Benjamming Cummings 1991

Estas tres metodologas van a ser fusionadas a finales de 1997 en una sola,
basada en la notacin UML

TEMA 1.4: EL PROCESO DE DESARROLLO UNIFICADO RUP

El proceso unificado de desarrollo (RUP) es una metodologa para la

ingeniera de software que va ms all del mero anlisis y diseo orientado a

objetos para proporcionar una familia de tcnicas que soportan el ciclo
completo de desarrollo de software. El resultado es un proceso basado en
componentes, dirigido por los casos de uso, centrado en la arquitectura,
iterativo e incremental. Caractersticas principales de RUP Centrado en los
modelos: Los diagramas son un vehculo de comunicacin ms expresivo que
las descripciones en lenguaje natural. Se trata de minimizar el uso de
descripciones y especificaciones textuales del sistema. Guiado por los
Casos de Uso: Los Casos de Uso son el instrumento para validar la
arquitectura del software y extraer los casos de prueba. Centrado en la
arquitectura: Los modelos son proyecciones del anlisis y el diseo constituye
la arquitectura del producto a desarrollar. Iterativo e incremental: Durante
todo el proceso de desarrollo se producen versiones incrementales (que se
acercan al producto terminado) del producto en desarrollo.

Analisis y Modelado de Sistemas de Informacin

Unidad 1

13

Instituto Tecnolgico Superior de Fresnillo Beneficios que aporta RUP

Academia de Informtica

Permite desarrollar aplicaciones sacando el mximo provecho de las nuevas

tecnologas, mejorando la calidad, le rendimiento, la reutilizacin, la
seguridad y el mantenimiento del
software mediante una gestin sistemtica de los riesgos. Permite la
produccin de software que cumpla con las necesidades de los usuarios, a
travs de la especificacin de los requisitos, con una agenda y costo
predecible. Enriquece la productividad en equipo y proporciona prcticas
ptimas de software a todos sus miembros. Permite llevar a cabo el proceso
de desarrollo prctico, brindando amplias guas, plantillas y ejemplos para
todas las actividades crticas. Proporciona guas explicitas para reas tales
como modelado de negocios, arquitectura Web, pruebas y calidad. Tambin
se proporciona guas para desarrollar en plataformas IBM WebSphere y
Microsoft Web Solution para acelerar el desarrollo de los proyectos. Se integra
estrechamente con herramientas Rational, permitiendo a los equipos de
desarrollo aprovechar todas las ventajas de las caractersticas de los
productos Rational, el Lenguaje de Modelado Unificado (UML) y otras
prcticas ptimas de la industria. Unifica todo el equipo de desarrollo de
software y mejora la comunicacin al brindar a cada miembro del mismo una
base de conocimientos, un lenguaje de modelado y un punto de vista de
cmo desarrollar software. Optimiza la productividad de cada miembro del
equipo al poner al alcance la experiencia derivada de miles de proyectos y
muchos lderes de la industria. No solo garantiza que los proyectos abordados
sern ejecutados ntegramente sino que adems evita desviaciones
importantes respecto a los plazos. Permite una definicin acertada del
sistema en un inicio para hacer innecesarias las reconstrucciones parciales
posteriores.

TEMA 1.5: EL LENGUAJE DE MODELADO UNIFICADO UML

UML es un lenguaje para modelar y comunicar informacin sobre sistemas,
para lo cual se usan diagramas y texto. Por ejemplo la Figura 1-5 comunica lo
siguiente: Un administrador dirige un equipo que trabaja en un proyecto.
Cada administrador tiene un nombre y un nmero de telfono, adems puede
iniciar o terminar un proyecto. Cada proyecto tiene un nombre, una fecha de
inicio y una fecha de fin. Cada equipo tiene una descripcin, y eso es todo lo

que nos interesa con respecto al equipo. Figura 1-5. Administradores,

proyectos y equipos.

Analisis y Modelado de Sistemas de Informacin

Unidad 1

14

Instituto Tecnolgico Superior de Fresnillo

Administrador Nombre Telefono IniciarProyecto() TerminarProyecto() Dirige
Equipo Descripcion Proyecto Nombre FerchaDeInicio FichaDeFin Administra

Academia de Informtica

Ejecuta

Fuente: O`Reilly 2003

Los tres aspectos de UML UML es una abreviacin de Unified Modeling

Language (Lenguaje de Modelado Unificado). Cada una de estas tres palabras
habla de un aspecto importante de UML, las prximas secciones hablaran de
estos tres aspectos. Language (Lenguaje) Un lenguaje nos permite la
comunicacin sobre un tema o concepto determinado. En el desarrollo de un
sistema, los temas que se incluyen son los requerimientos y el sistema. Sin
un lenguaje seria difcil para los miembros de un equipo comunicase y
colaborar para el desarrollo exitoso de un sistema. Los lenguajes, no siempre
se componen de palabras escritas. Por ejemplo, comnmente usamos
lenguajes de conteo para
ensear a los nios a contar en las clases de aritmtica. Los nios usan
entonces objetos como son, peras o manzanas, para representar algn
nmero. Ahora considere estos dos lenguajes para comunicar algn nmero
en especfico o das que dura un proyecto. Para representar el nmero cinco,
un lenguaje de conteo utiliza cinco objetos, mientras que un lenguaje
aritmtico se utiliza la cadena "5". Figura 1-6. La cantidad cinco en dos
lenguajes

Fuente: O`Reilly 2003

UML es un lenguaje para especificar, visualizar construir y documentar los

artifacts del sistema intensivo de procesos. UML en si no es un proceso, un
proceso implica un conjunto de pasos descritos por una metodologa para
resolver un problema y desarrollar un sistema que satisfaga los
requerimientos de un usuario. Modelo Un modelo es una representacin de

un tema, ste captura un conjunto de ideas conocidas como abstracciones.

Sin un modelo, es muy difcil para los miembros del equipo tener un

Analisis y Modelado de Sistemas de Informacin

Unidad 1

15

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica

entendimiento comn de los requerimientos del sistema, as como del
impacto de los cambios mientras se desarrolla el sistema. Cuando se crea el
modelo, si tratamos de representar todo al mismo tiempo, fcilmente
tendremos una sobrecarga de informacin, es por eso que hay que
concentrarse en capturar solo la informacin relevante para entender el
problema, resolverlo, e implementar la solucin, mientras se excluye
cualquier informacin que sea irrelevante que pudiera
dificultar el progreso del desarrollo. Unificado Este trmino se refiere al hecho
de que el Grupo de Administracin de Objetos (Object Management Group OMG) y el Rational Software Corporation, crearon UML para traer las mejores
prcticas de ingeniera a la industria de tecnologa y de los sistemas de
informacin. Sin un lenguaje en comn, es difcil para los nuevos miembros
de un equipo volverse productivo rpidamente y contribuir en el desarrollo de
un sistema. Metas y Alcances Para entender las metas y los alcances de la
OMG para UML, es mejor empezar por las motivaciones detrs de UML. Las
metas de los OMGs que hicieron UML son: Listo para usarse
Expresivo Simple Preciso Extensible Independiente de la implementacin
Independiente del proceso

Estando listo para usarse, siendo expresivo, simple y preciso, UML puede
inmediatamente ser aplicado para el desarrollo de proyectos. Para habilitar el
desarrollo de modelos precisos, la OMG presenta el Lenguaje de Restricciones
de Objetos (Object Constraint Language - OCL), un sublenguaje para adherir
condiciones que los elementos del modelo deben satisfacer para que el
mismo modelo sea considerado correcto. En cuanto a los alcances de la OMG
al momento de la creacin de UML fue incluir un lenguaje de modelado que
combina tres de los ms importantes mtodos de desarrollo de sistemas:
El Mtodo Booch `93 de Grady Booch. La Tcnica de Modelado de Objetos
(Object Modeling Technique - OMT) de James Rumbaugh. El mtodo de
Ingeniera de Software Orientado a Objetos (Object-Oriented Software
Engineering - OOSE) de and Ivar
Jacobson.

En conjunto con las mejores prcticas de la industria de tecnologa y de

sistemas de informacin. De manera separada son slo eso, mtodos, pero al
unirlos conforman una metodologa. Historia

Analisis y Modelado de Sistemas de Informacin

Unidad 1

16

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica La historia

de UML consiste de cinco Perodos distintos. Al entender esos Perodos se
puede entender como surgi UML y como esta evolucionando en estos
momentos. El Perodo de Fragmentacin Entre la mitad de 1970 y la mitad de
1990, las organizaciones comenzaron a entender el valor del software para
los negocios, pero solo tena una coleccin fragmentada de tcnicas para
desarrollar y dar mantenimiento al software. Tres mtodos sobresalieron: El
Mtodo Booch `93 de Grady Booch, que hace nfasis en el diseo y
construccin de sistemas de software. La Tcnica de Modelado de Objetos
(Object Modeling Technique - OMT) de James Rumbaugh, que hace nfasis en
el anlisis de los sistemas de software. El mtodo de Ingeniera de Software
Orientado a Objetos (Object-Oriented Software Engineering - OOSE) de and
Ivar Jacobson, que hace nfasis en la ingeniera del negocio y el anlisis de
los requerimientos. Conforme los mtodos orientados a objetos comenzaron a
evolucionar desde los mtodos estructurales, la industria se fue
fragmentando principalmente alrededor de estos tres mtodos. Los
practicantes de un mtodo no podan fcilmente entender los artifacts
producidos por un mtodo diferente. Adems estas personas tenan
problemas al pasar de una
organizacin hacia la siguiente debido a que dicho movimiento implicaba el
aprendizaje de un nuevo mtodo. El Perodo de Unificacin Entre la mitad de
1990 y la mitad de 1997, surgi la versin 1.0 de UML. James Rumbaugh y
posteriormente Ivar Jacobson, se unieron a Grady Booch en la Corporacin
Rational Software para unificar sus mtodos. Por sus esfuerzos de unin, se
les empezo a llamar Los Tres Amigos. Conforme las organizaciones
comenzaron a ver el valor de UML, el grupo de trabajo de de Diseo y Anlisis
de Objetos de la OMG elaboro una Solicitud para una Propuesta (Request for
Proposal - RFP) para establecer un estndar que definiera el significado de los
conceptos de la tecnologa orientada a objetos para las herramientas que
soportaran el diseo y el anlisis orientado a objetos. En conjunto con varias
organizaciones, la Corporacin Rational Software forma un Consorcio de
Socios de UML, y estos socios son los que envan la versin 1.0 de UML a la
OMG en respuesta a uno de los varios RFP iniciales. El Perodo de
Estandarizacin Hacia finales de 1997 se libera la versin 1.1 de UML, todas
las replicas a los RFP fueron combinadas en la versin 1.1 de UML. La OMG
adopto UML y asumi la responsabilidad del desarrollo de la estandarizacin
en noviembre de 1997. El Perodo de Revisin Despus de la adopcin de
UML en 1997, varias versiones surgieron. La OMG realizo un diagrama de las
revisiones del grupo de trabajo (revision task force - RTF) para aceptar
comentarios pblicos de UML y realizar la menor cantidad de trabajo editorial
y de actualizaciones tcnicas al estndar.
Varios vendedores empezaron a dar soporte y promocin

Analisis y Modelado de Sistemas de Informacin

Unidad 1

17

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica de UML

con herramientas, consultora y libros. La versin actual de UML es la 1.4 y la
OMG esta actualmente trabajando en versin 2.0 de UML. El Perodo de
Industrializacin A la par del perodo de revisin, los OMG estn proponiendo
que el estndar de UML se convierta en una estandarizacin internacional a
travs de una Especificacin de Disposicin Pblica (Publicly Available
Specification - PAS) a travs de la Organizacin Internacional de
Estndares(Organization for Standardization - ISO). UML y los Procesos
Aunque UML es independiente del proceso, sus creadores promueven un
proceso que sea dirigido por Casos de Uso (use-case driven), iterativo e
incremental. Para entender como UML esta relacionado con los procesos y los
tipos de procesos que sus creadores proponen, se debe tener un mejor
entendimiento acerca de cul es la mejor tcnica para aprender UML. Sin
embargo cualquier tipo de proceso incluso aquellos que no tienen estas
caractersticaspueden utilizar UML. Generalmente cada proceso de ciclo de
vida en el desarrollo de un sistema, involucra los siguientes tipos de
actividades: Requerimientos. Actividades de anlisis para entender
los requerimientos. Actividades de diseo para determinar como el sistema
va a satisfacer los requerimientos. Actividades de Implementacin para la
construccin del sistema. Actividades de Prueba para verificar que el sistema
satisface los
requerimientos. Actividades de Deployment para hacer que el sistema sea
accesible para sus usuarios.

Aplicando un Ciclo de Vida en Cascada Cuando se aplica el ciclo de vida de

cascada, las actividades son realizadas de una manera simple y linear para
todos los requerimientos. Esto a veces resulta en el descubrimiento de
problemas relacionados con la calidad, estos problemas se mantienen
escondidos durante las actividades de diseo e implementacin. Aplicando
un Ciclo de Vida Iterativo Cuando se aplica el Ciclo de Vida Iterativo, cada una
de las actividades del ciclo de vida son realizadas varias veces para un mejor
entendimiento de los requerimientos y desarrollar gradualmente un sistema
ms robusto. Casos de Uso Un caso de uso es un requerimiento funcional
descrito desde la perspectiva del usuario del sistema. Por ejemplo, un
requerimiento funcional para la mayora de los sistemas incluye una
funcionabilidad de seguridad que les permita a los usuarios entrar y salir del
sistema, agregar datos, procesar datos, generar reportes, etc. Arquitectura

Analisis y Modelado de Sistemas de Informacin

Unidad 1

18

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica La

arquitectura abarca los elementos que se necesitan para elaborar un sistema
y la manera en que estos trabajan juntos para proveer de funcionabilidad del
sistema. Los elementos y sus relaciones son conocidos como la estructura del
sistema. El modelado de la estructura del sistema se conoce como Modelado
de la Estructura. Los elementos y la manera en que estos interactan y
colaboran son
conocidos como el comportamiento del sistema. El modelado del
comportamiento del sistema es conocido como Modelado del
Comportamiento. Los distintos tipos de elementos que constituyen la
arquitectura del sistema, estructura y comportamiento estn determinados
por el paradigma orientado a objetos. Riesgo Un riesgo es cualquier
obstculo o incgnita que puede impedir nuestro xito. Para determinar que
casos de uso deben ser tomados en cuenta para la realizacin de una
iteracin y en que partes de la arquitectura nos tenemos que concentrar en
una iteracin en particular, lo primero que se tiene que hacer es identificar
los riesgos del proyecto. Una vez hecho esto se relacionan los riesgos ms
importantes con los casos de uso y los elementos de arquitectura que
resolveran dichos riesgos. Aprendiendo UML Aprender UML puede ser un
poco abrumador, debido a la amplitud y profundidad del lenguaje as como a
la ausencia de un proceso, si no se sabe sobre que partes de UML enfocarse.
Para poder entender como UML se relaciona con los procesos, uno se debe
concentrar en: El paradigma orientado a objetos, porque este establece las
bases para UML. El Modelado de la Estructural y el Modelado del
Comportamiento, porque ellos permiten entender los requerimientos y la
arquitectura. Otras capacidades de UML. Cuando se aprende UML es
importante concentrarse en lo esencial y entender cmo aplicar UML de
manera efectiva y exitosa al modelado de sistemas, en vez de atascarse en
tratar de aprender cada aspecto del lenguaje. Para lo que resta de los
captulos, se utilizar un caso de uso de un sistema de
administracin de proyectos para ayudar a aprender como leer, entender,
escribir y poder aplicar efectiva y exitosamente UML. El objetivo no es crear
un modelo completo o demasiado extenso para la implementacin de un
sistema, pero si explorar ese caso de uso y aprender como aplicar efectiva y
exitosamente UML para comunicar en el desarrollo de un sistema del mundo
real. Generalmente, en el caso de estudio un sistema de administracin de
proyectos provee funcionalidad para manejar proyectos, recursos y
administrar el sistema, se definen los siguientes roles: Administrador del
Proyecto (Project Manager) Es el responsable de asegurar la entrega de un
proyecto con calidad, dentro del tiempo especificado, costo y recursos.
Administrador de Recursos (Resource Manager)

Analisis y Modelado de Sistemas de Informacin

Unidad 1

19

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica Es el

responsable de asegurar que el personal disponible en el proyecto este
entrenado y con las habilidades necesarias. Recursos Humanos (Human
Resource) Es el responsable de asegurar que la calidad de un proyecto esta
siempre disponible. Administrador del Sistema (System Administrator) Es el
responsable de asegurar que un sistema de administracin de proyectos esta
disponible para un proyecto. Conforme se vaya avanzando en los captulos se
ir proveyendo de ms detalle sobre el caso de estudio donde sea necesario.
PRACTICAS:
Seleccionar una propuesta para el anlisis y modelado de un proyecto de
software y con l: Seleccionar una metodologa de desarrollo para
abordar
la propuesta de proyecto de desarrollo de software con base al anlisis
comparativo de metodologas. Identificar y definir requisitos. Realizar la
planeacin, estudio de factibilidad y anlisis costo/beneficio para un sistema
de informacin. Elaborar la planificacin del desarrollo del proyecto con base
en la metodologa seleccionada y en el modelo de requisitos. Modelar un
sistema de informacin con base en los requisitos, aplicando paradigma
orientado a objetos con UML.

EVALUACION DE LA UNIDAD:
Tabla con informacin sobre los aspectos y porcentajes de evaluacin

REFERENCIAS:
1. Bernd Bruegge, Allen H. Dutoit. Ingeniera de Software Orientado a
Objetos. Prentice Hall. 2. Ian Sommerville; Ingenieria de Software, Edit.
Addison Wesley; 2005. 3. James Rumbaugh, Ivar Jacobson, Graby Booch. El
Lenguaje Unificado de Modelado Manual de Referencia. Addison Wesley. 4.
Kenneth C. Lawden, Jane P. Lawden. Administracin de Los Sistemas de
Informacin, Organizacin y Tcnicas. 5. Laudon, K.; Laudon, J.; Sistemas de
Informacin Gerencial. Administracin de la Empresa Digital; 10 Edicin;
Edit. Pearson Prentice Hall. 2008. 6. Roger S. Pressman; Ingenieria de
software un Enfoque practico; Edit. Mc. Graw Hill; 2007. 7. Senn A. James.
Analisis y Diseo de Sistemas de Informacin. Addison Wesley. 8. Shari
Lawrence Pfleeger. Ingeniera de Software Teora y Prctica. Prentice Hall. 9.
Alfredo Weitzenfeld. Ingeniera de Software Orientada a Objetos con UML,
Java e Internet. Edit. Thomson. 2007

Analisis y Modelado de Sistemas de Informacin

Unidad 1

20