Unidad 1, El Modelo Del Proceso Del Software

Instituto Tecnolgico Superior de Coatzacoalcos
Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Unidad 1: El modelo del proceso del software.

Objetivo:
El estudiante conocer el modelo de proceso de software.
1.1 Conceptualizacin de tecnologa orientada a objetos.

Tecnologa orientada a objetos.
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
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 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?
L.S.C.A. Ral1Monforte Chuln
MORCH Systems

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:
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 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
MORCH Systems

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.).
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.
MORCH Systems

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.
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
// mtodos
}
MORCH Systems

Encapsulamiento
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.
1.2 Metodologas Emergentes de Desarrollo de Software
Una metodologa de desarrollo de software se refiere a un framework (Modelo de trabajo) 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:
MORCH Systems

* 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:
Dcada
1970s
1970s
1980s
1980s
1980s
1990s
1990s
1990s
1990s
1990s
1990s
Nvo. Milenio
Nvo. Milenio
Nvo. Milenio
Nvo. Milenio
Modelo:
Programacin estructurada sol
Programacin estructurada Jackson
Structured Systems Analysis and Design Methodology (SSADM)
Structured Analysis and Design Technique (SADT)
Ingeniera de la informacin (IE/IEM)
Rapid application development (RAD)
Programacin orientada a objetos (OOP)
Virtual finite state machine (VFSM)
Dynamic Systems Development Method desarrollado en UK
Scrum (desarrollo)
Rational Unified Process (RUP)
Extreme Programming(XP)
Enterprise Unified Process (EUP) extensiones RUP
Constructionist design methodology (CDM)
Unified Process (AUP)
Ao:
1969
1975
1980
1980
1981
1991
1990
1990
1995
1990
1999
1999
2002
2004
2005
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:
Enfoque:
Ao:
Modelo en cascada o Ciclo de vida clsico Framework lineal secuencial
1970.
MORCH Systems

Modelo:
Prototipado
Incremental:
Espiral:
RAD: Rapid Application Development
Enfoque:
Framework iterativo.
Combinacin de framework lineal e iterativo.
Combinacin de framework lineal e iterativo.
Framework iterativo.
Ao:
1988.
1980
1986
1980
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.
Es un refinamiento altamente influenciado del modelo de etapas. Existe, para este modelo, un reconocimiento de
los ciclos de retroalimentacin entre etapas, y una gua para confinar las retroalimentaciones a las etapas sucesivas
con el objetivo de minimizar el costo del retrabajo involucrado en retroalimentaciones a travs de muchas etapas.
Las ventajas que presentan tanto el modelo de etapas y de cascada tiene relacin con la idea de postular un marco
de trabajo claro, que reconoce y define las actividades involucradas en el desarrollo de software, permitiendo
establecer relaciones de cooperacin entre ellas. Corresponden, tambin, a los mtodos ms usados en desarrollo de
software y que han sido exitosos durante dcadas tanto en el desarrollo de grandes sistemas como en el de
pequeos.
Tanto el modelo de etapas como el de cascada, presentan algunas dificultades comunes. Por ejemplo, la
especificacin de los problemas. Ambos mtodos asumen que el diseador puede distinguir entre lo que el sistema
debe hacer y como el sistema lo har; pero algunos problemas no pueden ser divididos tan fcilmente para ser
atacados desde este prisma.
Por otro lado, generalmente los requerimientos son especificados al inicio del proyecto y, paradojalmente, cuando
se tiene la claridad suficiente para definir precisamente lo que se quiere es cuando se est en las ltimas etapas del
proyecto. Esto es consecuencia, en general, de que los clientes no estn familiarizados con la tecnologa, con lo
cual producen requerimientos muy vagos, que son interpretados arbitrariamente por los desarrolladores.
Otro factor importante es que estos mtodos asumen que una vez que los requerimientos han sido definidos
entonces ellos no cambiarn ms. Pero, dependiendo de la complejidad del proyecto, la implementacin final
puede ocurrir meses o, eventualmente, aos despus de que los requerimientos han sido especificados; as, en las
ltimas etapas del proyecto, los requerimientos pueden haber cambiado.
Existira un nfasis en la elaboracin de documentos. El sistema completo es descrito y registrado en papel, cada
etapa produce cierta cantidad de documentos. Esto lleva a que, por ejemplo, para sistemas complejos las
especificaciones de requerimientos pueden ser de cientos de pginas, explicando todos u cada uno de los detalles
del sistema. Y es difcil poder visualizar a priori, desde ste volumen de papel, las caractersticas del sistema.
Por ltimo, se ha detectado que el enfoque lineal de estos mtodos no sera el adecuado para reflejar el proceso de
desarrollo de software. Esto explica que se diga que para algunos proyectos el modelo clsico los lleva a seguir las
etapas en orden incorrecto. Ms an, es posible que todas las etapas del proyecto, estn comprimidas dentro de
MORCH Systems

