Captulo 1

Introduccin a los sistemas

Anlisis y diseo 1

Introduccin 1

El ciclo de vida de desarrollo de sistemas 2

Planificacin 3

Anlisis 3

Diseo 4

Implementacin 4

Metodologas de desarrollo de sistemas 5

Diseo estructurado 6

Desarrollo rpido de aplicaciones (RAD) 8

Desarrollo gil 12

Seleccionar el desarrollo apropiado

Metodologa 15

Funciones y habilidades tpicas del analista de sistemas 17

Analista de negocios 18

Analista de Sistemas 18

Analista de Infraestructura 18

Analista de Gestin del Cambio 19

Gerente de proyecto 19

Caractersticas Bsicas de Orientado a Objetos

Sistemas 19

Clases y objetos 19

Mtodos y mensajes 20

Encapsulacin e informacin oculta 20

Herencia 21

Polimorfismo y unin dinmica 22

Anlisis de Sistemas Orientado a Objetos

y Diseo (OOSAD) 23

Uso-Case Driven 24
Centrado en la arquitectura 24

Iterativo e Incremental 24

Beneficios de los sistemas orientados a objetos

Anlisis y diseo 25

El proceso unificado 25

Fases 26

Workfl ows 28

Extensiones al proceso Unifi ed 30

El lenguaje de modelado unificado 34

aplicando los conceptos en patterson

superstore 36

Revisin del captulo 36

El Captulo 1 presenta el ciclo de vida de desarrollo de sistemas (SDLC), el fourphase

fundamental

modelo (planificacin, anlisis, diseo e implementacin) comn a toda la informacin

proyectos de desarrollo de sistemas. Describe la evolucin de las metodologas de desarrollo

de sistemas

y discute los roles y las habilidades requeridas de un analista de sistemas. El captulo entonces

resume las caractersticas bsicas de los sistemas orientados a objetos y los fundamentos de

anlisis y diseo de sistemas orientados a objetos y se cierra con una descripcin de Unifi ed

Proceso y sus extensiones y el lenguaje de modelado unificado.

OBJETIVOS

Comprender el ciclo de vida de desarrollo de sistemas fundamentales y sus cuatro fases

Comprender la evolucin de las metodologas de desarrollo de sistemas

Estar familiarizado con los diferentes roles desempeados y las habilidades de un analista de
sistemas

Familiarcese con las caractersticas bsicas de los sistemas orientados a objetos

Familiarizarse con los principios fundamentales del anlisis de sistemas orientados a objetos

y diseo

Familiarcese con el proceso unificado, sus extensiones y el modelado unificado.

Idioma

INTRODUCCIN
El ciclo de vida de desarrollo de sistemas (SDLC) es el proceso de comprender cmo una
informacin

El sistema (IS) puede soportar las necesidades del negocio diseando un sistema,
construyndolo y

entregndolo a los usuarios. Si ha tomado una clase de programacin o ha programado en

el tuyo, esto probablemente suena bastante simple. Lamentablemente, no lo es. Una encuesta
de 1996 por

el Grupo Standish encontr que el 42 por ciento de todos los proyectos de SI corporativos
fueron abandonados

antes de la finalizacin Un estudio similar realizado en 1996 por la Oficina General de

Contabilidad

encontr que el 53 por ciento de todos los proyectos de SI del gobierno de EE. UU. fueron
abandonados. Desafortunadamente,

muchos de los sistemas que no se abandonan se entregan a los usuarios significativamente

tarde,

cuestan mucho ms de lo planeado, y tienen menos caractersticas de las originalmente

planeadas. Por ejemplo,

IAG Consulting informa que el 80 por ciento de los proyectos fueron a lo largo del tiempo, el 72
por ciento

estaban por encima del presupuesto, y el 55 por ciento contena menos de la funcionalidad
completa; Panorama

Consulting Solutions informa que el 54 por ciento de los proyectos de ERP fueron a lo largo del
tiempo, el 56 por ciento

superaron el presupuesto, y el 48 por ciento entreg menos del 50 por ciento de los beneficios
iniciales;

y un estudio de IBM informa que el 59 por ciento de los proyectos omitieron una o ms de las
veces,

dentro del presupuesto y las restricciones de calidad.1 Aunque nos gustara promover este
libro como

una bala de plata que te mantendr alejado de los fracasos de IS, admitimos fcilmente que
una bala de plata que

garantiza que el xito en el desarrollo de IS simplemente no existe. En cambio, este libro te

proporciona

con varios conceptos fundamentales y muchas tcnicas prcticas que puedes usar para

mejorar la probabilidad de xito

La persona clave en el SDLC es el analista de sistemas, que analiza la situacin comercial,

Identifica oportunidades para mejoras y disea un sistema de informacin para implementar

ellos. Ser un analista de sistemas es uno de los trabajos ms interesantes, emocionantes y
desafiantes

alrededor. Los analistas de sistemas trabajan con una variedad de personas y aprenden cmo
hacen negocios.

Especficamente, trabajan con un equipo de analistas de sistemas, programadores y otros en

un campo comn.

misin. Los analistas de sistemas sienten la satisfaccin de ver los sistemas que disearon y

desarrollados tienen un impacto comercial significativo, sabiendo que aportaron habilidades

nicas para

hacer que eso suceda

Sin embargo, el objetivo principal de un analista de sistemas no es crear un sistema

maravilloso;

en cambio, es para crear valor para la organizacin, lo que para la mayora de las empresas
significa

aumentar los beneficios (las agencias gubernamentales y las organizaciones sin fines de lucro
miden el valor)

diferentemente). Muchos sistemas fallidos han sido abandonados porque los analistas
intentaron construir un

sistema maravilloso sin entender claramente cmo el sistema encajara con el de una
organizacin

objetivos, procesos comerciales actuales y otros sistemas de informacin para proporcionar

valor.

Una inversin en un sistema de informacin es como cualquier otra inversin. El objetivo no es

adquirir la herramienta, porque la herramienta es simplemente un medio para un fin; el

objetivo es habilitar el

organizacin para realizar un mejor trabajo para que pueda obtener mayores beneficios o
servir a sus constituyentes

ms eficazmente.

Este libro presenta las habilidades fundamentales que un analista de sistemas necesita. Este es
un libro pragmtico

discute las mejores prcticas en el desarrollo de sistemas; no presenta una encuesta general
de sistemas

desarrollo que cubre todo sobre el tema. Por definicin, los analistas de sistemas hacen cosas

y desafiar la forma actual en que las organizaciones trabajan. Para aprovechar al mximo este
libro,

necesitar aplicar activamente a su propio proyecto de desarrollo de sistemas las ideas y

conceptos en
los ejemplos. Este libro lo gua a travs de todos los pasos para brindar una informacin
exitosa

sistema. Cuando termine el libro, no ser un analista experto, pero estar

listo para comenzar a construir sistemas de verdad

EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS

De muchas maneras, construir un sistema de informacin es similar a construir una casa.

Primero, la casa

(o el sistema de informacin) comienza con una idea bsica. En segundo lugar, esta idea se
transforma en una

dibujo simple que se muestra al cliente y se refina (a menudo a travs de varios dibujos,

cada uno mejorando el ltimo) hasta que el cliente acepte que la imagen muestra lo que l o
ella

quiere. Adems, se ha diseado un conjunto de planos que presenta informacin mucho ms

detallada sobre

la casa (por ejemplo, el tipo de grifos de agua o donde se colocarn las tomas telefnicas).
Finalmente,

la casa est construida siguiendo los planos, a menudo con algunos cambios dirigidos por el
cliente

como la casa est erigida.

El SDLC tiene un conjunto similar de cuatro fases fundamentales: planificacin, anlisis, diseo
y

implementacin. Los diferentes proyectos podran enfatizar diferentes partes del SDLC o
acercarse al

SDLC fases de diferentes maneras, pero todos los proyectos tienen elementos de estas cuatro
fases. Cada fase es

se compone de una serie de pasos, que se basan en tcnicas que producen entregables
(especfi

documentos y archivos que proporcionan comprensin sobre el proyecto).

Para obtener ms informacin sobre el problema, consulte Capers Jones, Patterns of Soft
ware System Failure and Success (Londres:

International Thompson Computer Press, 1996); KeithEllis, Business Analysis Benchmark: el

impacto de los negocios

Requisitos para el xito de los proyectos de tecnologa (2008). Obtenido en mayo de 2014 de
IAG Consulting, www.iag.biz;

H. H. Jorgensen, L. Owen y A. Neus, Making Change Work (2008). Obtenido en mayo de 2014
de IBM, www.ibm.
com; Panorama Consulting Solutions, Informe de ERP 2012 (2012). Obtenido en mayo de
2014 de Panorama- Consulting.com.

Por ejemplo, al solicitar la admisin a una universidad, todos los estudiantes pasan por el
mismo

fases: recopilacin, aplicacin y aceptacin de informacin. Cada una de estas fases tiene
pasos; para

ejemplo, la recopilacin de informacin incluye pasos como buscar escuelas, solicitar

informacin,

y leyendo folletos. Los estudiantes luego usan tcnicas (por ejemplo, bsqueda en Internet)
que

se puede aplicar a los pasos (por ejemplo, solicitar informacin) para crear entregables (por
ejemplo, evaluaciones

de diferentes aspectos de las universidades).

En muchos proyectos, las fases y los pasos del SDLC avanzan en una ruta lgica desde el inicio
hasta el final.

En otros proyectos, los equipos del proyecto se mueven por los pasos de forma consecutiva,
incremental,

iterativamente, o en otros patrones. En esta seccin, describimos las fases, las acciones y
algunas

de las tcnicas que se utilizan para llevar a cabo los pasos en un nivel muy alto.

Por ahora, hay dos puntos importantes para entender sobre el SDLC. Primero, deberas

tener una idea general de las fases y los pasos a travs de los cuales se mueven los proyectos
de SI y algunos de los

tcnicas que producen ciertos entregables. En segundo lugar, es importante entender que el

SDLC es un proceso de refinamiento gradual. Los entregables producidos en la fase de anlisis

proporcionan

una idea general de la forma del nuevo sistema. Estos productos se usan como entrada al

fase de diseo, que luego los refinancia para producir un conjunto de entregables que describe
en gran medida

trminos ms detallados exactamente cmo se construir el sistema. Estos productos, a su

vez, se usan

en la fase de implementacin para producir el sistema real. Cada fase refina y elabora

en el trabajo hecho previamente.

Planificacin

La fase de planificacin es el proceso fundamental para comprender por qu un sistema de

informacin
debe construirse y determinar cmo el equipo del proyecto construir. Tiene

dos pasos:

1. Durante el inicio del proyecto, se identifica el valor comercial del sistema para la
organizacin:

Cmo reducir los costos o aumentar los ingresos? La mayora de las ideas para nuevos
sistemas provienen de

fuera del rea de IS (por ejemplo, del departamento de marketing, departamento de

contabilidad) en

la forma de una solicitud de sistema. Una solicitud de sistema presenta un breve resumen de
un negocio

necesidad, y explica cmo un sistema que respalda la necesidad crear valor comercial.

El departamento de SI trabaja en conjunto con la persona o departamento que gener el

solicitud (llamada el patrocinador del proyecto) para realizar un anlisis de viabilidad.

La solicitud del sistema y el anlisis de viabilidad se presentan a un sistema de informacin

comit de aprobacin (a veces llamado comit de direccin), que decide

si el proyecto debe llevarse a cabo.

2. Una vez que se aprueba el proyecto, entra en la administracin del proyecto. Durante la
gestin del proyecto,

el gerente del proyecto crea un plan de trabajo, personal del proyecto y pone tcnicas

en su lugar para ayudar al equipo del proyecto a controlar y dirigir el proyecto

todo el SDLC. El producto para la gestin del proyecto es un plan de proyecto, que

describe cmo el equipo del proyecto desarrollar el sistema.

Anlisis

La fase de anlisis responde a las preguntas de quin utilizar el sistema, qu har el sistema

hacer, y dnde y cundo ser utilizado. Durante esta fase, el equipo del proyecto investiga
cualquier

sistema (s) actual (es), identifica oportunidades de mejora y desarrolla un concepto para el

nuevo sistema.

Th es fase tiene tres pasos:

1. Se desarrolla una estrategia de anlisis para guiar los esfuerzos del equipo del proyecto. Tal
estrategia

generalmente incluye un anlisis del sistema actual (llamado el sistema tal como est) y su

problemas y luego formas de disear un nuevo sistema (llamado el sistema futuro).

El siguiente paso es reunir los requisitos (por ejemplo, a travs de entrevistas o cuestionarios).
El anlisis de esta informacin, junto con los aportes del proyecto

patrocinador y muchas otras personas-conduce al desarrollo de un concepto para un nuevo

sistema. El concepto de sistema se usa luego como base para desarrollar un conjunto de
negocios

modelos de anlisis, que describen cmo funcionar la empresa si el nuevo sistema

es desarrollado.

3. Los anlisis, el concepto del sistema y los modelos se combinan en un documento llamado

la propuesta del sistema, que se presenta al patrocinador del proyecto y otra decisin clave

creadores (por ejemplo, miembros del comit de aprobacin) que deciden si el

proyecto debe seguir avanzando.

La propuesta del sistema es el producto inicial que describe qu requisitos comerciales

el nuevo sistema debera cumplir. Porque es realmente el primer paso en el diseo del nuevo
sistema,

algunos expertos argumentan que es inapropiado usar el trmino "anlisis" como el nombre
para esto

fase; algunos argumentan que un mejor nombre sera "anlisis y diseo inicial". La mayora de
las organizaciones

no obstante, contine usando el anlisis de nombre para esta fase, por lo que tambin lo
usamos en este libro. Slo

Tenga en cuenta que el producto de la fase de anlisis es a la vez un anlisis y un alto nivel.

diseo inicial para el nuevo sistema.

Diseo

La fase de diseo decide cmo funcionar el sistema, en trminos de hardware, software,

y la infraestructura de red; la interfaz de usuario, formularios e informes; y los programas

especficos,

bases de datos y archivos que sern necesarios. Aunque la mayora de las decisiones
estratgicas sobre la

sistema se hicieron en el desarrollo del concepto de sistema durante la fase de anlisis, el

los pasos en la fase de diseo determinan exactamente cmo funcionar el sistema. La fase de
diseo

tiene cuatro pasos:

1. La estrategia de diseo se desarrolla por primera vez. Aclara si el sistema ser desarrollado

por los propios programadores de la compaa, si el sistema se subcontratar

a otra empresa (generalmente una empresa de consultora), o si la compaa comprar un

paquete de software existente.

2. Esto conduce al desarrollo del diseo de arquitectura bsica para el sistema, que

describe el hardware, software y la infraestructura de red que se utilizar. En la mayora

casos, el sistema agregar o cambiar la infraestructura que ya existe en el

organizacin. El diseo de la interfaz especifica cmo los usuarios se movern a travs del
sistema

(por ejemplo, mtodos de navegacin como mens y botones en pantalla) y los formularios

e informa que el sistema usar.

3. Se desarrollan las especifi caciones de la base de datos y del archivo. Esa es la definicin
exacta de qu datos

ser almacenado y donde sern almacenados.

4. El equipo de analistas desarrolla el diseo del programa, que define los programas que

necesita ser escrito y exactamente lo que har cada programa.

Esta es una coleccin de entregas (diseo de arquitectura, diseo de interfaz, especificacin de

bases de datos y archivos,

y diseo del programa) es la especificacin del sistema que se entrega al equipo de

programacin

para la implementacin. Al final de la fase de diseo, el anlisis de viabilidad y el plan del

proyecto son

reexaminado y revisado, y el patrocinador y la aprobacin del proyecto toman otra decisin

comit sobre si terminar el proyecto o continuar.

Implementacin

La fase final en el SDLC es la fase de implementacin, durante la cual el sistema es en realidad

construido (o comprado, en el caso de un diseo de software empaquetado). Th es la fase que

generalmente

recibe la mayor atencin, porque para la mayora de los sistemas es el ms largo y el ms caro

parte del proceso de desarrollo. Th es fase tiene tres pasos:

1. La construccin del sistema es el primer paso. El sistema est construido y probado para
asegurar que

se realiza segn lo diseado. Debido a que el costo de los errores puede ser inmenso, las
pruebas son una de

los pasos ms crticos en la implementacin. La mayora de las organizaciones dan ms tiempo

y

atencin a las pruebas en lugar de escribir los programas en primer lugar.

2. El sistema est instalado. La instalacin es el proceso por el cual se cambia el sistema
anterior

apagado y el nuevo est encendido. Uno de los aspectos ms importantes de la conversin

es el desarrollo de un plan de capacitacin para ensear a los usuarios cmo usar el nuevo
sistema y

ayuda a administrar los cambios causados por el nuevo sistema.

3. El equipo de analistas establece un plan de apoyo para el sistema. Th es plan generalmente

