Documente Academic
Documente Profesional
Documente Cultură
Anlisis y diseo 1
Introduccin 1
Planificacin 3
Anlisis 3
Diseo 4
Implementacin 4
Diseo estructurado 6
Desarrollo gil 12
Metodologa 15
Analista de negocios 18
Analista de Sistemas 18
Analista de Infraestructura 18
Gerente de proyecto 19
Sistemas 19
Clases y objetos 19
Mtodos y mensajes 20
Herencia 21
y Diseo (OOSAD) 23
Uso-Case Driven 24
Centrado en la arquitectura 24
Iterativo e Incremental 24
Anlisis y diseo 25
El proceso unificado 25
Fases 26
Workfl ows 28
superstore 36
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
OBJETIVOS
Estar familiarizado con los diferentes roles desempeados y las habilidades de un analista de
sistemas
Familiarizarse con los principios fundamentales del anlisis de sistemas orientados a objetos
y diseo
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
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
encontr que el 53 por ciento de todos los proyectos de SI del gobierno de EE. UU. fueron
abandonados. Desafortunadamente,
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
con varios conceptos fundamentales y muchas tcnicas prcticas que puedes usar para
alrededor. Los analistas de sistemas trabajan con una variedad de personas y aprenden cmo
hacen negocios.
misin. Los analistas de sistemas sienten la satisfaccin de ver los sistemas que disearon y
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
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,
(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
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
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
Para obtener ms informacin sobre el problema, consulte Capers Jones, Patterns of Soft
ware System Failure and Success (Londres:
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
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
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
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
en la fase de implementacin para producir el sistema real. Cada fase refina y elabora
Planificacin
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
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.
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
todo el SDLC. El producto para la gestin del proyecto es un plan de proyecto, que
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.
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
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
sistema. El concepto de sistema se usa luego como base para desarrollar un conjunto de
negocios
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
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
bases de datos y archivos que sern necesarios. Aunque la mayora de las decisiones
estratgicas sobre la
los pasos en la fase de diseo determinan exactamente cmo funcionar el sistema. La fase de
diseo
1. La estrategia de diseo se desarrolla por primera vez. Aclara si el sistema ser desarrollado
2. Esto conduce al desarrollo del diseo de arquitectura bsica para el sistema, que
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
3. Se desarrollan las especifi caciones de la base de datos y del archivo. Esa es la definicin
exacta de qu datos
4. El equipo de analistas desarrolla el diseo del programa, que define los programas que
Implementacin
recibe la mayor atencin, porque para la mayora de los sistemas es el ms largo y el ms caro
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
es el desarrollo de un plan de capacitacin para ensear a los usuarios cmo usar el nuevo
sistema y
incluye una revisin formal o informal despus de la implementacin, as como una revisin
sistemtica
Una metodologa es un enfoque formal para implementar el SDLC (es decir, es una lista de
pasos
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
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
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
centrarse primero en definir los elementos principales del sistema (por ejemplo, sndwiches,
almuerzos) y mirar
fases y la cantidad de tiempo y esfuerzo dedicado a cada uno.3 En los primeros das de la
informtica,
usar al escribir programas para una clase de programacin. Puede funcionar para programas
pequeos que
(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
de Comercio, 1993.
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
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
desarrollo gil.
Diseo estructurado
Una cascada
Basado en desarrollo
Metodologa
enfoque al SDLC que se mueve lgicamente de una fase a la siguiente. Numerosos procesos
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).
para describir los procesos comerciales bsicos y los datos que los respaldan. Tradicional
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
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
muchos meses o aos). Si el equipo del proyecto no cumple con los requisitos importantes,
costoso
en papel; Cun probable es que recuerde las luces interiores que se encienden cuando las
puertas
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
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.
hecho en un subproyecto puede afectar a otro, y el final del proyecto puede requerir signifi
cado
esfuerzos de integracin.
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
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
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
(IT), los requisitos de los sistemas tienden a expandirse. Th era menos de un problema cuando
se usa
Desarrollo por fases Una metodologa gradual basada en el desarrollo divide un sistema
general en un
concepto, y el equipo del proyecto, los usuarios y el patrocinador del sistema clasifican los
requisitos en
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).
problemas que surgieron de la experiencia de los usuarios con la versin 1. La versin 2 est
diseada y
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
El mayor inconveniente del desarrollo por fases es que los usuarios comienzan a trabajar con
sistemas que
e incluirlos en la primera versin y administrar las expectativas de los usuarios a lo largo del
camino.
el sistema esta completo Con estas metodologas, los conceptos bsicos de anlisis y diseo
son
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.
que proporciona algunas caractersticas ms. Este proceso contina en un ciclo hasta que los
analistas, los usuarios,
hasta que sea aceptado como el nuevo sistema (vea la Figura 1-5).
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.
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
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).
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
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,
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
El equipo podra escribir una parte del programa con datos falsos para asegurarse de que
podran hacer una
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
en el sistema final.
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.
sistemas.
Desarrollo gil5
Una tercera categora de metodologas de desarrollo de sistemas todava est surgiendo hoy:
desarrollo gil.
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 cliente.
proceso.
Los clientes y los desarrolladores trabajan juntos para resolver el problema comercial.
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.
procesos.
Con base en estos principios, las metodologas giles se centran en la racionalizacin del
desarrollo del sistema
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
5 Estas buenas fuentes de informacin sobre el desarrollo gil y los sistemas orientados a
objetos son S. W. Ambler, Agile
Desarrollo: Principios, patrones y prcticas (Upper Saddle River, NJ: Prentice Hall, 2003).
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
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
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
el proceso de desarrollo de sistemas puede estar garantizado. Una cuarta gran crtica se basa
en si
Incluso con estas crticas, dado el potencial de enfoques giles para abordar el
enfoques deben ser considerados en algunas circunstancias. Adems, muchas de las tcnicas
alentado atendiendo al propsito subyacente del manifiesto gil y el
(XP) y Scrum.
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.
Wesley, 2000); C. Larman, Agile & Iterative Development: A Manager's Guide (Boston:
Addison-Wesley, 2004); METRO.
Las pruebas y las prcticas de codificacin eficiente son el ncleo de XP. El cdigo se prueba
todos los das y es
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
evolucionar a medida que las partes interesadas entienden el potencial que tiene la tecnologa
para proporcionar un
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 los forasteros que se mezclan con los iniciados podra ser demasiado optimista. XP requiere
una gran cantidad de
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
est en duda Finalmente, la metodologa necesita mucha entrada del usuario en el sitio, algo a
lo que
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
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).
sobre outsourcing fuera de la costa, vea P. Th. ibodeau, "ITAA Panel Debates Outsourcing
Pros, Cons", Computerworld
2003).
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,
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.
controle parte del caos innato, el desarrollo de Scrum se centra en algunas prcticas clave.
Equipos
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
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
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
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
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
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
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,
tener una metodologa "aprobada" para tener varias opciones de metodologa para no tener
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
proyecto y requieren tiempo extra para aprender. Sin embargo, una vez que son adoptados y
el equipo
Claridad de los requisitos del usuario Cuando los requisitos del usuario para un sistema no son
claros, es
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
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
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,
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
Complejidad del sistema Los sistemas complejos requieren un anlisis y diseo cuidadoso y
detallado.
Estructurado
gil
Metodologas
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
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
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
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
Las metodologas basadas en las cascadas son la peor opcin cuando el tiempo es escaso
porque
si un proyecto est dentro del cronograma. Esto es particularmente cierto en las metodologas
de diseo estructurado
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
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
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
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
tambin necesitan administrar a las personas con quienes trabajan y deben manejar la presin
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
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
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
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
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
Analizador de sistemas
l o ella representa los intereses del departamento de SI y trabaja intensamente a travs del
proyecto
Analista de Infraestructura
y bases de datos). Las tareas de un analista de infraestructura incluyen garantizar que la nueva
informacin
para apoyar el sistema. Es probable que el individuo tenga una formacin y experiencia
significativa en
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.
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
fase de implementacin, pero comienza a sentar las bases para el cambio durante el anlisis y
fases de diseo.
Gerente de proyecto
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
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,
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
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
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
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
un objeto de cita probablemente puede programar una nueva cita, eliminar una cita,
Uno de los aspectos ms confusos del desarrollo de sistemas orientados a objetos es el hecho
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
objeto puede realizar. Los mensajes son informacin enviada a objetos para activar mtodos.
Un mensaje
La clase del paciente recibe el mensaje de creacin y ejecuta su mtodo create () que luego
y datos en una sola entidad. El ocultamiento de informacin fue promovido por primera vez en
sistemas estructurados
Paciente
-nombre
-direccin
-Fecha de nacimiento
-telfono
-aseguradora
+ hacer cita ()
+ calcular la ltima visita ()
+ cambiar estado ()
+ crear ()
requerido para usar un mdulo de software se publicar al usuario del mdulo. Por lo general,
esto
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
Herencia
modelado a finales de los aos setenta y principios de los ochenta. La literatura de modelado
de datos sugiere usar
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
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,
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 ()
+ cambiar estado ()
+ 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
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.
FIGURA 1-11
Jerarqua de clase
con Resumen y
Clases concretas
Persona
Doctor Paciente
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
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 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.
usted mismo a los diferentes tipos de objetos grficos en la figura 1-13, tendramos que
escribir
objeto grfico que queramos dibujar, y tendramos que nombrar cada funcin de dibujo de
manera diferente
cualquiera de las metodologas tradicionales. Sin embargo, los enfoques orientados a objetos
estn ms asociados
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
De acuerdo con los creadores del lenguaje de modelado unificado (UML), Grady Booch, Ivar
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,
Centrado en la arquitectura
los enfoques de diseo y anlisis de sistemas orientados a objetos deben respaldar al menos
tres
o vista externa, describe el comportamiento del sistema desde la perspectiva del usuario. Los
Iterativo e incremental
Los enfoques modernos de anlisis y diseo de sistemas orientados a objetos hacen hincapi
en
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.
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
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
el sistema est interconectado y depende uno del otro (vea la Figura 1-14). Como cada
incremento
Los conceptos en el enfoque orientado a objetos permiten a los analistas dividir un sistema
complejo en
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
fases y workfl ows. Las fases son inicio, elaboracin, construccin y transicin.
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:
(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"
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
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)?
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,
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
algunos aspectos de las clases de dominio del problema que se implementan y prueban.
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
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
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.
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
la iteracin debe revertirse. Sin buenos controles de versin, retrocediendo a una anterior
entregable de esta fase es una implementacin del sistema que se puede lanzar para beta
y pruebas de aceptacin.
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.
ejecutando durante las fases anteriores del sistema en evolucin. Dependiendo de los
resultados
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
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
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
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
Requisitos Workfl ow En el proceso Unifi ed, los requisitos workfl ow incluyen eliciting
de los interesados directos del proyecto, como los usuarios finales, los gerentes dentro de la
organizacin del usuario final, y
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
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.
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
para las bibliotecas de clase. Al reutilizar las clases predefinidas, el analista puede evitar
reinventar la rueda
asociado a la fase de elaboracin, pero al igual que los requisitos workfl ow, es posible que
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
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,
se asocia principalmente con las fases de elaboracin y construccin del Proceso Unificado.
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
tambin debe integrar los mdulos separados, probados individualmente para crear una
versin ejecutable
fases de construccin.
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
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.
fase del proceso Unifi ed. El flujo de trabajo de implementacin incluye actividades tales como
soft ware
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
El proceso es tcnicamente activo durante las cuatro fases, el flujo de trabajo de gestin del
proyecto es
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
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
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.
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
y fases de transicin.
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
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
Tan grande y tan complejo como es el Proceso Unificado, muchos autores han sealado un
conjunto de
asuntos Gerenciales. Estas actividades se excluyeron explcitamente del proceso Unifi ed.
Segundo, el
el producto una vez que ha sido entregado. Nosotros, no es un proceso completo de software;
Es solo
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
(Lawrence, KS: CMP Books, 2000); S. W. Ambler y L. L. Constantine, la Fase de Elaboracin del
Proceso Unificada:
Ambler y L. L. Constantine, las fases de transicin y produccin del proceso unifi cado: mejores
prcticas en la implementacin
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
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
soft ware a diario. Las actividades incluyen la creacin de planes para la operacin y el apoyo
de la
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
desarrollo original. En ese punto, el trabajo del desarrollador puede haber comenzado.
Debido a que las actividades en este trabajo tienden a afectar muchos proyectos y el Proceso
Unificado
Modifi caciones y extensiones existentes de Workfl ow Adems de los workfls que eran
ser modifi cado y / o extendido a la fase de produccin. Estos trabajos incluyen la prueba,
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
tienen bases de datos asociadas que deben convertirse para interactuar con los nuevos
sistemas.
Trabajo del entorno El trabajo del entorno debe modificarse para incluir actividades
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.
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
Este es el flujo de trabajo que, adems, debe ocurrir en la fase de produccin para abordar
problemas tales como
Confi guracin y gestin del cambio Workfl ow La confi guracin y la gestin del cambio
evaluar el impacto potencial de los cambios propuestos. Una vez que los desarrolladores han
identificado estos
La Figura 1-17 muestra los captulos en los que las fases del Proceso Unificado Mejorado y
Inicio 2-4
Elaboracin 3-11
Construccin 8, 12
Transicin 12-13
Produccin 13
Mejorado UP
Requisitos 3-5, 10
Anlisis 3-7
Diseo 7-11
Implementacin 9, 12
Prueba 4-7, 12
Despliegue 13
Mejorado UP
Project Management 2, 13
Confi guracin y
13
Medio ambiente 2
Operaciones y Soporte 13
Infraestructura
administracin
Proceso Unifi ed Mejorado. Sin embargo, como muestra la Figura 1-17, las otras fases y flujos
de trabajo
generacin es compatible. Nosotros, desde una perspectiva comercial, creemos que las
actividades asociadas
Hasta 1995, los conceptos de objeto eran populares, pero se implementaron de muchas
maneras diferentes por
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
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
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
los datos y las relaciones estticas en un sistema de informacin. Los diagramas de estructura
incluyen
Edicin (Nueva York: Farrar, Straus y Giroux, 2006); Daniel H. Pink, Una mente completamente
nueva: por qu los cerebros correctos
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:
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.
A medida que el sistema se desarrolla, los diagramas evolucionan para incluir detalles que
finalmente conducen a
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
Despliegue Muestra la arquitectura fsica del sistema; tambin puede diseo fsico,
en la arquitectura fsica
Implementacin de componentes
Diagramas de comportamiento
Actividad Ilustrar trabajos de negocios independientes de las clases, el flujo Anlisis, Diseo
Descripcin general de la interaccin Ilustrar una visin general del flujo de control de un
proceso Anlisis, diseo
Mquina de estado de protocolo Ilustrar las dependencias entre los diferentes Anlisis,
Diseo
y diseo. En particular, estos captulos describen actividad, caso de uso, clase, objeto,
secuencia,
HIPERMERCADO
Este curso introducir muchos conceptos nuevos sobre el anlisis orientado a objetos y
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.
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,
Supertienda para ver cmo los conceptos presentados en cada captulo afectan a este
proyecto.
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).
metodologas.
Describe las caractersticas bsicas de los sistemas orientados a objetos: objetos, atributos,
mtodos, mensajes, encapsulacin,
Discutir las tres caractersticas bsicas de todos los anlisis de sistemas orientados a objetos y
el enfoque de diseo: uso de casos de uso,
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
Atributo
Comportamiento
Diagramas de comportamiento
Vista comportamental
Analista de negocios
Modelado de negocios
workfl ow
Agente de cambio
analista
Clase
Clases concretas
workfl de gestin
Construccin
Fase de construccin
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
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
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
(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
Analizador de sistemas
ciclo (SDLC)
Escritor tcnico
Prueba workfl ow
Prototipado de rowaway
Plan de entrenamiento
Fase de transicin
(UML)
Caso de uso
Caso de uso impulsado
Versin
Desarrollo de cascadas
Workfl ows
El plan de trabajo
PREGUNTAS
entregables.
comit de aprobacin?
SDLC?
general.
desarrollo.
14. Describe los elementos principales y los problemas con las fases
desarrollo.
creacin de prototipos.
creacin de prototipos.
Mel.
20. Cules son los principales roles desempeados por un analista de sistemas
en un equipo de proyecto?
centrado en la arquitectura?
incremental e iterativo?
Proceso?
CEREMONIAS
sistemas.
vendedor.
Qu ests diciendo?
L. Supongamos que eres un analista que trabaja para una pequea empresa
N. Suponga que usted es un analista que trabaja para una pequea empresa
MINICASES
proyectos en los que los usuarios finales tenan que hacer signifi cado
en este equipo
responder.
Los amigos de IBM de Jack fueron muy persuasivos, Jack sigue siendo un