cada una. Como se ha podido observar, la especificacin de mtodos ms acabados para el desarrollo de software
no logra superar el problema de la distancia entre la visin del usuario y la del desarrollador, ya que no se ha
buscado resolver ese problema, sino que las soluciones se centraron principalmente en la divisin de las tareas con
miras al control de las mismas, lo que si bien soluciona el problema de especificar y luego programar, crea otros,
como el presentado en el prrafo anterior, en que no todos los problemas podran ser abordados desde una misma
perspectiva de orden en las etapas.
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.
Problemas:
1. No siempre se sigue el flujo secuencial.
2. Es difcil tener un 100% de los requisitos al inicio.
3. El cliente debe tener paciencia. Los primeros resultados sern hasta que ya este operando el sistema.
Etapas del modelo de cascada:

a) Ingeniera y anlisis del sistema.
Interrelacin con hardware, personas, bases de
datos. (Documentar cada paso.)
b) Anlisis de los requisitos del software.
Hay que comprender el mbito de la
informacin del software, as como la funcin,
rendimiento y las interfases requeridas.
el
c) Diseo.
La estructura de los datos, la arquitectura del sw,
detalle procedimental, y la caracterizacin de la
interfase.
MORCH Systems
el

d) Codificacin.
Traducir el diseo para que lo entienda la mquina.
e) Prueba.
Cuando ya se ha generado el cdigo.
f) Mantenimiento.
El software sufrir cambios despus de que se entregue al cliente.
El prototipado
El prototipado es el framework de actividades dedicada al desarrollo de software prototipo, es decir, versiones
incompletas del software a desarrollar.
Este es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos
aspectos de l y as clarificar los requerimientos... Un prototipo es una representacin de un sistema, aunque no es
un sistema completo, posee las caractersticas del sistema final o parte de ellas".
Las fases que comprende el mtodo de desarrollo orientado a prototipos seran:
a) Investigacin preliminar
Las metas principales de esta fase son: determinar el problema y su mbito, la importancia y sus efectos
potenciales sobre la organizacin por una parte y, por otro lado, identificar una idea general de la solucin para
realizar un estudio de factibilidad que determine la factibilidad de una solucin software.
b) Definicin de los requerimientos del sistema
El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relacin al
proyecto bajo desarrollo. Esta etapa es la ms importante de
todo el ciclo de vida, es aqu donde el desarrollador determina
los requisitos mediante la construccin, demostracin y
retroalimentaciones del prototipo. Por lo mismo esta etapa ser
revisada con ms detalle luego de esta descripcin.
c) Diseo tcnico
Durante la construccin del prototipo, el desarrollador ha
obviado el diseo detallado. El sistema debe ser entonces
rediseado y documentado segn los estndares de la
organizacin y para ayudar a las mantenciones futuras. Esta
fase de diseo tcnico tiene dos etapas: por un lado, la
produccin de una documentacin de diseo que especifica y
describe la estructura del software, el control de flujo, las
interfaces de usuario y las funciones y, como segunda etapa, la
produccin de todo lo requerido para promover cualquier
mantencin futura del software.
MORCH Systems