incluye una revisin formal o informal despus de la implementacin, as como una revisin
sistemtica

forma de identificar los cambios mayores y menores necesarios para el sistema.

METODOLOGAS DE DESARROLLO DE SISTEMAS

Una metodologa es un enfoque formal para implementar el SDLC (es decir, es una lista de
pasos

y entregables). Existen muchas metodologas de desarrollo de sistemas diferentes, y cada

uno es nico, basado en el orden y el enfoque que coloca en cada fase del SDLC. Algunas
metodologas

son estndares formales utilizados por las agencias gubernamentales, mientras que otros se
han desarrollado

consultando empresas para vender a los clientes. Muchas organizaciones tienen metodologas
internas que

se han perfeccionado a lo largo de los aos, y explican exactamente cmo debe ser cada fase
del SDLC

ser realizado en esa compaa.

Hay muchas formas de categorizar metodologas. Una forma es mirando si

se enfocan en los procesos comerciales o los datos que respaldan el negocio. Un proceso
centrado

La metodologa enfatiza los modelos de procesos como el ncleo del concepto del sistema. En
la figura 1-1, para

Por ejemplo, las metodologas centradas en el proceso se centraran primero en la definicin

de los procesos (p.

ensamblar los ingredientes del sndwich). Las metodologas centradas en datos enfatizan los
modelos de datos como

ncleo del concepto de sistema. En la Figura 1-1, las metodologas centradas en los datos se
centraran primero en

Definir los contenidos de las reas de almacenamiento (por ejemplo, refrigerador) y cmo se
organizaron los contenidos.
2 Por el contrario, las metodologas orientadas a objetos intentan equilibrar el enfoque entre
procesos

y datos mediante la incorporacin de ambos en un modelo. En la Figura 1-1, estas

metodologas

centrarse primero en definir los elementos principales del sistema (por ejemplo, sndwiches,
almuerzos) y mirar

en los procesos y datos involucrados con cada elemento.

Otro factor importante en la categorizacin de metodologas es la secuencia del SDLC

fases y la cantidad de tiempo y esfuerzo dedicado a cada uno.3 En los primeros das de la
informtica,

los programadores no entendieron la necesidad de metodologas de ciclo de vida formales y

bien planificadas.

Estos tendan a pasar directamente de una fase de planificacin muy simple a la

etapa de construccin de la fase de implementacin; en otras palabras, de una manera muy

difusa, no bien pensada

solicitud de sistema en el cdigo de escritura. Este es el mismo enfoque que a veces

usar al escribir programas para una clase de programacin. Puede funcionar para programas
pequeos que

La metodologa moderna clsica centrada en el proceso es la de Edward Yourdon, Modern

Structured Analysis

(Englewood Cliff, NJ: Yourdon Press, 1989). Un ejemplo de una metodologa centrada en los
datos es la ingeniera de la informacin;

ver James Martin, Information Engineering, vols. 1-3 (Englewood Cliff, NJ: Prentice Hall,
1989). Un ampliamente

la metodologa estandarizada no orientada a objetos aceptada que equilibra procesos y

datos es IDEF; ver FIPS 183,

Definicin de Integracin para Modelado de Funciones, Publicaciones de Estndares

Federales de Procesamiento de Informacin, Departamento de los EE. UU.

de Comercio, 1993.

3 Una buena referencia para comparar metodologas de desarrollo de sistemas es Steve

McConnell, Rapid Development

(Redmond, WA: Microsoft Press, 1996).

FIGURA 1-1 Un modelo de comportamiento simple para hacer un almuerzo simple

requieren solo un programador, pero si los requisitos son complejos o confusos, es posible que
se pierden aspectos importantes del problema y tienen que comenzar de nuevo, descartando
parte de

el programa (y el tiempo y el esfuerzo empleados en escribirlo). Este enfoque tambin hace

que el trabajo en equipo

Difcil porque los miembros tienen poca idea sobre lo que se debe lograr y cmo

trabajar juntos para producir un producto final. En esta seccin, describimos tres clases
diferentes de

metodologas de desarrollo de sistemas: diseo estructurado, desarrollo rpido de

aplicaciones y

desarrollo gil.

Diseo estructurado

La primera categora de metodologas de desarrollo de sistemas se llama diseo estructurado.

Estas metodologas se volvieron dominantes en la dcada de 1980, reemplazando a las

anteriores

Una cascada

Basado en desarrollo

Metodologa

enfoque indisciplinado. Las metodologas de diseo estructurado adoptan un paso a paso

formal

enfoque al SDLC que se mueve lgicamente de una fase a la siguiente. Numerosos procesos

metodologas centradas y centradas en datos siguen el enfoque bsico de los dos

estructurados

las categoras de diseo que se describen a continuacin.

Desarrollo de la cascada La metodologa original de diseo estructurado (todava se usa hoy en

da) es

desarrollo de cascada Con las metodologas basadas en el desarrollo de cascadas, los analistas
y

los usuarios proceden en secuencia de una fase a la siguiente (vea la Figura 1-2). Los resultados
principales

para cada fase suelen ser muy largos (a menudo en cientos de pginas de longitud) y se
presentan a

el patrocinador del proyecto para su aprobacin a medida que el proyecto se mueve de una
fase a otra. Una vez que el patrocinador

aprueba el trabajo que se realiz para una fase, la fase finaliza y comienza la siguiente.
Esta metodologa se conoce como desarrollo en cascada porque avanza desde

fase a fase de la misma manera que una cascada. Aunque es posible retroceder en

el SDLC (por ejemplo, desde el diseo hasta el anlisis), es extremadamente difcil (imagnese
como un

salmn tratando de nadar aguas arriba contra una cascada, como se muestra en la Figura 1-2).

El diseo estructurado tambin introdujo el uso de tcnicas formales de modelado o

diagramacin

para describir los procesos comerciales bsicos y los datos que los respaldan. Tradicional

diseo estructurado utiliza un conjunto de diagramas para representar los procesos y un

conjunto separado de

diagramas para representar datos. Debido a que se usan dos conjuntos de diagramas, el
analista de sistemas debe

decida qu conjunto desarrollar primero y usar como ncleo del sistema: diagramas de
proceso-modelo

o diagramas de modelos de datos.

Las dos ventajas clave del enfoque de cascada de diseo estructurado son que identifica

es los requisitos del sistema mucho antes de que comience la programacin y minimiza los
cambios en el

requisitos a medida que avanza el proyecto. Las dos desventajas clave son que el diseo debe

se especifique completamente antes de que comience la programacin y que transcurra un

largo

finalizacin de la propuesta del sistema en la fase de anlisis y la entrega del sistema

(generalmente

muchos meses o aos). Si el equipo del proyecto no cumple con los requisitos importantes,
costoso

puede ser necesaria una programacin posterior a la implementacin (imagnese tratando de

disear un automvil)

en papel; Cun probable es que recuerde las luces interiores que se encienden cuando las
puertas

abrir o especificar el nmero correcto de vlvulas en el motor?). Un sistema tambin puede

requerir

reelaboracin significativa porque el entorno empresarial ha cambiado desde el momento en

que el

fase de anlisis ocurri.

Desarrollo paralelo La metodologa de desarrollo paralelo intenta abordar el problema

de largas demoras entre la fase de anlisis y la entrega del sistema. En lugar de hacer
diseo e implementacin en secuencia, realiza un diseo general para todo el sistema

y luego divide el proyecto en una serie de subproyectos distintos que se pueden disear y

implementado en paralelo. Una vez que todos los subproyectos estn completos, las piezas
separadas estn integradas

y el sistema se entrega (vea la Figura 1-3).

La principal ventaja de esta metodologa es que puede reducir el tiempo para entregar un

sistema; por lo tanto, hay menos posibilidades de que haya cambios en el entorno empresarial
que provocan retrabajo.

Sin embargo, a veces los subproyectos no son completamente independientes; decisiones de

diseo

hecho en un subproyecto puede afectar a otro, y el final del proyecto puede requerir signifi
cado

esfuerzos de integracin.

Desarrollo rpido de aplicaciones (RAD)

Una segunda categora de metodologas incluye el desarrollo rpido de aplicaciones (RAD)

metodologas. Estas son una clase ms nueva de metodologas de desarrollo de sistemas que
surgieron

en la dcada de 1990 Las metodologas basadas en RAD intentan abordar ambas debilidades
de estructura

disear metodologas ajustando las fases del SDLC para obtener una parte del sistema
desarrollado

rpidamente y en manos de los usuarios. De esta manera, los usuarios pueden comprender
mejor el

sistema y sugerir revisiones que acerquen el sistema a lo que se necesita4.

FIGURA 1-3 Una Metodologa Basada en el Desarrollo Paralelo

Uno de los mejores libros de RAD es Steve McConnell, Rapid Development (Redmond, WA:
Microsoft Press, 1996).

La mayora de las metodologas basadas en RAD recomiendan que los analistas usen tcnicas
especiales

y herramientas informticas para acelerar las fases de anlisis, diseo e implementacin, como

herramientas de ingeniera de software asistidas por computadora (CASE), sesiones de diseo

de aplicaciones conjuntas (JAD),

lenguajes de programacin visual o de cuarta generacin que simplifican y aceleran la

programacin,

y generadores de cdigo que automticamente producen programas a partir de

especificaciones de diseo. Los
combinacin de las fases modificadas de SDLC y el uso de estas herramientas y tcnicas mejora

la velocidad y la calidad del desarrollo de sistemas. Sin embargo, hay un posible problema sutil

con metodologas basadas en RAD: gestin de las expectativas del usuario. Debido al uso de las
herramientas y

tcnicas que pueden mejorar la velocidad y la calidad del desarrollo de sistemas, las
expectativas del usuario

de lo que es posible puede cambiar drsticamente. Como un usuario entiende mejor la

tecnologa de la informacin

(IT), los requisitos de los sistemas tienden a expandirse. Th era menos de un problema cuando
se usa

metodologas que pasaron mucho tiempo documentando a fondo los requisitos.

Desarrollo por fases Una metodologa gradual basada en el desarrollo divide un sistema
general en un

serie de versiones que se desarrollan secuencialmente. La fase de anlisis identifica el sistema

global

concepto, y el equipo del proyecto, los usuarios y el patrocinador del sistema clasifican los
requisitos en

una serie de versiones. Los requisitos ms importantes y fundamentales se incluyen en el

primera versin del sistema. La fase de anlisis luego conduce al diseo e implementacin,
pero

solo con el conjunto de requisitos identificados para la versin 1 (vea la Figura 1-4).

Una vez que se implementa la versin 1, el trabajo comienza en la versin 2. Se realiza un

anlisis adicional

basado en los requisitos previamente identificados y combinado con nuevas ideas y

problemas que surgieron de la experiencia de los usuarios con la versin 1. La versin 2 est
diseada y

implementado, y el trabajo comienza inmediatamente en la prxima versin. Este es un

proceso que contina hasta

el sistema est completo o ya no est en uso.

Las metodologas basadas en el desarrollo en fases tienen la ventaja de obtener rpidamente

una utilidad

sistema en manos de los usuarios. Aunque el sistema no realiza todas las funciones,

los usuarios necesitan al principio, comienza a proporcionar valor comercial antes que si el
sistema se entregara

despus de la finalizacin, como es el caso con la cascada y las metodologas paralelas.

Igualmente,
porque los usuarios comienzan a trabajar con el sistema antes, es ms probable que
identifiquen

requisitos adicionales antes que con situaciones de diseo estructurado.

El mayor inconveniente del desarrollo por fases es que los usuarios comienzan a trabajar con
sistemas que

estn intencionalmente incompletos. Es fundamental identificar las caractersticas ms

importantes y tiles

e incluirlos en la primera versin y administrar las expectativas de los usuarios a lo largo del
camino.

Creacin de prototipos Una metodologa basada en prototipos realiza el anlisis, el diseo y la

implementacin

fases concurrentemente, y las tres fases se realizan repetidamente en un ciclo hasta

el sistema esta completo Con estas metodologas, los conceptos bsicos de anlisis y diseo
son

realizado, y el trabajo comienza de inmediato en un prototipo del sistema, un programa rpido

y sucio

que proporciona una cantidad mnima de funciones. El primer prototipo suele ser la primera
parte del

sistema que se usa. Esto se muestra a los usuarios y al patrocinador del proyecto, quienes
brindan comentarios.

Estos comentarios se utilizan para volver a analizar, redisear y volver a implementar un

segundo prototipo,

que proporciona algunas caractersticas ms. Este proceso contina en un ciclo hasta que los
analistas, los usuarios,

y el patrocinador acepta que el prototipo proporciona suficiente funcionalidad para ser

instalado y utilizado en

la organizacin. Despus de que se instala el prototipo (ahora llamado el "sistema"), se

produce el refinanciamiento

hasta que sea aceptado como el nuevo sistema (vea la Figura 1-5).

La ventaja clave de una metodologa basada en prototipos es que proporciona muy

rpidamente

sistema con el que los usuarios pueden interactuar, incluso si no est listo para una
organizacin generalizada

usar al principio. Los prototipos aseguran a los usuarios que el equipo del proyecto est
trabajando en el sistema

(no hay grandes retrasos en los que los usuarios ven poco progreso), y la creacin de
prototipos ayuda a ms
refinar rpidamente los requisitos reales.

Una metodologa basada en el desarrollo por etapas

Un prototipo basado en Metodologa

El mayor problema con la creacin de prototipos es que su sistema acelerado lanza un desafo

intenta realizar un anlisis cuidadoso y metdico. A menudo, el prototipo sufre un impacto tan
significativo

cambios que muchas decisiones iniciales de diseo se vuelven malas. Th es puede causar
problemas

en el desarrollo de sistemas complejos porque problemas y problemas fundamentales no son

reconocidos

hasta bien entrado el proceso de desarrollo. Imagine construir un automvil y descubrir tarde
en

el proceso de creacin de prototipos que tiene que sacar todo el motor para cambiar el aceite
(porque

nadie pens en la necesidad de cambiar el aceite hasta despus de haber sido conducido
10,000 millas).

Prototipado a la baja Las metodologas basadas en prototipos de rowaway son similares a

las metodologas basadas en prototipos en que incluyen el desarrollo de prototipos; sin

embargo,

Los prototipos desechables se hacen en un punto diferente en el SDLC. Estos prototipos son

utilizado para un propsito muy diferente al que se discuti anteriormente, y tienen una muy
diferente

apariencia (vea la Figura 1-6).

Las metodologas basadas en prototipos desechables tienen un anlisis relativamente

minucioso

fase que se utiliza para recopilar informacin y desarrollar ideas para el concepto del sistema.

Sin embargo, los usuarios pueden no entender completamente muchas de las caractersticas
que sugieren, y

pueden ser problemas tcnicos desafiantes para ser resueltos. Cada uno de estos problemas se
examina analizando,

diseando y construyendo un prototipo de diseo. Un prototipo de diseo no es un sistema

funcional;

es un producto que representa una parte del sistema que necesita un refinamiento adicional, y

contiene solo los detalles suficientes para permitir a los usuarios entender los temas en
consideracin. por
Por ejemplo, supongamos que los usuarios no tienen completamente claro cmo debera
funcionar un sistema de entrada de pedidos.

En este caso, una serie de pantallas de maquetas parece ser un sistema, pero realmente no
hacen nada. O

supongamos que el equipo del proyecto necesita desarrollar un sofisticado programa de

grficos en Java. Los

El equipo podra escribir una parte del programa con datos falsos para asegurarse de que
podran hacer una

programa completo exitosamente.

Un sistema desarrollado usando este tipo de metodologa se basa en varios prototipos de

diseo

durante las fases de anlisis y diseo. Cada uno de los prototipos se utiliza para minimizar el
riesgo

asociado con el sistema al confirmar que los asuntos importantes se entienden antes que el
real

sistema est construido. Una vez que se resuelven los problemas, el proyecto pasa al diseo y
la implementacin.

En este punto, los prototipos de diseo se descartan, lo cual es una diferencia importante

entre estas metodologas y metodologas de prototipos, en la que evolucionan los prototipos

en el sistema final.

FIGURA 1-6 Una metodologa descartada basada en prototipos

Las metodologas basadas en prototipos de rowaway equilibran los beneficios de una buena
planificacin

fases de anlisis y diseo con las ventajas de usar prototipos para refinar problemas clave
antes

un sistema est construido. Puede llevar ms tiempo entregar el sistema final en comparacin
con el prototipado.

metodologas, pero este tipo de metodologa generalmente produce ms estable y confiable

sistemas.

Desarrollo gil5

Una tercera categora de metodologas de desarrollo de sistemas todava est surgiendo hoy:
desarrollo gil.

Todas las metodologas de desarrollo giles se basan en el manifiesto gil y un conjunto de

doce principios. El nfasis del manifiesto es enfocar a los desarrolladores en el trabajo

condiciones de los desarrolladores, el software de trabajo, los clientes y el cambio de