d) Programacin y prueba
Es donde los cambios identificados en el diseo tcnico son implementados y probados para asegurar la correccin
y completitud de los mismos con respecto a los requerimientos.
e) Operacin y mantencin
La instalacin del sistema en ambiente de explotacin, en este caso, resulta de menor complejidad, ya que se
supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Adems, la mantencin
tambin debera ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitira una
mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reduciran. Si eventualmente se
requiriese una mantencin entonces el proceso de prototipado es repetido y se definir un nuevo conjunto de
requerimientos.
La fase ms importante corresponde a la definicin de requerimientos, la cual correspondera a un proceso que
busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definicin de
requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:
f) Anlisis grueso y especificacin
El propsito de esta subfase es desarrollar un diseo bsico para el prototipo inicial.
g) Diseo y construccin
El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un
sistema con la mxima funcionalidad, poniendo nfasis en la interface del usuario.
h) Evaluacin
Esta etapa tiene dos propsitos: extraer a los usuarios la especificacin de los requerimientos adicionales del
sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definicin de requerimientos
del sistema. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el
prototipo antes de la siguiente evaluacin. El prototipo es repetidamente modificado y evaluado hasta que todos los
requerimientos del sistema han sido satisfechos. El proceso de evaluacin puede ser dividido en cuatro pasos
separados: preparacin, demostracin, uso del prototipo y discusin de comentarios. En esta fase se decide si el
prototipo es aceptado o modificado.
i) Modificacin
Esto ocurre cuando la definicin de requerimientos del sistema es alterada en la subfase de evaluacin. El
desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.
g) Trmino
Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relacin a
aspectos de calidad y de representacin de el sistema.
En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificacin de
requerimientos est claramente diferenciada de las dems. Es en ella donde se utiliza el prototipado, ya que permite
entregar al usuario lo que sera una visin la solucin final en etapas tempranas del desarrollo, reduciendo
tempranamente los costos de especificaciones errneas.
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:
L.S.C.A. Ral10
Monforte Chuln
MORCH Systems

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 mini-Cascada 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.
Los riesgos asociados con el desarrollo de sistemas
largos y complejos son enormes. Una forma de
reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles posteriores. El
desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del
sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el
sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no
demanda una forma especfica de observar el desarrollo de algn otro incremento. As, el modelo cascada puede
ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande.
Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para
los niveles subsiguientes son correctos.
Si un error importante es realizado, slo la ltima iteracin necesita ser descartada.
Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las
probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.
L.S.C.A. Ral11
Monforte Chuln
MORCH Systems

Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo
incremento.
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.
El modelo Espiral de Boehm para Ingeniera de
Software agrupa las mejores caractersticas del
modelo del ciclo de vida clsico y de prototipos.
Pero tambin agrega nuevas funciones que no estn
incluidas en los otros modelos, como el anlisis de
riesgo. El modelo espiral define cuatro actividades principales para el ciclo de vida.
I. Planificacin
La determinacin de los objetivos del proyecto, alternativas y restricciones.
II. Anlisis de Riesgo
El anlisis de alternativas y la identificacin y solucin de riesgos.
III. Ingeniera
Desarrollo del producto.
IV. Evaluacin del cliente
El asentimiento de los resultados de la ingeniera.
El modelo es representado por una espiral dividida en cuatro cuadrantes, en que cada uno describe las actividades
mencionadas anteriormente. El modelo espiral utiliza un esquema de desarrollo iterativo donde la primera iteracin
comienza en el centro del crculo e, incrementalmente, se va desplazando hacia afuera. Las siguientes iteraciones
sucesivas son versiones ms completas del software que est siendo construido. Al principio de cada iteracin del
ciclo de vida se hace un anlisis de riesgo, mientras, por el otro extremo, la revisin del proyecto se realiza al final
de la iteracin. As, se puede contrarrestar cualquier riesgo observado mediante las acciones adecuadas en el
tiempo preciso.
L.S.C.A. Ral12
Monforte Chuln
MORCH Systems

El modelo espiral es visto como un enfoque ms realista para el desarrollo de grandes sistemas de software. Usa un
mtodo evolucionario para desarrollo y prototipos como una tcnica de reduccin de riesgo (pese a que los
prototipos pueden ser usados en cualquier etapa dentro del ciclo de vida). Tambin utiliza el enfoque de
sistematizacin y el 'desarrollo en etapas' del ciclo de vida clsico, pero, con la diferencia que todos estn
incorporados dentro del esquema iterativo planteado por el modelo espiral.
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.
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. El modelo iterativamente realiza la produccin de
software, en lugar de enfocarse en un prototipo y produce la documentacin necesaria para facilitar el futuro
desarrollo y mantenimiento.
El enfoque DRA comprende las siguientes fases:
a) Modelado de gestin:
El flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas:
Qu informacin conduce el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la
informacin? Quin la proceso?
b) Modelado de datos:
El flujo de informacin definido como parte de la fase de modelado de gestin se refina como un conjunto de
objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de cada uno
de los objetos y las relaciones entre estos objetos.
L.S.C.A. Ral13
Monforte Chuln
MORCH Systems

c) Modelado de proceso:
Los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de informacin
necesario para implementar una funcin de gestin. Las
descripciones del proceso se crean para aadir, modificar,
suprimir, o recuperar un objeto de datos. Es la comunicacin entre
los objetos.
d) Generacin de aplicaciones:
El DRA asume la utilizacin de tcnicas de cuarta generacin. En
lugar de crear software con lenguajes de programacin de tercera
generacin, el proceso DRA trabaja para volver a utilizar
componentes de programas ya existentes (cuando es posible) o a
crear componentes reutilizables (cuando sea necesario). En todos
los casos se utilizan herramientas automticas para facilitar la
construccin del software.
e) Pruebas de entrega:
Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos de los componentes de los
programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.
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.
Anlisis y diseo orientado a objetos (ADOO).
El ADOO es un enfoque de la ingeniera de software que modela un sistema como un grupo de objetos que
interactan entre s. Este enfoque representa un dominio en trminos de conceptos compuestos por verbos y
sustantivos, clasificados de acuerdo a su dependencia funcional. En este mtodo de anlisis y diseo se crea un
conjunto de modelos utilizando una notacin acordada como, por ejemplo, el lenguaje unificado de modelado
(UML). ADOO aplica tcnicas de modelado de objetos para analizar los requerimientos para un contexto - por
ejemplo, un sistema de negocio, un conjunto de mdulos de software - y para disear una solucin para mejorar los
procesos involucrados. No est restringido al diseo de programas de computadora, sino que cubre sistemas
enteros de distinto tipo. Las metodologas de anlisis y diseo ms modernas son casos de uso guiados a travs de
requerimientos, diseo, implementacin, pruebas, y despliegue.
El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estndar usado en anlisis
L.S.C.A. Ral14
Monforte Chuln
MORCH Systems

Pasos del modelo de desarrollo de software orientado a objetos:
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.
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 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.
L.S.C.A. Ral15
Monforte Chuln
MORCH Systems

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.
Desarrollo
Metodologas pesadas.
Una metodologa de desarrollo de software Orientado a Objetos consta de:
Conceptos y diagramas.
Etapas y definicin de entregas en cada una de ellas.
Actividades y recomendaciones.
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
Grady Booch
Object
Oriented
Design Anlisis de Requerimientos
Oriented
with
Applications Anlisis
de
Dominio
Design
Benjamming
Cummings Diseo
1991
Objectory
Ivar Jacobson
Object-Oriented
Software Anlisis de Requerimientos
Enginnering
Anlisis
de
Robustez
A Use Case Driven Approach Diseo
Addison-Wesley
Implementacin
1992
Pruebas
Object
James Rumbaugh et. al.
Object Oriented Modeling and Anlisis
Modeling
Design
Diseo
del
Sistema
Technique
Prentice
Hall Diseo
de
Objetos
1991
Implementacin
Estas tres metodologas van a ser fusionadas a finales de 1997 en una sola, basada en la notacin UML.
L.S.C.A. Ral16
Monforte Chuln
MORCH Systems

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.
* 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.
L.S.C.A. Ral17
Monforte Chuln
MORCH Systems