direcciones
requisitos en lugar de centrarse en los procesos de desarrollo de sistemas detallados,
herramientas, todo incluido

documentacin, contratos legales y planes detallados. Esta programacin centrada

las metodologas tienen pocas reglas y prcticas, todas las cuales son bastante fciles de
seguir. Estas metodologas

tpicamente se basan solo en los doce principios del software gil. Estos principios

Incluya lo siguiente:

El software se entrega temprana y continuamente a travs del proceso de desarrollo,

satisfaciendo

el cliente.

Los requisitos cambiantes se adoptan independientemente de cundo ocurren en el

desarrollo

proceso.

Software de trabajo se entrega con frecuencia al cliente.

Los clientes y los desarrolladores trabajan juntos para resolver el problema comercial.

Individuos motivados crean soluciones; proporcionarles las herramientas y el entorno que

necesidad, y confe en ellos para cumplir.

La comunicacin cara a cara dentro del equipo de desarrollo es la ms eficiente y

mtodo eficaz de reunir requisitos.

La medida principal de progreso est funcionando, ejecutando soft ware.

Tanto los clientes como los desarrolladores deben trabajar a un ritmo sostenible. Eso es el

el nivel de trabajo podra mantenerse indefinidamente sin ningn agotamiento del trabajador.

La agilidad aumenta a travs de la atencin tanto a la excelencia tcnica como a un buen

diseo.

La simplicidad, la evitacin del trabajo innecesario, es esencial.

Los equipos autoorganizados desarrollan las mejores arquitecturas, requisitos y diseos.

Los equipos de desarrollo regularmente reflexionan sobre cmo mejorar su desarrollo

procesos.

Con base en estos principios, las metodologas giles se centran en la racionalizacin del
desarrollo del sistema

proceso al eliminar gran parte de la sobrecarga de modelado y documentacin y el tiempo

gastado en esas tareas. En cambio, los proyectos enfatizan el desarrollo simple e iterativo de
aplicaciones.6
Todas las metodologas de desarrollo gil siguen un ciclo simple a travs de las fases
tradicionales de

el proceso de desarrollo de sistemas (vea la Figura 1-7). Prcticamente todas las metodologas
giles se utilizan

junto con tecnologas orientadas a objetos.

5 Estas buenas fuentes de informacin sobre el desarrollo gil y los sistemas orientados a
objetos son S. W. Ambler, Agile

Modelado: prcticas efectivas para la programacin extrema y el proceso unificado (Nueva

York: Wiley, 2002); C. Larman,

Desarrollo gil e Iterativo: Una Gua de Gerentes (Boston: Addison-Wesley, 2004); R. C.

Martin, software Agile Soft

Desarrollo: Principios, patrones y prcticas (Upper Saddle River, NJ: Prentice Hall, 2003).

6 Vase Agile Alliance, www.agilealliance.com.

Sin embargo, las metodologas giles tienen crticas. Una de las principales crticas trata sobre

el entorno empresarial actual, donde gran parte del desarrollo de los sistemas de informacin
reales

est desprotegido, tercerizado y / o subcontratado. Dadas las metodologas giles de

desarrollo

requiriendo la ubicacin conjunta del equipo de desarrollo, esto parece ser una suposicin
muy poco realista.

Una segunda gran crtica es que si el desarrollo gil no se gestiona cuidadosamente, y por

la definicin no es as, el proceso de desarrollo puede convertirse en un enfoque de

prototipado que

esencialmente se convierte en un entorno de "programadores que se han vuelto salvajes"

donde los programadores intentan

para hackear soluciones juntas. Una tercera gran crtica, basada en la falta de documentacin
real

creado durante el desarrollo del software, plantea problemas con respecto a la auditabilidad

de los sistemas que se estn creando Sin documentacin suficiente, ni el sistema ni el

el proceso de desarrollo de sistemas puede estar garantizado. Una cuarta gran crtica se basa
en si

Los enfoques giles pueden ofrecer sistemas grandes de misin crtica.

Incluso con estas crticas, dado el potencial de enfoques giles para abordar el

Atrasos de aplicaciones y para proporcionar soluciones oportunas a muchos problemas de

negocios, giles

enfoques deben ser considerados en algunas circunstancias. Adems, muchas de las tcnicas
alentado atendiendo al propsito subyacente del manifiesto gil y el

un conjunto de doce principios giles es muy til en el desarrollo de sistemas orientados a

objetos. Dos de

los ejemplos ms populares de metodologas de desarrollo giles son la programacin extrema

(XP) y Scrum.

Programacin Extrema7 La programacin extrema (XP) se basa en cuatro valores centrales:

comunicacin,

simplicidad, retroalimentacin y valenta. Estos cuatro valores proporcionan una base que

Los desarrolladores de XP usan para crear cualquier sistema. En primer lugar, los
desarrolladores deben proporcionar una respuesta rpida

para los usuarios finales de manera continua. En segundo lugar, XP requiere que los
desarrolladores sigan al KISS

principio.8 Adems, los desarrolladores deben hacer cambios incrementales para hacer crecer
el sistema, y

no solo deben aceptar el cambio, deben abrazar el cambio. En cuarto lugar, los desarrolladores
deben tener una

primera mentalidad de calidad. XP tambin ayuda a los miembros del equipo a desarrollar sus
propias habilidades. Tres

de los principios clave que XP usa para crear sistemas exitosos son pruebas continuas, simples

codificacin realizada por pares de desarrolladores, e interacciones cercanas con los usuarios
finales para construir sistemas

muy rpidamente.

7 Para ms informacin, ver K. Beck, Programacin Externa Explicada: Embrace Change

(Reading, MA: Addison-

Wesley, 2000); C. Larman, Agile & Iterative Development: A Manager's Guide (Boston:
Addison-Wesley, 2004); METRO.

Lippert, S. Roock y H. Wolf, eXtreme Programming in Action: Experiencias prcticas de Real

World Projects (Nuevo

York: Wiley, 2002); www.extremeprogramming.org.

8 Mantenlo simple, estpido.

Las pruebas y las prcticas de codificacin eficiente son el ncleo de XP. El cdigo se prueba
todos los das y es

colocado en un entorno de prueba integrativo. Si existen errores, el cdigo se restituye hasta

que

est completamente libre de errores.

Un proyecto de XP comienza con historias de usuarios que describen lo que el sistema debe
hacer. Entonces,

programadores codifican en pequeos y simples mdulos y prueban para satisfacer esas

necesidades. Los usuarios son requeridos

estar disponible para aclarar preguntas y problemas a medida que surjan. Los estndares son
muy importantes

para minimizar la confusin, para que los equipos de XP utilicen un conjunto comn de
nombres, descripciones y codificacin

prcticas. Los proyectos de XP ofrecen resultados antes de lo que se acerca el RAD, y

raramente

atascarse en la recopilacin de requisitos para el sistema.

Los partidarios de XP reclaman muchas fortalezas asociadas con el desarrollo de software

utilizando XP.

Los programadores trabajan en estrecha colaboracin con todos los interesados y la

comunicacin entre todos los interesados

es mejorado Se fomentan las pruebas continuas del sistema en evolucin. El sistema es

desarrollado de manera evolutiva e incremental, lo que permite que los requisitos

evolucionar a medida que las partes interesadas entienden el potencial que tiene la tecnologa
para proporcionar un

solucin a su problema. La estimacin se basa en tareas y es realizada por el programador

quin implementar la solucin para la tarea bajo consideracin. Porque toda la programacin

se realiza de dos en dos, se desarrolla una responsabilidad compartida para cada componente
de software entre los

programadores. Finalmente, la calidad del producto final aumenta durante cada iteracin.

Para proyectos pequeos con equipos altamente motivados, cohesivos, estables y con
experiencia, XP

debera funcionar solo bien. Sin embargo, si el proyecto no es pequeo o los equipos no se
dividen, 9 el xito

de un esfuerzo de desarrollo de XP es dudoso. Esto tiende a poner en duda toda la idea

de traer contratistas externos a un entorno de equipo existente usando XP.10 La oportunidad

de los forasteros que se mezclan con los iniciados podra ser demasiado optimista. XP requiere
una gran cantidad de

disciplina, de lo contrario los proyectos se volvern desenfocados y caticos. XP solo se

recomienda

para pequeos grupos de desarrolladores, no ms de diez desarrolladores, y no se recomienda

para grandes
aplicaciones de misin crtica. Debido a la falta de anlisis y documentacin de diseo, hay

es solo documentacin de cdigo asociada con XP, por lo que se mantienen sistemas grandes
construidos con XP

puede ser imposible. Y porque los sistemas de informacin empresarial de misin crtica
tienden a existir

durante mucho tiempo, la utilidad de XP como metodologa de desarrollo del sistema de

informacin comercial

est en duda Finalmente, la metodologa necesita mucha entrada del usuario en el sitio, algo a
lo que

muchas unidades de negocios no pueden comprometerse.11 Sin embargo, algunas de las

tcnicas asociadas con

Los XP son tiles en el desarrollo de sistemas orientados a objetos. Por ejemplo, historias de
usuarios, programacin de pares,

y las pruebas continuas son herramientas invaluables desde las cuales los sistemas orientados
a objetos

el desarrollo podra beneficiarse.

Scrum12 Scrum es un trmino que es bien conocido por los fanticos del rugby. En rugby, un
scrum se usa para

reinicia un juego. En pocas palabras, los creadores del mtodo Scrum creen que no importa
cmo

Tanto planea, tan pronto como el soft ware comience a desarrollarse, se desata el caos y el

9 Un equipo jelled es aquel que tiene poco movimiento, un fuerte sentido de identidad, un
sentido de elite, una sensacin de que juntos

poseer el producto que se est desarrollando y disfrutar trabajando juntos. Para obtener
ms informacin sobre los equipos jelled,

ver T. DeMarco y T. Lister, Peopleware: Productive Projects and Teams (Nueva York: Dorset /
House, 1987).

Teniendo en cuenta la tendencia de la subcontratacin fuera de la costa, este es un

obstculo importante para que XP supere. Para ms informacin

sobre outsourcing fuera de la costa, vea P. Th. ibodeau, "ITAA Panel Debates Outsourcing
Pros, Cons", Computerworld

Actualizacin matutina (25 de septiembre de 2003); S. W. Ambler, "Chicken Little Was

Right", desarrollo de software (octubre)

2003).

11 Muchas de las observaciones sobre la utilidad de XP como un enfoque de desarrollo se

basaron en conversaciones con Brian

Henderson-Sellers.
12 Para ms informacin, ver C. Larman, Desarrollo gil e Iterativo: Una Gua de Gerentes
(Boston: Addison-

Wesley, 2004); K. Schwaber y M. Beedle, desarrollo de software Agile Soft con Scrum (Upper
Saddle River, NJ:

Prentice Hall, 2001); R. Wysocki, Gestin Eficaz del Proyecto: Tradicional, gil, Extremo, 5ta
Ed. (Indianpolis,

IN: Wiley Publishing, 2009).

los planes salen por la ventana.13 Lo mejor que puedes hacer es reaccionar donde el
proverbial rugby

la pelota sale disparada. Luego corres con la pelota hasta el prximo scrum. En el caso del
Scrum

metodologa, un sprint tiene una duracin de treinta das hbiles. Al final del sprint, se entrega
un sistema

al cliente.

De todos los enfoques de desarrollo de sistemas, en la superficie, Scrum es el ms catico. A

controle parte del caos innato, el desarrollo de Scrum se centra en algunas prcticas clave.
Equipos

son autoorganizados y autodirigidos. A diferencia de otros enfoques, los equipos de Scrum no

tienen un designado

Capitan del equipo. En cambio, los equipos se organizan de manera simbitica y establecen su

propios objetivos para cada sprint (iteracin). Una vez que ha comenzado un sprint, los
equipos de Scrum no consideran

cualquier requerimiento adicional. Cualquier nuevo requisito que se descubra se coloca en una
acumulacin

de los requisitos que an deben abordarse. Al comienzo de cada da de trabajo, un Scrum

reunin tiene lugar. Al final de cada sprint, el equipo demuestra el software al cliente.

En funcin de los resultados del sprint, se inicia un nuevo plan para el prximo sprint.

Las reuniones de Scrum son uno de los aspectos ms interesantes del proceso de desarrollo de
Scrum.

Los miembros del equipo asisten a las reuniones, pero cualquiera puede asistir. Sin embargo,
con muy

Algunas excepciones, solo los miembros del equipo pueden hablar. Una excepcin prominente
es la gestin

proporcionar retroalimentacin sobre la relevancia comercial del trabajo que realiza el

equipo. En esta reunin, todos los miembros del equipo forman un crculo e informan sobre lo
que lograron
durante el da anterior, declare lo que planean hacer hoy y describa cualquier cosa

eso bloque el progreso el da anterior. Para habilitar el progreso continuo, cualquier bloque
identificado

se trata dentro de una hora. Desde el punto de vista de Scrum, es mejor tomar una decisin
"mala"

sobre un bloque en este punto del desarrollo que no tomar una decisin. Porque el

las reuniones tienen lugar todos los das, una decisin incorrecta puede deshacerse fcilmente.
Larman14 sugiere que

cada miembro del equipo debe informar cualquier requisito adicional que haya sido
descubierto

durante el sprint y cualquier cosa que el miembro del equipo aprendi que podra ser til para
otros

miembros del equipo para saber.

Una de las principales crticas de Scrum, como con todas las metodologas giles, es que es
cuestionable

si Scrum puede escalar para desarrollar sistemas muy grandes y de misin crtica. Un tpico

El tamao del equipo de Scrum no es ms de siete miembros. El nico principio de

organizacin presentado por

Los seguidores de Scrum para abordar esta crtica es organizar un scrum de scrums. Cada
equipo se encuentra

todos los das, y despus de la reunin del equipo, un representante (no lder) de cada equipo

asiste a una reunin de scrum de scrums. Th contina hasta que el progreso de todo el sistema
tiene

sido determinado. Dependiendo de la cantidad de equipos involucrados, este enfoque para

administrar una

proyecto grande es dudoso. Sin embargo, como en XP y otros enfoques de desarrollo giles,
muchos

de las ideas y tcnicas asociadas con el desarrollo de Scrum son tiles en orientado a objetos

desarrollo de sistemas, como el enfoque de una reunin de Scrum, el desarrollo evolutivo e

incremental

enfoque para identificar los requisitos, y el enfoque incremental e iterativo de

desarrollo del sistema.

Seleccionar la Metodologa de Desarrollo Apropiada

Debido a que hay muchas metodologas, el primer desafo que enfrentan los analistas es
seleccionar qu

metodologa a usar. Elegir una metodologa no es simple, porque no hay una metodologa
siempre mejor (Si lo fuera, simplemente lo usaramos en todas partes!) Muchas
organizaciones tienen estndares

y polticas para guiar la eleccin de la metodologa. Descubrir que las organizaciones van
desde

13 Los desarrolladores de Scrum no son los primeros en cuestionar el uso de los planes. Una
de las mximas favoritas del presidente Eisenhower

fue: "Al prepararme para la batalla, siempre he encontrado que los planes son intiles, pero
la planificacin es indispensable". M. Dobson,

Streetwise Project Management: cmo administrar personas, procesos y tiempo para lograr
los resultados que necesita (Avon,

MA: F + W Publications, 2003), p. 43.

14 C. Larman, Agile & Iterative Development: A Manager's Guide (Boston: Addison-Wesley,

2004).

tener una metodologa "aprobada" para tener varias opciones de metodologa para no tener

polticas formales en absoluto.

La figura 1-8 resume algunos criterios importantes para seleccionar una metodologa. Una
importante

El tem no discutido en esta figura es el grado de experiencia del equipo analista. Muchos

de las metodologas basadas en RAD requieren el uso de nuevas herramientas y tcnicas que
tienen

curva de aprendizaje significativa. A menudo estas herramientas y tcnicas aumentan la

complejidad del

proyecto y requieren tiempo extra para aprender. Sin embargo, una vez que son adoptados y
el equipo

adquiere experiencia, las herramientas y tcnicas pueden aumentar significativamente la

velocidad a la que

la metodologa puede entregar un sistema final.

Claridad de los requisitos del usuario Cuando los requisitos del usuario para un sistema no son
claros, es

Es difcil entenderlos hablando de ellos y explicndolos con informes escritos.

Los usuarios normalmente necesitan interactuar con la tecnologa para comprender realmente
qu puede hacer un nuevo sistema

hacer y cmo mejor aplicarlo a sus necesidades. RAD y metodologas giles son generalmente
ms

apropiado cuando los requisitos del usuario no estn claros.

Familiaridad con la tecnologa Cuando el sistema utilizar nueva tecnologa con la cual los
analistas

y los programadores no estn familiarizados, la aplicacin temprana de la nueva tecnologa en

la metodologa

mejorar las posibilidades de xito Si el sistema est diseado sin cierta familiaridad

con la tecnologa base, los riesgos aumentan porque las herramientas pueden no ser capaces
de hacer lo

es necesario. Las metodologas basadas en prototipos de rowaway son particularmente

apropiadas si los usuarios

falta de familiaridad con la tecnologa porque explcitamente alientan a los desarrolladores a

desarrollar

prototipos de diseo para reas con altos riesgos. Las metodologas basadas en el desarrollo
de fases crean

oportunidades para investigar la tecnologa con cierta profundidad antes de que se complete
el diseo. Tambin,

debido a la naturaleza centrada en la programacin de las metodologas giles, tanto XP como

Scrum son

apropiado. Aunque podra pensar que las metodologas basadas en prototipos tambin son
apropiadas,

lo son mucho menos porque los primeros prototipos que se construyen generalmente solo
araan la superficie

de la nueva tecnologa. Por lo general, solo despus de varios prototipos y varios meses, la

los desarrolladores descubren debilidades o problemas en la nueva tecnologa.

Complejidad del sistema Los sistemas complejos requieren un anlisis y diseo cuidadoso y
detallado.

Las metodologas basadas en el prototipo de rowaway son particularmente adecuadas para

tales detalles

anlisis y diseo, pero las metodologas basadas en prototipos no lo son. La estructura

tradicional

Estructurado

Metodologas RAD Metodologas

gil

Metodologas

Cascada en paralelo creacin de prototipos en fases

Tirar a la basura
Prototipos de XP SCRUM

Con requisitos de usuario poco claros Pobre Pobre Bueno Excelente Excelente Excelente
Excelente

Con tecnologa desconocida Pobre Pobre Buena Pobre Excelente Buena Buena

Que son Complejos Bueno Bueno Bueno Malo Excelente Bueno Bueno

Que son confiables Bueno Bueno Bueno Malo Excelente Excelente Excelente

Con un horario corto Malo Bueno Excelente Excelente Bueno Excelente Excelente

Con horario Visibilidad Pobre Mala Excelente Excelente Buena Excelente Excelente

Excelente Bueno Excelente Excelente

FIGURA 1-8 Criterios para seleccionar una metodologa

las metodologas basadas en el diseo pueden manejar sistemas complejos, pero sin la
capacidad de obtener el

sistema o prototipos en las manos de los usuarios desde el principio, algunos problemas clave
pueden pasarse por alto.

Aunque las metodologas en fases basadas en el desarrollo permiten a los usuarios interactuar
con el sistema

Al principio del proceso, hemos observado que los equipos de proyectos que los siguen
tienden a dedicar menos

atencin al anlisis del dominio completo del problema de lo que podran hacer con otras
metodologas.

Finalmente, las metodologas giles son una mezcla cuando se trata de la complejidad del
sistema.

Si el sistema va a ser grande, las metodologas giles funcionarn mal. Sin embargo,

si el sistema es de tamao pequeo a mediano, los enfoques giles sern excelentes. Nosotros
los calificamos

bien en estos criterios.

Confiabilidad del sistema La confiabilidad del sistema suele ser un factor importante en el
desarrollo del sistema;

despus de todo, quin quiere un sistema poco confiable? Sin embargo, la confiabilidad es
solo un factor entre

varios. Para algunas aplicaciones, la confiabilidad es realmente crtica (por ejemplo, equipos
mdicos, misiles

sistemas de control), mientras que para otras aplicaciones (por ejemplo, juegos, videos de
Internet) es meramente
importante. Porque las metodologas de prototipos desechables combinan anlisis detallados y

fases de diseo con la capacidad para que el equipo del proyecto pruebe muchos enfoques
diferentes a travs de

disear prototipos antes de completar el diseo, son apropiados cuando la confiabilidad del
sistema

es una alta prioridad. Las metodologas de prototipos generalmente no son una buena opcin
cuando la confiabilidad

es crtico porque carece del anlisis cuidadoso y las fases de diseo que son esenciales para la
confiabilidad

sistemas. Sin embargo, debido al gran enfoque en las pruebas, evolutivo e incremental

identificacin de requisitos, y desarrollo iterativo e incremental, mtodos giles

puede ser el mejor enfoque general.

Horarios de horario corto Las metodologas giles y basadas en RAD son excelentes opciones
cuando

las lneas de tiempo son cortas porque permiten al equipo del proyecto ajustar la
funcionalidad en

el sistema se basa en una fecha de entrega especfica, y si el cronograma del proyecto

comienza a fallar, puede

reajustarse eliminando la funcionalidad de la versin o prototipo en desarrollo.

Las metodologas basadas en las cascadas son la peor opcin cuando el tiempo es escaso
porque

no permita cambios de horario fciles.

Programar visibilidad Uno de los mayores desafos en el desarrollo de sistemas es determinar

si un proyecto est dentro del cronograma. Esto es particularmente cierto en las metodologas
de diseo estructurado

porque el diseo y la implementacin ocurren al final del proyecto. Basado en RAD

las metodologas transfieren muchas de las decisiones crticas de diseo ms temprano en el

proyecto para ayudar a proyectar

los gerentes reconocen y abordan los factores de riesgo y mantienen las expectativas bajo
control. Sin embargo, dado

las reuniones de progreso diarias asociadas con los enfoques giles, la visibilidad del programa
siempre est activada

el proverbial quemador frontal.

ROLES Y HABILIDADES DEL ANALISTA DE SISTEMAS TPICOS

De las diversas fases y pasos realizados durante el SDLC queda claro que el equipo del proyecto
necesita una variedad de habilidades. Los miembros del proyecto son agentes de cambio que
identifican formas de mejorar

organizacin, construya un sistema de informacin para apoyarlos, y capacite y motive a otros

a

usa el sistema Comprender qu cambiar y cmo cambiarlo y convencer a los dems

de la necesidad de cambio, requiere una amplia gama de habilidades. Estas habilidades se

pueden dividir en

seis categoras principales: tcnica, comercial, analtica, interpersonal, de gestin y tica.

Los analistas deben tener las habilidades tcnicas para comprender la tcnica tcnica existente
de la organizacin.

medio ambiente, la tecnologa que conformar el nuevo sistema y la forma en que ambos
pueden

en una solucin tcnica integrada. Se requieren habilidades comerciales para comprender

cmo puede ser la TI.

aplicado a situaciones comerciales y para garantizar que el departamento de TI ofrezca un

valor comercial real. Analistas

son solucionadores de problemas continuos tanto a nivel de proyecto como a nivel

organizacional, y ellos ponen

sus habilidades analticas para la prueba con regularidad.

Los analistas a menudo necesitan comunicarse de manera efectiva cara a cara con usuarios y
gerentes de negocios

(que a menudo tiene poca experiencia con la tecnologa) y con programadores (que a menudo
tienen

ms experiencia tcnica que el analista). Deben poder hacer presentaciones a grandes y

grupos pequeos y escribir informes. No solo necesitan tener fuertes habilidades

interpersonales, sino

tambin necesitan administrar a las personas con quienes trabajan y deben manejar la presin

y riesgos asociados con situaciones poco claras.

Finalmente, los analistas deben tratar de manera justa, honesta y tica con otros miembros del
equipo del proyecto,

gerentes y usuarios del sistema. Los analistas suelen tratar informacin confidencial o
informacin

que, si se comparte con otros, podra causar daos (por ejemplo, desacuerdo entre los
empleados); es

importante para mantener la confianza y confianza con todas las personas.

Adems de estos seis conjuntos de habilidades generales, los analistas requieren muchas
habilidades especficas asociadas

con roles realizados en un proyecto. En los primeros das del desarrollo de sistemas, la mayora
de las organizaciones

se espera que una persona, el analista, tenga todas las habilidades especficas necesarias para
llevar a cabo un sistema

projecto de desarrollo. Algunas organizaciones pequeas todava esperan que una persona
realice muchos

roles, sino porque las organizaciones y la tecnologa se han vuelto ms complejas, ms grandes

las organizaciones ahora construyen equipos de proyectos que contienen varias personas con
una definicin clara

responsabilidades. Diferentes organizaciones dividen los roles de forma diferente. La mayora

de los equipos de IS incluyen

muchas otras personas, como los programadores, que realmente escriben los programas que
hacen

el sistema y los redactores tcnicos que preparan las pantallas de ayuda y otra documentacin

(por ejemplo, manuales de los usuarios y manuales de sistemas).

Analista de negocios

Un analista de negocios se enfoca en los problemas de negocios que rodean el sistema. Estos
temas incluyen

identificando el valor comercial que crear el sistema, desarrollando ideas y sugerencias para

cmo se pueden mejorar los procesos comerciales y diseando los nuevos procesos y polticas
en

conjuncin con el analista de sistemas. Es probable que el individuo tenga experiencia

comercial y algunos

tipo de entrenamiento profesional. l o ella representa los intereses del patrocinador del
proyecto y el

usuarios finales del sistema. Un analista de negocios ayuda en las fases de planificacin y
diseo pero es

ms activo en la fase de anlisis.

Analizador de sistemas

Un analista de sistemas se centra en los problemas de SI que rodean el sistema. Th is person

desarrolla ideas

y sugerencias sobre cmo la tecnologa de la informacin puede mejorar los procesos

comerciales, disea
nuevos procesos comerciales con la ayuda del analista de negocios, disea el nuevo sistema de
informacin,

y asegura que todos los estndares IS se mantengan. Un analista de sistemas probablemente

tenga signifi cado

capacitacin y experiencia en anlisis y diseo, programacin e incluso reas del negocio.

l o ella representa los intereses del departamento de SI y trabaja intensamente a travs del
proyecto

pero tal vez menos durante la fase de implementacin.

Analista de Infraestructura

Un analista de infraestructura se centra en los problemas tcnicos relacionados con la forma

en que el sistema

interactuar con la infraestructura tcnica de la organizacin (por ejemplo, hardware, software,

redes,

y bases de datos). Las tareas de un analista de infraestructura incluyen garantizar que la nueva
informacin

el sistema se ajusta a los estndares de la organizacin e identifica cambios de infraestructura

necesarios

para apoyar el sistema. Es probable que el individuo tenga una formacin y experiencia
significativa en

redes, administracin de bases de datos y diversos productos de hardware y software. El o

ella representa los intereses de la organizacin y el grupo de SI que finalmente tendr que

operar y soportar el nuevo sistema una vez que ha sido instalado. Un analista de
infraestructura

funciona durante todo el proyecto, pero tal vez menos durante las fases de planificacin y
anlisis.

Analista de gestin de cambios

Un analista de gestin de cambios se centra en las personas y los problemas de gestin que
rodean

la instalacin del sistema Los roles de esta persona incluyen asegurar que la documentacin
adecuada

y soporte estn disponibles para los usuarios, proporcionando capacitacin del usuario en el
nuevo sistema, y

desarrollando estrategias para superar la resistencia al cambio. Th es individuo debe tener

signifi -

No se puede entrenar y tener experiencia en el comportamiento organizacional en general y la

gestin del cambio.
en particular. l o ella representa los intereses del patrocinador del proyecto y los usuarios
para quienes

el sistema esta siendo diseado Un analista de gestin de cambios trabaja ms activamente

durante el

fase de implementacin, pero comienza a sentar las bases para el cambio durante el anlisis y

fases de diseo.

Gerente de proyecto

Un gerente de proyecto es responsable de garantizar que el proyecto se complete a tiempo y

dentro de

presupuesto y que el sistema entregue todos los beneficios previstos por el patrocinador del
proyecto. El papel

del gerente de proyecto incluye la gestin de los miembros del equipo, el desarrollo del plan
del proyecto,

asignar recursos y ser el principal punto de contacto cuando personas ajenas al equipo

tiene preguntas sobre el proyecto. Es probable que el individuo tenga experiencia significativa
en el proyecto

gestin y probablemente haya trabajado durante muchos aos como analista de sistemas de
antemano. l

o ella representa los intereses del departamento de SI y el patrocinador del proyecto. El

gerente de proyecto

trabaja intensamente durante todas las fases del proyecto.

CARACTERSTICAS BSICAS DE LOS SISTEMAS ORIENTADOS A OBJETOS

Los sistemas orientados a objetos se centran en capturar la estructura y el comportamiento de

los sistemas de informacin

en pequeos mdulos que abarcan tanto datos como procesos. Estos pequeos mdulos son
conocidos

como objetos. En esta seccin, describimos las caractersticas bsicas de los sistemas
orientados a objetos,

que incluyen clases, objetos, mtodos, mensajes, encapsulacin, ocultamiento de informacin,

herencia,

polimorfismo y vinculacin dinmica.15

Clases y objetos

Una clase es la plantilla general que utilizamos para definir y crear instancias u objetos
especficos. Cada

objeto est asociado con una clase. Por ejemplo, todos los objetos que capturan informacin
sobre
los pacientes pueden caer en una clase llamada Paciente, porque hay atributos (por ejemplo,
nombre, direccin,

fecha de nacimiento, telfono y compaa de seguros) y mtodos (por ejemplo, hacer una cita,
calcular el ltimo

visite, cambie el estado y proporcione el historial mdico) que comparten todos los pacientes
(consulte la Figura 1-9).

Un objeto es una instanciacin de una clase. En otras palabras, un objeto es una persona, lugar
o

cosa sobre la cual queremos capturar informacin. Si estuviramos construyendo un sistema

de citas

para una oficina de doctor, las clases pueden incluir Doctor, Paciente y Cita. Lo especifico

los pacientes, como Jim Maloney, Mary Wilson y Th eresa Marks, se consideran instancias, o

objetos, de la clase del paciente (vea la Figura 1-9).

15 En el Captulo 8, revisamos las caractersticas bsicas de los sistemas orientados a objetos

con ms detalle.

Cada objeto tiene atributos que describen informacin sobre el objeto, como el de un paciente

nombre, fecha de nacimiento, direccin y nmero de telfono. Los atributos tambin se usan
para representar relaciones

entre objetos; por ejemplo, podra haber un atributo de departamento en un empleado

objeto con un valor de un objeto de departamento que captura en qu departamento el

empleado

el objeto funciona El estado de un objeto se define por el valor de sus atributos y sus
relaciones

con otros objetos en un punto particular en el tiempo. Por ejemplo, un paciente puede tener
un estado de

nuevo o actual o anterior.

Cada objeto tambin tiene comportamientos. Los comportamientos especifican qu puede

hacer el objeto. Por ejemplo,

un objeto de cita probablemente puede programar una nueva cita, eliminar una cita,

y localice la prxima cita disponible. En la programacin orientada a objetos, los

comportamientos son

implementado como mtodos (ver la siguiente seccin).

Uno de los aspectos ms confusos del desarrollo de sistemas orientados a objetos es el hecho

que en la mayora de los lenguajes de programacin orientados a objetos, ambas clases e

instancias de clases
puede tener atributos y mtodos. Los atributos y mtodos de clase tienden a ser usados para
modelar

atributos (o mtodos) que tratan problemas relacionados con todas las instancias de la clase.
Por ejemplo,

para crear un nuevo objeto del paciente, se enva un mensaje a la clase del paciente para crear
una nueva instancia

de s mismo. Sin embargo, en este libro, nos centramos principalmente en los atributos y
mtodos de los objetos y

no de clases

Mtodos y mensajes

Los mtodos implementan el comportamiento de un objeto. Un mtodo no es ms que una

accin que

objeto puede realizar. Los mensajes son informacin enviada a objetos para activar mtodos.
Un mensaje

es esencialmente una llamada a funcin o procedimiento de un objeto a otro. Por ejemplo, si

el paciente es nuevo en la oficina del mdico, la recepcionista enva un mensaje de creacin a

la aplicacin.

La clase del paciente recibe el mensaje de creacin y ejecuta su mtodo create () que luego

crea un nuevo objeto: aPatient (vea la Figura 1-10).

Encapsulacin y ocultacin de informacin

Las ideas de encapsulacin y ocultamiento de informacin estn interrelacionadas en sistemas

orientados a objetos.

Sin embargo, ninguno de los trminos es nuevo. La encapsulacin es simplemente la

combinacin del proceso

y datos en una sola entidad. El ocultamiento de informacin fue promovido por primera vez en
sistemas estructurados

desarrollo. El principio de ocultar informacin sugiere que solo la informacin

Paciente

-nombre

-direccin

-Fecha de nacimiento

-telfono

-aseguradora

+ hacer cita ()
+ calcular la ltima visita ()

+ cambiar estado ()

+ proporciona historial mdico ()

+ crear ()

Jim Maloney: paciente Mary Wilson: paciente Theresa Marks: paciente

requerido para usar un mdulo de software se publicar al usuario del mdulo. Por lo general,
esto

implica que la informacin requerida para pasar al mdulo y la informacin

devuelto desde el mdulo se publican. Exactamente cmo el mdulo implementa el requerido

la funcionalidad no es relevante. Realmente no nos importa cmo el objeto realiza sus

funciones,

siempre que las funciones ocurran. En sistemas orientados a objetos, combina la

encapsulacin con el

el principio de ocultamiento de la informacin permite tratar objetos como cajas negras.

El hecho de que podamos usar un objeto llamando a mtodos es la clave de la reutilizacin

porque

protege el funcionamiento interno del objeto de los cambios en el sistema exterior, y

mantiene

el sistema no se ve afectado cuando se realizan cambios en un objeto. En la Figura 1-10,

observe

cmo se enva un mensaje (crear) a un objeto, sin embargo, los algoritmos internos necesarios
para responder a

el mensaje est oculto de otras partes del sistema. La nica informacin que un objeto

necesita saber es el conjunto de operaciones o mtodos que otros objetos pueden realizar y

los mensajes deben enviarse para activarlos.

Herencia

La herencia, como caracterstica de desarrollo de sistemas de informacin, se propuso en

datos

modelado a finales de los aos setenta y principios de los ochenta. La literatura de modelado
de datos sugiere usar

herencia para identificar clases de objetos de ms alto nivel o ms generales. Conjuntos

comunes de

los atributos y mtodos se pueden organizar en superclases. Por lo general, las clases se
organizan en
una jerarqua segn la cual las superclases, o clases generales, estn en la parte superior y las
subclases, o

clases especficas, estn en la parte inferior. En la Figura 1-11, la persona es una superclase
para las clases Doctor

y paciente. El mdico, a su vez, es una superclase para el mdico general y el especialista. Date
cuenta cmo

una clase (por ejemplo, Doctor) puede servir como una superclase y una subclase
concurrentemente. La relacin

entre la clase y su superclase se conoce como la relacin a-kind-of. Por ejemplo en

La figura 1-11, un mdico de medicina general es una especie de mdico, que es una especie
de persona.

Las subclases heredan los atributos y mtodos apropiados de las superclases anteriores

ellos. Th at is, cada subclase contiene atributos y mtodos de su superclase primaria. por

ejemplo, la figura 1-11 muestra que tanto el mdico como el paciente son subclases de
personas y, por lo tanto,

heredar los atributos y mtodos de la clase Person. La herencia lo hace ms simple

Definir clases. En lugar de repetir los atributos y mtodos en las clases de Doctor y Paciente

por separado, los atributos y mtodos que son comunes a ambos se colocan en la clase
Persona

y heredado por las clases debajo de l. Observe cuntas jerarquas de herencia mucho ms
eficientes

de clases de objetos son ms que los mismos objetos sin una jerarqua de herencia (consulte la
Figura 1-12).

La mayora de las clases en una jerarqua llevan a instancias; cualquier clase que tenga
instancias

se llama una clase concreta. Por ejemplo, si Mary Wilson y Jim Maloney son ejemplos de

la clase de Paciente, Paciente, se considerara una clase concreta (consulte la Figura 1-9).
Algunos

las clases no producen instancias porque se usan meramente como plantillas para otros,

FIGURA 1-10

Mensajes y

Mtodos

Recepcionista

crear
Paciente

-nombre

-direccin

-Fecha de nacimiento

-telfono

-aseguradora

+ hacer cita ()

+ calcular la ltima visita ()

+ cambiar estado ()

+ proporciona historial mdico ()

+ crear ()

un paciente

clases ms especficas (especialmente clases ubicadas en lo alto de una jerarqua). Las clases
son

a las que se hace referencia como clases abstractas. La persona es un ejemplo de una clase
abstracta. En lugar de crear

objetos de Persona, creamos instancias que representan las clases ms especficas de

Especialista

y Paciente, ambos tipos de Persona (vea la Figura 1-11).

Polimorfismo y unin dinmica

El polimorfismo significa que el mismo mensaje se puede interpretar de manera diferente por
diferentes

clases de objetos. Por ejemplo, insertar un paciente significa algo diferente a la insercin

una cita. Por lo tanto, es necesario recopilar y almacenar diferentes piezas de informacin.

Afortunadamente, no tenemos que preocuparnos por cmo se hace algo al usar objetos.

Podemos simplemente enviar un mensaje a un objeto, y ese objeto ser responsable de

interpretar

el mensaje apropiadamente. Por ejemplo, si un artista envi el mensaje Djate llevar a un

FIGURA 1-11

Jerarqua de clase

con Resumen y

Clases concretas
Persona

Doctor Paciente

Especialista en medicina general

Clases abstractas

Clases concretas

Paciente

-nombre

-direccin

-Fecha de nacimiento

-telfono

-aseguradora

+ updateBirthDate ()

+ updateInsuranceCarrier ()

Persona

-nombre

-direccin

-Fecha de nacimiento

-telfono

+ updateBirthDate ()

Doctor

Doctor

-nombre

-direccin

-Fecha de nacimiento

-telfono

-medicalSchoolSpecialty

+ updateBirthDate ()

+ updateMedicalSchoolSpecialty ()

VS.
-medicalSchoolSpecialty

+ updateMedicalSchoolSpecialty ()

Paciente

-aseguradora

+ updateInsuranceCarrier

objeto cuadrado, un objeto circular y un objeto triangular, los resultados seran muy
diferentes, incluso

aunque el mensaje es el mismo Observe en la Figura 1-13 cmo cada objeto responde
apropiadamente

(y diferente) a pesar de que los mensajes son idnticos.

El polimorfismo es posible a travs de la unin dinmica. La vinculacin dinmica o tarda es

una tcnica que retrasa el tipeo del objeto hasta el tiempo de ejecucin. El mtodo especfico
que es en realidad

llamado no es elegido por el sistema orientado a objetos hasta que el sistema se est
ejecutando. Esto es

en contraste con la vinculacin esttica. En un sistema estticamente ligado, se determina el

tipo de objeto

en tiempo de compilacin. Por lo tanto, el desarrollador debe elegir qu mtodo se debe

llamar

en lugar de permitir que el sistema lo haga. Es por eso que la mayora de los lenguajes de
programacin tradicionales

tienen una lgica de decisin complicada basada en los diferentes tipos de objetos en un
sistema.

Por ejemplo, en un lenguaje de programacin tradicional, en lugar de enviar el mensaje

Dibujar

usted mismo a los diferentes tipos de objetos grficos en la figura 1-13, tendramos que
escribir

lgica de decisin usando una declaracin de caso o un conjunto de sentencias if para

determinar qu tipo de

objeto grfico que queramos dibujar, y tendramos que nombrar cada funcin de dibujo de
manera diferente

(por ejemplo, dibujar un cuadrado, dibujar un crculo o dibujar un tringulo). Th es obviamente

hace que el sistema

mucho ms complicado y difcil de entender.

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS (OOSAD)

Los enfoques orientados a objetos para desarrollar sistemas de informacin, tcnicamente
hablando, pueden usar

cualquiera de las metodologas tradicionales. Sin embargo, los enfoques orientados a objetos
estn ms asociados

con un desarrollo en fases RAD o metodologa gil. La principal diferencia entre

un enfoque tradicional como el diseo estructurado y un enfoque orientado a objetos es cmo

un problema

se descompone En los enfoques tradicionales, el proceso de descomposicin del problema es

centrado en el proceso o centrado en los datos. Sin embargo, los procesos y los datos estn
tan estrechamente relacionados que es

Difcil elegir uno u otro como el enfoque principal. Basado en esta falta de congruencia con el

mundo real, nuevas metodologas orientadas a objetos han surgido que usan la secuencia
basada en RAD

de las fases del SDLC pero intenta equilibrar el nfasis entre el proceso y los datos enfocando
el

descomposicin de problemas en objetos que contienen datos y procesos.

De acuerdo con los creadores del lenguaje de modelado unificado (UML), Grady Booch, Ivar

Jacobson y James Rumbaugh, 16 cualquier enfoque moderno orientado a objetos para

desarrollar informacin

los sistemas deben estar basados en casos de uso, centrados en la arquitectura e iterativos e
incrementales.

Use-Case Driven

Use-case driven significa que los casos de uso son las principales herramientas de modelado
que definen el comportamiento de

el sistema. Un caso de uso describe cmo el usuario interacta con el sistema para realizar
alguna actividad,

como hacer un pedido, hacer una reserva o buscar informacin. Los casos de uso

se utilizan para identificar y comunicar los requisitos del sistema a los programadores

quien debe escribir el sistema Los casos de uso son inherentemente simples porque se enfocan
en solo uno

proceso de negocios a la vez. Por el contrario, los diagramas de modelo de proceso utilizados
por estructura tradicional

y las metodologas RAD son mucho ms complejas porque requieren el analista de sistemas

y usuario para desarrollar modelos de todo el sistema. Con las metodologas tradicionales,
cada sistema
se descompone en un conjunto de subsistemas, que a su vez se descomponen en otros
subsistemas,

y as. Th contina hasta que no tiene sentido descomponer el proceso, y a menudo es

requiere docenas de pginas de diagramas entrelazados. Por el contrario, un caso de uso se

centra en solo uno

proceso de negocios a la vez, entonces el desarrollo de modelos es mucho ms simple.

Centrado en la arquitectura

Cualquier enfoque moderno para el anlisis y diseo de sistemas debe centrarse en la

arquitectura.

Centrado en la arquitectura significa que la arquitectura de software subyacente del sistema

en evolucin

la especificacin dirige la especificacin, construccin y documentacin del sistema. Moderno

los enfoques de diseo y anlisis de sistemas orientados a objetos deben respaldar al menos
tres

pero vistas arquitectnicas interrelacionadas de un sistema: funcional, esttico y dinmico. El

funcional,

o vista externa, describe el comportamiento del sistema desde la perspectiva del usuario. Los

vista estructural o esttica, describe el sistema en trminos de atributos, mtodos, clases y

relaciones. La vista conductual o dinmica describe el comportamiento del sistema en

trminos

de mensajes pasados entre objetos y cambios de estado dentro de un objeto.

Iterativo e incremental

Los enfoques modernos de anlisis y diseo de sistemas orientados a objetos hacen hincapi
en

desarrollo incremental que se somete a pruebas y refinanciamiento continuos en todo el

vida del proyecto. Esto implica que los analistas de sistemas desarrollan su comprensin de un

problema del usuario mediante la construccin de las tres vistas arquitectnicas poco a poco.
El analista de sistemas

lo hace trabajando con el usuario para crear una representacin funcional del sistema en

estudiar. Luego, el analista intenta construir una representacin estructural del sistema en
evolucin.

Usando la representacin estructural del sistema, el analista distribuye la funcionalidad de

el sistema sobre la estructura en evolucin para crear una representacin del comportamiento
de la evolucin
sistema. Como un analista trabaja con el usuario en el desarrollo de las tres vistas
arquitectnicas de la

sistema en evolucin, el analista itera sobre cada uno de los puntos de vista y entre ellos. Th
en es, como el analista

entiende mejor las vistas estructurales y de comportamiento, el analista descubre los

requisitos faltantes

o tergiversaciones en la vista funcional. Esto es, a su vez, puede causar cambios

16 Grady Booch, Ivar Jacobson y James Rumbaugh, Gua de usuario del lenguaje de
modelado unificado (Reading, MA:

Addison-Wesley, 1999).

17 Para aquellos de ustedes que tienen experiencia con el anlisis y diseo estructurado
tradicional, este es uno de los ms inusuales

aspectos del anlisis y diseo orientado a objetos usando UML. A diferencia de los enfoques
estructurados, los enfoques orientados a objetos

enfatizar el enfoque en un solo caso de uso a la vez y distribuir ese caso de uso nico sobre
un conjunto de comunicaciones y

objetos colaboradores

en cascada a travs de las vistas estructurales y de comportamiento. Las tres vistas

arquitectnicas de

el sistema est interconectado y depende uno del otro (vea la Figura 1-14). Como cada
incremento

y se completa la iteracin, una representacin ms completa de la funcionalidad real del

usuario

requisitos est descubierto.

Beneficios del anlisis y diseo de sistemas orientados a objetos

Los conceptos en el enfoque orientado a objetos permiten a los analistas dividir un sistema
complejo en

mdulos ms pequeos y ms manejables, trabaje en los mdulos individualmente y frage

fcilmente

los mdulos vuelven a unirse para formar un sistema de informacin. Th es la modularidad

hace el desarrollo de sistemas

ms fcil de comprender, ms fcil de compartir entre los miembros de un equipo de

proyecto, y ms fcil de comunicar
a los usuarios, que son necesarios para proporcionar los requisitos y confirmar qu tan bien el
sistema

cumple con los requisitos a lo largo del proceso de desarrollo de sistemas. Al modularizar los
sistemas

desarrollo, el equipo del proyecto en realidad est creando piezas reutilizables que pueden ser
conectadas a

otros sistemas funcionan o se usan como puntos de partida para otros proyectos. En ltima
instancia, esto puede ahorrar tiempo

porque los nuevos proyectos no tienen que comenzar completamente desde cero.

EL PROCESO UNIFICADO

El proceso unifi cado es una metodologa especfica que establece cundo y cmo usar los
diversos

Tcnicas de Lenguaje de Modelado Unificado (UML) para anlisis y diseo orientado a objetos.

Los principales contribuyentes fueron Grady Booch, Ivar Jacobsen y James Rumbaugh.
Mientras

UML proporciona soporte estructural para desarrollar la estructura y el comportamiento de

una informacin

sistema, el proceso Unifi ed proporciona el soporte de comportamiento. El Proceso Unificado,

de

Por supuesto, est orientado a casos de uso, centrado en la arquitectura e iterativo e

incremental. Adems,

el Proceso Unificado es un proceso de desarrollo de sistemas bidimensionales descrito por un

conjunto de

fases y workfl ows. Las fases son inicio, elaboracin, construccin y transicin.

Los trabajos incluyen modelos de negocios, requisitos, anlisis, diseo, implementacin,

prueba, implementacin, confi guracin y gestin de cambios, gestin de proyectos y entorno.

18 La Figura 1-15 representa el Proceso Unificado.

FIGURA 1-14

Iterativo y

Incremental

Desarrollo

18 El material de esta seccin se basa en Khawar Zaman Ahmed y Cary E. Umrysh, Developing
Enterprise Java

Aplicaciones con J2EE y UML (Boston, MA: Addison-Wesley, 2002); Jim Arlow e Ila Neustadt,
UML y Th e
Proceso Unifi cado: Anlisis y Diseo Orientado a Objetos Prctico (Boston, MA: Addison-
Wesley, 2002); Peter Eeles,

Kelli Houston y Wojtek Kozacynski, Creacin de aplicaciones J2EE con el proceso Rational Unifi
ed (Boston, MA:

Addison-Wesley, 2003); Ivar Jacobson, Grady Booch y James Rumbaugh, el proceso de

desarrollo de software unificado

(Reading, MA: Addison-Wesley, 1999); Phillipe Krutchten, El Proceso Unificado Racional: Una
Introduccin, 2da Ed.

(Boston, MA: Addison-Wesley, 2000); "Proceso unificado racional: mejores prcticas para los
equipos de desarrollo de software"

Libro blanco de software de racionalizacin blanda, TP026B, Rev 11/01.

Fases

Las fases del proceso Unifi ed apoyan a un analista en el desarrollo de sistemas de informacin
en

una manera iterativa e incremental. Las fases describen cmo evoluciona un sistema de
informacin

a travs del tiempo. Segn la fase de desarrollo en la que se encuentre el sistema en evolucin,

el nivel de actividad vara sobre los workfl ows. La curva en la Figura 1-15 asociada con cada

workfl ow aproxima la cantidad de actividad que tiene lugar durante la fase especfica. por

Por ejemplo, la fase inicial involucra principalmente el modelado de negocios y los requisitos
workfl

sin embargo, prcticamente ignorando los trabajos de prueba y despliegue. Cada fase contiene
un conjunto

de iteraciones, y cada iteracin usa los diversos archivos de trabajo para crear una versin
incremental de

el sistema en evolucin. A medida que el sistema evoluciona a travs de las fases, mejora y se
vuelve ms

completar. Cada fase tiene objetivos, un foco de actividad sobre los flujos de trabajo e
incrementales

entregables. Cada una de las fases se describe a continuacin.

Inicio En muchos sentidos, la fase de inicio es muy similar a la fase de planificacin de un

Enfoque SDLC. En esta fase, se presenta un caso de negocios para el sistema propuesto. Esta

incluye un anlisis de viabilidad que debera responder preguntas tales como las siguientes:
Tenemos la capacidad tcnica para construirlo (viabilidad tcnica)?

Si lo construimos, proporcionar valor comercial (viabilidad econmica)?

Si lo construimos, ser utilizado por la organizacin (viabilidad organizacional)?

Para responder estas preguntas, el equipo de desarrollo realiza trabajos relacionados

principalmente con

los modelos de negocio, los requisitos y el trabajo de anlisis. En algunos casos, dependiendo
de

las dificultades tcnicas que podran encontrarse durante el desarrollo del sistema,

se desarrolla un prototipo de usar y tirar. Esto implica que el diseo, la implementacin y la

prueba

workfl ows tambin podra estar involucrado. La gestin del proyecto y el entorno de apoyo

workfl ows son muy relevantes para esta fase. Los principales entregables desde la fase de
inicio

son un documento de visin que establece el alcance del proyecto; identifica los requisitos
primarios

y restricciones establece un plan de proyecto inicial; y describe la viabilidad y los riesgos

asociados

con el proyecto, la adopcin del entorno necesario para desarrollar el sistema, y

algunos aspectos de las clases de dominio del problema que se implementan y prueban.

Elaboracin Cuando normalmente pensamos en anlisis y diseo de sistemas orientados a

objetos,

las actividades relacionadas con la fase de elaboracin del Proceso Unificado son las ms
relevantes.

Los trabajos de anlisis y diseo son el enfoque principal durante esta fase. La elaboracin

la fase contina con el desarrollo del documento de visin, incluida la finalizacin del negocio

caso, revisar la evaluacin de riesgos y completar un plan de proyecto con suficiente detalle
para permitir

las partes interesadas para poder estar de acuerdo con la construccin del sistema final real.
Se trata de

reuniendo los requisitos, construyendo los modelos estructurales y de comportamiento UML

de la

dominio del problema, y detallando cmo los modelos del dominio del problema encajan en el
sistema en evolucin
arquitectura. Los desarrolladores estn involucrados con todas las funciones de ingeniera de
despliegue excepto en

esta fase A medida que los desarrolladores iteran sobre las hojas de trabajo, la importancia de
abordar

la confi guracin y la gestin del cambio se hacen evidentes. Adems, las herramientas de
desarrollo

adquiridos durante la fase de inicio se vuelven crticos para el xito del proyecto durante

esta fase.19 Los productos principales de esta fase incluyen la estructura y el comportamiento
de UML

diagramas y un ejecutable de una versin de referencia del sistema de informacin en

evolucin. Los

la versin de referencia sirve como base para todas las iteraciones posteriores. Al proporcionar
una base slida

en este punto, los desarrolladores tienen una base para completar el sistema en la
construccin

y fases de transicin.

Construccin La fase de construccin se centra principalmente en la programacin de la

informacin en evolucin

sistema. Esta fase se refiere principalmente al trabajo de implementacin. Sin embargo,

los requisitos de workfl ow y los trabajos de anlisis y diseo tambin estn involucrados

con esta fase. Es durante esta fase que se identifican los requisitos faltantes y el

los modelos de anlisis y diseo finalmente se completan. Por lo general, hay iteraciones de

workfl ow durante esta fase, y durante la ltima iteracin, las patadas workfl ow de despliegue

en marcha alta. El trabajo de gestin de configuracin y cambio, con su control de versiones

actividades, se vuelve extremadamente importante durante la fase de construccin. A veces,

un

la iteracin debe revertirse. Sin buenos controles de versin, retrocediendo a una anterior

versin (implementacin incremental) del sistema es casi imposible. El primario

entregable de esta fase es una implementacin del sistema que se puede lanzar para beta

y pruebas de aceptacin.

Transicin Al igual que la fase de construccin, la fase de transicin aborda aspectos

tpicamente

asociado con la fase de implementacin de un enfoque SDLC tradicional. Su primaria

el foco est en los trabajos de prueba y despliegue. Esencialmente, el modelado de negocios,

requisitos, y los trabajos de anlisis deberan haberse completado en iteraciones anteriores

del sistema de informacin en evolucin. Adems, el workfl ow de prueba habr sido

Con UML que comprende varias tcnicas de diagramacin relacionadas, manteniendo los
diagramas coordinados y el

Las diferentes versiones del sistema en evolucin sincronizado normalmente estn ms all
de las capacidades de un simple desarrollador de sistemas mortales.

Estas herramientas generalmente incluyen administracin de proyectos y herramientas

CASE. Describimos el uso de estas herramientas en el Captulo 2.

ejecutando durante las fases anteriores del sistema en evolucin. Dependiendo de los
resultados

del workfl ow de prueba, algunas actividades de rediseo y programacin en el diseo y

los trabajos de implementacin podran ser necesarios, pero deberan ser mnimos en este
punto.

Desde una perspectiva gerencial, la gestin del proyecto, la configuracin y la gestin del
cambio,

y el medio ambiente estn involucrados. Algunas de las actividades que tienen lugar son beta y

pruebas de aceptacin, ajuste de precisin del diseo y la implementacin, capacitacin del

usuario y rodamiento

el producto final en una plataforma de produccin. Obviamente, el producto principal es

el sistema de informacin ejecutable real. Los otros entregables incluyen manuales de usuario,
un

plan para apoyar a los usuarios y un plan para actualizar el sistema de informacin en el
futuro.

Workfl ows

Los documentos describen las tareas o actividades que realiza un desarrollador para
desarrollar una informacin

sistema a lo largo del tiempo. Los formularios de trabajo del Proceso Unificado se agrupan en
dos grandes

categoras: ingeniera y apoyo.

Trabajos de ingeniera Trabajos de ingeniera incluyen modelos de negocios, requisitos,

trabajos de anlisis, diseo, implementacin, prueba e implementacin. El trabajo de

ingeniera

Se tratan las actividades que producen el producto tcnico (es decir, el sistema de
informacin).
Trabajo de modelado de negocios El trabajo de modelado de negocios descubre problemas y

identifica proyectos potenciales dentro de una organizacin de usuarios. Este es el trabajo que
ayuda a la administracin en

entendiendo el alcance de los proyectos que pueden mejorar la eficiencia y la eficacia de un

organizacin de usuarios. El propsito principal del modelado de negocios es asegurar que

ambos desarrolladores

y las organizaciones de usuarios entienden dnde y cmo el sistema de informacin a ser

desarrollado

se adapta a los procesos de negocio de la organizacin usuaria. Este es el trabajo que se

ejecuta principalmente

durante la fase de inicio para garantizar que desarrollemos sistemas de informacin que

sentido de negocios. Las actividades que tienen lugar en este trabajo estn ms estrechamente
asociadas con

la fase de planificacin del SDLC tradicional; sin embargo, recopilacin de requisitos y caso de
uso

y las tcnicas de modelado de procesos comerciales tambin nos ayudan a comprender la

situacin comercial.

Requisitos Workfl ow En el proceso Unifi ed, los requisitos workfl ow incluyen eliciting

ambos requisitos funcionales y no funcionales. Por lo general, los requisitos se renen

de los interesados directos del proyecto, como los usuarios finales, los gerentes dentro de la
organizacin del usuario final, y

incluso clientes. Los requisitos de workfl ow se utilizan ms durante el inicio y la elaboracin

fases Los requisitos identificados son muy tiles para desarrollar el documento de visin

y los casos de uso utilizados durante todo el proceso de desarrollo. Requerimientos adicionales

tienden a ser descubiertos durante todo el proceso de desarrollo. De hecho, solo la fase de
transicin

tiende a tener pocos, si acaso, requisitos adicionales identificados.

Trabajo de anlisis El trabajo de anlisis aborda principalmente la creacin de un anlisis

modelo del dominio del problema En el proceso Unifi ed, el analista comienza a disear la
arquitectura

asociado con el dominio del problema; usando el UML, el analista crea estructural y

diagramas de comportamiento que describen una descripcin de las clases de dominio del
problema y sus interacciones.

El propsito principal del trabajo de anlisis es asegurar que tanto el desarrollador

y las organizaciones de usuarios entienden el problema subyacente y su dominio sin
sobreanalizar.

Si no tienen cuidado, los analistas pueden crear parlisis de anlisis, que ocurre cuando el

proyecto se vuelve tan empantanado con el anlisis de que el sistema nunca est realmente
diseado o

implementado. Un segundo objetivo del trabajo de anlisis es identificar clases tiles

reutilizables

para las bibliotecas de clase. Al reutilizar las clases predefinidas, el analista puede evitar
reinventar la rueda

al crear los diagramas estructurales y de comportamiento. El trabajo de anlisis es

predominantemente

asociado a la fase de elaboracin, pero al igual que los requisitos workfl ow, es posible que

Se requerir un anlisis adicional durante todo el proceso de desarrollo.

Trabajo de diseo El trabajo de diseo transforma el modelo de anlisis en una forma que
puede

ser utilizado para implementar el sistema: el modelo de diseo. Mientras que el trabajo de
anlisis se concentr

para comprender el dominio del problema, el flujo de trabajo de diseo se centra en

desarrollar un

solucin que se ejecutar en un entorno especfico. Bsicamente, el trabajo de diseo

simplemente

mejora la descripcin del sistema en evolucin agregando clases que abordan el entorno

del sistema al modelo de anlisis en evolucin. El trabajo de diseo utiliza actividades tales

como el diseo detallado de la clase de dominio del problema, la optimizacin del sistema de
informacin en evolucin,

diseo de base de datos, diseo de interfaz de usuario y diseo de arquitectura fsica. El

trabajo de diseo

se asocia principalmente con las fases de elaboracin y construccin del Proceso Unificado.

Trabajo de Implementacin El propsito principal del trabajo de implementacin es

crea una solucin ejecutable basada en el modelo de diseo (es decir, programacin). Esto
incluye

no solo escribiendo nuevas clases sino tambin incorporando clases reutilizables de la clase
ejecutable
bibliotecas en la solucin en evolucin. Como con cualquier actividad de programacin, las
nuevas clases y

sus interacciones con las clases reutilizables incorporadas deben ser probadas. Finalmente, en
el caso de

mltiples grupos que realizan la implementacin del sistema de informacin, los

implementadores

tambin debe integrar los mdulos separados, probados individualmente para crear una
versin ejecutable

del sistema. El trabajo de implementacin se asocia principalmente con la elaboracin y

fases de construccin.

Prueba de trabajo El objetivo principal del trabajo de prueba es aumentar la calidad

del sistema en evolucin. Las pruebas van ms all de la simple prueba unitaria asociada con el

trabajo de implementacin. En este caso, las pruebas tambin incluyen probar la integracin
de todos

mdulos utilizados para implementar el sistema, las pruebas de aceptacin del usuario y las
pruebas alfa reales

del software. En trminos prcticos, las pruebas deberan continuar durante todo el desarrollo

del sistema; la prueba de los modelos de anlisis y diseo ocurre durante la elaboracin y

fases de construccin, mientras que las pruebas de implementacin se realizan principalmente

durante

construccin y, hasta cierto punto, fases de transicin. Bsicamente, al final de cada iteracin

Durante el desarrollo del sistema de informacin, se debe realizar algn tipo de prueba.

Workflow de implementacin El workfl ow de implementacin est ms asociado con la

transicin

fase del proceso Unifi ed. El flujo de trabajo de implementacin incluye actividades tales como
soft ware

empaque, distribucin, instalacin y prueba beta. Cuando realmente se implementa el nuevo

sistema

en una organizacin de usuarios, los desarrolladores podran tener que convertir los datos
actuales, la interfaz

el nuevo software con el software existente y capacitar al usuario final para usar el nuevo
sistema.

Apoyo a los trabajos Los trabajos de apoyo incluyen la gestin del proyecto, confi

gestin de cambio y de gestin, y trabajo de entorno. Los trabajos de apoyo

enfocarse en los aspectos gerenciales del desarrollo de sistemas de informacin.

Project Management Workfl ow Mientras que los otros archivos de trabajo asociados con Unifi
ed

El proceso es tcnicamente activo durante las cuatro fases, el flujo de trabajo de gestin del
proyecto es

el nico flujo de trabajo verdaderamente en fase cruzada. El proceso de desarrollo admite

incrementos y

desarrollo iterativo, por lo que los sistemas de informacin tienden a crecer o evolucionar con
el tiempo. Al final

de cada iteracin, una nueva versin incremental del sistema est lista para la entrega. El
proyecto

trabajo de gestin es bastante importante debido a la complejidad de la bidimensional

modelo de desarrollo del proceso Unifi ed (workfl ows y fases). Estas son las actividades de
workfl ow

incluye la identificacin y gestin de riesgos, la gestin del alcance, la estimacin del tiempo
para completar

cada iteracin y todo el proyecto, estimando el costo de la iteracin individual y el

todo el proyecto, y el seguimiento del progreso que se est realizando hacia la versin final de
la evolucin

sistema de informacion.

Confi guracin y trabajo de gestin del cambio El objetivo principal de la confi guracin

y el trabajo de gestin del cambio consiste en realizar un seguimiento del estado del sistema
en evolucin.

En pocas palabras, el sistema de informacin en evolucin comprende un conjunto de

artefactos (por ejemplo, diagramas,

cdigo fuente y ejecutables). Durante el proceso de desarrollo, estos artefactos son

modificados.

Una cantidad sustancial de trabajo, y, por lo tanto, dinero, est involucrado en el desarrollo de
los artefactos.

Los propios artefactos deben manejarse ya que se manejar cualquier activo caro: acceso

se deben establecer controles para proteger los artefactos de ser robados o destruidos.
Adems,

porque los artefactos se modifican en una base regular, si no continua, buena versin

mecanismos de control deben ser establecidos. Por ltimo, una buena parte de la gestin de
proyectos
la informacin debe ser capturada (por ejemplo, autor, hora y ubicacin de cada modificacin).
Los

la configuracin y la gestin del cambio se asocian principalmente con la construccin

y fases de transicin.

Trabajo de Medio Ambiente Durante el desarrollo de un sistema de informacin, el desarrollo

el equipo necesita usar diferentes herramientas y procesos. Las direcciones de workfl ow del
entorno

estas necesidades Por ejemplo, una herramienta CASE que admite el desarrollo de un objeto
orientado

sistema de informacin a travs del UML podra ser necesario. Otras herramientas necesarias
incluyen la programacin

entornos, herramientas de gestin de proyectos y herramientas de gestin de configuracin.

El trabajo del entorno implica la adquisicin e instalacin de estas herramientas. Aunque esto

workfl ow puede estar activo durante todas las fases del proceso Unifi ed, debe estar
involucrado

principalmente con la fase de inicio.

Extensiones al proceso Unifi ed

Tan grande y tan complejo como es el Proceso Unificado, muchos autores han sealado un
conjunto de

Debilidades crticas. Primero, el Proceso Unificado no se ocupa del personal, el presupuesto o

el contrato

asuntos Gerenciales. Estas actividades se excluyeron explcitamente del proceso Unifi ed.
Segundo, el

Unified Process no aborda problemas relacionados con el mantenimiento, las operaciones o el

soporte de

el producto una vez que ha sido entregado. Nosotros, no es un proceso completo de software;
Es solo

un proceso de desarrollo. Adems, el Proceso Unifi cado no aborda el proyecto cruzado o

interproyecto

cuestiones. Considerando la importancia de la reutilizacin en el desarrollo de sistemas

orientados a objetos y la

hecho de que en muchas organizaciones los empleados trabajan en muchos proyectos

diferentes al mismo tiempo,

omitir los problemas entre proyectos es una gran omisin.

Para abordar estas omisiones, Ambler y Constantine sugieren agregar una fase de produccin
y dos workfl ows: las operaciones y el flujo de trabajo de soporte y la gestin de la
infraestructura

workfl ow (consulte la Figura 1-16) .20 Adems de estos nuevos archivos de trabajo, la prueba,
implementacin y

los workfl del ambiente son modifi cados, y la gerencia del proyecto y la confi guracin

y los workfiles de gestin del cambio se extienden a la fase de produccin. Estas extensiones

20 S. W. Ambler y L. L. Constantine, La Fase de Inicio del Proceso Unificada: Mejores Prcticas

en la Implementacin de la UP

(Lawrence, KS: CMP Books, 2000); S. W. Ambler y L. L. Constantine, la Fase de Elaboracin del
Proceso Unificada:

Mejores prcticas en la implementacin de UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler

y L. L. Constantine, The e

Fase de construccin de proceso unifi cado: Mejores prcticas en la implementacin de UP

(Lawrence, KS: CMP Books, 2000); S. W.

Ambler y L. L. Constantine, las fases de transicin y produccin del proceso unifi cado: mejores
prcticas en la implementacin

UP (Lawrence, KS: CMP Books, 2002).

se basan en procesos alternativos de soft ware orientados a objetos: el proceso OPEN

(orientado a objetos)

Proceso, entorno y notacin) y el proceso de software orientado a objetos.21

Fase de produccin La fase de produccin se ocupa principalmente de cuestiones relacionadas

con la

producto de software despus de que se haya implementado con xito. Th es fase se centra en
cuestiones relacionadas

para actualizar, mantener y operar el software. A diferencia de las fases anteriores, hay

sin iteraciones o entregables incrementales. Si se va a desarrollar una nueva versin del

software,

21 S. W. Ambler, Patrones de procesos: creacin de sistemas a gran escala con tecnologa de

objetos (Cambridge, Reino Unido: SIGS

Books / Cambridge University Press, 1998); S. W. Ambler, Ms patrones de proceso: entrega de

sistemas a gran escala

Usando Object Technology (Cambridge, Reino Unido: SIGS Books / Cambridge University Press,
1999); I. Graham, B. Henderson-

Sellers, y H. Younessi, la especificacin del proceso OPEN (Harlow, Reino Unido: Addison-
Wesley, 1997); B. Henderson-Sellers y
B. Unhelkar, OPEN Modelado con UML (Harlow, Reino Unido: Addison-Wesley, 2000).

entonces los desarrolladores deben comenzar una nueva ejecucin a travs de las primeras
cuatro fases. Basado en las actividades

que tienen lugar durante esta fase, ningn trabajo de ingeniera es relevante. El apoyo

Los workfl ows que estn activos durante esta fase incluyen la gestin de confi guracin y
cambio

workfl ow, workfl ow de gestin de proyectos, las nuevas operaciones y workfl de soporte

ow, y el workfl de gestin de la infraestructura.

Operaciones y soporte Workfl ow Las operaciones y el flujo de trabajo de soporte, como se

puede adivinar,

aborda problemas relacionados con el soporte de la versin actual del software y el

funcionamiento del

soft ware a diario. Las actividades incluyen la creacin de planes para la operacin y el apoyo
de la

producto de software una vez que se ha implementado, creando capacitacin y

documentacin del usuario, poniendo

en lugar de los procedimientos de respaldo necesarios, monitoreando y optimizando el

desempeo del

software y realizar mantenimiento correctivo en el software. Este es el trabajo que se

convierte

activo durante la fase de construccin; su nivel de actividad aumenta a lo largo de la transicin

y, finalmente, la fase de produccin. El trabajo finalmente termina cuando la versin actual de

el software se reemplaza por una nueva versin. Muchos desarrolladores tienen la falsa
impresin de que

una vez que el software ha sido entregado al cliente, su trabajo ha finalizado. En la mayora de
los casos, el

el trabajo de soporte del producto de software es mucho ms costoso y consume mucho

tiempo que el

desarrollo original. En ese punto, el trabajo del desarrollador puede haber comenzado.

Trabajo de gestin de la infraestructura La gestin primaria de infraestructura workfl ow

El objetivo es apoyar el desarrollo de la infraestructura necesaria para desarrollar objetivos

orientados

sistemas. Actividades tales como desarrollo y modificacin de bibliotecas, estndares,

y los modelos empresariales son muy importantes. Cuando el desarrollo y mantenimiento de

un
el modelo de arquitectura de dominio de problemas va ms all del alcance de un solo
proyecto y la reutilizacin

va a ocurrir, el flujo de trabajo de gestin de la infraestructura es esencial. Otra muy

importante

El conjunto de actividades entre proyectos es la mejora del proceso de desarrollo de software.

Debido a que las actividades en este trabajo tienden a afectar muchos proyectos y el Proceso
Unificado

se enfoca solo en un proyecto especfico, el Proceso Unificado tiende a ignorar estas

actividades (es decir,

estn simplemente ms all del alcance y el propsito del Proceso Unificado).

Modifi caciones y extensiones existentes de Workfl ow Adems de los workfls que eran

agregado a las deficiencias de direccin contenidas en el Proceso Unificado, los flujos de

trabajo existentes tenan que

ser modifi cado y / o extendido a la fase de produccin. Estos trabajos incluyen la prueba,

implementacin, entorno, gestin de proyectos y configuracin y gestin de cambios

workfl ows.

Trabajo de prueba Para que se desarrollen sistemas de informacin de alta calidad, se deben
realizar pruebas

hecho en cada entregable, incluidos los creados durante la fase de inicio. De lo contrario,
menos

que los sistemas de alta calidad sern entregados al cliente.

Trabajo de implementacin Los sistemas heredados existen en la mayora de las corporaciones

hoy en da, y estos sistemas

tienen bases de datos asociadas que deben convertirse para interactuar con los nuevos
sistemas.

Debido a la complejidad de implementar nuevos sistemas, la conversin requiere una

planificacin significativa.

Por lo tanto, las actividades en el trabajo de implementacin deben comenzar en la fase de

inicio

en lugar de esperar hasta el final de la fase de construccin, como lo sugiere el Proceso

Unificado.

Trabajo del entorno El trabajo del entorno debe modificarse para incluir actividades

relacionado con la configuracin del entorno de operaciones y produccin. El trabajo real

realizado

es similar al trabajo relacionado con la configuracin del entorno de desarrollo que fue

realizado durante la fase de inicio. En este caso, el trabajo adicional se realiza durante
la fase de transicin.

Workfl ow de Project Management Aunque el workfl de gestin de proyectos no

incluir el personal del proyecto, administrar los contratos entre los clientes y proveedores, y

administrar el presupuesto del proyecto, estas actividades son cruciales para el xito de
cualquier software

projecto de desarrollo. Sugerimos extender la gestin de proyectos para incluir estas

actividades.

Este es el flujo de trabajo que, adems, debe ocurrir en la fase de produccin para abordar
problemas tales como

capacitacin, administracin de personal y administracin de relaciones con clientes.

Confi guracin y gestin del cambio Workfl ow La confi guracin y la gestin del cambio

workfl ow se extiende a la nueva fase de produccin. Actividades realizadas durante el

La fase de produccin incluye la identificacin de posibles mejoras en el sistema operativo y

evaluar el impacto potencial de los cambios propuestos. Una vez que los desarrolladores han
identificado estos

cambios y comprender su impacto, pueden programar los cambios que se realizarn y

desplegarn

con lanzamientos futuros.

La Figura 1-17 muestra los captulos en los que las fases del Proceso Unificado Mejorado y

los trabajos estn cubiertos. Dada la subcontratacin off-shore y la automatizacin de la

informacin

Captulos de fases UP mejoradas

Inicio 2-4

Elaboracin 3-11

Construccin 8, 12

Transicin 12-13

Produccin 13

Mejorado UP

Trabajos de ingeniera Captulos

Business Modeling 2-5

Requisitos 3-5, 10
Anlisis 3-7

Diseo 7-11

Implementacin 9, 12

Prueba 4-7, 12

Despliegue 13

Mejorado UP

Apoyo a los cuadros de trabajo Captulos

Project Management 2, 13

Confi guracin y

Gestin del cambio

13

Medio ambiente 2

Operaciones y Soporte 13

Infraestructura

administracin

FIGURA 1-17 El proceso unifi cado mejorado y la organizacin de libros de texto

tecnologa, 22 en este libro de texto, nos enfocamos principalmente en la fase de elaboracin

y el negocio

modelado, requisitos, anlisis, diseo y trabajo de gestin de proyectos del

Proceso Unifi ed Mejorado. Sin embargo, como muestra la Figura 1-17, las otras fases y flujos
de trabajo

estn cubiertos. En muchos entornos de desarrollo de sistemas orientados a objetos de hoy, el

cdigo

generacin es compatible. Nosotros, desde una perspectiva comercial, creemos que las
actividades asociadas

con estos workfl ows son los ms importantes.

EL LENGUAJE DE MODELADO UNIFICADO

Hasta 1995, los conceptos de objeto eran populares, pero se implementaron de muchas
maneras diferentes por

Diferentes desarrolladores. Cada desarrollador tena su propia metodologa y notacin (por

ejemplo,
Booch, Coad, Moses, OMT, OOSE, SOMA) .23 En 1995, Rational Soft ware trajo

tres lderes de la industria juntos para crear un enfoque nico para los sistemas orientados a
objetos

desarrollo. Grady Booch, Ivar Jacobson y James Rumbaugh trabajaron con otros para

crear un conjunto estndar de tcnicas de diagramacin conocido como el lenguaje de

modelado unificado

(UML) El objetivo de UML era proporcionar un vocabulario comn de objetos orientados

trminos y tcnicas de diagramacin lo suficientemente ricas como para modelar cualquier

proyecto de desarrollo de sistemas

desde el anlisis hasta la implementacin. En noviembre de 1997, la gestin de objetos

Grupo (OMG) formalmente aceptado UML como el estndar para todos los desarrolladores de
objetos. Durante el

los aos siguientes, el UML ha pasado por mltiples revisiones menores. La versin actual

de UML es la Versin 2.5.

La versin 2.5 del UML define un conjunto de cinco tcnicas de diagramacin utilizadas para
modelar un

sistema. Los diagramas se dividen en dos grupos principales: uno para modelar la estructura

de un sistema y uno para el comportamiento de modelado. Los diagramas de estructura

proporcionan una forma de representar

los datos y las relaciones estticas en un sistema de informacin. Los diagramas de estructura
incluyen

clase, objeto, paquete, implementacin, componente, estructura compuesta y diagramas de

profi le.

Los diagramas de comportamiento proporcionan al analista una forma de describir las

relaciones dinmicas entre

las instancias u objetos que representan el sistema de informacin comercial. Tambin

permiten modelar

del comportamiento dinmico de los objetos individuales a lo largo de su vida. El

comportamiento

los diagramas apoyan al analista en el modelado de los requisitos funcionales de una

informacin en evolucin

sistema. Los diagramas de modelado del comportamiento incluyen actividad, secuencia,

comunicacin,

descripcin general de interaccin, temporizacin, mquina de estado de comportamiento,

mquina de estado de protocolo y caso de uso

Diagramas.24 La Figura 1-18 proporciona una descripcin general de estos diagramas.

22 Vase Thomas L. Friedman, El mundo es plano: una breve historia del siglo XXI, actualizada
y ampliada

Edicin (Nueva York: Farrar, Straus y Giroux, 2006); Daniel H. Pink, Una mente completamente
nueva: por qu los cerebros correctos

Rule the Future (Nueva York: Riverhead Books, 2006).

23 Ver Grady Booch, Anlisis y Diseo Orientado a Objetos con Aplicaciones, 2da Ed. (Redwood
City, CA: Benjamin /

Cummings, 1994); Peter Coad y Edward Yourdon, Anlisis orientado a objetos, 2nd Ed.
(Englewood Cliff s, NJ:

Yourdon Press, 1991); Peter Coad y Edward Yourdon, diseo orientado a objetos (Englewood
Cliff s, NJ: Yourdon

Press, 1991); Brian Henderson-Sellers y Julian Edwards, Libro dos del conocimiento orientado a
objetos: el trabajo

Object (Sydney, Australia: Prentice Hall, 1994); James Rumbaugh, Michael Blaha, William
Premerlani, Frederick

Eddy y William Lorensen, Modelado y Diseo Orientado a Objetos (Englewood Cliff, NJ:
Prentice Hall, 1991);

Ivar Jacobson, Magnus Christerson, Patrik Jonsson y Gunnar Overgaard, Ingeniera de software
orientado a objetos:

Un enfoque de caso de uso (Wokingham, Inglaterra: Addison-Wesley, 1992); Ian Graham,

migrando a la tecnologa de objetos

(Wokingham, Inglaterra: Addison-Wesley, 1994).

24 El material contenido en esta seccin se basa en el Lenguaje de modelado unificado:

superestructura versin 2.4,

ptc / 2010-11-14 (www.uml.org). Otras referencias tiles incluyen a Michael Jesse Chonoles y
James A. Schardt,

UML 2 para Dummies (Indianapolis, IN: Wiley, 2003); Hans-Erik Eriksson, Magnus Penker, Brian
Lyons y David

Fado, UML 2 Toolkit (Indianapolis, IN: Wiley, 2004); Kendall Scott, Fast Track UML 2.0
(Berkeley, CA: Apress,

2004). Para una descripcin completa de todos los diagramas, vea www.uml.org.

Dependiendo de en qu parte del proceso de desarrollo se encuentre el sistema, juegan

diferentes diagramas

un papel ms importante. En algunos casos, la misma tcnica de diagramacin se usa a lo largo

de
el proceso de desarrollo. En ese caso, los diagramas comienzan muy conceptuales y abstractos.

A medida que el sistema se desarrolla, los diagramas evolucionan para incluir detalles que
finalmente conducen a

generando y desarrollando cdigo En otras palabras, los diagramas pasan de documentar el

requisitos para disear el diseo. En general, la notacin consistente, la integracin entre

las tcnicas de diagramacin y la aplicacin de los diagramas en todo el desarrollo

proceso hace que UML sea un lenguaje poderoso y flexible para analistas y desarrolladores.
Luego

Los captulos proporcionan ms detalles sobre el uso de un subconjunto del UML en el anlisis
de sistemas orientados a objetos

Diagramas de estructura

Clase Ilustrar las relaciones entre las clases modeladas Anlisis, Diseo

en el sistema

Objeto Ilustrar las relaciones entre los objetos modelados Anlisis, Diseo

en el sistema; utilizado cuando instancias reales de las clases

comunicar mejor el modelo

Paquete Agrupe otros elementos UML para formar Anlisis, Diseo,

construcciones de alto nivel Implementacin

Despliegue Muestra la arquitectura fsica del sistema; tambin puede diseo fsico,

se usar para mostrar los componentes de software que se estn implementando.

en la arquitectura fsica

Componente Ilustra las relaciones fsicas entre el software Diseo fsico,

Implementacin de componentes

Diseo de estructura compuesta Ilustrar la estructura interna de una clase, es decir, el

anlisis, diseo

relaciones entre las partes de una clase

Profi le Usado para desarrollar extensiones para el UML en s mismo Ninguno

Diagramas de comportamiento

Actividad Ilustrar trabajos de negocios independientes de las clases, el flujo Anlisis, Diseo

de actividades en un caso de uso, o diseo detallado de un mtodo

Secuencia Modelar el comportamiento de los objetos dentro de un caso de uso; Anlisis,
Diseo

se centra en el orden basado en el tiempo de una actividad

Comunicacin Modelar el comportamiento de los objetos dentro de un caso de uso; Anlisis,

Diseo

centrarse en la comunicacin entre un conjunto de

objetos colaboradores de una actividad

Descripcin general de la interaccin Ilustrar una visin general del flujo de control de un
proceso Anlisis, diseo

Timing Ilustre la interaccin entre un conjunto de objetos y el estado Analysis, Design

cambios que atraviesan a lo largo de un eje de tiempo

Mquina de estado de comportamiento Examine el comportamiento de una clase Anlisis,

Diseo

Mquina de estado de protocolo Ilustrar las dependencias entre los diferentes Anlisis,
Diseo

interfaces de una clase

Use-Case Capture requisitos comerciales para el sistema e ilustre Analysis

la interaccin entre el sistema y su entorno

FIGURA 1-18 Resumen del diagrama UML 2.5

y diseo. En particular, estos captulos describen actividad, caso de uso, clase, objeto,
secuencia,

diagramas de comunicacin, paquete e implementacin y las mquinas de estado de

comportamiento. Nosotros

tambin introduce un diagrama UML opcional, el diagrama de navegacin de Windows, que es

una extensin

a la mquina de estado de comportamiento que se utiliza para disear la navegacin del

usuario a travs de una informacin

interfaces de usuario del sistema.

APLICANDO LOS CONCEPTOS EN PATTERSON

HIPERMERCADO

Este curso introducir muchos conceptos nuevos sobre el anlisis orientado a objetos y

diseo. Para que estos conceptos sean ms relevantes y comprensibles, aplicaremos el

conceptos, presentados en cada captulo, a una empresa ficticia llamada Patterson Superstore.
Patterson es una cadena minorista establecida en Pittsburgh, Pensilvania, en 1985.
Actualmente, Patterson

utiliza una aplicacin mvil para facilitar el pedido de recetas, la notificacin y los servicios de
autorrefrigeracin.

Este servicio es ampliamente utilizado por la base de clientes de Patterson, y Patterson ha

apalancado

esta aplicacin mvil para obtener una ventaja sobre los competidores menos avanzados
tcnicamente.

Los clientes ahora quieren usar esta tecnologa para acceder a los servicios de clnicas de salud.
El vicio

El presidente de los servicios de farmacia, Max Ross, quisiera aprovechar esta oportunidad
para posicionarse

Patterson como lder en el uso del uso de la tecnologa para el acceso a la clnica. El sistema
que l

las previsiones permitirn la comunicacin en tiempo real con el personal mdico (audio,
video,

y texto), programacin de citas mviles, evaluacin de telesalud y diagnstico de menores

problemas a travs de videollamadas. A lo largo del libro, volveremos a visitar Patterson

Supertienda para ver cmo los conceptos presentados en cada captulo afectan a este
proyecto.

Puede encontrar el resto del caso en: www.wiley.com/go/dennis/casestudy

REVISIN DEL CAPTULO

Despus de leer y estudiar este captulo, usted debera ser capaz de:

Describa las cuatro fases principales del Ciclo de vida de desarrollo de sistemas (SDLC).

Explicar la evolucin de las metodologas de desarrollo de sistemas desde centradas en

procesos a centradas en datos y basadas en RAD

metodologas.

Explicar las diferentes funciones desempeadas por un analista de sistemas en el proceso de

desarrollo de sistemas de informacin.

Describe las caractersticas bsicas de los sistemas orientados a objetos: objetos, atributos,
mtodos, mensajes, encapsulacin,

ocultacin de informacin, polimorfismo, enlace dinmico y herencia.

Discutir las tres caractersticas bsicas de todos los anlisis de sistemas orientados a objetos y
el enfoque de diseo: uso de casos de uso,

centrado en la arquitectura, e iterativo e incremental.

Describe el proceso Unifi ed.

Enumere y categorice, en cuanto a su propsito principal, los diferentes diagramas asociados
con el Modelado Unificado

Idioma (UML).

TRMINOS CLAVE

Clases abstractas

Desarrollo gil

Una especie de

Modelo de anlisis

Anlisis parlisis

Fase de anlisis

Estrategia de anlisis

Trabajo de anlisis

Comit de aprobacin

Centrado en la arquitectura

Diseo arquitectnico

Sistema tal como est

Atributo

Comportamiento

Diagramas de comportamiento

Vista comportamental

Analista de negocios

Modelado de negocios

workfl ow

Agente de cambio

Gestin del cambio

analista

Clase

Clases concretas

Confi guracin y cambio

workfl de gestin
Construccin

Fase de construccin

Base de datos y archivo

especifi cacin

Centrado en datos

metodologa

Entregable

Despliegue workfl ow

Modelo de diseo

Fase de diseo

Diseo prototipo

Estrategia de diseo

Diseo workfl ow

Enlace dinmico

Vista dinmica

Fase de elaboracin

Encapsulacin

Trabajo de ingeniera

Ambiente

workfl ow

Vista externa

Programacin extrema (XP)

Anlisis de viabilidad

Vista funcional

Refinamiento gradual

Fase de implementacin

Trabajo de implementacin

Fase de inicio

Incremental

Ocultacin de informacin

Analista de infraestructura
Gestin de la infraestructura

workfl ow

Heredar

Herencia

Ejemplo

Diseo de interfaz

Iterativo

Mensaje

Mtodo

Metodologa

Objeto

Gestin de objetos

Grupo (OMG)

Orientado a objetos

metodologas

Operaciones y soporte

workfl ow

Desarrollo paralelo

Desarrollo gradual

Fases

Fase de planeamiento

Polimorfismo

Metodologa centrada en el proceso

Fase de produccin

Diseo de programa

Programador

Gestin de proyectos

Gestin de proyectos

workfl ow

Gerente de proyecto

Plan de proyecto
Patrocinador de proyecto

Prototipos

Desarrollo rpido de aplicaciones

(RAD)

Recopilacin de requisitos

Requisitos workfl ow

Mel

Estado

Enlace esttico

Vista esttica

Vista estructural

Diagramas de estructura

Diseo estructurado

Subclase

Superclase

Plan de apoyo

Propuesta del sistema

Prototipo del sistema

Solicitud del sistema

Especificacin del sistema

Analizador de sistemas

Vida de desarrollo de sistemas

ciclo (SDLC)

Escritor tcnico

Prueba workfl ow

Prototipado de rowaway

Plan de entrenamiento

Fase de transicin

Lenguaje de modelado unificado

(UML)

Caso de uso
Caso de uso impulsado

Versin

Desarrollo de cascadas

Workfl ows

El plan de trabajo

PREGUNTAS

1. Comparar y contrastar fases, pasos, tcnicas y

entregables.

2. Describe las fases principales en el SDLC.

3. Describe los pasos principales en la fase de planificacin.

Cules son los principales entregables?

4. Describe los pasos principales en la fase de anlisis.

Cules son los principales entregables?

5. Describe los pasos principales en la fase de diseo. Qu

son los principales entregables?

6. Describe los pasos principales en la implementacin

fase. Cules son los principales entregables?

7. Cules son los roles de un patrocinador del proyecto y el

comit de aprobacin?

8. Qu significa el refinamiento gradual en el contexto de

SDLC?

9. Compara y contrasta metodologas centradas en el proceso

con metodologas centradas en datos.

10. Comparar y contrastar metodologas basadas en el diseo estructurado

en general a las metodologas basadas en RAD en

general.

11. Compara y contrasta programacin extrema y

la creacin de prototipos desechables.

12. Describe los principales elementos y problemas con la cascada

desarrollo.

13. Describe los elementos principales y problemas con el paralelo

desarrollo.

14. Describe los elementos principales y los problemas con las fases

desarrollo.

15. Describe los principales elementos y problemas con

creacin de prototipos.

16. Describe los elementos principales y los problemas con el desechable

creacin de prototipos.

17. Describe los principales elementos y problemas con XP.

18. Describe los principales elementos y problemas con

Mel.

19. Cules son los factores clave en la seleccin de una metodologa?

20. Cules son los principales roles desempeados por un analista de sistemas

en un equipo de proyecto?

21. Compare y contraste la funcin de un analista de sistemas,

analista de negocios y analista de infraestructura.

22. Cul es la diferencia entre clases y objetos?

23. Qu son mtodos y mensajes?

24. Por qu se ocultan la encapsulacin y la informacin?

caractersticas importantes de los sistemas orientados a objetos?

25. Qu se entiende por polimorfismo cuando se aplica a

sistemas orientados a objetos?

26. Compara y contrasta la unin dinmica y esttica.

27. Qu es un caso de uso?

28. Qu se entiende por uso-caso conducido?

29. Qu es el lenguaje de modelado unificado?

30. Quin es el Grupo de gestin de objetos?

31. Cul es el propsito principal de los diagramas de estructura?

Da algunos ejemplos de diagramas de estructura.

32. Para qu se usan los diagramas de comportamiento? Dar algo

ejemplos de diagramas de comportamiento.

33. Por qu es importante que un enfoque OOSAD sea

centrado en la arquitectura?

34. Qu significa que un enfoque OOSAD sea

incremental e iterativo?

35. Cules son las fases y los trabajos de Unifi ed?

Proceso?

36. Compare las fases del proceso Unifi ed con el

fases del modelo de cascada

37. Qu fase en el SDLC es ms importante? Por qu?

38. Describa los principales elementos y problemas con un objetivo orientado

enfoque para desarrollar sistemas de informacin.

CEREMONIAS

A. Supongamos que usted es un gerente de proyecto que usa una cascada

metodologa basada en el desarrollo en un gran y

proyecto complejo. Su gerente acaba de leer la ltima

artculo en Computerworld que aboga por reemplazar

esta metodologa con prototipos y viene a ti

solicitando que cambies Qu diras?

B. Los tipos bsicos de metodologas discutidos en este

el captulo se puede combinar e integrar para formar un nuevo

metodologas hbridas. Supongamos que se combinara

La creacin de prototipos desechables con el uso de la cascada

desarrollo. Qu aspecto tendra la metodologa?

me gusta? Haz un dibujo (similar a los de las Figuras 1-2

a travs de 1-7). Cmo funcionara esta nueva metodologa?

comparar con los dems?

C. Busque en la Web diferentes tipos de oportunidades de trabajo

que estn disponibles para las personas que quieren un analista

posiciones? Compare y contraste las habilidades que los anuncios

pregunte por las habilidades que presentamos en este captulo.

D. Th tinta sobre su posicin ideal de analista. Escribe un anuncio

contratar a alguien para ese puesto. Qu requisitos

tendra el trabajo? Qu habilidades y experiencia

ser requerido? Cmo podra un solicitante demostrar

tener las habilidades y experiencia apropiadas?

E. Usando su motor de bsqueda web favorito, encuentre una alternativa

descripciones de las caractersticas bsicas de objectoriented

sistemas.

F. Buscar programacin orientada a objetos en Wikipedia.

Escribe un breve informe basado en su entrada.

G. Elija un lenguaje de programacin orientado a objetos,

como C ++, Java, Objective-C, Smalltalk o VB.Net,

y use la Web para descubrir cmo el lenguaje soporta

las caractersticas bsicas de los sistemas orientados a objetos.

H. Suponga que le han asignado la tarea de crear

un sistema orientado a objetos que podra ser utilizado para

ayudar a los estudiantes a encontrar un apartamento apropiado

para vivir en el prximo semestre Cuales son los diferentes tipos

de objetos (es decir, clases) que desea incluir en

tu sistema? Qu atributos o mtodos quieres?

Quieres incluir en su definicin? Es posible que

organizarlos en una jerarqua de herencia? Si es as, hazlo

eso. Si no, por qu no?

I. Crear una jerarqua de herencia que podra usarse para

representan las siguientes clases: contador, cliente,

departamento, empleado, gerente, organizacin y

vendedor.

J. Investigar el proceso Rational Unifi ed de IBM (RUP) en el

Web. RUP es una versin comercial que extiende aspectos de

el proceso Unifi ed. Escriba un breve memo que describa cmo

est relacionado con el proceso Unifi ed como se describe en este captulo.

(Sugerencia: un buen sitio web para comenzar es www-01.

ibm.com/soft ware / rational / rup /)

K. Supongamos que usted es un gerente de proyecto que normalmente tiene

estado usando una metodologa basada en desarrollo de cascada

en un proyecto grande y complejo. Tu gerente tiene

acaba de leer el ltimo artculo en Computerworld que defiende

reemplazando esta metodologa con el Unifi ed

Procese y llegue a usted solicitndole que cambie.

Qu ests diciendo?

L. Supongamos que eres un analista que trabaja para una pequea empresa

desarrollar un sistema de contabilidad. Lo usaras?

el Proceso Unificado para desarrollar el sistema, o lo hara

prefieres uno de los otros enfoques? Por qu?

M. Supongamos que usted es un analista que desarrolla una nueva informacin

sistema para automatizar las transacciones de venta

y administrar el inventario para cada tienda minorista en un gran

cadena. El sistema se instalar en cada tienda

e intercambiar datos con una computadora central en el

Oficina central de la compaa. Usaras el Unifi ed?

Proceso para desarrollar el sistema, o preferiras

uno de los otros enfoques? Por qu?

N. Suponga que usted es un analista que trabaja para una pequea empresa

desarrollar un sistema de contabilidad. Que tipo de

metodologa que usaras? Por qu?

O. Supongamos que es un analista que est desarrollando un nuevo ejecutivo

sistema de informacin destinado a proporcionar una estrategia clave

informacin de bases de datos corporativas existentes

a los altos ejecutivos para ayudarlos a tomar decisiones.

Qu tipo de metodologa usaras? Por qu?

P. Investigue el lenguaje de modelado unificado en el

Web. Escriba un resumen de noticias de prrafo que describa el

estado actual del UML. (Sugerencia: un buen sitio web con

que para comenzar es www.uml.org).

Q. Investigue el Object Management Group (OMG) en el

Web. Escribir un informe que describa el propsito del OMG

y con lo que est involucrado adems del UML. (Sugerencia: A

un buen sitio web con el que comenzar es www.omg.org).

R. Usando la Web, encuentre un conjunto de herramientas CASE que soportan

el UML Un par de ejemplos incluyen Poseidn,

Rational Rose y Visual Paradigm. Encuentra al menos dos

Ms. Escribe un breve informe que describa qu tan bien

apoyar el UML, y hacer una recomendacin sobre

cul crees que sera mejor para un equipo de proyecto

para usar en el desarrollo de una informacin orientada a objetos

sistema que usa el UML

MINICASES

1. Barbara Singleton, gerente de ventas regionales occidentales

en la compaa WAMAP, solicit que el IS

departamento desarrollar una gestin de fuerza de ventas y

sistema de seguimiento que le permitira controlar mejor

el desempeo de su personal de ventas. Desafortunadamente,

debido a la acumulacin masiva de trabajo que enfrenta el IS

departamento, su solicitud recibi baja prioridad.

Despus de seis meses de inaccin por parte del departamento de SI,

Brbara decidi tomar el asunto en sus propias manos.

Basado en el consejo de amigos, Barbara compr

software de base de datos simple y construy una fuerza de ventas

sistema de gestin y seguimiento por s misma.

Aunque el sistema de Barbara ha sido "completado"

durante aproximadamente seis semanas, todava tiene muchas caractersticas que

no funciona correctamente, y algunas funciones estn llenas

de errores El asistente de Brbara desconfa de la

sistema que ella secretamente ha vuelto a usar su viejo

sistema basado en papel, porque es mucho ms confiable.

Una noche, durante la cena, Barbara se quej

un amigo analista de sistemas, "No s lo que pas

mal con este proyecto. Pareca bastante simple

yo. Estos individuos IS queran que siguiera este elaborado

conjunto de pasos y tareas, pero no pens que todo eso realmente

aplicado a un sistema basado en PC. Solo pens que podra

construir este sistema y modificarlo hasta que tenga lo que

Yo quera sin todo el alboroto y la molestia de la metodologa

los tipos IS estaban presionando. Quiero decir, no lo hace

que solo se aplica a sus sistemas grandes y caros? "

Asumiendo que eres el amigo analista de sistemas de Barbara,

cmo responderas a su queja?

2. Marcus Weber, gerente de proyecto de IS en ICAN Mutual

Insurance Co., est revisando los arreglos de personal

para su prximo gran proyecto, el desarrollo de un

asistente experto del asegurador basado en el sistema. Esto nuevo

sistema implicar una forma completamente nueva para los suscriptores

para realizar sus tareas. El asistente del suscriptor

sistema funcionar como una especie de suscripcin

supervisor, revisando los elementos clave de cada aplicacin,

verificar la consistencia en el asegurador

decisiones, y asegurar que no haya factores crticos

sido pasado por alto El objetivo del nuevo sistema es

mejorar la calidad de las decisiones de los suscriptores y

para mejorar la productividad de los suscriptores Se espera

que el nuevo sistema cambiar sustancialmente el camino

el personal de suscripcin hace su trabajo.

Marcus est consternado al saber que debido al presupuesto

restricciones, debe elegir entre uno de los dos disponibles

los miembros del personal. Barry Filmore ha tenido considerables

experiencia y entrenamiento en lo individual y organizacional

comportamiento. Barry ha trabajado en varios otros

proyectos en los que los usuarios finales tenan que hacer signifi cado

ajustes al nuevo sistema, y Barry parece

tener una habilidad especial para anticipar problemas y suavizar

la transicin a un nuevo ambiente de trabajo. Marcus tena

esperaba tener la participacin de Barry en este proyecto.

El otro miembro del personal potencial de Marcus es Kim Danville.

Antes de unirse a ICAN Mutual, Kim tuvo una considerable

experiencia laboral con el sistema experto

tecnologas que ICAN ha elegido para este experto

proyecto de sistema Marcus estaba contando con Kim para

ayudar a integrar la nueva tecnologa del sistema experto en

El entorno de sistemas de ICAN, y tambin para proporcionar

capacitacin en el trabajo y puntos de vista para los otros desarrolladores

en este equipo

Dado que el presupuesto de Marcus solo le permitir

agregar a Barry o Kim a este equipo de proyecto, pero no a ambos,

Qu opcin recomiendas para l? Justifica tu

responder.

Joe Brown, el presidente de Roanoke Manufacturing,

solicit que Jack Jones, el gerente de departamento de MIS,

investigar la viabilidad de vender sus productos

a travs de la web. Actualmente, el departamento de MIS todava est

utilizando un mainframe de IBM como su implementacin principal

ambiente. Como primer paso, Jack contact a su

amigos en IBM para ver si tenan alguna sugerencia sobre

cmo Roanoke Manufacturing podra avanzar hacia el apoyo

ventas en un ambiente de comercio electrnico

manteniendo su mainframe como su sistema principal.

Sus amigos explicaron que IBM (www.ibm.com) ahora

admite Java y Linux en sus mainframes. Jack tiene

tambin se enter de que IBM posee Rational (www-01.ibm.

com / soft ware / rational /), el creador de UML y

el proceso Unifi ed. Los amigos de Jack sugirieron que Jack

investigar el uso de sistemas orientados a objetos como base para

desarrollando el nuevo sistema. Tambin sugirieron que

utilizando el proceso Rational Unifi ed (RUP), Java y virtual

Mquinas Linux en su mainframe actual como una forma

para apoyar el movimiento hacia una electrnica distribuida

sistema de comercio protegera su inversin actual

en sus sistemas heredados mientras permite que el nuevo sistema

ser desarrollado de una manera ms moderna. Aunque

Los amigos de IBM de Jack fueron muy persuasivos, Jack sigue siendo un

poco cauteloso acerca de mover su operacin de una estructura

enfoque de sistemas a este nuevo objeto orientado

enfoque. Asumiendo que eres uno de Jack's IBM

amigos, cmo lo convenceran de avanzar hacia

usando un mtodo de desarrollo de sistemas orientado a objetos,

como RUP, y el uso de Java y Linux como base para

desarrollando e implementando el nuevo sistema en Roanoke

Mainframe actual de fabricacin?