1.5. El Lenguaje de Modelado Unificado UML
Por que nace el UML? La falta de estandarizacin en la manera de representar grficamente un modelo, un
lenguaje no slo para comunicar las ideas a otros desarrolladores sino tambin para servir de apoyo en los procesos
de anlisis de un problema. Se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language).
UML.
Quienes y como crearon el UML? El lenguaje UML comenz, cuando Rumbaugh se uni a la compaa Rational
fundada por Booch, para unificar dos mtodos que haban desarrollado: el mtodo Booch y el OMT (Object
Modelling Tool ). En octubre de 1995, Jacobson, se uni a Rational y la colaboracin de otras empresas para que
aportaran sus ideas. Condujeron a la definicin de la primera versin de UML. El 14 de noviembre de 1997 cuando
el Grupo Administrador de Objetos (Object Management Group, OMG) public como estndar la versin 1.1 del
Lenguaje Unificado de Modelado (Unified Modeling Language, UML).
En que se centra el UML? UML es un lenguaje, que proporciona un vocabulario y unas reglas para permitir una
comunicacin. En este caso, este lenguaje se centra en la representacin grfica de un sistema. Se puede aplicar en
el desarrollo de software entregando gran variedad de formas para dar soporte a una metodologa de desarrollo de
software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o
proceso usar.
Los elementos de UML se clasifican en estructurales (Clases, interfaces. Colaboraciones, casos de uso, clases
activas, componentes y nodos), de comportamiento (interacciones y mquinas de estado), de agrupacin (paquetes)
y de anotacin (notas). A su vez, hay cuatro tipos de relaciones: De Dependencia, de asociacin, de agrupacin y
de realizacin. Para construir un plano de software que tenga sentido, lo que se hace es combinar los elementos
estructurales con sus respectivas relaciones, segn sea el caso, obteniendo como resultado uno de los nueve
diagramas que existen en UML, a saber: De clases, De objetos, de casos de uso, de secuencia, de colaboracin, de
estados, de actividades, de componentes y de despliegue.
UML nos indica cmo crear y leer los modelos, pero no dice cmo crearlos. Esto ltimo es el objetivo de las
metodologas de desarrollo.
Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:
Visualizar: UML permite expresar de una forma grfica un sistema de forma que otro lo puede entender.
Especificar: UML permite especificar cules son las caractersticas de un sistema antes de su construccin.
Construir: A partir de los modelos especificados se pueden construir los sistemas diseados.
Documentar: Los propios elementos grficos sirven como documentacin del sistema desarrollado que pueden
servir para su futura revisin.
Aunque UML est pensado para modelar sistemas complejos con gran cantidad de software, el lenguaje es los
suficientemente expresivo como para modelar sistemas que no son informticos, como flujos de trabajo (workflow)
en una empresa, diseo de la estructura de una organizacin y por supuesto, en el diseo de hardware.
Un modelo UML esta compuesto por tres clases de bloques de construccin:
Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.)
Relaciones: relacionan los elementos entre s.
Diagramas: Son colecciones de elementos con sus relaciones.
L.S.C.A. Ral18
Monforte Chuln
MORCH Systems

Un Diagrama es la representacin grfica de un conjunto de elementos con sus relaciones. UML ofrece una amplia
variedad de diagramas para visualizar el sistema desde varias perspectivas.
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado.
* Diagrama de clases.
* Diagrama de componentes.
* Diagrama de objetos.
Diagrama de estructura compuesta. * Diagrama de despliegue.
* Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado.
* Diagrama de actividades.
* Diagrama de casos de uso.
* Diagrama de estados
Los Diagramas de Interaccin son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de
control y de datos entre los elementos del sistema modelado.
* Diagrama de secuencia
* Diagrama de comunicacin, que es una versin simplificada del Diagrama de colaboracin
* Diagrama de tiempos
* Diagrama global de interacciones o Diagrama de vista de interaccin
Lema:
El mejor amigo del estudiante es el conocimiento, pues en el encontraras que hacer en el maana. Y recuerda un licenciado no
es una copia, es original y se atreve a cambiar una realidad, no importa el tiempo o el espacio, todo es posible mientras creas
que es as.
Gracias a Dios: Ya vas hacer profesionista, ser profesional es parte de una mejor calidad de vida para ti y para toda tu
familia, lograrlo es una gran satisfaccin de manera espiritual, emocional, social y laboral; bscalo, esfurzate y disfrtalo; y
veras que ser profesionista es excelentemente profesional.
MORCH Systems.
L.S.C.A. Ral19
Monforte Chuln
MORCH Systems

Unidad 1, El Modelo Del Proceso Del Software

Cargado por

Copyright:

Formatos disponibles

Unidad 1, El Modelo Del Proceso Del Software

Cargado por

Información del documento

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

Unidad 1, El Modelo Del Proceso Del Software

Cargado por

Copyright:

Formatos disponibles

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica