GE0827 Análisis de Sistemas I - 2009 - Informática

UNIVLRSIDAD LS1A1AL A DIS1ANCIA
VICLRRLC1ORA ACADLMICA
LSCULLA CILNCIAS LXAC1AS Y NA1URALLS

Anlisis de Sistemas I

Cdigo: 82

Guia de estudio

Preparada por:
Alonso Marin Snchez

San Jos, Costa Rica
2009

2 22 2

Ldicin acadmica:
Ana Mara Sandoal Poeda

Lncargado de catedra:
Roberto Morales

Reisin ilolgica:
scar Alarado Vega

3 33 3

Lste trabajo nace con la intencin de aorecer el proceso de aprendizaje de los estudiantes que han
optado por el diplomado en Inormatica de la Uniersidad Lstatal a Distancia ,UNLD,, puntualmente
en el curso de Analisis de Sistemas I.
Para resoler un problema de cualquier ndole se necesita realizar un proceso de obtencin y analisis de
inormacin que permita entender lo que se enrenta y elaborar la o las estrategias para resolerlo.
Con el tema del analisis de los sistemas de inormacin ocurre lo mismo. Ls preciso, e ineitable para
los analistas, entender la naturaleza del problema al que estan por enrentarse, desde una perspectia
inicialmente tecnolgica ,cuando se estan delimitando los inicios del proyecto, y, al aanzar en su
desarrollo, establecer una mas robusta y alimentada por el aporte gradual del tema que se esta
explorando.
Conocer cmo esta constituido el problema es un paso muy importante para el objetio inal esperado
por el cliente, mas si los analistas no tienen los mecanismos necesarios para traducir un problema en
trminos computacionales y presentarlo como un conjunto de procesos, mtodos y herramientas,
realmente se ha aanzado muy poco en pro del uturo sistema.
Para esto existe la ingeniera de sistemas, y en particular la ingeniera de .oftrare, rama que entra a
proeer una serie de actiidades asociadas a la calidad, que a a acilitar la creacin de .oftrare robusto y
consistente.
La gua que esta leyendo esta arraigada de manera directa con el libro de texto del curso Anlisis de
Sistemas I, llamado Ingenieria del software. Un enfoque prctico, de Roger S. Pressman. Cada
uno de los temas deinidos aca, contempla una serie de captulos agrupados de manera consciente.
Lsta organizacin expresa una perspectia mas orientada a los intereses particulares del curso y menos
dentro del libro de texto, de manera generalizada.
Se espera que el esuerzo de su parte por leer y analizar esta gua de estudio le permita ampliar su
perspectia a la hora de enrentar, como uturo proesional, el desarrollo de aplicaciones inormaticas
en donde solo el analisis robusto y coniable permita garantizar la continuidad y mejoramiento del
negocio, motios que son los que dan origen a los nueos desarrollos.
De parte de este seridor y de la UNLD en general, le damos la bienenida a este curso, esperando que
sea de su agrado tanto en la narratia como en su contenido, y que realmente ayude y acilite el proceso
de ensenanza-aprendizaje del que sera sujeto este perodo lectio.
Motivacin

4 44 4

Lsta gua de estudio esta separada en cuatro temas, cada uno tiene asociados arios captulos
relacionados directamente con la materia del libro Ingenieria del Software. Un enfoque prctico de
Roger S. Pressman, texto base del curso Analisis de Sistemas I.
La estructura de cada una de los temas es la siguiente:
Inicio del tema
Corresponde a la presentacin de cada tema, incluye el ttulo y algn
mensaje sobre la materia que esta por estudiar. Se espera que analice el
texto y lo compare con el tema despus de haberlo estudiado.
Objetivos
Ln esta seccin se presenta una lista de objetios que se pretenden
alcanzar con la lectura y comprensin de cada captulo del tema.

Sumario del tema
Ln esta parte se consigna un listado de los captulos del libro de texto
que se estudiaran en este tema. Se mantiene la numeracin para
ubicarlos mas acilmente y se agregaron hipernculos para que pueda
ingresar directamente a cada uno de ellos.
Ademas, en esta pagina encontrara los hipernculos para acceder a las
reerencias de la bibliograa, al glosario de trminos del tema y a los
enlaces electrnicos de inters que se relacionan con la tematica tratada
en los dierentes captulos estudiados.
Inicio de los capitulos
La presentacin de cada captulo consiste en el ttulo y un mensaje
sobre la materia que esta por estudiar. Ln algunas ocasiones las ideas
expuestas en esta parte son de reconocidos especialistas en el tema del
captulo. Cuando es de esa manera, se indica a quin se le atribuye ese
pensamiento. Ln otros casos, las ideas son del autor de esta gua de
estudio.
Ademas, se despliega el sumario para ese captulo en particular. Note
que corresponde a los aspectos tratados en el libro de texto.

Cmo estudiar con esta guia

5 55 5
Localizacin de subtemas en el libro de texto
Se orece al lector una tabla que establece la relacin entre la materia
de la gua de estudio y dnde esta localizada en el libro de texto.
Para claridad del lector se orece el nmero de pagina, del libro de
texto, en la cual encontrara la inormacin.

Comentarios generales
Ls una introduccin al captulo que esta por estudiar. Le ayudara a
hacer la transicin entre el captulo anterior y el que esta por leer.

Desarrollo
Despus de este ttulo comienza la materia que se ha de estudiar para
cada captulo. Ll desarrollo de esta gua ue pensado y escrito para que
el estudiante obtenga una perspectia dierente de lo que esta por
aprender directamente del libro de curso. Desde un enoque liiano y
simple se busca explicar los argumentos mas importantes expuestos
por el autor del texto base, sin pretender aduenarse de los conocimientos que el mismo orece, sino
mas bien complementar esta inormacin con una narratia dierente y con una serie de actividades.
Ln el desarrollo de los temas, encontrara una serie de iguras elaboradas por el autor para ilustrar los
temas tratados.

Ljercicios sugeridos
Al inal de cada captulo de la gua encontrara una lista de ejercicios.
Ln ella tendra una serie de actiidades que se le sugieren para reorzar
sus conocimientos sobre la materia que acaba de leer y estudiar.

Referencias
Ln cada uno de los temas encontrara una lista de reerencias.
Contiene los materiales utilizados para la elaboracin de la gua.
Lncontrara los datos acomodados en orden alabtico.

6 66 6
Glosario de anlisis de software
Cada seccin, correspondiente a un tema de estudio de esta gua, tiene
una seccin de glosario. Ln ella encontrara un conjunto de trminos
complejos y su correspondiente signiicado. Lsto le ayudara a
interpretar su utilizacin en el contexto de cada tematica.

Lnlaces electrnicos
Para cada tema hay una lista de enlaces electrnicos que contienen
inormacin releante con respecto a la existente en cada captulo y
que sire como material de apoyo en su estudio.
Ln cada caso se indica el captulo del libro que utiliza el concepto o
tema y la direccin electrnica de cada reerencia.

7 77 7
El proceso de
elaboracin de software

Ma. qve vva ai.citiva o vv cvero ae covocivievto, ta ivgeviera e. vv rerbo, vva
atabra ev acciv, vva vavera ae aboraar vv robteva. Scott Whitmire

Ob]etivos

Lstudiar el proceso que conduce a la creacin de un fraveror/ marco de trabajo, acilitara su labor en
la ingeniera de .oftrare en el mundo de la inormacin y el conocimiento.
Cuando termine de leer este tema, estara en capacidad de:

Analizar y entender qu es un proceso de .oftrare, cmo se caracteriza y cuales son las
actiidades asociadas al marco que lo orma y regula.
Lxplicar la importancia de utilizar un modelo prescriptio idneo, que permita especiicar,
realizar prototipos, disenar, implementar, reisar y probar las actiidades deinidas en un
proyecto de desarrollo de .oftrare particular.
Deinir qu es el desarrollo rapido dentro de la jerga del desarrollo de .oftrare y sus dierencias y
entajas con otras metodologas existentes.
Conocer cuales son los conceptos que guan la ejecucin de la ingeniera de .oftrare en la
practica, mediante principios bien establecidos, que prooquen calidad en el producto de
.oftrare generado.
Tema

8 88 8
8umario

Los captulos que conorman este tema se encuentran en el libro de texto y son los siguientes:

Capitulo 2 Ll proceso: una visin general
Capitulo 3 Modelos prescriptivos de proceso
Capitulo 4 Desarrollo gil
Capitulo S La prctica: una visin generica

Ademas, podra consultar las siguientes secciones:

Referencias bibliogrficas
Glosario de terminos
Lnlaces electrnicos relacionados con el tema

9 99 9
El proceso: una visin general

Cvo .e covcibe et sotware covo roce.o, iaevtificar cvo aebe .er et roceaer ,
qve regta. .ov ivortavte. .egvir .i .e e.era qve et roavcto or evtregar cvevte
cov atta catiaaa , .vvivi.tre a tievo.

8umario

Los temas que estudiara en este captulo son:
Ingeniera del .oftrare: una tecnologa estratiicada
Marco de trabajo para el proceso
Integracin del modelo de capacidad de madurez ,IMCM,
Patrones del proceso
Laluacin del proceso
Modelos de proceso personales y en equipo
1ecnologa del proceso
Producto y proceso

Capitulo

10 10 10 10

SUB1LMAS PGINAS
Ll proceso: una isin general 22
Ingeniera del .oftrare: una tecnologa estratiicada 23
Marco de trabajo para el proceso 24
Integracin del modelo de capacidad de madurez ,IMCM, 29
Patrones del proceso 34
Laluacin del proceso 36
Modelos de proceso personales y en equipo 38
1ecnologa del proceso 42
Producto y proceso 43

11 11 11 11

ara iniciar con el tratamiento de la unidad didactica, es imprescindible que sea claro para el
estudiante qu es lo que se espera se entienda por proceso de .oftrare` y su relacin con
ingeniera del .oftrare`.
Ls posible er el proceso de .oftrare como una actiidad sinnimo de ingeniera del .oftrare, o como
algo separado. Ll proceso de .oftrare deine el enoque que se adopta mientras se desarrolla, aunque
debe considerarse que tambin la ingeniera del .oftrare abarca las tecnologas requeridas para el proceso
,como mtodos tcnicos y herramientas automatizadas,.
Ll proceso del .oftrare, desde un punto de ista tcnico, se deine como un marco de trabajo para las
tareas que se requieren en la construccin de .oftrare de alta calidad. Lsta explicacin deja claro que la
ingeniera de .oftrare corresponde a las reglas dentro de un enoque sistematico y el proceso es isto
como la instancia de estas reglas aplicadas.
Ln resumen, el proceso del .oftrare se puede er como un conjunto de actiidades que permiten crear
un producto de .oftrare. Lstas actiidades se deinen como: especificacin, desarrollo, validacin y
evaluacin.
Ls de inters en este captulo describir ampliamente ,qu es, ,cmo se aplica y ,para qu sire la
ingeniera del .oftrare, con la inalidad de entender como reproducir los procesos, de manera tal que se
logre alcanzar desarrollo de productos con calidad.

12 12 12 12
Desarrollo

Lxisten muchas deiniciones para tratar de expresar lo que en realidad signiica el trmino ingenieria
de software. Algunos autores expresan el concepto en trminos de principios slidos, coniabilidad y
eiciencia, otros en trminos de un enoque sistematico, de disciplina y de cuantiicacin al desarrollo,
operacin y mantenimiento del .oftrare.
1odos ellos tienen la razn, pero a la ez dejan al descubierto aspectos importantes dentro de una
descripcin completa del trmino. Preguntas como:
,Cuales son los principios slidos de la ingeniera, que pueden aplicarse en el desarrollo del .oftrare
de la computadora
,De qu manera se construye, econmicamente, un .oftrare coniable
,Qu se necesita para crear programas que uncionen de manera eiciente en arias maquinas reales
dierentes
Lstas son preguntas no solucionadas todaa por la comunidad inormatica. Al no tener esas respuestas
es necesario enocar la ingeniera de .oftrare como una tecnologa estratiicada, donde se depende
completamente de la interaccin entre las capas en cada niel de esta estructura, compuesta por el
proceso, los metodos y las herramientas.
Como se comentaba al inicio, es ital comprender cual es el alcance que tiene la ingeniera de .oftrare
dentro del contexto de desarrollo de sistemas de inormacin.
Ll libro indica que la ingeniera de .oftrare debe reconocerse como una tecnologa organizada por
estratos, donde todas las capas se conabulan para garantizar el marco que sustenta la calidad del
.oftrare, calidad esperada por los clientes, como la esperaran al comprar cualquier otro producto
tangible, como un ehculo o un par de zapatos.
Ln la pagina 24 del libro de texto encontrara una aliosa explicacin de los dierentes estratos que
soportan la ingeniera del .oftrare, enueltos en una gran cortina permeable de calidad, que le da alcance
a cada uno de los estratos indicados aca.
vortavte:
Proceso: es el elemento que mantiene juntos los estratos de la tecnologa y que permite el
desarrollo racional y a tiempo del .oftrare.
Metodos: son los que proporcionan el cmo` de la parte tcnica para construir el .oftrare.
Herramientas: son las que proporcionan el soporte automatizado de orma parcial o completa
para el proceso y los mtodos.

13 13 13 13

Iigura 0J Lstrato de la ingenieria del software.
Ls necesario ubicar la ingeniera de .oftrare dentro de un marco de trabajo para el proceso, que
permite identiicar un nmero de actiidades que son comunes y se aplican a todos los proyectos de
.oftrare por realizar.
Cada actiidad a a tener una lista de acciones o tareas relacionadas que permiten deoler un
material entregable al inalizar la misma.
La unidad didactica propone un marco genrico para el proceso del .oftrare. Lste procedimiento es
enatico respecto a la comunicacin, la planeacin, el modelado, la construccin y el despliegue.

Actividad
Se recomienda al estudiante analizar la descripcin propuesta para cada uno de estos trminos, en la unidad
didactica, y apoyarse en el cuadro inormatio en la pagina 2, que describe acilmente a qu se reiere el
autor con acciones asociadas a una actiidad puntual dentro de un marco de trabajo.
Por encima de las actiidades del modelo propuesto, se encuentran otras de tipo sombrilla, que
permiten principalmente medir, gestionar y controlar las acciones descritas anteriormente. Llamarlas
de tipo sombrilla` hace reerencia a su papel como marco protector para la adaptacin y para el buen
desarrollo de las actiidades a lo interno del desarrollo.
Ls necesario mencionar que hay una uerte corriente sobre el tema de los modelos giles. Lstos
modelos son un poco mas inormales y sus procesos se basan en la agilidad, manejabilidad y
adaptabilidad, para garantizar la eectiidad de los modelos tradicionales. Lste aspecto se retomara en
captulos posteriores.

Actividad
Se le sugiere pensar, a lo largo de los temas, en semejanzas y dierencias entre los modelos descritos en este
tema y los que se mostraran posteriormente.
Respecto a los modelos de procesos, el libro incorpora uno imprescindible para el tema. Se trata del
CMM, o CMMI como se le conoce recientemente.

14 14 14 14
Ll Instituto de Ingeniera de oftrare, ,SLI, por sus siglas en Ingles, con sede en Lstados Unidos,
desarroll un modelo complejo basado en un conjunto de capacidades de .oftrare que deben estar
presentes, orzosamente, conorme las organizaciones logran alcanzar dierentes grados de madurez y
capacidad del proceso.
Como el libro de texto se edit en junio de 2005, y este modelo es apoyado por dierentes
organizaciones de la industria del .oftrare, es eidente que el modelo ha eolucionado hasta la echa.
Por este motio, se le guiara para que se reiera a la literatura mas actualizada sobre este tema tan
importante dentro del desarrollo del .oftrare. Al inal de este captulo, encontrara reerencias web sobre
el SLI, y los nueos lineamientos que se han madurado en torno al CMMI.

CMMI ,Caabitit, Matvrit, Moaet
+
vtegratiov,
CMMI es el sucesor de CMM. Ll objetio del proyecto CMMI es mejorar la utilizacin de modelos de
madurez, por medio de la integracin de arios modelos dierentes en un solo marco ,fraveror/,. lue
creado por los miembros de la industria, el gobierno y el SLI. Lntre los principales patrocinadores se
incluyen la Oicina del Secretario de Deensa ,OSD, y la ^atiovat Defev.e vav.triat ...ociatiov.

vortavte:
CMMI: el IMCM. Son siglas que, para eectos de la gua de estudio, signiican lo mismo.

La SLI deine el CMMI de la siguiente manera: La Integracin del Modelo de Capacidad de Madurez
,CMMI, por sus siglas en ingls,, es un proceso de mejora en el enoque, que proporciona a las
organizaciones los elementos esenciales para los procesos eectios. Se puede utilizar para guiar la
mejora del proceso a tras de un proyecto, una diisin, o toda una organizacin. CMMI ayuda a
integrar las unciones de organizacin ,tradicionalmente separadas,, mejora el proceso establecido para
las metas y prioridades y proporciona orientacin para los procesos de calidad y un punto de reerencia
para ealuar los procesos actuales.

Dos representaciones: continua y escalonada
Ll modelo para .oftrare CMM-S\ establece 5 nieles de madurez para clasiicar a las organizaciones,
en uncin de qu areas de procesos consiguen sus objetios y se gestionan con principios de
ingeniera. Lsto se denomina un modelo escalonado, o centrado en la madurez de la organizacin.

15 15 15 15

Iigura 02 Modelo escalonado CMMI.
Ll modelo para ingeniera de sistemas SL-CMM establece seis nieles posibles de capacidad para una
de las 22 areas de proceso implicadas en la ingeniera de sistemas ,er reerencia web a la izquierda,. No
agrupa los procesos en cinco tramos para deinir el niel de madurez de la organizacin, sino que
directamente analiza la capacidad de cada proceso por separado. Ls lo que se denomina un modelo
continuo.

Iigura 03 Modelo continuo CMMI.
Ln el equipo de desarrollo de CMMI haba deensores de ambos tipos de representaciones. Ll
resultado ue la publicacin del modelo con dos representaciones: continua y escalonada. Son
equialentes, y cada organizacin puede optar por adoptar la que se adapte a sus caractersticas y
prioridades de mejora.
La isin continua de una organizacin mostrara la representacin de niel de capacidad de cada una
de las areas de proceso del modelo.
La isin escalonada deinira a la organizacin dandole en su conjunto un niel de madurez del 1 al 5.
Los 6 nieles deinidos en CMMI para medir la capacidad de los procesos son:
0, Incompleto: el proceso no se realiza, o no se consiguen sus objetios.
1, Ljecutado: el proceso se ejecuta y se logra su objetio.

16 16 16 16
2, Gestionado: ademas de ejecutarse, el proceso se planiica, se reisa y se eala para comprobar
que cumple los requisitos.
3, Definido: ademas de ser un proceso gestionado se ajusta a la poltica de procesos que existe en la
organizacin, alineada con las directias de la empresa.
4, Cuantitativamente gestionado: ademas de ser un proceso deinido se controla utilizando
tcnicas cuantitatias.
5, Optimizante: ademas de ser un proceso cuantitatiamente gestionado, de orma sistematica se
reisa y modiica o cambia para adaptarlo a los objetios del negocio. Implica mejora continua.

Patrones de proceso y evaluacin
Los patrones son un bastin dentro del proceso de desarrollo de .oftrare. Permiten crear guas con
grados de abstraccin bastante amplios para darle solucin a problemas cotidianos en el desarrollo de
.oftrare, de una manera robusta y ordenada.
vortavte:
Los patrones de proceso se deinen como un mtodo consistente para describir una caracterstica
importante del proceso y darle una posible solucin satisactoria.

Ll libro presenta un posible patrn por seguir ,puede ubicarlo a partir de la pagina 34,, sin embargo, es
claro que no es el nico existente. Ll uso de un patrn no garantiza, por s solo, que el resultado de la
ejecucin sea satisactorio. Se necesita meter, dentro de una actiidad ealuatia, la aplicacin de dicho
patrn para alidar su correcta ejecucin.
Ll libro presenta y sugiere arios enoques interesantes sobre la eratvaciv ae roce.o. de .oftrare, algunos
de ellos son: CMM para mejoramiento de proceso interno, ISO 9001:2000 para .oftrare, entre otros.
Actividad
Lea la inormacin de las paginas 3 y 38, del libro de texto, reerida al ISO 9001:2000.
Consulte el enlace senalado en la pagina 38 y describa con sus propias palabras la importancia y la necesidad
de contar con este instrumento.

17 17 17 17

Iigura 04 Relacin entre proceso del software y metodos para la evaluacin.
Debido al reconocimiento internacional del ISO 9001:2000 es necesario conocer un poco mas a ondo
del tema. Ln el captulo 26 del libro de texto, se habla sobre la gestin de calidad. La lectura de este
captulo le permitira ampliar el tema.

Procesos de software personal y en equipo
1anto los patrones como los procesos mencionados anteriormente son lleados a la practica por
dierentes personas.
La eectiidad de los patrones, en las dierentes organizaciones o corporaciones, depende
exclusiamente de la ainidad de ellos con la orma interna de trabajo de las personas que los utilizan.
Por lo tanto, es necesario orquestar dichos procesos individuales, que nacen del comportamiento de
cada quien, con el comportamiento grupal del equipo en el proyecto asignado. Qu tan de la mano
se presente esta relacin, sera una medida para entender qu tan bien o qu tan mal sera la entrega en
cada proceso terminado.
La postura en la unidad didactica promuee que dicha relacin s existe y que se requiere de un arduo
trabajo, capacitacin y coordinacin para lograr aanzar en este tema. Ambos procesos destacan la
medicin, planeacin y autodireccin como partes importantes de un proceso exitoso.
Ll detalle que justiica la existencia de estas proposiciones, tanto de proceso de software personal
como de equipo, lo puede detallar en la pagina 39 a la 41 del libro de texto.

1ecnologia a favor del proceso y del producto
La ejecucin de los procesos de .oftrare se beneicia ampliamente de las herramientas de tecnologias
de procesos. Lstas herramientas permiten automatizar los marcos de trabajo de los modelos de
procesos de la organizacin, y esto aumenta la eiciencia de las actiidades de analisis de procesos,
organizacin de tareas, control y monitoreo de progreso y administracin de calidad tcnica, entre
otras.
La aplicacin de estas herramientas disminuye los costos y aumenta la productiidad de cada etapa.
Lsto se debe a que, normalmente, estas labores son muy tediosas de documentar de manera manual.

18 18 18 18
La relacin dual existente entre el proceso y el producto es ital para que los ingenieros de .oftrare
depuren los mecanismos para abricar productos de alta calidad basados siempre en ingeniera del
.oftrare, y a la ez garantizar la continuidad del proceso y del producto.

19 19 19 19
E]ercicios sugeridos

Ln la pagina 46 del libro de texto encontrara algunos problemas y puntos por considerar sobre el
captulo que acaba de estudiar.
Ls importante que intente resoler los siguientes ejercicios. Lsto le permitira medir su aprendizaje.

1. Ln la igura 01 de esta gua, se colocan los estratos de la ingeniera del .oftrare,
arriba de un estrato titulado un enoque en la calidad`. Lsto implica un
programa de calidad de una organizacin amplia como gestin de la calidad total.
Realice una pequena inestigacin y desarrolle una gua de los principios claes`
que deben regir un programa de gestin de calidad total. Inestigue tambin,
acerca de la gestin de la calidad total para el desarrollo del .oftrare. Llabore un
inorme de una pagina sobre cada uno de estos temas.
2. Las actiidades sombrilla ocurren a lo largo de todo proceso de .oftrare. ,Se
aplican de modo uniorme a tras del proceso o algunas estan concentradas en
una o mas actiidades del marco de trabajo Lxplique ampliamente su respuesta.
3. Describa con sus propias palabras un marco de trabajo del proceso. Cuando
se dice que las actiidades del marco de trabajo son aplicables a todos los
proyectos, ,esto signiica que las mismas tareas de trabajo se aplican a todos los
proyectos, sin importar el tamano y la complejidad Lxplique detalladamente.
4. Inestigue acerca de CMMI, y su eolucin desde CMM. Llabore un resumen
acerca de este aance y sobre la aceptacin en la comunidad de desarrollo de
.oftrare.
5. ,Cual es el propsito de la ealuacin del proceso Indique porqu existe y de
dnde proiene su importancia.

20 20 20 20
Modelos prescriptivos de proceso

Cvo oraevar et cao. ev et ae.arrotto aet sotware, veaiavte et ttevaao ae vv
varco ae traba;o aefiviao, cov vv cov;vvto ae tarea. etcita. ara caaa vva ae
ta. acciove. ae ta ivgeviera ae .i.teva..

8umario


Modelos prescriptios
Ll modelo en cascada
Modelos de procesos incrementales
Modelos de proceso eolutios
Modelos especializados de procesos
Ll proceso uniicado
Capitulo

21 21 21 21

SUB1LMAS PGINAS
Modelos prescriptios 49
Ll modelo en cascada 50
Modelos de procesos incrementales 51
Modelos de proceso eolutios 54
Modelos especializados de procesos 63
Ll proceso uniicado 6

22 22 22 22

sea cual sea la manera deinida en una organizacin de llear a cabo el desarrollo de un proyecto
de .oftrare, debe recurrir a un marco de trabajo lleno de actiidades compuestas por un grupo
importante de acciones asociadas a la ingeniera de .oftrare.
A la ez, debera orquestar dicho marco de trabajo al ambiente en que se desarrollara y a las personas
que lo pondran en practica. Bajo esta premisa, los estudiosos de la materia han obserado las mejores
practicas en el desarrollo de .oftrare a tras del tiempo, y han extrado algunos modelos prescriptivos
que permiten, para dierentes tipos de proyectos, soluciones ajustables segn cada caso.
Se dice que son prescriptios porque precisamente senalan una serie de elementos del proceso, tales
como: actividades del marco de trabajo, acciones de ingenieria de software, tareas, productos
de trabajo, aseguramiento de la calidad y mecanismos de control de cambio para cada
proyecto.
Las actiidades genricas del marco de trabajo estan identiicadas como: comunicacin, planeacin,
modelado, construccin y desarrollo. Las caractersticas en los modelos que se describiran
seguidamente, le permitiran ealuar cual se ajusta mejor a la necesidad existente.

23 23 23 23
Desarrollo

Los modelos prescriptios se pueden agrupar en las siguientes categoras: lineales o en cascada,
incrementales, evolutivos, especializados de proceso y un caso particular de agrupamiento,
conocido como el proceso unificado.
Para el caso de los modelos en cascada o lineales, se dira que ue el primer modelo de proceso
creado y es isto como el modelo clsico por excelencia. Se puede decir que nace por el sentido
comn aplicado al desarrollo normal de un producto de .oftrare.
1iene las etapas basicas necesarias para garantizar un desarrollo consistente del producto. Una ez
ejecutada y terminada cada ase, sta sire como insumo para la siguiente. Lsto permite la continuidad
del proceso y la entrega al inal de un producto terminado.
Ahora bien, la existencia de los demas modelos se debe, principalmente, a que este primer paradigma
presenta algunos problemas diciles de subsanar en cuando a desarrollo se reiere.
Ln detalle, se presentan problemas como los siguientes:
Covortavievto vo tiveat: los proyectos de .oftrare en la actualidad tienen esta particularidad.
Reqverivievto. ivtcito.: el cliente normalmente no tiene toda la inormacin necesaria para aclarar el
dominio del problema a los analistas.
vacievcia: la naturaleza del modelo llea a obserar un producto tangible hasta que casi todas las
etapas se concretaron.

La existencia del modelo de cascada, en la actualidad, se da porque concurren situaciones donde el
listado de requerimientos es muy estatico ,por aspectos muy propios del negocio,, lo que hace
importante y eiciente este modelo, mas no es lo comn en estos das. Al contrario, en la gran mayora
de los casos para las organizaciones, tanto pblicas como priadas, los requerimientos son
completamente cambiantes da a da.

Actividad
Puede complementar la explicacin para este modelo, en la pagina 50 del libro de texto.

Iigura 0S Modelo de cascada.

24 24 24 24
Ll modelo incremental solenta algunas de las deiciencias encontradas en el modelo anterior.
Permite separar los requerimientos funcionales, conocidos como las condiciones mnimas de
uncionamiento que debe tener el .oftrare, de los requerimientos no funcionales, que son los que se
trabajan de una manera iteratia sobre el producto de inicio y que no orman parte de la lnea base del
mismo.
Lo que hacen estos requerimientos no uncionales es complementar a los uncionales para darle
elegancia, robustez y eiciencia al producto, sin embargo el .oftrare, en el peor de los escenarios, puede
iniciar sin ellos.
Cada iteracin o incremento del proceso, nos acerca mas al producto inal por desarrollar. Lo esperado
en cada iteracin es que deuela un roavcto fvvciovat con el contenido de las iteraciones hasta el
momento de su creacin.

Actividad

Iigura 06 Modelo incremental.
Como otra opcin al hablar de modelos incrementales se encuentra al desarrollo rpido de
aplicaciones ,DRA,, el cual reiere siempre a proyectos con problemas de calendario ajustado.
Cuando se tienen los requerimientos claros ,cosa que sucede muy pocas eces, y se logra delimitar el
ambito de proyecto, este modelo es uerte candidato a dar solucin a dicho desarrollo.
La separacin por equipos de trabajo, de todo el conjunto de personas que an a trabajar en el
proyecto, permite modularlo en grandes unciones para las cuales se an a aplicar todas las actiidades
del marco de trabajo deinidas en el captulo 1, como lo son la comunicacin, planeacin,
modelado, construccin y despliegue.

25 25 25 25
Lxisten inconenientes para este modelo, el principal corresponde a no lograr la cantidad necesaria de
recurso humano cuando el proyecto es de grandes dimensiones ,muchos equipos DRA,. Por otro
lado, si el proyecto no se modula de una manera adecuada, la construccin de los componentes sera
problematica, sin excepcin.
Actividad

Iigura 07 Modelo desarrollo rpido de aplicaciones.
Aparte de los aspectos mencionados hasta el momento, que describen los problemas a considerar en el
desarrollo del .oftrare, se tienen que tomar en cuenta aspectos propios del mercado como la
competitiidad, que propone una echa meta de salida para el producto.
Se necesitan mecanismos que permitan desarrollar ersiones del producto en los tiempos que marque
la competencia, y que a la ez permitan ser la base directa para iniciar, sobre este, el nueo esuerzo
por cumplir para la siguiente meta propuesta en el tiempo.
Por este motio, se crean los modelos evolutivos, que a su ez son iteratios y que permiten obtener
ersiones cada ez mas completas del .oftrare, ajustado a tiempos especicos.
Como primer ejemplo de estos modelos eolutios, se senala la construccin de prototipos. Lste
paradigma de desarrollo permite que el cliente y el ingeniero de .oftrare identiiquen los requerimientos
conocidos, tengan claros los objetios globales a cumplir con el desarrollo y las areas en donde haga
alta mas inormacin.
Con este insumo, algo disminuido para lo que normalmente se ocupa, se inicia la creacin de un
prototipo visual ,sin contenido o cdigo desarrollado,, en donde se plasma lo que el cliente o usuario
inal esperara er del producto terminado al inal del proceso.

26 26 26 26
Ll cliente eala este prototipo y se retroalimenta al equipo de trabajo para que pereccione la
propuesta de este primer prototipo base. Ll objetio es conseguir, a partir de la alimentacin isual y la
interaccin con el prototipo, la ersin que cumpla con las expectatias.
Lste es un punto crucial, porque al encontrar el producto a niel de prototipo, que agrupe las
caractersticas necesarias y esperadas por el cliente, el equipo de trabajo debera, en la buena teora,
extraer de este trabajo la lista de requerimientos y eliminarlo casi por completo, para no proocar la
sensacin, ni en el cliente ni en el equipo, de que la tarea esta casi por terminar.
Recuerde que para este modelo en particular, se inicia de alguna orma de atras hacia adelante,
obteniendo primero el caparazn del sistema, y luego el contenido de operacin.
Con la lista anterior debera iniciar la creacin del nueo proyecto que ahora s sera el producto inal
que se ha de entregar al cliente.

Actividad

Iigura 08 Modelo por prototipo.
Ll modelo por prototipo tambin tiene sus deiciencias a la hora de interactuar con el cliente, debido a
que le crea una falsa expectativa de que hace alta muy poco para pasar del prototipo a la ersin
utilizable, desconociendo que la esencia esta en el cdigo que a dentro del prototipo que obsera y
que es precisamente lo que esta por iniciar.
Ll modelo en espiral es otro de los modelos eolutios. Ls muy amoso entre los modelos de .oftrare
debido a la importancia que le otorga al manejo y administracin del riesgo para el proyecto.
1al y como lo describe el nombre del modelo, se trata de una espiral que en cada uno de los circuitos o
iteraciones aplica cada una de las actiidades genricas del marco de trabajo explicado anteriormente

27 27 27 27
,captulo 1,. Lo hace de manera tal que el actor riesgo se considera ampliamente en cada reolucin,
con el in de mitigarlo o eliminarlo segn sea el caso.
La primera ez puede ser que se trate tan solo de la especiicacin del producto, pero posiblemente el
paso siguiente sea generar un prototipo, y as aanzar hasta obtener el producto inal ampliamente
reinado por la espiral.
Se necesita mucho conocimiento por parte de las personas que quieren implementar este modelo,
debido a la habilidad necesaria para abstraer el riesgo en cada iteracin y ponerlo en beneicio del
proyecto. De hecho, este es el motio por el cual no siempre se escoge como modelo, aunque en el
papel sea tan coneniente.

Actividad

Iigura 09 Modelo en espiral.
Como ltimo modelo propuesto para los tipos eolutios, tenemos el de desarrollo concurrente, que
se representa en orma esquematica como una serie de actiidades del marco de trabajo, acciones y
tareas de la ingeniera de .oftrare y sus estados asociados.
Ln un momento del proceso, todas las actiidades del marco de trabajo existen de manera
concurrente, posiblemente en estados dierentes. Lste proceso se aplica a todos los desarrollos de
.oftrare y proporciona una isin exacta del estado del proyecto. Ln lugar de coninar las actiidades,
acciones y tareas a una secuencia de eentos, deine una red de actiidades concurrente.

Actividad

28 28 28 28

Iigura J0 Modelo desarrollo concurrente.
Los modelos especializados de procesos son otra ariante. Su ortaleza es la reutilizacin de los
modelos conencionales descritos en parraos anteriores. Lntran en igencia cuando ya se ha tomado
un enoque de ingeniera de .oftrare de manera robusta.
Dentro de esta gama tenemos al desarrollo basado por componentes, que busca reducir
bruscamente los tiempos de la etapa de construccin del .oftrare, mediante la componentizacin.
vortavte:
La componentizacin se describe como la separacin o empaquetado de mdulos de sistema,
clases o paquetes de clases orientadas a objetos, que se logran orquestar dentro de la etapa de
construccin y que permiten, mediante su adquisicin, reducir ampliamente los tiempos, gracias a
que estan completamente desarrollados.

Su uncionalidad esta dirigida a la presentacin mediante interaces amigables, que permiten al .oftrare
integrarse acilmente al resto de .oftrare desarrollado o incorporado de la misma manera.
Actividad
Puede complementar la explicacin para este modelo, en la pagina 63 del libro de texto y en todo el captulo
30.
1ambin, dentro de los modelos especializados en los procesos, se encuentra el modelo de metodos
formales. Lste modelo esta sustentado en la eriicacin matematica rigurosa y en el analisis estadstico
de las pruebas arrojadas en dierentes etapas del desarrollo, principalmente en la parte de pruebas
unitarias e integrales del .oftrare.

29 29 29 29

Actividad
Puede complementar la explicacin para este modelo, en la pagina 64 del libro de texto y en los captulos 28
y 29.

Como ltimo ejemplo dentro de los modelos especializados al proceso, se tiene al desarrollo del
software orientado a aspectos. Se reiere, principalmente, a las areas de inters para el cliente, que
permite identiicar qu aspectos del .oftrare deben ser uertemente tratados para que, a partir de un
enoque metodolgico, se deina, especiique, disene y construyan aspectos del .oftrare, istos como
mecanismos mas alla de subrutinas y ligados para localizar la expresin de un inters general.
Las tcnicas orientadas a aspectos extienden las tcnicas tradicionales como la orientacin a objetos,
permitiendo a los desarrolladores encapsular en mdulos separados los aspectos, propiedades que
normalmente atraiesan o estan presentes en arios componentes del sistema.
Lsta tecnologa propugna la identiicacin, separacin y modularizacin de los distintos aspectos que
interienen en una aplicacin, para componerlos luego y construir la aplicacin inal.
Ll beneicio principal de esta tecnologa es la mejora dada en la modularizacin de los sistemas, con
esto se obtiene un cdigo menos enmaranado`, eitandose la mezcla entre uncionalidad y aspectos
extra-uncionales, acilitandose el mantenimiento y la eolucin del cdigo.

Actividad
Puede complementar la explicacin para este modelo en la pagina 65 del libro de texto y en los captulos 28
y 29.

Proceso unificado (PU)
Ll tema del proceso uniicado del .oftrare, debido a su masia utilizacin en la actualidad, necesita un
espacio aparte para su descripcin como modelo de desarrollo de .oftrare.
Ll PU es un proceso de .oftrare guiado por los casos de uso, de arquitectura cntrica, iteratio e
incremental disenado como un marco que permite a todos los mtodos y herramientas del UML
,|vifiea Moaetivg avgvage, coniir.
vortavte:
Un caso de uso es una coleccin de escenarios con xito y allos relacionados, que describen a los
actores utilizando un sistema para satisacer un objetio` ,Larman 2004,.

30 30 30 30
Ln el proceso uniicado se encuentran claramente representadas, mediante ases, las cinco grandes
actiidades genricas del marco de trabajo para cualquier modelo de procesos.

vortavte:
Iase de inicio: es la comunicacin con el cliente para identiicar requerimientos de negocios
,casos de uso, y la planeacin de los mismos.
Iase de elaboracin: es la continuacin de comunicacin y ademas actiidades de modelado del
negocio genrico del proceso. Algunas eces se alcanza un sistema ejecutable en su primera ersin
o iteracin.
Iase de construccin: es la parte constructia de un proceso genrico de .oftrare. Se da la
codiicacin de cada incremento de analisis dado por la ase de elaboracin anterior, para la
iteracin actual.
Iase de transicin: es la accin que abarca las ltimas actiidades de la ase de construccin y la
primera parte de la actiidad de despliegue. Se dan las primeras pruebas al .oftrare y la
retroalimentacin del usuario para la siguiente iteracin.
Iase de produccin: es la monitorizacin de las ases subsecuentes del .oftrare, paralelo a la ase
de transicin. Permite retomar inormes por desperectos y cambios nueos en el .oftrare.

Ls importante indicar que al ser un proceso iterativo incremental, al realizarse alguna de las etapas de
construccin, transicin y produccin para un caso especico, ya se ha iniciado una nuea iteracin
para el siguiente incremento del proceso, lo que nos indica que existe concurrencia en las etapas.
Ll proceso unificado de rational ,Ratiovat |vifiea Proce.. en ingls, habitualmente resumido como
RUP, es un proceso de desarrollo de .oftrare y junto con el Lenguaje Uniicado de Modelado UML,
constituye la metodologa estandar mas utilizada para el analisis, implementacin y documentacin de
sistemas orientados a objetos para el PU.

Actividad
A su izquierda esta la reerencia de la pagina de IBM, empresa de computacin que compr recientemente
los derechos de Ratiovat oftrare. Inestigue los productos relacionados con la ingeniera de .oftrare y la orma
en cmo acilitan cada ez mas el proceso operatio a los equipos de trabajo.

31 31 31 31

Iigura JJ. Diagrama fases y actividades del proceso unificado.

Actividad
Puede complementar la explicacin para este modelo en la pagina 6 del libro de texto. 1endra acceso a una
bree historia del PU. Ademas, en la parte 2 de su material, era los mtodos que pueblan el proceso y las
tcnicas del UML.

32 32 32 32
Cuadro de capacidades de algunos modelos de ciclo de vida del software. Iuente: McConnell, Steve
(J996) De.arrotto , ge.tiv ae ro,ecto. ivforvatico.. Mexico D.I.: Prentice Hall, segunda edicin.
CAPACIDADLS DLL MODLLO DLL CICLO DL
VIDA
CASCADA
PURA
LSPIRAL
PRO1O1IPO
LVOLU1IVO
LN1RLGA
LVOLU1IVA
1rabaja con poca identiicacin de los
requerimientos
Malo Lxcelente Lxcelente Medio a excelente
1rabaja con poca comprensin sobre la
arquitectura
Malo Lxcelente Malo a medio Malo
Genera un sistema altamente iable Lxcelente Lxcelente Medio Medio a excelente
Genera un sistema con amplio desarrollo Lxcelente Lxcelente Lxcelente Lxcelente
Gestiona riesgos Malo Lxcelente Medio Medio
Lsta sometido a una planiicacin predeinida Medio Medio Malo Medio
Requiere poco tiempo de gestin Malo Medio Medio Medio
Permite modiicaciones a medio camino Malo Medio Lxcelente Medio a excelente
Orece a los clientes signos isibles de
progreso
Medio Lxcelente Medio Lxcelente
Orece a la directia signos isibles de
progreso
Medio Lxcelente Medio Lxcelente
Requiere poca soisticacin para los directios
y desarrolladores
Medio Malo Malo Medio

Ll cuadro anterior le presenta una comparacin entre algunos de los modelos descritos en este
captulo. Ln la primera columna contiene arias caractersticas importantes entre los modelos
eicientes.
Ln ila inicial, estan indicados algunos de los modelos que son de inters y que son utilizados
comnmente.

Actividad
Analice detenidamente el cuadro de capacidades de los modelos de ciclo de ida del .oftrare. Obsere los
alores asignados en cada una de las celdas. Indique en cuales concuerda con el alor asignado y en cuales
no. Si su respuesta es negatia, describa los motios que lo llean a razonar de esa manera.

33 33 33 33


6. D tres ejemplos de proyectos de .oftrare adaptables al modelo en cascada. Sea
especico.
. Para lograr un desarrollo rapido, el modelo DRA asume la existencia de una
cosa. ,Cual es y por qu dicha suposicin no siempre es erdadera
8. Proporcione tres ejemplos de proyectos de .oftrare adaptables al modelo
incremental. Sea especico.
9. ,Cuales son las entajas y desentajas de desarrollar .oftrare con calidad lo
suicientemente buena` Lsto es, ,qu pasa cuando se resalta la elocidad de
desarrollo sobre la calidad del proyecto
10. Ls posible probar que un componente de .oftrare o incluso un programa
completo esta correcto. Lntonces, ,por qu no todos lo hacen
11. Lxplique por qu los programas que se desarrollan utilizando el desarrollo
eolutio tienden a ser diciles de mantener.

34 34 34 34
Desarrollo agil

Cvo oraevar et cao. ev et ae.arrotto aet sotware, veaiavte et ttevaao ae vv
varco ae traba;o aefiviao, cov vv cov;vvto ae tarea. etcita. ara caaa vva ae
ta. acciove. ae ta ivgeviera ae .i.teva..

8umario


Agilidad en el desarrollo
,Qu es un proceso agil
Modelos agiles de proceso
Capitulo

35 35 35 35

SUB1LMAS PGINAS
Agilidad en el desarrollo 9
,Qu es un proceso agil 81
Modelos agiles de proceso 84

36 36 36 36

a aparicin del desarrollo gil obedece a la necesidad del ser humano de proocar lexibilidad
y dinamismo en las actiidades que ejecuta. Lsto lo hace para buscar siempre agilidad en los
procesos y con esto, la obtencin del producto en la menor cantidad de tiempo y sin perder
ningn atributo importante en su coneccin.
Ln la actualidad, tal como se ha planteado repetidamente, las necesidades de mercado son muy
cambiantes en el mundo del desarrollo de .oftrare. Lsto obedece, muchas eces, a las situaciones que
establece la competencia.
Por lo tanto, los equipos de desarrollo deben proeer soluciones cada ez mas rapidas y robustas en
contenido, pero que a la ez no disminuya su calidad a cambio de esa elocidad.
Ll desarrollo agil busca precisamente eso: cmo sacarle el mayor proecho a la ingeniera de .oftrare
pero con un niel de desarrollo mucho mas ligero o dinamico que el isto hasta este momento. Se
buscara, en este captulo, exponer la manera de conseguirlo y aplicarlo en el mundo real. Siempre habra
que tener presente que esta produccin acelerada no es iable para todo tipo de proyecto, aspecto que
tambin se explicara.

37 37 37 37
Desarrollo

Ls posible encontrar la agilidad dentro del contexto del desarrollo del .oftrare, un ejemplo son aquellos
esuerzos en donde se asumen los lineamientos indicados por la ingeniera del .oftrare, en donde se le
da mucha seriedad al tema del cambio, como eje conductor para alcanzar dicha agilidad.

Actividad
Analice la descripcin que orece Iar Jacobson, en la pagina 9 del libro, para el tema de agilidad.
Considere las apreciaciones dadas por l y cmo deben ser incluidas en un desarrollo de .oftrare. ,Qu tan
sencillo es lograrlo

Ademas del tema del cambio, para el desarrollo agil encontramos elementos que deben ser
considerados tales como la estimulacin en la comunicacin de los interesados en el proyecto, la
entrega pronta del .oftrare operatio y la flexibilidad en la planiicacin del material.

vortavte:
Ll desarrollo agil basa su existencia en la incertidumbre existente en cualquiera de las etapas del
proyecto. Lste titubeo se presenta al no poder controlar las modiicaciones ,aumento -
disminucin, a los requerimientos ya establecidos o que estan por enir. Ante esto, solo una buena
administracin de soporte para el control de cambio nos ayudara a salir con los tiempos
establecidos y con la calidad esperada para el desarrollo.

Actividad
Ln la pagina 90 del libro de texto, se encuentran 12 principios para alcanzar la agilidad en el desarrollo, lalas
y analcelas a la luz de lo entendido hasta ahora para desarrollo agil de .oftrare.

Un proceso agil de .oftrare debe tener uerte adaptabilidad para que sea un xito, en gran medida
porque estos enoques son incrementales, lo que indica claramente que aanzan en cuerpo para cada
nuea iteracin.
Lsto llea a pensar que esta adaptacin incremental requiere aspectos como la retroalimentacin del
cliente, incrementos de .oftrare que permitan entregar soluciones o prototipos ejecutables que siran de
catalizador al cliente, para medir el grado de aance con respecto a lo indicado en el analisis preio a la
etapa de construccin.
Lxisten tres suposiciones claes acerca de los proyectos de .oftrare, que son aptos para un proceso de
desarrollo agil de .oftrare. Se encuentran en el siguiente recuadro:

38 38 38 38

vortavte:
Resulta dicil predecir cuales requisitos del .oftrare persistiran y cuales cambiaran.
Para muchos tipos de .oftrare, el diseno y la construccin estan intercalados, por lo tanto, el
diseno se prueba casi cuando se crea.
Ll analisis del diseno y la construccin no son predecibles.

Con estas tres suposiciones, se genera una incgnita importante por resoler: ,se puede desarrollar un
proceso manipulable de manera impredecible
La respuesta a esto se encuentra en la adaptabilidad del proceso, tal y como se mencion en parraos
anteriores, para con el proyecto y sus condiciones tcnicas y de ambiente.
1al como lo indica el libro, el factor humano es un elemento ital para la consecucin exitosa de un
proyecto. Principalmente porque el proceso se debe ajustar a personas y equipos de trabajo
especicos, cada uno con sus talentos y habilidades puestos al sericio del proceso.

Actividad
Ln las paginas 83 a 84 del libro de texto, se encuentra un grupo de rasgos clae entre la gente y el equipo de
desarrollo. Ls importante que las lea, las analice y las ubique en el comportamiento cotidiano del ser
humano, a la luz de lo entendido hasta ahora para desarrollo agil de .oftrare.

Modelos giles de procesos
Para los modelos agiles de procesos de desarrollo del .oftrare, tambin hay dierentes propuestas. 1odas
buscan encontrar un lugar y posicionarse en la mente de los ingenieros y desarrolladores de .oftrare,
como la propuesta mas completa para dar agilidad a los proyectos de desarrollo.
Como primer exponente, esta al modelo de la programacin extrema ,PL,, basado en un conjunto
de reglas y practicas que ocurren en el contexto de las cuatro actiidades del marco de trabajo:
planeacin, diseo, codificacin y pruebas.

39 39 39 39

Iigura J2 Proceso de la programacin extrema.
La planeacin esta basada en una serie de historias similares a lo que sera un caso de uso, que
describen las caractersticas y unciones requeridas por el sistema. Lstas historias se analizan y clasiican
segn el peso otorgado al valor y al costo dado, para iniciar el desarrollo segn sea ese peso.
Ln el diseo se intenta respetar al maximo la simplicidad de lo recolectado hasta el momento. Ln
otras palabras, se trata de modelar la historia tal y como qued deinida en la etapa anterior.
Ll diseno se apoya en las tarjetas de CRC ,Colaborador-Responsabilidad-Clase, captulo 8 del libro de
texto,, que llean a este modelo a un contexto orientado a objetos.
Se apoya en el concepto de refabricacin, que permite sugerir modiicaciones al diseno de orma que
lo mejoren de manera radical. Lste proceso se realiza tanto antes como despus de la codiicacin.
Se espera que antes del inicio de la codificacin se presente una etapa de pruebas de unidad, que
ealen lo indicado en las historias que an incluidas en la iteracin de ese momento en particular.
Lsto se hace con el in de aorecer el proceso de eriicacin de cdigo por parte de los
desarrolladores, mediante dicha retroalimentacin.
Ln la etapa de pruebas, se crean las pruebas de unidad, que se enocan en cada uno de los
componentes desarrollados de manera indiidual. Dichas pruebas tratan de automatizarse dentro del
marco de trabajo del proceso, para que sean exactas y repetibles cuanto se quiera.

Actividad
Ln las paginas 84 a 88 del texto, se encuentra cada una de las etapas descritas con amplitud. Lalas y
analcelas para ahondar en el tema de los procesos agiles de desarrollo. Llabore un resumen que
complemente su estudio.
Otro de los mtodos descrito en el libro es el desarrollo adaptativo del software ,DSA,, basado en la
colaboracin humana y la organizacin propia del equipo. Lsta pensado en 3 ases: especulacin,
colaboracin y aprendizaje. Ademas, utiliza un proceso iteratio que incorpora inteligentemente la
planeacin del ciclo adaptatio, mtodos de recopilacin de requisitos y un ciclo iteratio de desarrollo
que incorpora grupos enocados al cliente.

40 40 40 40

Iigura J3 Desarrollo adaptativo del software
Ll desarrollo de sistemas dinamicos MDSD es otro mtodo explicacin que da el texto sobre los
modelos agiles de proceso. Lste basa su enoque en proporcionar un marco de trabajo para construir y
mantener sistemas con restricciones de tiempo mediante prototipos incrementales en un ambiente
de proyecto controlado.
Al igual que el PL y el SDA es un proceso iteratio del .oftrare, pero con la caracterstica que sigue la
regla del 80,20 ,80 de la aplicacin en el 20 del tiempo total,. Lsto es que solo se necesita el
trabajo suiciente para cada incremento y para acilitar el pase al siguiente moimiento en ruta hacia el
nueo incremento.
1ambin el libro nos describe el modelo mele, que incorpora las siguientes actiidades del marco de
trabajo: requisitos, anlisis, diseo, evolucin y entrega. Ln cada actiidad del marco de trabajo, las
tareas se suceden dentro del patrn de proceso` llamado sprint. Ll trabajo dentro de cada .rivt se
adapta al problema y, con recuencia, lo modiica en tiempo real por medio del equipo de trabajo.
Los patrones de proceso mencionados ya han probado su uso y eectiidad en proyectos con tiempos
reducidos de entrega, requerimientos cambiantes y condiciones adersas para el negocio.
Cada patrn de proceso contiene un conjunto de actiidades de desarrollo: lista de retrasos, sprint,
reuniones de mele, y demostracin.
Actividad
Ln las paginas 89 a 95 del texto se encuentra cada uno de estos mtodos descritos con mayor amplitud.
Lalos para complementar su estudio del tema.

La lista de mtodos agiles de proceso es mas larga an, contemplando a mtodos como el de la amilia
Cristal, o los de desarrollo conducido por caractersticas ,DCC,, o modelado agil ,MA,.
1odos estos mtodos tratan, a su manera y con sus elementos distintios, de ayudar al ingeniero de
.oftrare a alcanzar su maxima meta: la de entregar cada desarrollo solicitado en los tiempos establecidos,
con la calidad esperada y con la satisaccin del cliente de por medio.

41 41 41 41

Actividad
Ln las paginas 95 a 98 del libro de texto, se encuentra cada uno de estos mtodos descritos completamente.
Ls necesario que realice la lectura para comprender su existencia como mtodos agiles.

42 42 42 42


12. Describa, con palabras propias, la palabra agilidad ,dentro del ambito de
proyectos de .oftrare,.
13. ,Podra cada uno de los procesos agiles describirse recurriendo a las actiidades
genricas del marco de trabajo mencionado en el captulo 3 de esta gua
Construya una tabla que coloque las actiidades genricas dentro de las
actiidades deinidas para cada proceso agil.
14. Seleccione un principio de agilidad de los enunciados en la seccin 4.1 ,segunda
actiidad mencionada en este captulo de la gua, y trate de determinar si cada
uno de los modelos de procesos presentados en este captulo muestran ese
principio.
15. ,Por qu cambian tanto los requisitos Despus de todo ,la gente no sabe lo que
quiere Ample su respuesta.
16. Considere los siete rasgos enunciados en la seccin 4.2.2 ,tercera actiidad
mencionada en este captulo de la gua,. Ordene los rasgos con base en su
percepcin desde lo que es mas importante a lo menos.

43 43 43 43
La practica: una visin general

.ev vv rivciio geverico, ta ractica e. vva cotecciv ae covceto., rivciio.,
vetoao. , berravievta. a ta. qve vv ivgeviero ae sotware recvrre a aiario.

8umario

Los temas tratados en este captulo son:

La practica de ingeniera de .oftrare
Practicas de comunicacin
Practicas de planeacin
Practicas del modelado
Practicas de la construccin
Despliegue
Capitulo

44 44 44 44

SUB1LMAS PGINAS
La practica de ingeniera de .oftrare 105
Practicas de comunicacin 109
Practicas de planeacin 113
Practicas del modelado 116
Practicas de la construccin 122
Despliegue 126

45 45 45 45

l arte de la ingeniera de .oftrare es una coleccin de conceptos, principios, mtodos y
herramientas a las que los ingenieros encargados del .oftrare recurren todos los das para
resoler problemas en la creacin de programas para la computadora.
1odo aspecto que nos presente un cmo resoler, en cuestin de cdigo, remite directamente a alguna
de las actiidades asociadas con ingeniera de .oftrare.
La isin genrica que se describira permite er todo el proceso de desarrollo, desde que se concibe la
idea hasta que tenemos algo tangible en las manos.
Permite er con claridad cmo se atienden cada una de las situaciones que aumentan o disminuyen el
ritmo marcado en cada actiidad realizada para la construccin del .oftrare.

46 46 46 46
Desarrollo

1al y como se mencion en los comentarios generales, la ingeniera soporta de manera metdica las
actiidades del quehacer inormatico, en cuanto a desarrollo de .oftrare se reiere.
La gua de estudio, en el captulo siguiente, lo orienta para adentrarse en el mundo real del ingeniero y
en la practica de la ingeniera de .oftrare, en cuanto a la dimensin de las actiidades y del entorno que
encontrara en las dierentes organizaciones.
1odo esto a muy de la mano con las actividades genericas dentro del marco de trabajo descrito en
captulos anteriores.

vortavte:
Las actiidades genricas dentro del marco de trabajo son: comunicacin, planeacin,
modelado, construccin y despliegue.

Ln la practica se debe seguir una serie de principios genericos y conceptos que rigen cada una de
estas actiidades.
Ll libro de texto hace hincapi en la importancia del tema de resolucin de problemas, de hecho
puntualiza los pasos necesarios que representan la esencia en la resolucin de problemas.
Los pasos necesarios para dar solucin a un problema puntual son: entender el problema, planear la
solucin, llear a cabo el plan y examinar los resultados obtenidos. Lstos pasos se pueden ajustar para
un problema de .oftrare.

vortavte:
Ajuste para el desarrollo de .oftrare:
Lntender el problema: comunicacin y analisis.
Planear la solucin: modelado y diseno de .oftrare.
Llevar a cabo el plan: generacin de cdigo.
Lxaminar los resultados obtenidos para probar la precisin: realizacin de pruebas y
aseguramiento de la calidad.

Actividad
Ln la pagina 106 del libro de texto se encuentran los cuatro puntos para alcanzar la esencia de la practica.
Lea las preguntas asociadas y analcelas segn su experiencia personal. Contraste estos principios con los
problemas que ie en su ida diaria, y la orma en cmo los resuele.

47 47 47 47
Los principios expuestos son, en general, leyes que gobiernan ciertas acciones en el pensamiento
humano. Su alcance puede tener dierentes nieles de abstraccin, desde estar asociados a una actiidad
genrica de la ingeniera del .oftrare, hasta estar presente en alguna de sus actiidades.
Ln el libro de Roger S. Pressman se proponen siete principios bsicos que se reproducen
rapidamente en las actiidades sobre la ingeniera de .oftrare, a saber:

vortavte:
Principios esenciales de la ingeniera del .oftrare:
I Razn por la que todo existe: orecer un alor al usuario.
II Mantenerlo simple: todo diseno debe ser tan simple como sea posible, pero no mas simple.
III Mantener la isin: una isin clara es esencial para el proyecto de sotware.
IV Lo que uno produzca otros lo consumiran: pensar en consumidores de la reutilizacin.
V Lstar abierto al uturo: resoler problemas de orma general, no especica.
VI Planear para la reutilizacin: la reutilizacin ahorra tiempo y esuerzo y su planeacin, de esa
manera, otorga alor agregado.
VII Pensar: cuando se tiene un pensamiento claro y completo antes de cada accin, se producen
los mejores resultados.

Actividad
Ln las paginas 10 - 109 del libro de texto se encuentran los siete principios esenciales de la ingeniera de
.oftrare. Lea el desarrollo de cada uno de estos principios y analcelos segn su experiencia particular.
,Por qu se consideran principios esenciales, ,agregara usted algunos

1al y como se describi en captulos anteriores, la etapa de la comunicacin ,permite la obtencin de
los requerimientos, orma parte del marco de trabajo de la ingeniera de .oftrare. Al igual que las demas
etapas, esta regida por principios que permiten llear a cabo dicha etapa de la manera mas completa y
eiciente.

vortavte:
Principios esenciales de la comunicacin:
I Lscuchar.
II Prepararse antes de comunicar.
III Alguien debe acilitar la actiidad.
IV La comunicacin cara a cara es lo mejor.
V 1omar notas y documentar las decisiones.

48 48 48 48
VI Buscar colaboracin.
VII Conserar el enoque, examinar un mdulo a la ez.
VIII Si algo no esta claro, se hace un dibujo.
IX Una ez que se llega a un acuerdo sobre algo, se debe continuar. Lste estado no debe
cambiar, no importa si se llega a un acuerdo posterior, o no.
X La negociacin no es un concurso o un juego. lunciona mejor cuando ambas partes ganan.

Actividad
Ln las paginas 110 - 111 del libro de texto, se encuentran los diez principios esenciales de la comunicacin.
Lea el desarrollo de cada uno de estos principios y analcelos segn su experiencia particular.
,Por qu es tan importante el leantado de requerimientos, ,agregara usted algunos principios, ,cuales

Ln la planeacin encontramos el camino ordenado mediante las pautas por seguir, para aplicar los
objetios tacticos deinidos en la comunicacin, mediante un conjunto de practicas tcnicas. Se
encuentra tambin en esta etapa una serie de principios que guan de manera ordenada y metdica su
realizacin:

vortavte:
Principios esenciales de la planeacin:
I Lntender los alcances del proyecto.
II Inolucrar al cliente en la actiidad de planeacin.
III Reconocer que la planeacin es iteratia.
IV Lstimar con base en el conocimiento disponible.
V Considerar el riesgo cuando se deine el plan.
VI Ser realista.
VII Ajustar la granularidad mientras se deine el plan.
VIII Deinir cmo se intentara asegurar la calidad.
IX Describir cmo se pretende incluir el cambio.
X Adaptar el plan a menudo y hacer ajustes cuando se requieran.

Actividad
Ln las paginas 113 - 115 del libro de texto, se encuentran los diez principios esenciales de la planeacin. Lea
el desarrollo de cada uno de estos principios y analcelos segn su experiencia propia.

49 49 49 49
Prcticas del modelado
Los modelos de analisis y diseno permiten entender porqu y cmo se desarrollara la solucin,
tomando en cuenta los dominios de informacin, funcional y del comportamiento ,analisis,, y de
caractersticas que ayudan a su construccin, como lo son la arquitectura, la interfaz de usuario y el
detalle a nivel de componentes ,diseno,.
Lxisten una ariedad de principios operatios, que permiten ejecutar estas practicas de modelado de
manera segura y ordenada, a pesar de la existencia de dierentes mtodos de modelado en el mercado.

vortavte:
Principios esenciales del modelado del anlisis:
I Ll dominio de inormacin de un problema debe representarse y entenderse.
II Se deben deinir las unciones que ejecuta el .oftrare.
III Se debe representar el comportamiento del .oftrare ,como consecuencia de eentos externos,.
IV Los modelos que presentan inormacin, uncin y comportamiento deben partirse de
orma que descubran el detalle de una manera estratiicada o jerarquica.
V La tarea del analisis debe moerse de la inormacin esencial hacia el detalle de la
implementacin.
Principios esenciales del modelado del diseo:
I Ll diseno debe ser rastreable hasta el modelo de analisis.
II Siempre se debe considerar la arquitectura del sistema que se a a construir.
III Ll diseno de datos es tan importante como el diseno de unciones de procesamiento.
IV Las interaces ,internas y externas, deben disenarse con cuidado.
V Ll diseno de interaz del usuario debe ajustarse a las necesidades del usuario inal.
VI Ll diseno al niel de componentes debe ser independiente del modo uncional.
VII Los componentes deben estar apareados entre s en ormas mnimas y inculadas con el
ambiente externo.
VIII Las representaciones del diseno ,modelos, deben ser acilmente comprensibles.
IX Ll diseno debe desarrollarse de manera interactia. Ln cada iteracin el desarrollador debe
buscar la mayor simplicidad.

Prcticas de la construccin
La practica de la construccin establece el momento donde se toman todos los lineamientos
encontrados y se desarrolla el cdigo que a a soportar la lgica deinida para la aplicacin.

50 50 50 50
Posterior a esta etapa, endra una serie de pruebas de dierentes tipos, que permiten asegurar, tanto a
lo interno como a lo externo, que la interaccin entre los componentes esta correcta y, por lo tanto, se
an a obtener los resultados deseados por el cliente.
Los tipos dierentes de pruebas son: unitarias, de validacin y de aceptacin.

vortavte:
1anto las pruebas unitarias, como las de alidacin y las de aceptacin, seran retomadas en los
captulos 13 y 14, que nos hablan sobre estrategias y tcnicas para el tema de las pruebas de un
sistema de inormacin, que es tan importante y amplio en la bsqueda de .oftrare de calidad.
Ln las paginas 123 a la 125 del libro de texto encontrara detalles de algunos principios asociados,
tanto a la codiicacin como a las pruebas en s.

Actividad
A la luz de lo ledo hasta ahora, analice y describa por qu es tan importante esta etapa dentro de todo el
ciclo de desarrollo de .oftrare.

Una ez terminada la etapa de construccin, solo queda el despliegue del programa desarrollado y ya
probado, que se coloca en las maquinas del cliente. Se debe recordar, tal y como se senal en captulos
anteriores, que el paradigma de desarrollo de sistemas que mas ha aanzado es el evolutivo. Lste
proee en todo su ciclo de accin, dierentes entregas del producto eolucionado, para tener al inal
una ersin remozada y robusta que acapara cada aance, pero mejorado en cada iteracin del ciclo.
Cada una de estas entregas, debe respetar una serie de principios claes para su correcto ingreso y
despliegue:

vortavte:
Privciio. ara et despliegue:
e aebev aavivi.trar ta. eectatira. qve et ctievte tieve aet sotware.
e aebe ev.avbtar , robar vv aqvete ae evtrega covteto.
e aebe e.tabtecer vv regivev ae .oorte avte. ae evtregar et sotware.
1 e aebe roorciovar vateriat iv.trvctiro a.ociaao a to. v.vario. fivate..
1 t sotware cov errore. .e aebe arregtar rivero , evtregar ae.ve..

Actividad
Ln las paginas 126 y 12 del libro de texto encontrara los principios asociados al despliegue. Analice y
describa la importancia de un buen proceso de despliegue, como etapa directa de interaccin con el usuario
o cliente inal.

51 51 51 51

Ln la pagina 131 del libro de texto encontrara algunos problemas y puntos que debe considerar acerca
del captulo que acaba de estudiar.
Ls importante que intente resoler los siguientes ejercicios, lo cual le permitira medir su aprendizaje.

1. Inestigue acerca de la facilitacin` para la actiidad de comunicarse. Prepare
un conjunto de directrices que se enoquen solo en este punto.
18. ,Ln que diieren la comunicacin agil y la comunicacin de la ingeniera de
.oftrare tradicional ,Ln que se asemejan
19. Inestigue acerca de la negociacin` para la actiidad de comunicarse. Prepare
un conjunto de directrices que se enoquen solo en este aspecto.
20. Describir lo que signiica granularidad en el contexto de un calendario de
proyecto.
21. ,Cuales son los tres dominios que se consideran durante el modelado de
analisis.
22. Ln sus propias palabras, ,qu es una prueba exitosa ,Cmo se mide

52 52 52 52
Referencias

Larman, Craig ,2004, UML y Patrones. Mxico D.l.: Prentice lall, segunda edicin.

McConnell, Stee ,1996, Desarrollo y gestin de proyectos informticos. Mxico D.l.: Prentice
lall, segunda edicin.

53 53 53 53
Glosario de analisis de software

CMM: Caabitit, Matvrit, Moaet o Modelo de Capacidad y Madurez es un modelo de ealuacin de los
procesos de una organizacin. lue desarrollado inicialmente para los procesos relatios al
.oftrare por la Uniersidad Carnegie-Mellon para el SLI ,oftrare vgiveerivg v.titvte, en los
Lstados Unidos.

CMMI: Caabitit, Matvrit, Moaet vtegratiov es un modelo para la mejora de procesos que proporciona a
las organizaciones los elementos esenciales para procesos eicaces. Las mejores practicas
CMMI se publican en los documentos llamados modelos. Ln la actualidad hay dos areas de
inters cubiertas por los modelos de CMMI: desarrollo ,se tratan procesos de desarrollo de
productos y sericios, y adquisicin ,se tratan: la gestin de la cadena de suministro,
adquisicin y contratacin externa en los procesos del gobierno y la industria,.

Iramework: estructura de soporte deinida en la cual otro proyecto de .oftrare puede ser organizado y
desarrollado. 1picamente, un fraveror/ puede incluir soporte de programas, bibliotecas y un
lenguaje interpretado entre otros .oftrare para ayudar a desarrollar y unir los dierentes
componentes de un proyecto. Un fraveror/ representa una arquitectura de .oftrare que modela
las relaciones generales de las entidades del dominio. Proee una estructura y una metodologa
de trabajo la cual extiende o utiliza las aplicaciones del dominio.

ISO: vtervatiovat Orgaviatiov for tavaaraiatiov u Organizacin Internacional para la Lstandarizacin es
el organismo encargado de promoer el desarrollo de normas internacionales de abricacin,
comercio y comunicacin para todas las ramas industriales a excepcin de la elctrica y la
electrnica. Su uncin principal es la de buscar la estandarizacin de normas de productos y
seguridad para las empresas u organizaciones a niel internacional

OMG: ,Ob;ect Mavagevevt Crov, por sus siglas en ingls, Grupo de Gestin de Objetos es un
consorcio dedicado al cuidado y establecimiento de diersos estandares de tecnologas
orientadas a objetos. Ls una organizacin sin animo de lucro que promuee el uso de
tecnologa orientada a objetos mediante guas y especiicaciones para las mismas.

UML: ,|vifiea Moaetivg avgvage, por sus siglas en ingls, Lenguaje Unificado de Modelado es el
lenguaje de modelado de sistemas de .oftrare mas conocido y utilizado en la actualidad, esta
respaldado por el OMG ,Ob;ect Mavagevevt Crov,. Ls un lenguaje graico para isualizar,
especiicar, construir y documentar un sistema de .oftrare. UML orece un estandar para

54 54 54 54
describir un plano` del sistema ,modelo,, incluyendo aspectos conceptuales tales como
procesos de negocios y unciones del sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y componentes de .oftrare reutilizables.

55 55 55 55
Enlaces electrnicos

CAP1ULO CONCLP1O PGINA
2 Pagina oicial CMMI http:,,www.sei.cmu.edu,cmmi,
2 ltima reisin del CMMI http:,,www.sei.cmu.edu,cmmi,adoption,pd,c
mmi-oeriew0.pd
2 Sitio en espanol de CMMI http:,,es.wikipedia.org,wiki,CMMI
2 Imagen 1 de estructura CMMI
1.1
http:,,upload.wikimedia.org,wikipedia,commo
ns,3,3c, Lstructuracmmi11cont.png
2 Pagina oicial de ISO http:,,www.iso.org,iso,home.htm
3 Descripcin del proceso
uniicado
http:,,es.wikipedia.org,wiki,Proceso_Uniicado
3 Descripcin del proceso
uniicado de Rational
http:,,es.wikipedia.org,wiki,RUP
3 Pagina de IBM acerca del RUP http:,,www-
306.ibm.com,sotware,mx,rational,
4 Descripcin de programacin
extrema
http:,,es.wikipedia.org,wiki,ProgramaciC3
B3n_Lxtrema
4 Descripcin del maniiesto agil http:,,www.extremeprogramming.org,index.ht
ml
4 Descripcin del maniiesto agil,
indicado en el libro de texto
http:,,agilemaniesto.org,
4 Descripcin metodologas agiles
en desarrollo de .oftrare
http:,,www.willyde.net,descargas,pre,1odo
Agil.pd

56 56 56 56
La practica de
la ingenieria de software

.ta ractica e. vv avtio arregto ae covceto., rivciio., vetoao., , berravievta. qve
aebev cov.iaerar.e cvavao .e tavea et sotware. Rere.evta to. aetatte. - ta.
cov.iaeraciove. tecvica. , to. cvo - qve e.tav ba;o ta .verficie aet roce.o ae
sotware. Roger Pressman

Ob]etivos

Lste tema pretende llear a la practica todos los conceptos, mtodos y tcnicas mencionadas en el tema
I, con la esperanza de que el estudiante encuentre la conexin y el sentido existente, entre la teora
relatada y las aplicaciones en el mundo real, para el desarrollo del .oftrare.
Cuando termine de estudiar este tema, estara en capacidad de:

Analizar cuales son los conceptos y principios que deben seguirse para una ingeniera del
.oftrare cada ez mas eectia.
Lntender qu aspectos de la ingeniera de sistemas corresponden especicamente al area de
ingeniera de requisitos, ademas de identiicar cuales conceptos son necesarios para su buena
aplicacin.
Describir cmo se obtiene el modelo de analisis y cuales son los elementos necesarios para
soportarlo.
Lxplicar en qu consiste la ingeniera de diseno, y cuales son los conceptos que permiten darle
un ambiente robusto en su realizacin.
Tema

57 57 57 57
8umario


Capitulo 6 Ingenieria de sistemas
Capitulo 7 Ingenieria de requisitos
Capitulo 8 Modelado de anlisis


58 58 58 58
ngenieria de sistemas

.vo ba, vaaa va. aifcit ae tterar a cabo, va. etigro.o ae reatiar o ae eito
va. ivcierto qve evcabear ta ivtroavcciv ae vv vvero oraev ae co.a..
Maquiavelo

8umario
Los temas tratados en este captulo son:
Sistemas basados en computadora
La jerarqua de la ingeniera de sistemas
Ingeniera de procesos de negocios
Ingeniera del producto
Modelado del sistema
Capitulo

59 59 59 59

SUB1LMAS PGINAS
Sistemas basados en computadora 134
La jerarqua de la ingeniera de sistemas 136
Ingeniera de procesos de negocios: una isin general 140
Ingeniera del producto: una isin general 142
Modelado del sistema 144

60 60 60 60

a ingenieria de sistemas comprende una serie de elementos que se relacionan con el
desarrollo del sistema como producto inal. Ademas, esta ingeniera se considera una serie de
partes de un todo`, que permiten al sistema desarrollado terminar del modo esperado.
La ingenieria del software tan solo es un eslabn dentro de este proceso de ingeniera de sistemas.
Antes de ella, se trabaj oportunamente en aspectos de analisis, diseno y organizacin que permitieran
crear el ambiente ptimo que enuele a la ingeniera del .oftrare, para que sta trabaje bien.
Ln este captulo se dara la introduccin a la rama de las ingenieras que interesa en este curso: la
ingeniera de .oftrare. Se usara la ptica de la ingeniera, ista desde un enoque de proceso de negocios
y tambin desde un enoque orientado al producto como tal, para acilitar su comprensin.

61 61 61 61
Desarrollo

Sistemas basados en computadora
Para empezar es importante tener claro qu se entiende cuando se habla de la palabra sistema. 1anto
en diccionario como en libros, encontrara deiniciones de dnde escoger.
Ll libro de Pressman propone, como la ersin mas acertada para el mundo de la computacin, la
siguiente deinicin:

vortavte:
Concepto de sistema: conjunto o disposicin de elementos que estan organizados para cumplir
una meta predeinida al procesar inormacin.

Actividad
Inestigue sobre otras deiniciones, tanto en el libro de texto como en dierentes uentes, para la palabra
sistema. Contraste los signiicados encontrados con el propuesto aca y determine semejanzas y dierencias.

Los elementos que se menciona en la deinicin dada, es posible enlistarlos en el siguiente cuadro:

vortavte:
Llementos del sistema.
Software: programa de computadora.
Hardware: dierentes tipos de dispositios electrnicos tangibles que proporcionan una uncin
externa del mundo real.
Personas: usuario y operadores de .oftrare y bararare.
Bases de datos: recopilacin de inormacin acezada mediante el .oftrare.
Documentacin: inormacin descriptia que detalle el uso y operacin del sistema.
Procedimientos: pasos que deine el uso especico de cada elemento del sistema.

Jerarquia de la ingenieria de sistemas
La ingeniera de sistemas se puede acomodar de manera jerarquica. Lsto permite naegar siempre de lo
general a lo especico, y pasar por todos los estratos de esta cadena de elementos. Se puede describir
dicha jerarqua de la siguiente orma:

vortavte:

62 62 62 62
Jerarqua de sistema.
Visin global: conjunto de dominios.
VG ~ |D1, D2, D3,. DN|
Visin dominio: conjunto de elementos.
VD ~ |L1, L2, L3,. LN|
Visin elementos: conjunto de componentes.
VL ~ |C1, C2, C3,. CN|

1odo este enoque le permitira al ingeniero de sistemas tener una perspectia amplia de la localizacin
del elemento que resuele una necesidad puntual. Le ayudara a entender de manera intuitia cuando
debe bajar para atacar algn problema, segn corresponda, dentro de la jerarqua presentada.

Iigura 0J - Jerarquia de ingenieria de sistemas.

Actividad:
Analice la igura anterior. Considere los siguientes aspectos:
,Ls posible determinar qu representan las subdiisiones de cada isin
,Qu tipo de ayuda le brinda este esquema
Inestigue sobre algn sistema ya desarrollado en su area de trabajo. Ubique cada uno de los estratos de esta
jerarqua en el sistema escogido.

63 63 63 63
Ll modelado de sistemas permite a los ingenieros crear su isin del problema por resoler, de
manera tal que:
Logren deinir los procesos que satisacen las necesidades de la isin que se considera.
Representen el comportamiento del proceso y sus supuestos.
Deinan de modo explcito las entradas exgenas y endgenas de inormacin al modelo.
Representen todas las uniones que permitan al ingeniero entender mejor la isin.

Ademas, se deben considerar algunas restricciones que se presentan en el modelado de sistemas,
debido a que existe todo un ambiente muy complejo que modiica el estado de las cosas en cada
momento para el modelado.
Se debe tener claro cual es este estado actual, en el momento de iniciado el proceso, para contemplar
tipos de restricciones como las siguientes:

vortavte:
1ipos de restricciones para el modelado.
Supuestos: reducen el nmero de permutaciones y ariaciones posibles, lo que permite al modelo
relejar el problema de una manera razonable.
Simplificaciones: permiten la creacin del modelo a tiempo.
Limitaciones: ayudan a delimitar el sistema.
Restricciones: guan la manera de crear el modelo y tomar el enoque al implementarlo.
Preferencias: indican la arquitectura preerida para todos los datos, unciones y tecnologa.

Por otro lado, el modelado de sistemas y las herramientas de simulacin, se utiliza ampliamente en los
sistemas clasiicados como reactivos, y que estan basados en computadoras. Lsto porque dichos
sistemas normalmente son de tiempo real y su ejecucin correcta puede salar idas o ahorrar grandes
cantidades de dinero.
De ah que la capacidad de simulacin de la operacin del sistema, antes de que el mismo se ponga a
produccin, es ital para el xito integral del proyecto.

Ingenieria de proceso de negocios
Ll libro describe la ingeniera de procesos de negocios, como un enoque dentro de la ingeniera de
sistemas que crea un plan general para implementar la arquitectura de cmputo. Se diide en tres
arquitecturas dierentes:

64 64 64 64
vortavte:
Arquitecturas dentro de la ingeniera de proceso.
Arquitectura de datos: proporciona un marco de trabajo para las necesidades de inormacin de
un negocio o de una uncin de negocio.
Arquitectura de aplicaciones: abarca elementos de un sistema que transorma objetos dentro de
la arquitectura de datos por algn propsito de negocio.
Arquitectura de la tecnologia: proporciona el undamento para las estructuras de datos y
aplicacin.

Actividad:
Analice la igura que se encuentra en la pagina 141 del libro de texto, llamada a ;erarqva ae ta ivgeviera ae
roce.o. ae vegocio..
Considere la orma, la estructura, los nieles que se presentan y la releancia de cada uno. Lale la jerarqua
y d su opinin al respecto.

Ingenieria de producto
Llear una serie de capacidades deinidas por el cliente a un programa desarrollado es la inalidad de la
ingeniera de producto. Para lograrlo, debe tener una arquitectura y una estructura que la soporte.
La arquitectura mencionada abarca cuatro componentes, a saber: software, hardware, datos y
personas.
Una isin general del dominio se consigue al determinar los requerimientos del cliente ,ingeniera de
requisitos,. Lsta ingeniera tiene como trabajo asignar uncin y comportamiento a cada uno de los
componentes descritos anteriormente.
1erminada esta asignacin, sigue la ingeniera de componentes, que rene un conjunto de actiidades
para cada uno de los componentes de ingeniera de sistema: ingeniera de software, de hardware, de
datos y la humana.

Modelado de sistema
Los modelos de sistemas tienden a ser jerarquicos por naturaleza. Ln su parte mas alta se representa un
modelo del sistema completo. Cuando se empieza a reinar aparece el niel de detalle de los
componentes, y culminan con la aparicin de los modelos de ingenieria que son especicos para
cada una de las disciplinas de ingeniera que esta asociada.
Como los modelos mas emblematicos para el modelado de sistemas, se encuentra el modelado de
sistemas de Hatley-Pirbhai y el modelado de sistemas con UML.
Ll libro de texto expone cada uno de estos modelos de manera amplia y trata de exponer la actiidad y
ptica del modelado de sistemas, a partir de estos dos mtodos tan utilizados hoy da.

65 65 65 65
Ll modelo de latley-Pirbhai permite representar la entrada, el procesamiento y la salida junto con
la interfaz de usuario y su correspondiente mantenimiento. Ademas, le suma una caracterstica
importante al modelado tradicional: el procesamiento de autocomprobacin.
Por otro lado, en el modelado con UML, lo que se obtiene como dierenciador, dentro de los modelos
actuales, es la gran cantidad de diagramas que pueden utilizarse para el analisis y diseno a niel del
.oftrare y del sistema.
Lstos diagramas aumentan la ptica sobre el sistema y su contexto, ampliando la cantidad de istas
estaticas y dinamicas existentes sobre el mismo problema en comn.
Dentro del desarrollo de los sistemas nos enocamos en tres dierentes modelos: el funcional, el de
objetos y el dinmico. Para el modelo uncional, el UML propone el diagrama de casos de uso, para
el de objetos propone el diagrama de clases, y para el dinamico se propone los modelos de secuencia,
actividad y de estados.

Actividad:
Ll libro de texto, en las paginas 144 a 150, describe ampliamente ambos modelos y hace uso de un caso
practico para su explicacin.
Lea y eale ambos modelos. Compare las entajas orecidas para cada caso. Analice si ambos modelos
siren para los mismos tipos de problema que se puedan presentar a la hora de desarrollar una solucin de
.oftrare.

66 66 66 66


23. Seleccione algn sistema con el que est amiliarizado y haga lo siguiente:
Deina el conjunto de dominios que deinan la isin global
del sistema.
Describa el conjunto de elementos que componen dos de los
dominios del sistema.
Para un elemento, identiique los componentes tcnicos
por desarrollar.
24. Seleccione algn sistema grande con el cual est amiliarizado, y establezca
suposiciones, simpliicaciones, limitaciones, restricciones y preerencias que se
deberan hacer para construir un modelado de sistemas eicaz.
25. La ingeniera de procesos del negocio requiere deinir datos, arquitectura de
aplicaciones, ademas de una infraestructura de aplicaciones. Describa cada
uno de estos trminos mediante un ejemplo.
26. Un ingeniero de sistemas puede recibir encargos de tres procedencias: el
desarrollo de sistemas, el cliente o una organizacin externa. Discuta los pros y
los contras de cada procedencia.
2. Describa al ingeniero de sistemas ideal`, considerando las lecturas, sobre la
ingeniera de sistemas, realizadas hasta ahora. Qu caractersticas seran las mas
propicias para que su labor nunca sea tropiezo para el desarrollo de un sistema en
particular.
28. Aerige sobre el UML. A parte de los ya mencionados, ,qu diagramas existen,
y para qu se utilizan

67 67 67 67
ngenieria de requisitos

.vv ctievte evtra a .v oficiva , aice: Yo .e qve v.tea iev.a qve evtievae to qve
aigo, ero to qve v.tea vo evtievae e. qve to qve aigo vo e. reatvevte to qve qviero
aecir.

8umario
Los temas que se tratan en este captulo son:
1areas de la ingeniera de requisitos
Inicio del proceso de la ingeniera de requisitos
Obtencin de requisitos
Desarrollo de casos de uso
Construccin del modelo de analisis
Negociacin y alidacin de requisitos
Capitulo

68 68 68 68

SUB1LMAS PGINAS
Un puente hacia el diseno y la construccin 156
1areas de la ingeniera de requisitos 15
Inicio del proceso de la ingeniera de requisitos 163
Obtencin de requisitos 166
Desarrollo de casos de uso 13
Construccin del modelo de analisis 19
Negociacin de requisitos 184
Validacin de requisitos 186

69 69 69 69

a ingeniera de requisitos ocupa un espacio ital dentro de todo el proceso de desarrollo de
.oftrare. Permite al ingeniero o grupo de ingenieros, mediante dierentes tcnicas de obtencin
de requerimientos, alcanzar la primera isin del cliente acerca del producto por construir.
Aunque casi ningn requerimiento es perpetuo en el tiempo, estos plantean un escenario bastante
complicado a los analistas y desarrolladores del producto, ya que estaran en un constante reproceso
entre las etapas que soportan el desarrollo de .oftrare.
Debido a este detalle, el desarrollo normal de los productos de .oftrare adopta la evolucin iterativa
como el modelo de desarrollo mas comn en la actualidad.
Lste captulo dara una perspectia mas clara de cmo se debe tratar el tema del leantamiento y
manejo de requisitos, dentro del proceso de desarrollo de sistemas. Con esto se trata de aclarar al lector
la importancia de que el equipo de desarrollo haga un erdadero esuerzo por entender los requisitos
del problema antes de intentar resolerlo.

70 70 70 70
Desarrollo

La ingeniera de requisitos representa el primer esuerzo real por tratar de alcanzar el sentimiento del
cliente, con respecto a la necesidad que se quiere cubrir.
Lsta disciplina proporciona a los ingenieros lo necesario para lograr entender qu es lo que realmente
quiere, analizar sus necesidades, evaluar la factibilidad de lo que pide, negociar una solucin
razonable, eliminar ambigedades, validar la especificacin y administrar los requerimientos
conorme cambian en el tiempo.
Ll proceso de la ingeniera de requisitos se compone de siete distintas unciones, a saber: inicio,
obtencin, elaboracin, negociacin, especificacin, validacin y gestin.

Inicio del proceso de la ingenieria de requisitos
Ls importante entender que la localizacin del cliente no necesariamente estara siempre al alcance del
encargado de obtener los requerimientos. La unidad didactica sugiere que el primer enoque por seguir
es el de entender la diversidad de localizaciones, opiniones y calidades de los clientes, que se
pueden dar al inicio de un proceso de leantamiento de requerimientos.
De esta situacin se obtienen algunos pasos requeridos para atender esta realidad y sacar el mayor
proecho, con la intencin de crear un proyecto exitoso.
Se debe recordar que el objetio principal es conseguir una visin global del problema que se intenta
atacar. Lsto se ira depurando a como se aanza en las distintas unciones de la ingeniera de requisitos.
Obsere:

vortavte:
Pasos requeridos para iniciar la ingenieria de requisitos:
Identificacin de los interesados: todos aquellos que se beneician de orma directa o
indirecta del sistema que esta en desarrollo.
Reconocimiento de mltiples puntos de vista: clientes dierentes, mltiples puntos de ista
sobre los requerimientos.
1rabajo con respecto a la colaboracin: clientes colaborando entre s. Buscar areas en
comn y areas en desacuerdo para tomar acciones.
Iormulacin de las primeras preguntas: deben ser de libre contexto, enocadas en el
cliente, metas generales y beneicio directo.

Actividad:

71 71 71 71
Ln las paginas 165 y 166 del libro de texto, encontrara algunas preguntas de libre contexto`, asociadas con
el tema del inicio para la ingeniera de requisitos.
Lea y estudie dichas preguntas. Analice si considera que estas preguntas son suicientes para
obtener la inormacin necesaria para continuar con el proceso de la ingeniera de requisitos.
Lxplique su respuesta en orma detallada.

Obtencin de requisitos
lasta aqu, se tiene la isin genrica del problema isto desde algunos metros de altura. Ahora se
proundizara en la obtencin de los requerimientos pero de una manera mas ormal.
Se han propuesto muchos enoques dierentes para la recopilacin conjunta de requisitos, la mayora
concuerdan con las siguientes directrices basicas:
Reunin dirigida por algn asistente, no debe quedar a la libre.
Lstablecer reglas para la preparacin y participacin.
Agenda ormal, pero con libertad para el lujo de ideas.
Siempre debe tener un moderador.
Predeinir mecanismos para aterrizar lo encontrado.
Obtener como meta la identiicacin del problema, la solucin propuesta y garantizar el
ambiente para que se cumpla.

Actividad:
Ln las paginas 16 y 10 del libro de texto se presenta un lujo de eentos mediante un ejemplo puntual
asociado a la lectura anterior de las directrices.
Lea y estudie el caso con el in de entender para qu existen dichas directrices y la importancia de que se
cumplan. Justiique sus ideas.

Ll despliegue de la funcin de calidad ,QlD por sus siglas en ingls, se maneja para cada una de
las etapas del proceso de ingeniera. Ln particular para la obtencin de requisitos, esta tcnica se
presenta con el objeto de traducir las necesidades del cliente en requisitos tcnicos del .oftrare.
Para lograrlo, el QlD resalta una comprensin de qu es alioso y lo acomoda en tres tipos de
requisitos:
vortavte:
1ipos de requisitos para la QID:
Normales: obligatorios para el cliente, responden a los objetios y metas.

72 72 72 72
Lsperados: estan implcitos en el producto o sistema. No se piden de manera explcita, tan
solo se esperan como obios.
Lstimulantes: caractersticas que an mas alla de lo esperado por el cliente.

Ln esta etapa de obtencin de requisitos, se obtiene como producto de trabajo en la mayora de
sistemas lo siguiente:
Un enunciado de necesidad y actibilidad.
Un enunciado limitado del ambito del sistema o producto.
Una lista de clientes, usuarios y otros interesados que participaron en la obtencin de
requisitos.
Una descripcin del ambiente tcnico del sistema.
Una lista de requisitos ordenados por uncin, y las restricciones de dominio aplicables para
cada uno.
Un conjunto de escenarios de uso para discernir la utilizacin del sistema en dierentes
condiciones de operacin.
Algn prototipo desarrollado que ejempliique mejor los requerimientos.

Desarrollo de casos de uso
Ln esencia, un caso de uso ,CU, cuenta una historia estilizada de la manera en que un usuario inal
interacta con el sistema en un conjunto especico de circunstancias`. La idea de este desarrollo es
mostrar siempre el sistema desde el punto de ista del usuario final.
Ll CU contiene actores, que son las dierentes personas ,o dispositios, que utilizan el sistema dentro
del contexto de la uncin y el comportamiento que se describira.

73 73 73 73

Iigura 02 Ljemplo de diagrama de CU para una biblioteca.
Ln los CU que se desarrollan estan claros los actores del uturo sistema. Una ez identiicados, se
puede llear a cabo una serie de preguntas que tienen que ser contestadas por el CU para darlo como
satisactorio.
,Quin,es, es ,son, el,los, actor,es, primario,s,
,Cuales son las metas de cada actor
,Cuales son las condiciones preias que deben existir antes de comenzar la historia
,Cuales son las tareas o unciones principales que realiza cada actor
,Cuales excepciones podran considerarse mientras se describe la historia
,Cuales son las ariaciones posibles en la interaccin de cada autor
,Cual es la inormacin del sistema que cada actor adquirira, producira o cambiara
,Cada actor tendra que inormar al sistema acerca de cambios en el ambiente externo
,Cual es la inormacin que cada actor desea del sistema
,Cada actor quiere ser inormado de cambios inesperados
Actividad:
Ln las paginas 15 y 18 del libro de texto, se presentan arios ejemplos de cmo documentar los CU.
Lea y estudie cada caso con el in de entender cmo se describen los CU, tanto de manera en prosa y cmo
mediante el uso de plantilla.

74 74 74 74
Ll modelo de anlisis es una representacin de los requisitos en un momento determinado, por lo
tanto es normal que algunos de stos se modiiquen en el siguiente momento de ealuacin.
Ll objetio del modelo es describir los dominios requeridos de inormacin, uncionamiento y
comportamiento para un sistema basado en computadoras. Ln el captulo siguiente se hablara
ampliamente sobre este tema.

Actividad:
Ln las paginas 19 a 184 del libro de texto se describe la construccin del modelo de analisis y sus
elementos. Lea y estudie el enoque dado desde la ingeniera de requerimientos.
Llabore un resumen, para que pueda compararlo con el enoque que encontrara en el siguiente captulo del
libro de texto.

Negociacin y validacin de requisitos
Ln su deseo por lograr todo lo que se propone, el ser humano necesita aterrizar sus ideas y deenderlas
a capa y espada ante los demas, siempre con el aan de quedar ganancioso en la toma de decisiones
acordada por todos los participantes.
Lsta etapa es la que se conoce como negociacin dentro del marco de ingeniera de requisitos, y
busca encontrar un balance de la uncionalidad, el rendimiento y otras caractersticas del producto
rente al costo y el tiempo de colocacin en el mercado.
Por otro lado, una ez alcanzados los acuerdos correspondientes a lo que se a a hacer y a lo que no se
a a hacer, se comienza la etapa de validacin de requerimientos. Ln esta etapa, se examina cada
elemento del modelo de analisis para conocer su consistencia, sus omisiones y sus ambigedades.
Ll cliente les otorga una jerarqua y se agrupan en paquetes que se implementaran como incrementos
de .oftrare.
Se tienen identiicadas preguntas para alidar que el modelo de requisitos es un relejo exacto de las
necesidades del cliente, y que se esta preparado para pasar a la etapa de diseno.

Actividad:
Ln la pagina 186 del libro de texto se enlistan algunas de las preguntas que alidan el modelo de requisitos.
Lea cada una de las preguntas. Analice las posibles respuestas y determine cuales otras deberan agregarse
para ortalecer la sensacin de entrega de un producto robusto como documento de requisitos.

75 75 75 75


29. ,Por qu arios desarrolladores de .oftrare no prestan mucha atencin a la
ingeniera de requisitos

30. ,Qu implica el anlisis de factibilidad` cuando se examina dentro del
contexto de la uncin inicio

31. A usted se le ha dado la responsabilidad de obtener requisitos de un cliente que
dice estar demasiado ocupado para reunirse con usted. ,Qu cosas debera hacer

32. Lxponga algunos de los problemas que pueden surgir cuando los requisitos
deben obtenerse de tres o cuatro personas dierentes.

33. ,Por qu se dice que el modelo de anlisis representa una oto instantanea de
un sistema en el tiempo

34. Desarrolle al menos tres preguntas de contexto libre` adicionales que pueda
hacerle a algn interesado durante la ase de inicio.

35. Desarrolle un CU ,utilizando la plantilla, para los siguientes problemas:
Busque libros para un tema especico en una librera en lnea
Pague el recibo telenico, desde el sericio que le presta su
entidad bancaria en lnea.

76 76 76 76
Modelado de analisis

.Por qve aebevo. cov.trvir voaeto.. Porqve vo cov.trvivo. et .i.teva , ,a.
a re.ve.ta e. qve oaevo. cov.trvir voaeto. ae tat forva qve re.attevo. o
evfaticevo. cierta. caracter.tica. crtica. aet .i.teva, at vi.vo tievo qve
qvitavo. evfa.i. a otro. a.ecto. aet .i.teva.
Ld Yourdon

8umario
Analisis de requisitos
Lnoques y conceptos del modelado del analisis
Analisis orientado a objetos
Modelado basado en escenarios, orientado al lujo y basado en clases
Creacin de un modelo de comportamiento
Capitulo

77 77 77 77

SUB1LMAS PGINAS
Analisis de requisitos 192
Lnoques del modelado del analisis 196
Conceptos del modelado del analisis 19
Analisis orientado a objetos 201
Modelado basado en escenarios 202
Modelado orientado al lujo 211
Modelado basado en clases 219
Creacin de un modelo de comportamiento 235

78 78 78 78

a ingeniera de sistemas persigue, mediante el modelado del analisis, encontrar dierentes as
que permitan a las partes inolucradas, obtener una isin tan clara como sea posible ,sin
importar cuantas dierentes istas se ocupen, de las dimensiones en tamano y alcance del
sistema que se desea construir. Lsto permite tambin determinar qu requerimientos deberan
ser atendidos.
Aspectos asociados a la inormacin contenida, a las unciones por realizar y al comportamiento de los
dierentes objetos que componen el sistema, deberan atenderse de manera integral, para garantizar con
esto que la solucin alcanzara con xito la utilizacin y consumo de parte del usuario inal.
Lste captulo describira y analizara dichos modelos, ademas, intentara dar una isin clara del orden de
actiidades y de los posibles insumos necesarios para llear a cabo un buen modelado del analisis, lo
suicientemente robusto como para soportar las etapas enideras y obtener un producto tangible,
como lo sera el sistema desarrollado ya puesto en produccin.

79 79 79 79
Desarrollo

Como se estudi en el captulo anterior, la ingeniera de requisitos produce un documento entregable,
que contiene todos los aspectos operacionales esperados en la creacin del nueo producto de .oftrare.
Con este documento se inicia el anlisis de requisitos, mediante el cual se indican las caractersticas
operacionales, restricciones y una posible interaz sugerida del .oftrare, con otros elementos del sistema.
Ll analisis de requisitos le proporciona al disenador una representacin de la inormacin, la uncin y
el comportamiento que lograra trasladar a disenos arquitectnicos, de interaz y en el niel de
componentes.
Ll modelo de anlisis junto a la especiicacin de requisitos, le permiten tambin tanto al cliente
como al desarrollador, saber cmo ealuar la calidad una ez construido el .oftrare.
Ll modelo de analisis busca cumplir tres grandes objetios:
Describir qu requiere el cliente.
Lstablecer una base para la creacin de un diseno de .oftrare.
Deinir un conjunto de requisitos que puedan alidarse una ez construido el producto.

Iigura 03 Modelo de anlisis como puente entre la descripcin del sistema y el modelo de diseo.
Lste modelo llena el aco entre la descripcin dada a nivel de sistema que detalla la uncionalidad
total del sistema y del diseo de software ,igura anterior,, que detalla la arquitectura de la aplicacin,
la interaz y la estructura a niel de componentes.
Algunas reglas practicas que sugiere el libro de Pressman para la creacin de un modelo de analisis, son
las siguientes:
vortavte:
Reglas para la creacin de un modelo de anlisis:
Debe centrarse en los requisitos isibles dentro del problema o dominio del negocio.

80 80 80 80
Cada elemento del modelo debe agregarse a un acuerdo general de los requisitos de .oftrare y
proporcionar una isin interna del dominio de inormacin, uncin y comportamiento del
sistema.
Debe retrasarse la consideracin de la inraestructura y otros modelos no uncionales hasta el
diseno.
Se debe minimizar el acoplamiento de todo el sistema.
Se debe tener la seguridad de que el modelo de analisis proporciona alor a todos los
interesados.
Ll modelo debe mantenerse tan simple como pueda ser posible.

Actividad:
Ln la pagina 195 del libro de texto, se encuentran detalladas las reglas descritas anteriormente.
Lalas y analcelas dentro del contexto del modelado del analisis. Indique si se podra ampliar la lista, de ser
airmatia su respuesta, hagalo.

Para el modelado de analisis hay dos enoques claramente deinidos: el enoque llamado anlisis
estructurado y el analisis orientado a objetos.
Ll anlisis estructurado busca que se reconozca la separacin entre los datos y su proceso de
transormacin. Lste enoque sugiere que el proceso que transorma los datos y los datos en s, deben
ser entidades separadas.
Por otro lado, el enoque orientado a objetos se centra en la creacin de clases y la colaboracin
existente entre ellas para obtener los requerimientos del cliente.
La pregunta es ,cual es mejor, bueno la respuesta no es sencilla, depende de la capacidad de la persona
para escoger, y de er qu combinacin de representaciones de ambos enfoques le permitira
alcanzar el mejor modelo de requisitos de .oftrare y la orma mas rapida de pasar al diseno.

Iigura 04 Llementos del modelo de anlisis.

81 81 81 81
Ll modelado de los datos es la primera actiidad que se llea a cabo en el modelado del analisis, para
llearlo a cabo se deinen todos los objetos de datos que se procesan dentro del sistema y las relaciones
entre estos. Se deiniran algunos conceptos dentro del modelado de datos.

vortavte:
Conceptos dentro del modelado de datos:
Objeto de datos: se deine como una representacin casi de cualquier inormacin
compuesta` que el .oftrare deba entender. Lsta inormacin compuesta se reiere a algo que tiene
muchas propiedades o atributos dierentes.
Atributos: deinen las propiedades de un objeto de datos, y toman una de tres caractersticas
dierentes.
1, Nombrar una ocurrencia del objeto.
2, Describir la ocurrencia.
3, lacer reerencia a otra ocurrencia en otra tabla.
Relaciones: son las conexiones de objetos entre s y se determinan entendiendo el papel de un
objeto con otro dentro del contexto de .oftrare que se a a construir.
Cardinalidad: el modelo de datos debe ser capaz de representar el nmero de ocurrencias de
los objetos en una relacin dada.
Modalidad: deine la obligatoriedad entre los objetos de que se presente una ocurrencia.

Actividad:
Ln las paginas 199 y 200 del libro de texto se encuentran mas detallados estos conceptos de modelado de
datos.
Lalos y analcelos dentro del contexto del modelado del analisis, esto le permitira ampliar su isin del tema.

Anlisis orientado a objetos
Ll anlisis orientado a objetos ,AOO, consiste en la deinicin de todas las clases, relaciones y
comportamientos asociados a las clases, que son releantes y que necesitan resolerse para obtener
solucin al problema planteado. Se deber ejecutar algunas tareas para lograr el AOO:
vortavte:
1areas para lograr el AOO:
Comunicar los requisitos basicos del usuario entre el cliente y el ingeniero de .oftrare.
Identiicar las clases con sus mtodos y atributos.
Deinir la jerarqua de estas clases.
Representar las relaciones de objeto a objeto.
Modelar el comportamiento del objeto.

82 82 82 82
1odos los pasos anteriores se ejecutan de manera iteratia hasta que el modelo est completo.

Modelado basado en escenarios
Para obtener la aprobacin del cliente es necesario presentarle una solucin que cubra todas las
carencias de inormacin y que la manera de interactuar y acceder a ellas sea lo mas sencillo posible.
Ll modelo basado en escenarios hace uso de los casos de uso y de los diagramas de actividad y
carril para lograr construir modelos signiicatios que permitan una solucin como la descrita
anteriormente.
1al y como se mencion en el captulo anterior de esta gua, la idea de un caso de uso es mostrar
siempre el sistema desde el punto de ista del usuario inal.
Las dos primeras tareas de la ingeniera de requisitos: inicio y obtencin, acilitan la inormacin
necesaria para comenzar a escribir los casos de uso. Lstos se inician realizando una serie de unciones o
actiidades que realiza un actor especico.

Actividad:
Ln las paginas 205 a 208 del libro de texto encontrara un caso de uso como ejemplo. Ll mismo se llea
desde la simple descripcin relatada, pasando por una representacin del mismo caso pero como enunciado
declaratio y luego lleandolo a modo de plantilla ormal. Al inal cierra con la igura 8.6, que describe un
caso de uso, pero de orma graica.
Lea estas representaciones de caso de uso, analcelas y establezca comparaciones para determinar cmo
explicara, con sus propias palabras, un caso de uso.

Los diagramas de actividad contribuyen al modelado de analisis al apoyar a los casos de uso
mediante una representacin graica del lujo de interaccin dentro de un escenario especico.
Lste diagrama, similar a los amosos diagramas de flujo de datos ,DID, en el analisis estructurado,
permite representar unciones, lujo de datos, rombos de decisin y lneas paralelas para determinar
actiidades paralelas.
Con esta dinamica es acil entender que el diagrama de actiidad proporciona oportunidades que no
tendramos solo con los casos de uso, como son las opciones de decisiones controladas.
Los diagramas de carril representan una ariante del diagrama de actiidad. Permite al modelador
representar el lujo de actiidades descritas por el caso de uso, y al mismo tiempo, indicar qu actor o
clase de analisis tiene la responsabilidad de la accin descrita, mediante un rectangulo de actiidad.

Actividad:

83 83 83 83
Contine la actiidad anterior. Ln las paginas 209 y 210 del libro de texto encontrara las iguras 8. y 8.8, con
ejemplos de un diagrama de actiidad y un diagrama de carril respectiamente. Los ejemplos corresponden
al sistema de seguridad Hogar seguro.
Lstudie estas iguras, con el in de entender de manera isual los conceptos sobre diagrama de actiidad y de
carril.

Modelado orientado al flujo
Ll modelo de lujo de datos, mejor conocido como DlD, se construye mediante lechas rotuladas que
representan a los objetos de datos, y mediante crculos que representan las transformaciones de
estos datos.
Lste modelado se presenta como un diagrama jerarquico, donde el primer niel, llamado nivel 0 o de
contexto, contiene la totalidad del sistema. A partir de ah, se inicia un proceso de reinamiento, que
se desgrana cada ez mas por cada niel que baje en la jerarqua, hasta encontrar el niel en que un
proceso representa una uncin nica. Lxisten algunas pautas para la creacin de un diagrama de lujo
de datos:

vortavte:
Pautas para la creacin de un DID:
1. Ll niel 0 del DlD debe representar al sistema como una sola burbuja.
2. La entrada y la salida primaria deben establecerse con cuidado.
3. La reinacin debe comenzar por el aislamiento de procesos, objeto de datos y
almacenamiento de datos candidatos a ser representados en el siguiente niel.
4. 1odas las lechas y burbujas se deben rotular con nombres signiicatios.
5. Se debe mantener la continuidad del lujo de inormacin al cambiar de niel a niel.
6. La reinacin de las burbujas debe hacerse una por una.

Ls importante indicar que la generacin de un DlD puede seguir un enoque sumamente simple para
su implementacin. Se puede lograr por medio de un analisis gramatical` de los sustantios y erbos
que se desprenden de las primeras reuniones en el leantamiento de requerimientos.
Los erbos encontrados en la narratia inicial seran los posibles procesos por plasmar en el DlD. Por
otro lado, los sustantios encontrados se eran como las entidades externas, objetos de datos o
control, o almacenamientos de datos existentes.
A pesar que en la mayora de las aplicaciones el modelo de datos del DlD son suicientes para obtener
la isin del sistema por construir, existen casos en donde no basta dicha postura, y se requiere,
ademas, un modelo de control del flujo.
Lste modelo de control del lujo se presenta principalmente en las aplicaciones que estan guiadas en
eentos y no por datos, y que producen inormacin de control en lugar de reportes de datos.

84 84 84 84
La especificacin de control ,LC,, por otro lado, representa el comportamiento del sistema en un
momento del tiempo dado. Contiene un diagrama de estado que no es mas que una representacin
secuencial del comportamiento del sistema.
Sumado a la LC, tenemos a la especificacin de procesos ,LP,, que se utiliza para describir todos los
procesos del modelo de lujo que aparecen en el niel inal de cada reinacin. Cada una de estas mini
especiicaciones` sire como gua para el uturo diseno de componentes de la aplicacin.

Actividad:
Cada una de las anteriores especiicaciones asociadas al DlD, se encuentra detallada en las paginas 215 a 218
del libro de texto. Para ello se utiliza el ejemplo sobre el sistema de seguridad Hogar seguro.
Lea y analice estas descripciones, con el in de entender mejor el entorno que acompana a los DlD.

Modelado basado en clases
Como se menciona en parraos anteriores, al realizar un analisis gramatical` de la narratia inicial, se
pueden obtener los sustantios y erbos que se desprenden del problema por resoler.
Los sustantios encontrados se eran como: entidades externas, cosas, sucesos o eventos, papeles
o roles, unidades organizacionales, sitios o estructuras, dentro del ambito del problema. Cada uno
de estos sustantios se era como una potencial clase y se le debe dar un tratamiento en este sentido.
Ll libro de texto sugiere seis caractersticas que debe llear una clase potencial, para ser considerada en
el modelo de analisis.

vortavte:
Caractersticas para una clase potencial y su inculacin al modelo de anlisis:
1. Informacin referida: inormacin de la clase, es ital para el uncionamiento del sistema.
2. Servicios requeridos: conjunto de operaciones que permiten cambios en los atributos de la
clase.
3. Atributos mltiples: deben ser arios los atributos que describan la clase. Una clase con solo
un atributo, posiblemente se ea mejor como atributo en otra tabla.
4. Atributos comunes: se dan para todos los casos y se utilizaran en todas las instancias de la
clase.
5. Operaciones comunes: se dan para todos los casos y se utilizaran en todas las instancias de la
clase.
6. Requisitos esenciales: las entidades externas se an a crear como clases en el modelo de
requisitos porque aparecen en el espacio del problema.

Ll incluir una clase en el modelo de requisitos, signiica que la misma cumple con todas o casi todas
estas caractersticas.

85 85 85 85
Los atributos a los que nos reerimos en estas caractersticas deseables son los que permiten deinir la
clase y depurar qu signiica en el contexto del espacio del problema.
Las operaciones son las acciones que deinen el comportamiento de un objeto. Lstas se diiden en
cuatro categoras de operaciones:
1. Las que manipulan datos
2. Las que realizan algn cmputo
3. Las que preguntan acerca del estado de un objeto
4. Las que lo monitorean para la ocurrencia de un objeto de control

Iigura 0S Ljemplo de una clase.
Ll modelo de clase-responsabililidad-colaborador, conocido como el CRC, permite de manera
simple identiicar y organizar las clases releantes para los requisitos encontrados.
Ln este modelo, las responsabilidades son los atributos y las operaciones releantes para la clase. Los
colaboradores son las clases que se requieren para que una clase reciba la inormacin necesaria para
completar una responsabilidad. Para este modelo, tenemos una extensin del concepto de clases
descrito anteriormente, que se diiden en las siguientes categoras:

vortavte:
Categoras de clases para el modelo CRC:
1. Clases entidad: llamadas tambin clases modelo de negocios. Se extraen de manera directa
del enunciado del problema.
2. Clases frontera: crean la interaz que el usuario e y con la cual interacta.
3. Clases controlador: manejan una unidad de trabajo` desde el inicio hasta el inal. Controlan
la interaccin y el mantenimiento entre los objetos.

Con respecto a las responsabilidades, el libro de texto sugiere cinco directrices para determinar la
responsabilidad de las clases, a saber:

86 86 86 86
vortavte:
Directrices para las responsabilidades de las clases en el modelo CRC:
1. La inteligencia del sistema se debe distribuir entre las clases para abordar, de mejor manera, las
necesidades de las clases.
2. Cada responsabilidad debe establecerse tan general como sea posible.
3. La inormacin y el comportamiento relacionado con ella deben estar dentro de la misma
clase.
4. La inormacin relatia a una cosa debe localizarse con una sola clase, no distribuirse entre
muchas de ellas.
5. Las responsabilidades deben compartirse entre clases relacionadas cuando esto es apropiado.

Para abordar el tema de las colaboraciones, se puede decir que las clases le hacen rente a sus
responsabilidades en una de dos ormas:
Una clase puede utilizar sus propias operaciones para manipular sus propios atributos.
Una clase puede colaborar con otras clases.
Las colaboraciones se producen cuando una clase no puede cumplir una responsabilidad por s sola, y
ocupa la interaccin con otra.

Actividad:
Ln las paginas 225 a 231 del libro de texto, se detalla el modelo CRC. Para hacerlo se hace uso del caso del
sistema de seguridad Hogar seguro.
Lea y analice estas descripciones, con el in de entender mejor el modelo y su alcance, en colaboracin con el
modelado de analisis.

Las clases de analisis tienden a estar relacionadas de alguna manera, con mayor o menor niel de
cohesin. Lstas relaciones, en UML ,|vifiea Moaetivg avgvage, por sus siglas en ingls, Lenguaje
Unificado de Modelado, son conocidas como asociaciones.
Lstas asociaciones se pueden detallar mas cuando se incluye el atributo de multiplicidad para deinir
la cantidad de posibles ocurrencias entre ellas.
Por otro lado, cuando una clase depende de alguna manera de otra, dandose una relacin estilo cliente-
seridor, se da una relacin de dependencia, tal y como lo maneja el UML.
1ambin es importante describir el concepto de categorizacin dentro del tema de las clases de analisis.
Los elementos de analisis ,CU, Casos de Uso, y clases de analisis, se clasiican y se empaquetan como
una agrupacin, llamada paquete de anlisis, a la que se le da un nombre representatio.
Creacin de un modelo de comportamiento

87 87 87 87
Ll modelo de comportamiento es un enoque dinamico. La razn de este modelo es indicar la orma
en que el .oftrare respondera a los eentos o estmulos externos. Ll siguiente cuadro resume los pasos
necesarios para obtener un modelo de comportamiento correcto:

vortavte:
Pasos para obtener un modelo de comportamiento dentro del modelado de analisis:
1. Laluar todos los CU para entender por completo la secuencia de interaccin dentro del
sistema. Lntender el eento que se presenta, mas que la misma inormacin transitada a tras del
CU.
2. Identiicar los eentos del punto 1 que conducen la secuencia de interaccin. Lntender la
orma en que estos eentos se relacionan con las clases especicas.
3. Crear una secuencia para cada CU. Lsto se realiza mediante un diagrama de secuencia que
indica cmo los eentos causan transiciones de objeto a objeto, como una uncin del tiempo.
4. Crear un diagrama de estado para todo el sistema. Lsto se llea a cabo mediante un diagrama
de estado que representa los estados actios para cada clase y los eentos o disparadores que
ocasionan cambios entre los estados actios.
5. Reisar el modelo de comportamiento para eriicar su exactitud y consistencia.

Actividad:
Ln las paginas 23 a 238 del libro de texto, se orece un diagrama de estado y otro de secuencia. Para hacerlo
se hace uso del caso del sistema de seguridad Hogar seguro.
Obsere y analice estos diagramas, con el in de entender la nuea dimensin del mismo escenario,
representado a tras de estos 2 nueos tipos de diagrama.

88 88 88 88


36. ,Ls posible comenzar al proceso de codiicacin inmediatamente despus de
haber creado el modelo de analisis Lxplique su respuesta y justiique los puntos
en contra.

3. Un analisis practico es aquel en el cual el modelo debe enocarse en los
requisitos que son isibles dentro de los dominios del negocio`. ,Cuales tipos de
requisitos no son isibles en estos dominios Proporcione ejemplos.

38. ,Cual es el propsito del analisis del dominio ,Cmo se relaciona con el
concepto de los patrones de requisitos

39. Ln unas cuantas lneas, describa las dierencias primordiales entre el analisis
estructurado y el analisis orientado a objetos.

40. Suponga que le solicitaron construir uno de los siguientes sistemas:
Un sistema simple de acturacin para un negocio pequeno.
Un sistema en lnea para la compra de boletos a una empresa de cine.
Un sistema de escogencia de citas en lnea, para el seguro social.

Dibuje un modelo a niel de contexto ,DlD de niel 0, para alguno de estos 3
sistemas.
Lscriba una narrativa del procesamiento para el sistema al niel de contexto.
Luego, dibuje los DlD a los nieles 1 y 2, creando un analisis gramatical` apoyados
en la narratia creada.
Rotule cada uno de los procesos y lujos de datos.

89 89 89 89
Referencias

Larman, C. ,2004,. UML y Patrones. Segunda edicin. Mxico D.l.: Prentice lall.

McConnell, S. ,1996,. Desarrollo y gestin de proyectos inormaticos. Segunda edicin. Mxico D.l.:
Prentice lall.

90 90 90 90
Glosario de trminos

UML: ,|vifiea Moaetivg avgvage, por sus siglas en ingls,. Lenguaje Unificado de Modelado es el
lenguaje de modelado de sistemas de .oftrare mas conocido y utilizado en la actualidad, esta
respaldado por el OMG ,Ob;ect Mavagevevt Crov,. Ls un lenguaje graico para isualizar,
especiicar, construir y documentar un sistema de .oftrare. UML orece un estandar para
describir un plano` del sistema ,modelo,, incluyendo aspectos conceptuales tales como
procesos de negocios y unciones del sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y componentes de .oftrare reutilizables.

91 91 91 91
Enlaces electrnicos relacionados con el tema

6 Pagina oicial UML http:,,www.uml.org,
6 1utorial UML http:,,www.clikear.com,manuales,uml,index.a
spx

92 92 92 92
Principios de diseo aplicado en la
ingenieria de software

a, ao. forva. ae cov.trvir vv ai.evo ae sotware: vva e. bacerto tav .ivte qve
obriavevte vo ba,a aeficievcia., , ta otra e. bacerto tav covticaao qve vo ba,a
aeficievcia. obria..
C. A. R. Hoare

Ob]etivos

Los documentos del modelo del analisis permiten conocer qu es necesario hacer para satisacer los
requerimientos deinidos por el cliente. Ll diseno iene a ser la representacin graica que amarra las
relaciones existentes entre el .oftrare y el bararare, las estructuras que soportaran la inormacin y los
datos y las interases entre componentes que expondran las opciones necesarias para que el usuario
inal realice su trabajo.
Cuando termine de estudiar este tema, usted estara en capacidad de:
Lntender los conceptos que acompanan el modelado del diseno para los sistemas de
inormacin, haciendo uso de los dierentes modelados que existen para este in.

Reconocer la necesidad de un diseno arquitectnico que lo soporte de manera robusta y
sostenible a partir del modelado de analisis y diseno.

Conocer y aplicar el concepto de componente y su aplicabilidad en el mundo del diseno
arquitectnico.
Tema

93 93 93 93
8umario


Capitulo 9 Ingenieria del diseo
Capitulo J0 Diseo arquitectnico
Capitulo JJ Diseo al nivel de componentes


94 94 94 94
ngenieria del diseo

.Pveae. v.ar vv borraaor ev ta tabta ae ai.evo o vv vartitto ev et .itio ae
cov.trvcciv.
Irank Lloyd Wright

8umario

Diseno dentro del contexto de la ingeniera del .oftrare
Proceso y calidad del diseno
Conceptos de diseno
Ll modelado del diseno
Diseno de .oftrare basado en patrones
Capitulo

95 95 95 95

SUB1LMAS PGINAS
Diseno dentro del contexto de la ingeniera del .oftrare 24
Proceso y calidad del diseno 249
Conceptos de diseno 252
Ll modelado del diseno 262
Diseno de .oftrare basado en patrones 269

96 96 96 96

n este captulo se determinaran las bases y los conceptos necesarios para alcanzar un diseo
robusto y basado en patrones que soporten su creacin de manera exitosa y repetible en el
tiempo.
Lsto solo se logra teniendo muy bien deinidas y aterrizadas las etapas que anteceden al diseno, como
lo son la ingeniera de requisitos y el modelo del analisis basado en el documento de requerimientos
resultante.
Lste captulo se centrara, tanto en los conceptos que permiten a los ejecutores de un proyecto de
.oftrare desarrollar productos exitosos a partir de la aplicacin de los undamentos relacionados con la
materia de diseno, como en las tecnicas del modelo por s mismo, que permite incorporar los
patrones de diseno para obtener productos mas completos.
Ademas, se procurara que el lector comprenda la transicin suridas por las clases deinidas en el
modelado del analisis, al pasar de un niel mas bajo de abstraccin al modelo de diseno, y con esto
llegar a presentar la isin del detalle para el cliente.

97 97 97 97
Desarrollo

Diseo dentro del contexto de la ingenieria del software
Ll diseno de .oftrare es, en deinitia, la ltima accin dentro de la ingeniera que corresponde a la
actiidad del modelado. Permite crear una plataorma para la construccin del cdigo y la
correspondiente etapa de pruebas.
Lxiste una relacin directa entre los elementos del modelo de analisis descritos en el captulo 8 y los
modelos de diseno para crear una especiicacin completa. Ln la siguiente igura, se acilita la relacin
mental entre los dierentes grupos de elementos del modelado de analisis, contra las dierentes etapas
del modelo de diseno de .oftrare.

Iigura 0J 1ransformacin del modelo de anlisis al de diseo.
La siguiente es la descripcin de los cuatro nieles dentro del modelado del diseno, descrito en la igura
anterior:

vortavte:
Cuatro niveles del modelado del diseo:
Diseo de datos/clase: transorma los modelos de analisis y clases en las clases de diseno y las estructuras
de datos que se requieren para la implementacin del .oftrare.
Diseo arquitectnico: deine la relacin entre los elementos estructurales mas importantes del .oftrare.
Diseo de interfaz: describe la orma en que el .oftrare se comunica con los sistemas que interactan con l
y con los seres humanos que lo utilizan.
Diseo a nivel de componentes: transorma los elementos estructurales de la arquitectura de .oftrare en
una descripcin procedimental de los componentes de este.

Proceso y calidad del diseo

98 98 98 98
Conorme se reina el modelado del diseno, se alcanza un niel de abstraccin mucho mas bajo que el
encontrado originalmente con la primera iteracin. Lste niel debe representar, muy de cerca, los
requisitos dados por la ingeniera de requisitos, ista en captulos anteriores. Algunas caractersticas que
siren como gua para la ealuacin de un buen proceso de diseno son:

vortavte:
Caracteristicas para la ealuacin de un buen proceso de diseno:
Debe implementar todos los requisitos explicitos contenidos en el modelo de anlisis, y debe ajustarse
a todos los requisitos implicitos que desea el cliente.
Debe ser una guia legible y comprensible para quienes generan cdigo, quienes realizan pruebas, y dan
soporte al .oftrare.
Debe proporcionar una imagen completa del .oftrare -dando direccin a los dominios de datos,
uncionales y de comportamiento- desde una perspectia de implementacin.

Para alcanzar estas metas de diseno, se debe trabajar sobre aspectos relacionados con el tema de
calidad. Ls necesario establecer algunas directrices que deben existir para establecer criterios tcnicos
y con esto poder ealuar la calidad de un diseno.

Actividad:
Lncontrara la explicacin acerca de las directrices mencionadas anteriormente en las paginas 249 y 250 del
libro de texto.
Lalas y analcelas con respecto a lo que usted esperara de un modelado de diseno.

Atributos de calidad
Los atributos de calidad que se presentan a continuacin, deben entenderse como aspectos del
producto inal que se esperara existieran en l y que son considerados desde el inicio del proceso de
diseno.

Claro esta que la proundidad de cada uno de estos atributos a a depender del tipo de .oftrare a
desarrollar. Por ejemplo, una entidad bancaria con transacciones por el web, esperara er el atributo de
confiabilidad, como uno de los atributos de calidad mas uertes en su pagina.

vortavte:
Atributos de calidad en el diseo:
Iuncionalidad: se estima al ealuar el conjunto de caractersticas y capacidades del programa, la generalidad
de las unciones que se entregan y la seguridad del sistema en su totalidad.
Iacilidad de uso: se alora al considerar los actores humanos, la esttica, consistencia y documentacin
general.
La confiabilidad: se aala al medir la recuencia y seeridad de las allas, la precisin de los resultados de la
salida, la media del momento de allas, la habilidad para recuperarse de las allas y la preisibilidad del
programa.

99 99 99 99
Ll desempeo: se mide con la elocidad de procesamiento, tiempos de respuesta, consumo de recursos,
rendimiento y eicacia.
La soportabilidad: combina la habilidad de extender el programa, la adaptabilidad y la sericiabilidad.
Ademas, la resistencia a pruebas, compatibilidad, conigurabilidad, acilidad con que puede instalarse, y la
acilidad para localizar problemas.

Conceptos de diseo
Como en toda disciplina, el dominio de los undamentos es lo que prooca la creacin de un producto
uerte y cimentado. Ln la ingeniera de .oftrare en general y en el diseno de .oftrare en particular, no se
da la excepcin, por lo que se debe iniciar con el esuerzo de entender los dierentes conceptos que
deben estar presentes en el diseno.

Lstos conceptos son los que permiten obtener modelos robustos en su composicin, y por lo tanto
permitiran hacer que un programa uncione y a la ez lo haga del modo correcto.

vortavte:
Conceptos de diseno:
Abstraccin: para eectos del diseno, el niel de abstraccin en una solucin se establece en trminos
generales con el lenguaje del entorno del problema y en grados de menor abstraccin, se proporciona una
descripcin mas detallada de la solucin. Ln la medida en que cambian los dierentes grados de abstraccin
se trabaja para crear abstracciones procedimentales y de datos.
Arquitectura: alude a la estructura general del software ,organizacin de componentes, y las ormas en
que la estructura proporciona una integridad conceptual para un sistema.
Patrones: describen una estructura de diseo que resuele un problema de diseo en particular,
dentro de un contexto especico y en medio de uerzas que pueden tener un impacto en la manera en que
se aplica y utiliza dicho patrn.
Modularidad: el .oftrare se diide en componentes con nombres independientes y que es posible abordar
de manera indiidual. Los patrones de arquitectura en el diseno materializan la modularidad.
Ocultacin de informacin: los mdulos deben especiicarse y disenarse de manera que la inormacin
que esta dentro del modulo sea inaccesible para otros mdulos que no necesiten de esa inormacin.
Independencia funcional: se consigue al desarrollar mdulos con una funcin determinante y una
aversin a la interaccin excesia con los demas mdulos.
Refinamiento: se presenta al refinar de manera sucesiva los nieles de detalle procedimentales. Una
jerarqua se desarrolla al descomponer el enunciado macro de una uncin paso a paso, hasta alcanzar el
niel de cdigo.
Refabricacin: tcnica de reorganizacin que simpliica el diseno ,o cdigo, de un componente sin
cambiar su uncin o comportamiento.
Clases de diseo: permiten reinar las clases de analisis al proporcionar detalles al diseno que admitan la
implementacin de las clases y prooca que se produzca un conjunto nueo de clases de diseno que
implementen una inraestructura de .oftrare para soportar la solucin del negocio. Se sugieren cinco tipos de
clases: de interfaz con el usuario, del dominio de negocios, de proceso, persistentes y de sistema.
Por otro lado, una clase de diseno bien conormada, debe tener presentes estas cuatro caractersticas: ser
completa y suficiente, primitivismo, cohesin alta y bajo acoplamiento.

100 100 100 100

Actividad:
Ln las paginas 252 y 261 del libro de texto se describen con mas detalle cada uno de estos conceptos. Lalos
y analcelos para una mejor comprensin de los undamentos del diseno.

Ll modelo de diseo
Para mostrar de una manera mas graica el tema del modelo de diseno, se a a ejempliicar mediante un
graico con dos dimensiones, sean: el proceso y la abstraccin.
Ll proceso indica la eolucin del modelo de diseno conorme se ejecutan las tareas de diseno.
La abstraccin representa el grado de detalle a medida que cada elemento del modelo de analisis se
transorma en su equialente de diseno y despus se reina de una manera iteratia.

Iigura 02 Dimensiones del modelo de anlisis.
Los elementos que integran el diseo de los datos, o la arquitectura de los datos, an a tener una
prounda inluencia sobre la arquitectura inal del .oftrare a desarrollar, desde su presentacin inicial que
es bastante abstracta ,dada por la ingeniera de requisitos,, hasta llegar de manera progresia a los
nieles mas bajos, donde se llegara a la implementacin especica de cada aspecto.
Ln el modelo de diseno tambin se encuentran los elementos del diseo arquitectnico, que dan
una isin global, a cierta altura, de lo que se a a desarrollar, tal como lo hara un plano para una casa
antes de construir.
Ademas, estan los elementos del diseo de interfaz, que determinan la manera en que se interacta
con la aplicacin, y la direccin y orma en que se llearan a cabo las acciones. Ln esta parte del diseno,
se indica cmo luye la inormacin hacia auera del sistema y como ste esta comunicado entre los
componentes deinidos como parte de la arquitectura.

101 101 101 101
Ll diseno a nivel de componentes orma parte de la columna ertebral de un buen diseno de .oftrare.
Para eectos del desarrollo de una solucin, el diseno a niel de componentes describe por completo
cada detalle interno de cada componente de .oftrare.
Lsta descripcin se logra con la deinicin de estructuras de datos ,mencionadas en parraos
anteriores, para todos los objetos de datos locales, con las reglas de negocio aplicadas mediante la
secuencia de pasos para aplicar la lgica correspondiente y con una interaz que permita el acceso a
todas las operaciones de los componentes.
Por ltimo, el diseo a nivel del despliegue permite conocer cmo se ubicaran la uncionalidad y los
subsistemas dentro del entorno computacional sico que soportaran al .oftrare.

Diseo de software basado en patrones
La tendencia en las ingenieras modernas es muy clara: identiicar patrones que den soluciones
medibles para resoler problemas. Para el diseno de .oftrare, esto se aplica a la pereccin.
Los patrones de diseno se pueden describir utilizando una plantilla, que contiene todos los aspectos
por considerar para que su uso sea proechoso. Un patrn de diseno puede considerar tambin un
conjunto de fuerzas de diseo, que son las que describen requisitos no uncionales asociados con el
.oftrare por crear y que a la ez permiten deinir las limitaciones que restringen la manera en que se
implementara el diseno.
Los patrones de diseno necesitan la etapa de modelado de analisis completada para poder utilizarse. Ll
analista obsera el entorno del problema y las limitantes encontradas en la realidad del proyecto y
eala si se puede o no aplicar algn patrn existente. Dicho patrn existente se puede aplicar para
alguno de los siguientes tipos de patrones: arquitectnicos, de diseo y de idiomas.
Ls importante mencionar la existencia del concepto: marcos de trabajo. Son una mini arquitectura
reutilizable` que orece un conjunto de comportamientos y de estructuras genricas que estan bien
identiicadas para una amilia de abstracciones de .oftrare en un dominio dado.
Ll marco de trabajo contiene una serie de puntos de conexin` dentro de un esqueleto`, que le
permiten adaptarse a un dominio de un problema especico. Ln trminos de orientacin a objetos, un
marco de trabajo es una coleccin de clases que cooperan.

102 102 102 102


41. ,Cmo se relacionan los conceptos de acoplamiento y portabilidad de .oftrare
Proporcione ejemplos claros.
42. ,Se debe implementar un diseo modular como .oftrare monoltico ,Cmo se
puede lograr esto ,Ll desempeo es la nica justiicacin para la
implementacin del .oftrare monoltico
43. Lxplique la relacin entre el concepto de ocultacin de inormacin como un
atributo de modularidad eectia y el concepto de independencia de mdulo.
44. Describa, con argumentos propios, la arquitectura de .oftrare.
45. ,Se disena un .oftrare cuando se escribe` un programa ,Qu es lo que hace que
el diseo de .oftrare sea dierente a la generacin de cdigo
46. ,Cmo se eala la calidad de un diseno de .oftrare

103 103 103 103
Diseo arquitectnico

a e.trvctvra ae vv .i.teva ae .oftrare roorciova ta ecotoga ev qve vace,
vaavra , vvere et caigo. |v babitaa biev ai.evaao ervite et eito ev ta
erotvciv ae toao. to. covovevte. ae vv .i.teva ae .oftrare. R. Pattis

8umario

Arquitectura de .oftrare
Diseno de datos
Lstilos y patrones arquitectnicos
Diseno arquitectnico
Laluacin de disenos arquitectnicos alternos
Correlacin lujo de datos en una arquitectura de .oftrare
Capitulo

104 104 104 104

SUB1LMAS PGINAS
Arquitectura de .oftrare 26
Diseno de datos 28
Lstilos y patrones arquitectnicos 280
Diseno arquitectnico 28
Laluacin de disenos arquitectnicos alternos 294
Correlacin lujo de datos en una arquitectura de .oftrare 29

105 105 105 105

l primer sistema separado por mdulos es un ejemplo de un sistema con arquitectura. La
separacin de las actiidades de dierente naturaleza dentro de un mismo sistema acilita el
entendimiento de cada una de sus partes y permite reconocer la importancia dentro del
analisis de diseno para determinar claramente los lmites entre ellos, como una buena practica.
Aspectos como un bajo acople y una alta cohesin entre los mdulos de un sistema otorgan una
independencia uncional de gran alor para los desarrollos de sistemas que se espera sean escalables y
robustos es su conormacin en el tiempo.
Un buen modelo de diseno en la arquitectura da soporte a los conceptos mencionados, y la acogida de
uno o arios patrones arquitectnicos le otorgan un grado alto de robustez, tanto en las capas de los
datos, como en su mismo modelo de diseno.
Ll objetio de este captulo es que el estudiante comprenda cual es el enoque sistematico que se le
debe dar como tratamiento al diseno arquitectnico y su importancia dentro de la ingeniera del .oftrare.

106 106 106 106
Desarrollo

Arquitectura del software
Si se isualiza un producto de .oftrare como un ediicio, se podra decir como analoga que su
arquitectura representa la manera en que los diersos componentes del mismo se integran para ormar
un todo cohesionado.
La arquitectura de .oftrare se puede deinir como la estructura o las estructuras del sistema que
permiten que un ingeniero del .oftrare realice las siguientes acciones:
1, Analizar la eectiidad del diseno para cumplir con los requisitos establecidos.
2, Considerar opciones arquitectnicas en una etapa en que an resulta relatiamente acil hacer
cambios en el diseno.
3, Reducir los riesgos asociados con la construccin del .oftrare.

vortavte:
La arquitectura de .oftrare es necesaria porque:
Sus representaciones permiten la comunicacin entre todas las partes interesadas en el
desarrollo de un sistema de cmputo.
Destaca las decisiones iniciales relacionadas con el diseno que tendra un impacto proundo en
todo el trabajo de la ingeniera de .oftrare que le sigue y en el xito inal del sistema como entidad
operacional.
Constituye un modelo relatiamente pequeno e intelectualmente comprensible de cmo esta
estructurado el sistema y cmo trabajan juntos sus componentes.

Diseo de datos
Se debe separar el diseno de datos en dos partes: el nivel arquitectnico y el nivel de componentes.
Ll diseo de datos, a nivel arquitectnico, aboga por un enoque de utilidad para la colaboracin
entre las dierentes bases de datos que contienen los datos operatios del negocio. Lsta inormacin es
ital para obtener entajas en dierentes lneas, tanto para analisis simple a niel operatio, como para
analisis para la toma de decisiones a niel ejecutio.
Para esta segunda lnea, se han desarrollado tcnicas como la mineria de datos, para extraer
conocimiento de la inormacin y lograr extraer patrones de comportamiento en los datos y
tendencias.
Ll diseo de datos a nivel de componentes se concentra en la representacin de estructuras de
datos a las que se tiene acceso en orma directa mediante uno o mas componentes de .oftrare.

107 107 107 107

Actividad:
Ln las paginas 29 - 280 del libro de texto se encuentra un conjunto de principios para la especiicacin de
datos. Lalo y analcelo con respecto al modelo de analisis, que es donde se origina realmente el diseno de
datos existente en cada componente.

Lstilos y patrones arquitectnicos
Ls preciso indicar que un estilo arquitectnico tambin se puede er como una plantilla. Un estilo
arquitectnico es una transormacin impuesta por el diseno de todo un sistema. Su objetio es
establecer una estructura para todos los componentes del sistema.
Un patrn arquitectnico tambin impone una transormacin en el diseno de la arquitectura, pero
ademas:
1, Su alcance es mejor porque se concentra en un aspecto en lugar de toda la arquitectura.
2, Impone una regla sobre la arquitectura.
3, 1iende a abarcar aspectos especicos del comportamiento dentro del contexto de la arquitectura.
Ls posible encontrar una bree taxonoma de estilos arquitectnicos a tras del tiempo.

vortavte:
Lstilos arquitectnicos:
Arquitectura centrada en datos: en el centro de la arquitectura radica un almacn de datos, para
el cual existen componentes de aplicaciones que tienen opcin de gestionar dicha inormacin.
Lste estilo promuee la capacidad de integracin.
Arquitectura de flujo de datos: se aplica cuando los datos de entrada deben transormarse en
datos de salida mediante una serie de componentes para el calculo o la manipulacin.
Arquitectura de llamada y retorno: permite a un arquitecto de sistema obtener una estructura de
programa que resulte acil de gestionar. Posee dos subestilos: arquitectura de programa
principal/subprograma y la de llamada de procedimiento remoto.
Arquitectura orientada a objetos: se crean componentes que encapsulan los datos y las
operaciones que deben aplicarse para manipularlos. Componentes coordinados mediante
mensajera entre los objetos.
Arquitectura estratificada: se presentan arias capas en donde cada una de ellas realiza
operaciones que se acercan, progresiamente, al conjunto de instrucciones de la maquina.

Por otro lado, los patrones arquitectnicos deinen un enoque especico para el manejo de algunas
caractersticas de comportamiento del sistema. Una de estas caractersticas puede ser la concurrencia,
que busca que la maquina simule paralelismo en la ejecucin de arias tareas a la ez. Las aplicaciones
tienen arias maneras de llear a cabo esta simulacin, y cada una de estas ormas tiene su patrn
arquitectnico correspondiente.

108 108 108 108
1ambin se puede citar la persistencia, que permite a un objeto instanciado ,creado a partir de una
clase, en un momento dado, depositar sus alores o atributos en un almacn de datos, que los uele
isibles y accesibles cuando se necesite acceder a ellos para alguna operacin.
Al terminar el proceso de diseno, el ingeniero de .oftrare tiene en sus manos arias opciones
arquitectnicas para decidirse con respecto a la que ungira como la oicial en un trabajo especico.
Lxisten algunas preguntas que acilitan el encontrar cual de las opciones deinidas es la mejor.

Actividad:
Ln la pagina 28 del libro de texto se encuentra un conjunto de preguntas que acilitan la escogencia del
modelo arquitectnico por seguir. Lalas y analcelas para entender de qu manera se acilita la
discriminacin y se obtiene la mejor opcin.

Diseo arquitectnico
Cuando se habla del diseno arquitectnico a ser asociado, debe ponerse en perspectia el sistema que
esta por construirse. Ln este diseno se debe considerar las entidades externas, tales como otros
sistemas o personas, y la naturaleza de la interaccin. Ambos elementos obtienen la inormacin de
la etapa de requerimientos.
Lste diseno arquitectnico de contexto que se menciona, permite entender cmo a a interactuar el
sistema con las entidades que lo limitan en todas las direcciones.
Los sistemas que interactan con el sistema destino se clasiican como: superordinados,
subordinados, al nivel de par y como actores.

Actividad:
Ln las paginas 288 - 289 del libro de texto se encuentra la descripcin de dichos tipos de sistemas. Lala y
analcela dentro del contexto del sistema destino.

Iigura 03 Diagrama de contexto arquitectnico.

109 109 109 109
Otro elemento que apoya la deinicin del diseno en la arquitectura es el arquetipo. Ls un patrn que
representa una abstraccin central importante en el diseno de la arquitectura para el sistema destino.
Los arquetipos orman la base de la arquitectura, pero no se puede dejar de lado que son
abstracciones que deben reinarse cada ez mas conorme se aanza con el diseno arquitectnico.
Ln este aance del diseno, tenemos que eligir cuales componentes deben mantenerse y en qu orma.
Lstos componentes de la arquitectura del .oftrare se derian de tres uentes: los dominios de la
aplicacin, la inraestructura y la interaz.
Lgicamente, en la creacin del modelo de analisis no se trabaj la parte arquitectnica, por lo que
debera poner mucha atencin en esta etapa para la deriacin y el reinamiento de los componentes de
dicha capa arquitectnica, apoyados en un diseno que es iteratio.

Lvaluacin de diseos arquitectnicos alternos

Un metodo de anlisis de compensacin para la arquitectura
Ll Instituto de Ingeniera de .oftrare ,SLI por sus siglas en ingls, desarroll un mtodo conocido por
sus siglas: MACA. Dicho mtodo busca deinir un proceso de ealuacin iteratio para las dierentes
arquitecturas de .oftrare. Se realizan las siguientes actiidades de analisis de diseno, tambin
iteratiamente.

vortavte:
Actiidades de analisis de diseno que se presentan iteratiamente.
1. Recopilar escenarios: se desarrolla un conjunto de casos de uso, para presentar el sistema
desde el punto de ista del usuario.
2. Deducir requisitos, restricciones y descripcin de entornos: es un proceso asociado a la
ingeniera de requisitos y busca asegurar que se atiendan las preocupaciones descubiertas en el
proceso.
3. Describir los estilos/patrones arquitectnicos elegidos: se basa en los puntos 1 y 2.
4. Lvaluar cada atributo de calidad de manera aislada: ejemplos son coniabilidad,
desempeno, seguridad, entre otros.
5. Identificar la sensibilidad de cada atributo: el cambio en un atributo que aecte
signiicatiamente la arquitectura es un punto de sensibilidad para la misma.
6. Analizar las arquitecturas alternas basadas en la sensibilidad de cada atributo: este
proceso se basa en el paso 5.

La posible eliminacin de las arquitecturas presentadas o la modiicacin de las aceptadas se deben
basar, principalmente, en los puntos 5 y 6, para luego oler a aplicar el MACA.

Complejidad arquitectnica
Lsta tcnica consiste en considerar las dependencias entre los componentes dentro de la arquitectura,
las cuales estan orientadas por la inormacin, el lujo de control, o ambas, dentro del mismo sistema.
Lstas dependencias se agrupan en tres partes: las compartidas, que se dan entre consumidores que

110 110 110 110
usan el mismo recurso o productores que producen para los mismos consumidores, las de flujo, que
representan las relaciones de dependencia entre productores y consumidores de recursos y las
restringidas, que representan restricciones de lujo relatio de control entre un conjunto de
actiidades.
Lstas dependencias guardan similitud en concepto, con el acoplamiento mencionado en captulos
anteriores.

Actividad:
Ln la pagina 298 del libro de texto se encuentra la descripcin de otro mtodo de ealuacin de arquitectura.
Lalo y analcelo dentro del contexto de los anteriores mtodos descritos en este documento.

Correlacin del flujo de datos en una arquitectura de software
Debido a que hasta el momento todas las arquitecturas presentadas son dierentes entre s, es acil
deducir que la correlacin que se esperara realizar y que logre la transicin del modelo de analisis a
diersos estilos arquitectnicos, sea compleja y dicil.
Lxiste una tcnica de correlacin arquitectnica con el nombre de: llamada y retorno, que permite a
un disenador deriar arquitecturas de llamada y retorno algo complejas a partir de DlD dentro del
modelo de analisis.

Ilujo de transformacin
Dentro de un lujo de datos normal tenemos un ingreso de datos que llamaremos flujo de entrada,
una accin con estos datos que llamaremos centro de transformacin y, un conjunto de datos
alterados de manera indicada y deinida, que llamaremos flujo de salida. Ll lujo general de los datos
ocurre de manera secuencial y escoge algunas de las posibles rutas del lujo. A todo este proceso se le
conoce con el nombre de flujo de transformacin.

Ilujo de transaccin
Una transaccin se puede er como la esencia de un lujo de inormacin. Lsta transaccin tiene la
capacidad de disparar otro nueo lujo de datos por una de arias rutas. A este comportamiento se le
llama flujo de transaccin, porque se conierte la inormacin del mundo exterior y se crea la
transaccin.
Ln el lujo se presenta un elemento que es el que dispara la accin y la encarrila a alguno de los lujos
existentes ,rutas de accin,. Lste elemento se conoce como el centro de transaccin.

111 111 111 111

Iigura 04 Ilujo de transaccin.

Correlacin de transformaciones
Lsta correlacin esta conormada por un conjunto de pasos de diseno que permiten que un DlD, con
caractersticas de lujo de de transormacin, se correlacione con un estilo arquitectnico especico.
Con el in de relacionar los DlD dentro de una arquitectura, se llean a cabo los siguientes pasos de
diseno:

vortavte:
Pasos de diseno para relacionar los DlD dentro de una arquitectura:
1. Revisar el modelo fundamental del sistema: diagrama de contexto para un analisis con
orientacin a DlD.
2. Revisar y refinar los DID para el software: pasar del niel de contexto a los siguientes
nieles, hasta encontrar un niel de cohesin tan alto que incite a la creacin de un componente.
3. Determinar si el DID tiene caracteristicas de flujo de transaccin o de transformacin:
se seleccionan las caractersticas globales del lujo de todo el .oftrare, con base en la naturaleza del
DlD, para determinar qu tipo de lujo es.
4. Aislar el centro de transformacin al especificar limites de flujo de entrada y salida: se
deben resaltar en este paso solo los lmites razonables para el centro de transormacin segn
considere el analista.
5. Realizar una factorizacin de primer nivel: al encontrar un lujo de transormacin, se
correlaciona un DlD con una arquitectura de llamada y retorno` que proporciona control para el
procesamiento de la inormacin de entrada, transormacin y salida.
6. Realizar una factorizacin de segundo nivel: se obtiene al correlacionar las
transormaciones indiiduales ,burbujas, de un DlD con los mdulos apropiados dentro de la
arquitectura.

112 112 112 112
. Refinar la arquitectura de primera iteracin empleando diseo heuristico para mejorar
la calidad del software: los componentes se expanden y contraen para producir una actorizacin
sensible ,buena cohesin, acoplamiento mnimo y una estructura sin problemas,.

Actividad:
Ln las paginas 299 - 305 del libro de texto se encuentran descritos de manera mas amplia, los pasos del
diseno que permiten relacionar los DlD con una arquitectura y la correlacin de transormaciones. Lalos y
analcelos detenidamente, buscando entender de manera detallada este tema de tanta releancia para el curso
al cual asiste.

Correlacin de transacciones
Ahora se daran los pasos dentro del diseno para correlacionar el lujo de transaccin con una
arquitectura de .oftrare. Ls importante indicar que tanto los tres primeros pasos como el ltimo son
idnticos a los de las correlaciones en las transormaciones explicadas anteriormente.

vortavte:
Pasos de diseno para relacionar los DlD dentro de una arquitectura:
1. Revisar el modelo fundamental del sistema.
2. Revisar y refinar los DID para el software.
3. Determinar si el DID tiene caracteristicas de flujo de transaccin o de transformacin.
4. Identificar el centro de transaccin y las caracteristicas de flujo de cada una de las rutas
de accin: la ubicacin del centro de transaccin se desprende directamente del DlD. Lste se
encuentra en el origen de arias rutas de accin que luyen de l de manera radial.
5. Correlacionar el DID con una estructura de programa sensible al procesamiento de la
transaccin: cada camino del lujo de accin del DlD se correlaciona con una estructura que
corresponde a sus caractersticas de lujo especicas.
6. Iactorizar y refinar la estructura de transaccin y la de cada camino de accin: cada
camino de accin del DlD tiene sus propias caractersticas de lujos de inormacin.
. Refinar la arquitectura de primera iteracin empleando diseo heuristico para mejorar
la calida del software.

Actividad:
Ln las paginas 30 - 310 del libro de texto se encuentra descrita, de manera mas amplia, los pasos del diseno
que permiten relacionar los DlD con una arquitectura y la correlacin de transacciones. Lalos y analcelos
detenidamente, buscando entender este tema de tanta releancia para el curso al cual asiste. Lale cada
aspecto mencionado y contrastelo con lo deinido en la correlacin de transormaciones.

113 113 113 113


4. Lmpleando la arquitectura de una casa como metaora, realice comparaciones
con la arquitectura del .oftrare. ,Ln qu son similares las disciplinas de la
arquitectura clasica y la del .oftrare ,Ln qu se dierencian
48. ,Lxplicar la dierencia entre una base de datos que sire a una o mas aplicaciones
de negocios conencionales y un almacn de datos
49. ,Que signiican los trminos: estilo arquitectnico, patrn arquitectnico y marco
conceptual Buscar en Internet y describir la dierencia entre cada uno de estos
trminos y sus contrapartes.
50. Lmpleando un DlD, y una descripcin del procesamiento, describir un sistema
de cmputo que tenga distintas caractersticas de lujo de transormacin. Deina
los lmites de lujo y correlacionar el DlD con la arquitectura del .oftrare
empleando la tcnica de correlacin de transormaciones`.

114 114 114 114
Diseo al nivel de componentes
vrariabtevevte .e ae.cvbre qve vv .i.teva covte;o qve fvvciovaba ba
erotvciovaao a artir ae vv .i.teva .ivte qve tavbiev fvvciovaba.
John Gall

8umario
,Componente ,Qu es
Diseno de componentes basado en clases
Conduccin del diseno al niel de componentes
Diseno de componentes conencionales
Capitulo

115 115 115 115

SUB1LMAS PGINAS
,Qu es un componente 316
Diseno de componentes basado en clases 322
Conduccin del diseno al niel de componentes 331
Diseno de componentes conencionales 340

1 11 116 16 16 16

a existencia de conceptos como componentizacin tiene su origen en la idea de reutilizar las
cosas, tal y como se realiza en las dierentes actiidades del diario iir. Ll desarrollo de .oftrare
no es la excepcin, mas aun cuando su propia naturaleza acilita este tipo de implementacin,
al ser tan acil su multiplicacin o reproduccin.
Ll concepto de componente se puede deinir como un proeedor de sericios al cual se le cargan
algunos insumos ,alores de entrada, y deuele algn resultado de alor para el proceso que se llea a
cabo.
Lo que ocurri adentro de l se debe entender como un proceso de caja negra, donde su
implementacin debe ser ignorada por el cliente a niel de .oftrare, y tan solo debe retomar lo deuelto
por el sericio utilizado.
Lamentablemente no es tan acil trasladar el tema de los componentes a la realidad, pues as como
tiene grandes entajas cuando es bien aplicado, tambin tiene grandes complicaciones asociadas
cuando no se respetaron sus undamentos, mismas que se aclararan en este captulo.

117 117 117 117
Desarrollo

,Componente? ,Que es?
Pensar en qu es un componente en un ambiente de desarrollo de .oftrare es como pensar en la
separacin de aposentos existente para el proceso de construccin, que se da cuando se esta
construyendo una casa a niel modular.
Cada uno de estos mdulos representa un componente de la casa, y la suma de estos representa la casa
en su totalidad, con sus respectios mecanismos de comunicacin y accesos entre sus aposentos. Lsta
es una isin un poco generalizada que se tiene de la palabra componente en el ambiente de desarrollo
de .oftrare.
La deinicin de componente` en el ambiente de ingeniera de .oftrare es un bloque de
construccin modular, desplegable y reemplazable de un sistema que encapsula
implementacin y expone un conjunto de interfaces`. Por otro lado, el signiicado que asume
algunas eces en el mundo inormatico depende del contexto en que se mencione y de quin lo
mencione.
Por ejemplo, lo podemos escuchar relacionado con: orientacin a objetos, bajo el concepto
convencional o relacionado con el proceso. Se a a describir rapidamente cada una de estas ormas
con que se relaciona.
Considere el signiicado de clase` dentro del mundo orientado a objetos, desde este concepto, un
componente es un contenedor de un conjunto de clases que colaboran entre si. Cada clase debe
contener los atributos y los mtodos que le permiten llear a cabo su implementacin.
1ambin se tiene la interaz entre las clases, que mediante mensajera entre ellas, logra la comunicacin
deseada y que ue deinida en la etapa de analisis y en la de diseno.

118 118 118 118

Iigura 0S Llaboracin de un componente de diseo.
Otro enoque que encontramos es el convencional, el cual busca deinir un componente como un
elemento funcional (mdulo) que incorpora la lgica de procesamiento, las estructuras
internas de los datos necesarios para implementar dicha lgica, y una interfaz que permita la
inocacin de dicho componente y el paso de datos.
Cada modulo reside dentro de la arquitectura y representa uno de tres papeles: como componente de
control, como componente de dominio o, como componente de infraestructura. Al igual que el
concepto orientado a objetos, este enoque deria del modelo de analisis.
Por ltimo, se tiene el enoque relacionado con el proceso, dentro del cual se parte de la existencia
de una biblioteca de componentes, misma que se encuentran debidamente descrita y documentada
para que los ingenieros de un proyecto conozcan qu unciones realizan y cuales, de calzar en sus
necesidades, pueden utilizar para consumirlas e ir poblando la arquitectura del proyecto, logrando con
esto ahorro de tiempo en desarrollo para uncionalidades ya encapsuladas.

119 119 119 119
Diseo de componentes basados en clases
\a se ha mencionado que el concepto de componente esta directamente relacionado con el tema de las
clases, las cuales tienen su nacimiento en la etapa de analisis descrita en captulos anteriores.
La lgica encapsulada en ellas ,operaciones,, los atributos que las describen, y las interaces que
permiten que se maniiesten son los elementos que permiten pensar en el inicio de la etapa de
construccin.
Lxiste una serie de principios en el mundo de diseno de componentes que es importante describir aca,
con el in de conormar disenos cada ez mas sensibles al cambio y por ende con mayor adaptabilidad.

vortavte:
Principios para el diseo de componentes:
1. Abierto cerrado: el componente de un modulo debe estar abierto para extensin dentro del
dominio uncional que atiende, pero cerrado para modiicacin a niel de cdigo o lgica.
2. Sustitucin por Liskov: cualquier clase deriada de una clase principal se debe apegar a
cualquier contrato implcito entre la clase principal y los componentes que la usan.
3. Inversin de la independencia: depende de las abstracciones, no de las concreciones. Las
abstracciones son el lugar donde un diseno se puede extender sin grandes complicaciones.
4. Segregacin de la interfaz: es mejor tener muchas interaces especicas del cliente que una
de propsito general. Se debe tener una interaz especializada para serir a cada categora
importante para el cliente.
5. Lquivalencia entre reutilizacin y versin: la esencia de la reutilizacin es la misma que la
de la ersin. Se deben agrupar las clases reutilizables en paquetes que pueden manejarse y
controlarse a medida que eolucionan nueas ersiones.
6. Principio de cierre comn: las clases que cambian juntas deben permanecer juntas. Cuando
las clases se empaquetan como parte de un diseno, deben atender la misma area de unciones o
comportamientos.
. Reutilizacin: las clases que no se reutilizan juntas no deben agruparse juntas. Lsto es porque
innecesariamente se tendra que estar actualizando otros paquetes, solo para que cierta
uncionalidad sea la que sira.

Actividad:
Ln las paginas 322 - 325 del libro de texto se encuentra el conjunto de principios descritos anteriormente,
de manera mas detallada. Lea y analice estos principios para reorzar sus conocimientos sobre el tema.

1enemos por aparte un grupo de tres lineamientos que apoyan al diseno y que tambin son
importantes de mencionar, tal y como lo haremos a continuacin.

120 120 120 120
Los componentes deben traer consigo desde su creacin en el modelo arquitectnico, una
convencin de asignacin de nombres que se a a reinar hasta llegar al modelo de diseno, al niel
de componentes.
Las interfaces deben seguir estos lineamientos:
Cuando los diagramas se uelan mas complejos se debe usar la representacin de lneas y crculo
para la interaz, en lugar del enoque mas ormal del recuadro UML y la echa con lnea de
guiones.
Por razones de consistencia, las interaces deben luir desde la izquierda del recuadro del
componente.
Solo deben mostrarse las interaces releantes del componente en cuestin.

Las dependencias deben modelarse de izquierda a derecha y las herencias de abajo hacia arriba, para
mejorar su legibilidad.
Se tiene tambin un par de caractersticas de alta importancia en el mundo de los componentes, tal
como lo son la alta cohesin y el bajo acoplamiento. \a en el captulo 8 se mencion un poco, mas
es importante retomarlo con uerza, en esta descripcin ampliada y detallada de los componentes.
La cohesin se deine, en el contexto de los componentes, como la relacin orzada esperada para los
atributos y operaciones existentes en la o las clases asociadas al componente gracias a su misma
naturaleza, por lo que ueron agrupadas.
Dentro de esta caracterstica, se encuentran tambin dierentes nieles de intensidad, tales como los
siguientes:
uncional
de capa
de comunicacin
secuencial
procedimental
temporal
de utilidad

Actividad:
Ln las paginas 32 - 328 del libro de texto, se encuentra el detalle de los nieles descritos anteriormente.
Lalos y analcelos para reorzar sus conocimientos. Llabore un esquema que muestre las relaciones entre
estos nieles.
Ll acoplamiento es una medida cualitatia del grado en que las clases necesitan conectarse entre s.
1ambin permite isualizar, mediante la mensajera, que sea posible disparar acciones necesarias de
alguna de las clases inolucradas. Por otro lado, se ha dicho tambin que cuanto ms bajo sea el niel
de acoplamiento, mejor sera para el desarrollo de cada componente por separado, y para el sistema en
general.
1ambin se encuentran dierentes nieles de acoplamiento de clases, agrupado de la siguiente manera:
como acoplamiento del contenido, como acoplamiento comn, como acoplamiento de estampa,
como acoplamiento de datos, como acoplamiento de llamada y rutina, como acoplamiento de uso
de tipo, como acoplamiento de inclusin o importacin y como acoplamiento externo.

121 121 121 121
Actividad:
Ln las paginas 329 - 330 del libro de texto, se encuentra estos nieles de acoplamiento descritos
anteriormente, pero mas detallados. Lea y analice esta inormacin. Deina cada niel con sus propias
palabras.

Ls importante anotar que aunque la comunicacin entre los componentes es importante, debe
reducirse al maximo, logrando con esto la mayor cantidad de independencia posible entre ellos y traer
con esto acilidades en aspectos tales como el mantenimiento.

Conduccin del diseo al nivel de componentes
Ls responsabilidad del disenador basarse tanto en el analisis como en los modelos arquitectnicos para
transormarlos en una representacin de diseno que proporcione detalles suicientes para iniciar la
etapa de construccin.
Se ha deinido un conjunto de tareas basicas para el diseno al niel de componentes, que detallamos a
continuacin.

vortavte:
Conjunto de tareas bsicas para el diseo al niel de componentes:
1. Identiicar todas las clases de diseno que correspondan al dominio del problema.
2. Identiicar todas las clases de diseno que corresponden al dominio de la inraestructura.
3. Llaborar todas las clases de diseno que no se adquieran como componentes reutilizables.
a. Lspeciicar los detalles del mensaje cuando las clases o los componentes colaboran.
b. Identiicar las interaces apropiadas para cada componente.
c. Llaborar atributos y deinir los tipos y las estructuras de datos necesarios para
implementarlos.
d. Describir de manera detallada el lujo de procesamiento dentro de cada operacin.
4. Describir uentes de datos persistentes ,bases de datos y archios, e identiicar las clases
necesarias para manejarlas.
5. Desarrollar y elaborar representaciones del comportamiento de una clase o un componente.
6. Llaborar diagramas de despliegue para proporcionar detalles de la implementacin adicional.
. lactorizar todas las representaciones del diseno a niel de componentes y siempre deben
considerarse alternatias.

Actividad:
Ln las paginas 331 - 33 del libro de texto se detallan las tareas tpicas del diseno al niel de componentes.
1ambin se usa un ejemplo dentro del libro, con la explicacin respectia en cada punto descrito. Lea esta
inormacin y proponga un nueo ejemplo.

122 122 122 122

Diseo de componentes convencionales
A inicios de los anos sesenta, un grupo de cienticos de la computacin iniciaron con lo que hoy se
conoce como los fundamentos del diseo a niel de componentes, para componentes tradicionales.
Propusieron un conjunto de construcciones lgicas restringidas, a partir de las cuales se pudiera crear
cualquier programa. Dentro de estas construcciones encontramos la secuencia ,pasos secuenciales,, la
condicin ,eentos lgicos, y la repeticin ,bucles,.
Se ha comprobado, tal y como se era en captulos posteriores asociados a las mtricas de .oftrare, que
las construcciones estructuradas reducen la complejidad del programa y, por lo tanto, mejoran la
lectura, la prueba y el mantenimiento de la misma.
Lsta orma de trabajo esta basada en el concepto de Psicologa llamado fragmentacin, proceso de
construccin humana que trabaja por patrones o agrupamientos, y acilita mas su comprensin que si
analizaramos cada parte por separado.
Por otro lado, para este conjunto de construcciones lgicas tambin tenemos su correspondiente
notacin grfica ,igura 06,. Consiste en elementos de un flujo de datos que describen isualmente
cada una de las construcciones deinidas.
1enemos un objeto diamante ,si-entonces-si_no, para representar una condicin lgica. Las lechas
salientes y entrantes de este diamante muestran el flujo de control. Las cajas de procesamiento
conectadas por una lnea representan la secuencia.
La construccin de repeticin ejecuta primero una parte de hacer mientras, prueba una condicin y
ejecuta una tarea del bucle de manera repetitia, siempre y cuando la condicin siga siendo erdadera.
Una parte repetir hasta ejecuta primero la tarea de bucle, luego prueba una condicin y repite la tarea
hasta que la condicin alla.

Iigura 06 Diagrama de flujo de construcciones.
Ls importante tener presente que el uso exclusio de las construcciones estructuradas puede llegar a
introducir ineiciencia cuando se requiere un escape de un conjunto de bucles anidados o de
condiciones anidadas.

123 123 123 123
Las construcciones de programacin estructurada deben acilitar la comprensin del diseno. Si el
hecho de respetarlas por completo introduce una complejidad innecesaria, es permitido iolarlas en
beneicio del buen diseno.

Actividad:
Ln las pagina 342 - 343 del libro de texto se describe otro tipo de notacin asociada con el diseno de
componentes, la notacin tabular del diseno, que utiliza una tabla de decisin. Lea esta inormacin y
comparela con la descrita anteriormente. ,Qu tienen en comn, ,en qu se dierencian, ,puede una
suplantar completamente a la otra, ,en qu casos debe usarse cada una de ellas

Ademas de las dos notaciones mencionadas anteriormente, tenemos tambin lo que se denomina
como lenguaje de diseo de programas ,PDL por sus siglas en ingls,, mas conocido como
seudocdigo. Lste es un lenguaje rudimentario porque utiliza el ocabulario de un idioma ,ingls, y la
sintaxis general de otro ,un lenguaje estructurado de programacin,. Ls claro que el enoque que se le
quiere dar es de diseno, para no enredarse con un enoque orientado a la codiicacin directamente.
Ll PDL no es un lenguaje de programacin, el encargado de diseno puede adaptarlo como quiera sin
pensar en problemas o errores de sintaxis.
Se dice en trminos generales, que el PDL es, en el ambiente de notacin de diseno, el que mejor se
ajusta o el que orece la mejor combinacin de caractersticas. Ll PDL puede incrustarse directamente
en los listados de cdigo uente ,existe .oftrare para interpretar y extraer el cdigo del seudocdigo,,
mejorando la documentacin y acilitando mas el mantenimiento del diseno.
Ls claro tambin que es una opinin y que puede no ser tan cierta para algunos encargados de diseno,
pues la eleccin de una herramienta de diseno estara en uncin de manera mas estrecha, con actores
humanos que con los atributos tcnicos.

124 124 124 124


51. ,Considerara que los patrones son una orma eectia de reutilizar en el diseno a
niel de componentes, ,por qu, ,cuales son las desentajas de este enoque
52. Lnliste, segn su criterio, las entajas y las desentajas que se presentan en la
reutilizacin de componentes.
53. Describa el paradigma orientado a objetos mediante sus propios argumentos.
54. Lxplique: ,por qu no siempre los ahorros que se presentan en la reutilizacin
del .oftrare a partir de componentes, no son proporcionales al tamano de los
componentes que la reutilizan
55. ,Por qu es importante crear abstracciones que siran como interaz entre
componentes

125 125 125 125
Referencias

Bruegge, B., Dutoit, A. ,2002,. Ingeniera de oftrare Orientado a Objetos. Mxico D.l.: Prentice lall.

Larman, C. ,2004,. UML y Patrones. Segunda edicin. Madrid: Prentice lall.

Sommerille, I. ,2002,. Ingeniera de oftrare. Sexta edicin. Mxico D.l.: Addison \esley.

126 126 126 126
Glosario de analisis de software

DID: un diagrama de lujo de datos ,DlD por sus siglas en espanol e ingls, es una representacin
graica del lujo` de datos a tras de un sistema de inormacin. Un diagrama de lujo de
datos tambin se puede utilizar para la isualizacin de procesamiento de datos ,diseno
estructurado,. Ls una practica comn para un disenador dibujar un contexto a niel de DlD
que primero muestra la interaccin entre el sistema y las entidades externas. Lste contexto a
niel de DlD se explot` para mostrar mas detalles del sistema que se esta modelando.

SLI: el oftrare vgiveerivg v.titvte es un instituto ederal estadounidense de inestigacin y desarrollo,
undado por el Congreso de los Lstados Unidos en 1984. Ll objetio de este instituto es
desarrollar modelos de ealuacin y de mejora en el desarrollo de .oftrare que dieran respuesta
a los problemas que generaba al ejrcito estadounidense la programacin e integracin de los
sub-sistemas de .oftrare en la construccin de complejos sistemas militares. Lsta institucin es
inanciada por el Departamento de Deensa de los Lstados Unidos y administrada por la
Uniersidad Carnegie Mellon. Ls un reerente en Ingeniera de .oftrare debido al desarrollo del
modelo S\-CMM ,1991, que ha sido el punto de arranque de todos los que han ormado
parte del modelo desarrollado sobre el concepto de capacidad y madurez, hasta el actual
CMMI.

127 127 127 127
Enlaces electrnicos

10 Pagina oicial SLI http:,,www.sei.cmu.edu,
10 Descripcin de los DlD http:,,es.wikipedia.org,wiki,Diagrama_de_l
ujo_de_datos
11 Descripcin de la teora de
componentes
http:,,es.wikipedia.org,wiki,Componentes_de_
sotware
11 Descripcin de la teora de las
estructuras condicionales
http:,,es.wikipedia.org,wiki,Condicional_,prog
ramacin,
11 Descripcin de la teora de los
PDL o pseudocdigos
http:,,books.google.co.cr,booksid~cOVSIiw2
mLAC&pg~PA60&lpg~PA60&dq~P
DL2BpseudocC3B3digo&sourc
e~bl&ots~4bqhh0Q8m&sig~i43lq0
d5pS4ta9AtClGad-
96g&hl~es&ei~CbysSaaVC4GCtwet6
oGLBg&sa~X&oi~book_result&resn
um~1&ct~result4PPA131,M1

128 128 128 128
Diseo exterior y evaluacin del software

e ba cov.trviao et sotware.
.bora .oto e.tavo. tratavao ae qve fvvciove.
Declaracin hecha en una reunin conjunta
de programa ejecutivo S1ARS L8A ISD

Ob]etivos

Ll trabajo realizado hasta ahora responde a actiidades de creacin, como lo son el analisis y el diseno.
Ls el momento de llear a cabo la accin contraria y sacar conclusiones de lo aanzado hasta ahora. Ll
tema de las pruebas es importante pues es aca donde se trata de alsear lo creado, exponiendo los
modelos del sistema y encontrando las allas antes de llegar a la mesa de trabajo del cliente inal.
Ademas, se a a explorar el amplio mundo del analisis y diseno de interaces, entanas mediante las
cuales los usuarios inales interactan con la maquina cliente y logran explotar sus bondades como
sistema.
Cuando termine de estudiar este tema, estara en capacidad de:
Lntender la importancia de un buen analisis, diseno y ealuacin para la interaz de los
sistemas y su interaccin con los usuarios inales.

Aplicar las estrategias que existen sobre los dierentes tipos de prueba, tanto para ambiente
tradicional como para el orientado a objetos.

Aprender a incluir, dentro de la estrategia de pruebas, las dierentes tcnicas deinidas para el
diseno de casos de prueba.
Tema

129 129 129 129
8umario


Capitulo J2 Diseo de la interfaz de usuario
Capitulo J3 Lstrategias de prueba del software
Capitulo J4 1ecnicas de prueba del software



130 130 130 130
Diseo de la interfaz de usuario

ievre be ae.eaao qve vi covvtaaora .ea tav facit ae vave;ar covo vi
tetefovo. Mi ae.eo .e ba rvetto reatiaaa. Ya vo .e cvo v.ar vi tetefovo.
Bjarne Stronstrup (creador del C++)

8umario
Las reglas basicas
Analisis y diseno de la interaz de usuario
Analisis de la interaz
Pasos del diseno de la interaz
Laluacin del diseno
Capitulo

131 131 131 131

SUB1LMAS PGINAS
Las reglas de oro 351
Analisis y diseno de la interaz de usuario 356
Analisis de la interaz 359
Pasos del diseno de la interaz 368
Laluacin del diseno 3

132 132 132 132

todo ese gran esuerzo realizado en el analisis, ese listado de requerimientos ya tentatiamente
resueltos por la lgica aplicada y todo el plano arquitectnico que los soporta, se le debe
permitir trabajar mediante algn mecanismo que el ser humano interprete bien, y le pueda
sacar proecho.
Ll diseno de la interaz de usuario debe proeer precisamente eso. Ll tema de diseno de interaz se
puede diidir en tres grandes areas como son el diseno para componentes, el diseno entre el .oftrare y
otros productos y consumidores no humanos y el diseno para seres humanos.
Ln este captulo se a a enatizar en la tercera area mencionada, o sea, en el diseno de interaz para el
usuario inal.
Se tocaran temas asociados a los principios que deben regir el diseno de dicha interaz y a todas las
reglas por seguir para obtener un mecanismo de aproechamiento de toda la lgica desarrollada,
misma que intentara resoler problemas deinidos por el usuario que se encuentra al rente de la
aplicacin.

133 133 133 133
Desarrollo

Reglas bsicas
Lxisten tres reglas en las que, con el tiempo, se ha llegado a comprobar su eicacia en lo que a diseno
de interaces se reiere. Lstas reglas son las siguientes:
Dar el control al usuario.
Reducir la carga de la memoria del usuario.
Lograr que la interaz sea consistente.
La accin de dar el control al usuario por s sola parece una excelente idea acil de acatar, mas no
siempre resulta de esa manera en las dierentes interaces a las que nos enrentamos da a da, en
particular en el uso de los sistemas.
Lxisten algunos principios de diseno que es necesario seguir para realmente otorgarle al usuario el
control de la interaz.

vortavte:
Principios para darle el control al usuario en el diseo de interfaces:
1. Definir los modos de interaccin de forma que el usuario no realice acciones innecesarias o
indeseables: el usuario debe escoger en qu modo se encuentra. Ln caso de existir mas modos debe poder
cambiar en el momento que lo desee.
2. Proporcionar una interaccin flexible: segn el tipo de actiidad por realizar en el sistema, as debe
estar adecuada la interaccin sica entre la computadora y el usuario.
3. Incluir las opciones de interrumpir y deshacer la interaccin del usuario: en cualquier momento
el usuario debe tener la opcin de interrumpir la secuencia y pasar a otra actiidad.
4. Depurar la interaccin a medida que aumenten los grados de destreza: cuanto mas destreza
acumulada tenga el usuario, ste debe tener la opcin de personalizar la interaccin a coneniencia.
5. Oculte al usuario ocasional los elementos tecnicos internos: el usuario solo debe preocuparse por
el ambiente de la aplicacin, ninguna capa que est por debajo de esta debe ser de conocimiento para el
mismo, se da por resuelto.
6. Disear interaccin directa con los objetos que aparecen por pantalla: cuanto mas similar sea la
manipulacin dada a un objeto en la aplicacin, a uno de la ida real, mejor la experiencia para el usuario.

La segunda regla es la de reducir la carga en la memoria del usuario. Ls claro que al tener la
computadora la oportunidad de almacenar inormacin, se conierte en un uerte aliado para retener la
mayor cantidad de inormacin que sea de inters para el usuario y para la aplicacin.
1ambin existen algunos principios de diseno que es necesario seguir para lograr que una interaz
reduzca la carga de memoria que recae en el usuario.

134 134 134 134

vortavte:
Principios para lograr que una interaz reduzca la carga de memoria que recae en el usuario:
1. Reducir la demanda de memoria a corto plazo: apoyarse en pistas isuales para recordarle al usuario
la secuencia de pasos ya realizados.
2. Definir valores por defecto que tengan significado: acercarle al usuario los alores por deecto que
aplique mas a lo que normalmente el usuario digitara.
3. Definir accesos directos intuitivos: debe estar directamente relacionado con la accin que a a
ejecutar el acceso, y que su uso sea intuitio.
4. Ll formato visual de la interfaz debe basarse en una metfora tomada de la vida real: se le debe
acercar al usuario en la medida de lo posible el ambiente y el lujo que normalmente hara si el proceso uera
manual.
5. Desglosar la informacin de manera progresiva: la inormacin debe estar acomodada de manera
jerarquica, mirando primero el niel mas abstracto y luego pasando al detalle.

Como tercera y ltima regla, se tiene la de lograr que la interfaz sea consistente. Lsta regla lo que
busca es deinir un estandar de diseno en toda la inormacin que se le a a presentar al usuario, tener
mecanismos de entrada que estn restringidos a un conjunto limitado de opciones que se utilice de
manera consistente, y mecanismos para trasladarse de una tarea a otra desarrollados tambin de manera
consistente.
Los siguientes principios de diseno son necesarios para crear una interaz consistente.

vortavte:
Principios para lograr que una interaz sea consistente:
Permitir que el usuario incluya la tarea actual en un contexto que tenga algn significado: el usuario
debe sentirse identiicado con la actiidad que esta realizando y el entorno de la aplicacin le debe
proporcionar esa sensacin.
Mantener la consistencia en una familia de aplicaciones: todas las aplicaciones deben tener las mismas
reglas de diseno ejecutadas.
Si modelos interactivos anteriores han generado expectativas en los usuarios, no se debe hacer
cambios a menos que haya razones inexcusables: debe respetarse algunos estandares de la industria en
cuanto a la interaccin entre las aplicaciones. Ljemplo l1 para la ayuda.

Anlisis y diseo de la interfaz de usuario
Ln el analisis y diseno de una interaz de usuario, para cualquier aplicacin, entran en juego cuatro
modelos. La tarea del disenador de interaz es conciliar estos cuatro modelos para obtener la interace
que mejor recoge las necesidades del cliente.
Ll modelo del usuario, que es la isin que se debe tener del usuario, sus caractersticas como ser
humano, cualidades y calidades, entre otras. Ln resumen, la comprensin absoluta del usuario inal
,isin tcnica,.

135 135 135 135
Ll modelo de diseo, el cual incorpora datos, arquitectura, interaz y las representaciones
procedimentales del .oftrare ,unciones y procedimientos,.
Ll modelo mental del usuario, que es la percepcin del sistema que tiene en la cabeza el usuario
inal. Un usuario puede tener una isin mucho mas cercana de la realidad con solo una ez que haya
utilizado la aplicacin, que otro usuario con muchas mas participaciones, todo depende del modelo
mental con que enga.
Ll modelo de la implementacin busca combinar la apariencia externa de la interaz del sistema, con
toda la inormacin de ayuda que describe la sintaxis y la semantica del sistema, o sea, ayuda en libros,
manuales, u otros materiales.

Actividad:
Digite en algn buscador en la Internet ,Coogte, Yaboo, .O earcb, un tema de su agrado y escoja la primera
pagina de las encontradas.
Obsrela, utilcela un rato y luego describa en sus propias palabras, la experiencia como usuario dentro del
contexto del diseno de interaces. Indique su opinin al respecto, para cada uno de los modelos.

A la hora de enocar el analisis y diseno de interaces como un proceso, se necesita pensar en un
modelo iteratio e incremental. Lste modelo es similar al estudiado en captulos anteriores, el llamado
modelo en espiral. Dentro de este modelo, amos a encontrar las siguientes etapas:
1. Analisis y modelado de usuarios, tareas y entornos.
2. Diseno de la interaz.
3. Construccin de la interaz.
4. Validacin de la interaz.
Ll modelo sugiere que cada una de estas etapas se hara mas de una ez, y que el incremento por giro
en esta signiica elaboracin de requerimientos y cambios en el diseno. A la ez, se esperara en la etapa
de construccin la creacin de prototipos.

136 136 136 136
Iigura 0J Ll proceso de diseo de la interfaz de usuario.

Anlisis de la interfaz
Un buen diseno de interaz signiica comprender cuatro cosas:
1, Las personas que interactan por medio de la interaz.
2, Las tareas que los usuarios inales deben realizar.
3, Ll contenido que se presenta como parte de la interaz.
4, Ll entorno en que se realizan estas tareas.

Con respecto a las personas que usan el sistema, y debido a que cada una tiene una imagen mental
distinta, es importante conciliar, como se dijo antes, la isin del usuario inal con el modelo que tiene
el ingeniero en su cabeza.
Lntreistas con el usuario, inormacin de entas y sus categoras, inormacin de mercadotecnia y la
proeniente de soporte, son uentes para conocer a las personas que inalmente usaran la aplicacin, y
qu las motia y las complace.
Ll anlisis y el modelado de las tareas es otra de las cosas importantes de comprender. Ln esta
etapa se trata de encontrar respuestas a preguntas como ,qu trabajo hara el usuario en circunstancias
especicas, ,cuales tareas y subtareas realiza el usuario mientras trabaja, ,en qu secuencia se
presentan las tareas del trabajo, ,cual es la jerarqua de las tareas
Como instrumento de recoleccin de requisitos usamos los casos de uso, solo que esta ez lo
delimitamos a que un actor siempre sera una persona.
A partir del este caso de uso, el ingeniero de .oftrare extraera tareas y objetos, ademas del lujo general
de la interaccin.
La elaboracin de las tareas se trabaja bajo el enoque de descomposicin uncional isto en el
captulo 9 de esta gua, que permite reinar las tareas de procesamiento requeridas.
Con la idea de comprender las tareas indispensables para alcanzar los objetios de cada actiidad, el
ingeniero de .oftrare debe comprender las actiidades que realizan las personas mediante los mtodos
manuales, y luego relacionarlas con un conjunto similar de tareas que se implementan en el contexto de
la interaz de usuario.

137 137 137 137
Otra etapa es la de elaboracin de los objetos que soportan la interaccin. Ln lugar de concentrarse
tanto en las tareas, el ingeniero extrae del caso de uso alguna otra inormacin suministrada por el
usuario y obtiene los objetos sicos que soportaran dicha interaccin.
Cuando se presentan los casos en donde arios usuarios deben interactuar con una misma interaz, no
basta con tener claro el analisis de la tarea ni la elaboracin de los objetos. Para estos casos es necesario
llear a cabo el anlisis del flujo de trabajo, el cual le permite al ingeniero de .oftrare entender cmo
se realiza el proceso donde se inolucra mas de una persona y mas de un papel a la ez.
La existencia de un lujo de trabajo establece una jerarquia de tareas que se debe respetar para obtener
los resultados esperados. La jerarqua se deria de una elaboracin, paso a paso, de cada tarea solicitada
por el usuario.
Otra actiidad sumamente importante dentro del diseno de la interaz es el anlisis del contenido de
la pantalla. Las tareas mencionadas anteriormente, traen consigo contenido que debe ser tratado
,texto, imagenes, deos, entre otros,.
Lste contenido iene almacenado mediante objetos de datos, tales como componentes productores de
tipo externo, mediante bases de datos externas o directamente mediante sistemas externos a la
aplicacin en mencin. Ls necesario considerar el ormato y la esttica en este punto para el contenido
de la aplicacin.
Como parte de las actiidades inales por considerar, el anlisis del entorno de trabajo se uele una
obligacin que debe ser analizada. La ocupacin sica que tendra el usuario inal debe estar en
completa armona con la interaz que se ha de presentar en la aplicacin.

Pasos del diseo de la interfaz
Ll libro de estudio sugiere que a pesar de la existencia de dierentes modelos para el diseno de la
interaz, se pueden identiicar algunos pasos claes para llearla a cabo:
Deinir los objetos y las acciones de la interaz con base en el conocimiento desarrollado durante el
analisis de la inormacin.
Deinir eentos que cambiaran el estado de la interaz y modelar este comportamiento.
Representar cada estado de la interaz como el usuario inal lo era.
Indicar cmo interpreta el usuario el estado del sistema a partir de la interaz proporcionada.

Cada paso del diseno de la interaz, por ser iteratio, se dara arias eces y en cada uno de ellos se a a
reinar y detallar cada paso anterior.
Un paso importante en el diseno de la interaz es la deinicin de los objetos que sta tendra y las
acciones que se le aplicaran, tal y como se hara en un caso de uso con los nombres ,objetos, y erbos
,acciones,.
Una ez deinidos los objetos, se clasiican por objetos tipo destino ,Lj. impresora,, origen ,Lj.
inorme, y de aplicacin ,Lj. lista de correos,. Ademas, cuando el disenador esta contento con cada
objeto y tiene deinidas las acciones asociadas a cada objeto, ya puede iniciar con el ormato de la
pantalla.

138 138 138 138
Ll proceso de ormato de la pantalla es interactio y en l se elabora el diseno graico y se ingresan
iconos y el texto descriptio deinido como importante.
1ambin se incorporan los elementos primarios y secundarios para los mens y si se logra encontrar
una metaora de la realidad que uncione para la aplicacin, se especiica y se acopla al diseno para que
se integre.

Actividad:
Como parte de los pasos del diseno de la interaz, en las paginas 31 - 32 del libro de texto, se indica que el
tema de patrones de diseno para la interaz de usuario no es parte integral de la naturaleza de dicho libro.
Inicie una bsqueda en la cantidad de medios posibles, sobre el tema de patrones de diseo para la interaz
de usuario.
Ademas, en las paginas 32 - 35 del libro de texto, se habla sobre temas de diseo. Analice esos temas e
identiique qu acciones se pueden tomar para mitigarlos.

Lvaluacin del diseo
Despus de seguir todos los lineamientos antes expuestos, lo que queda es llear a cabo la ealuacin
del diseno deinido. Corresponde iniciar algn mecanismo que permita al usuario inal utilizar la
interaz de la aplicacin y ealuar si sta corresponde con lo esperado.
Ln la igura 02 puede obserar cmo se trabajara con el ciclo de ealuacin que permite deinir si la
aplicacin satisace completamente al usuario inal.

Iigura 02 Ciclo de evaluacin de diseo de la interfaz.

139 139 139 139
Ls importante entender que no es necesario tener terminado un prototipo para iniciar la ealuacin de
la calidad.
Desde las primeras iteraciones del bucle en el ciclo de ida, es posible comenzar a identiicar problemas
e iniciar su correccin para que, cuando se est cerca del prototipo, los ajustes sean mnimos.

140 140 140 140


56. Suponga que se le ha pedido desarrollar un portal para un banco a web.
Desarrolle en papel ,segn su criterio,, los modelos del usuario, del dseno, del
mental y de la implementacin.
5. Como usuario inal de la web, para entender que existe consistencia en un portal
corporatio, a niel de interaz ,qu necesita usted percibir en l
58. Indique por medio de un listado, ejemplos de por qu es importante tomar en
cuenta la ariabilidad del tiempo de respuesta.
59. Desarrolle dos principios de diseno adicionales que reduzcan la carga en la
memoria del usuario`.
60. Desarrolle dos principios de diseno adicionales que den el control al usuario`.

141 141 141 141
Estrategias de pruebas del software

t otivi.vo e. et etigro ocvaciovat ae ta rogravaciv, ta rveba, et
tratavievto. Kent Beck

8umario
Un enoque estratgico para las pruebas de .oftrare
Aspectos estratgicos
Lstrategia de prueba para el .oftrare conencional
Lstrategia de prueba para el .oftrare orientado a objetos
Pruebas de alidacin
Pruebas de sistema
Ll arte de la depuracin
Capitulo

142 142 142 142

SUB1LMAS PGINAS
Un enoque estratgico para las pruebas de .oftrare 383
Aspectos estratgicos 390
Lstrategia de prueba para el .oftrare conencional 391
Lstrategia de prueba para el .oftrare orientado a objetos 402
Pruebas de alidacin 404
Pruebas de sistema 406
Ll arte de la depuracin 409

143 143 143 143

a prueba es un elemento ital para garantizar que los pasos seguidos en la construccin de un
producto permiten asegurar el uncionamiento satisactorio, en su ejecucin, a la hora de
ponerlo a trabajar. Por este motio se debe llear a cabo, de manera planiicada y ordenada, de
orma que realmente permita ejercitar lo construido y llearlo a todos los nieles en donde
podra llegar a estar sometido en el ambiente de destino.
Una estrategia de pruebas de .oftrare integra los mtodos de diseno de casos de prueba, para ensamblar
un proceso que contenga todos los elementos necesarios en el niel de entorno que proporcionen un
resultado exitoso y que ademas permitan entender cuanto esuerzo, tiempo y recursos se consumiran.
Ll resultado debe contener las etapas de planeacin, diseno de casos, ejecucin, recoleccin y
ealuacin de resultados importantes, deben incluirse los casos no exitosos.
Lste captulo tratara de detallar cada uno de estos aspectos mencionados anteriormente, con el aan de
que usted comprenda lo necesario y beneicioso que resulta el explayarse, en la medida de lo posible,
en esta etapa dentro del desarrollo de .oftrare.

144 144 144 144
Desarrollo

Un enfoque estrategico para las pruebas del software
Ln este captulo es preciso resaltar el alor que debe tener la prueba dentro del amplio proceso de
desarrollo de .oftrare. A pesar de ser parte de las ltimas etapas, no por esto es de menor alor en dicho
proceso y el retorno es inaluable y muy sano para el uturo sistema.
Ls importante, por lo tanto, contar con una estrategia que permita tanto al usuario inal como al
equipo de desarrollo, saber que el producto elaborado esta dentro de los parametros esperados en
cuando a su naturaleza y razn de ser.
La estrategia por escoger debe permitir la inclusin de actiidades ejecutadas de manera sistematica que
permitan incorporar tcnicas y mtodos especicos del diseno de casos de prueba.
Lxisten algunas caractersticas genricas importantes de conocer, para la creacin de plantillas y para las
pruebas de .oftrare.

vortavte:
Caracteristicas genericas importantes para la creacin de plantillas para pruebas:
1. Un equipo de .oftrare debe eectuar reisiones tcnicas ormales y eectias.
2. La prueba comienza a niel de componentes y trabaja hacia auera`, hacia la integracin de todo el
sistema de cmputo.
3. Dierentes tcnicas de pruebas son apropiadas en dierentes momentos.
4. La prueba la dirige el desarrollador de .oftrare ,para proyectos grandes existira un grupo independiente,.
5. La prueba y la depuracin son actiidades dierentes, pero la segunda debe estar incluida en cualquier
estrategia de prueba.

La existencia de una estrategia es importante tambin para el jee del proyecto, que normalmente es la
igura que tendra que dar cuenta cuando aumente la presin del proyecto al acercarse las echas lmite.
Sera muy importante para l tener a mano mecanismos que le permitan medir el aance del proyecto y
a la ez trabajar en la deteccin y correccin tempranera de problemas.
La prueba de .oftrare realmente pertenece a un conjunto mas grande de actiidades conocido como
verificacin y validacin ,VyV,, actiidades que a la ez pertenecen al aseguramiento de la calidad
del .oftrare, tema que se era mas a ondo en captulos posteriores.
Se habla de verificacin cuando se quiere asegurar que la implementacin del .oftrare se realiz
correctamente. La validacin lo que permite es saber si el .oftrare desarrollado satisace realmente lo
que el cliente espera de l.
La existencia de esta etapa muchas eces llea a los desarrolladores a limitar esuerzos en cuando al
aseguramiento de la calidad, y llea todo a un embudo de reisin` al tener inalizadas arias etapas
dentro de una misma iteracin o si se quiere al trmino de arias iteraciones.

145 145 145 145
No se debe pensar que las pruebas son una red de seguridad que atrapara todos los errores proocados
por practicas dbiles dentro del proceso de ingeniera de .oftrare aplicado. No es posible probar la
calidad, si no esta ah antes de que empiece la prueba, no estara ah cuando termine.
Otro aspecto importante que resalta el libro de texto es la experiencia que pasa el o los desarrolladores
del .oftrare cuando se habla del tema de la prueba. De alguna manera, pensar en que alguien pruebe
algo que uno desarroll signiica para su creador algn niel de desconianza sobre su trabajo y la
calidad asociada. Pero es ineitable trabajarlo de esta manera. Siempre es necesario, para eliminar el
conlicto de intereses, que alguien mas reise el trabajo desarrollado y lo trate de e.tre.ar
1
o llear al
extremo, para encontrar esos errores tan diciles de alcanzar antes de la puesta a produccin.
Para proyectos grandes, normalmente se tiene un grupo independiente de prueba ,GIP,, el cual
debe estar muy de la mano de los desarrolladores para alcanzar pruebas de calidad y de alto grado de
satisaccin. Lste GIP es parte del proyecto de desarrollo de .oftrare y realmente iene desde las etapas
de analisis y diseno, con las pruebas correspondientes para cada etapa.
La estrategia de pruebas por seguir, para los casos en donde se a a utilizar una arquitectura
convencional, es muy similar al modelo de la espiral, isto en captulos anteriores.
Ll libro trata de establecer una relacin directa entre este modelo y la estrategia por seguir, tal como en
la igura 03. La prueba de unidad comienza con el rtice de la espiral y se concentra en cada
componente, tal y como se implement en el cdigo uente.
Luego sigue la prueba de integracin donde se atiende el diseno y la construccin hasta llegar a la
prueba de validacin, donde se alidan los requisitos establecidos como parte del analisis,
comparandolos con el .oftrare construido. Para inalizar, llegan las pruebas de sistema, donde se
prueba el .oftrare como un todo ,ingeniera de .oftrare, y otros elementos del sistema a un niel de
contexto.
Cada ez que se llea a cabo una iteracin se ensancha el alcance de la prueba, reorzando cada ez
mas la calidad en cada una de las etapas que conorman el .oftrare.

Iigura 03 Lstrategia de prueba para arquitectura de software convencional.

1
Signiica llear al lmite las capacidades deinidas para un sistema, esto permite probar ampliamente su estabilidad.

146 146 146 146
Por otro lado, la estrategia de pruebas a seguir para los casos en donde se a a utilizar una
arquitectura orientada a objetos es muy similar a la estrategia conencional, mas no igual en su
enoque.
Ln el enoque conencional, cuando la prueba es pequena, el elemento mas pequeno es el mdulo
individual, en cambio en el enoque orientado a objetos se hace reerencia a las clases y las
operaciones asociadas, que necesitan de la comunicacin y colaboracin entre ella y otras clases.
Lsta relacin entre clases obliga a incluir dentro de las pruebas una de tipo regresin, para descubrir
errores debido al cambio entre la composicin de las clases y su interaccin con las que est asociada
dicha clase.
Ll momento en que deben terminarse las actividades de prueba es dicil de determinar, ya que
realmente nunca se terminan de dar. Cada ez que el usuario utiliza la aplicacin, ya despus de
implementado el sistema en produccin, es implcitamente un ejercicio que prueba la aplicacin, a er
qu tan alido es su comportamiento con el esperado por el usuario inal.
Sin embargo, lo que s se puede lograr, segn el texto gua, es aplicar ciertas mtricas que hagan uso de
modelos probabilsticos que nos ayuden a despejar las allas en rangos muy eleados ,cercanos al 95,,
antes de entregar el .oftrare para produccin.

Actividad:
Inestigue qu tipo de mtricas o modelos estadsticos existen en el mercado para disminuir al maximo el
grado de allas por encontrar en las aplicaciones de .oftrare.
Analice qu tipo de producto se estara introduciendo en el mercado con la aplicacin de dichos modelos y
cmo sera la misma aplicacin, pero sin ellos. Describa las dierencias.

Aspectos estrategicos
Lxisten algunos temas sugeridos en el libro de reerencia que indican cmo desarrollar una estrategia
de pruebas con xito.

vortavte:
Pasos para desarrollar una estrategia de pruebas con exito:
1. Lspeciicar los requisitos del producto de manera cuantiicable mucho antes de que empiecen las
pruebas.
2. Lstablecer explcitamente los objetios de la prueba.
3. Comprender cuales son los usuarios del .oftrare y desarrollar un peril para cada categora de usuario.
4. Desarrollar un plan de prueba que destaque la prueba del ciclo rapido.
5. Construir un .oftrare robusto disenado para probarse a s mismo.
6. Usar reisiones ormales tcnicas y eectias como iltro preio a la prueba ,captulo 26,.
. Realizar reisiones tcnicas ormales para ealuar la estrategia de prueba y los propios casos de prueba.

147 147 147 147
8. Desarrollar un enoque de mejora continua para el proceso de prueba.

Lstas directrices permiten un marco robusto para pensar en una estrategia de pruebas mas consistente
y alejada de allas.

Lstrategias de prueba para el software convencional
Lxisten arias estrategias, seguidas por los equipos de desarrollo de .oftrare, para llear a cabo las
pruebas necesarias para ealuar la aplicacin desarrollada.
No necesariamente todas las estrategias dan los resultados esperados, sobre todo cuando se escoge la
opcin de probar todo al inal, como si se tratara de una actiidad desarrollada en una sola etapa.
La estrategia mas acertada, sugiere el libro de reerencia, es optar por un enfoque incremental, se
inicia con las pruebas de unidades indiiduales, luego las pruebas disenadas para acilitar la integracin
de dichas unidades, y por ltimo las pruebas sobre el sistema completo.
La prueba que inicia este proceso es la prueba de unidad. A continuacin se describe puntualmente la
parte de la estrategia sugerida para esta etapa.
Ll libro de texto indica que la prueba de unidad se basa, tal y como se mencion anteriormente, sobre
la unidad mnima dentro del diseno de .oftrare: el componente o mdulo del sistema. Lstas pruebas
se deben concentrar en la lgica del procesamiento interno y en las estructuras de datos dentro de los
lmites impuestos a los componentes.
Ademas, explica que dentro de las consideraciones necesarias tenemos que atacar temas como la
interaz del mdulo de prueba, examinar las estructuras de datos, recorrer todos los caminos
independientes en las estructuras y probar las condiciones lmite para asegurar que el mdulo opera
correctamente.
Las pruebas selectivas de las rutas de ejecucin son itales de reisar. Ls preciso eitar errores
debidos a calculos incorrectos, comparaciones errneas o lujos de control inapropiados.
Por otro lado, hace mencin a un aspecto muy importante dentro de la programacin: que
normalmente se malentiende su incorporacin cuando se relaciona con los casos de pruebas.
lablamos del amoso control de errores, ya que en muchos casos, debido a su existencia, no se
realizan las pruebas como deben ser, alindose de la existencia de dicho control a niel de cdigo,
pues se espera que todo se atrape por ah.

Actividad:
Consiga el cdigo de un programa que est en operacin o que est al menos en etapa de pruebas. Ll cdigo
debe ser de un lenguaje de programacin orientado a objetos, preeriblemente C-- o Jaa.
Ljercite lo aprendido en la lectura. Ljecute todas las reisiones mencionadas, asociadas con la estrategia de
pruebas. Siga la pista a algunos lujos de datos, obligue a un segmento del cdigo a salir por el control de
errores y contraste lo ledo contra lo obserado en dicha actiidad.

148 148 148 148

Cuando se habla de los procedimientos de prueba de unidad, el libro sugiere trabajar con la
creacin de .oftrare controlador, de resguardo o ambos dependiendo del caso. Ver igura 04.
Ll .oftrare controlador es el que permite encapsular al mdulo que se ha de probar, de manera tal que
acepte los datos de prueba, los pase al componente y luego imprime los datos de importancia de dicha
prueba.
Ll .oftrare de resguardo usa la interaz del mdulo subordinado, realiza una mnima manipulacin de
datos, proporciona eriicacin de entrada y deuele el control al mdulo de prueba, o sea cierra el
ciclo programa principal componente resguardo.

Iigura 04 Lntorno de pruebas de unidad.
Como segunda etapa dentro del ciclo de pruebas esta la prueba de integracin. Lstas pruebas son
una tcnica sistematica para construir la integracin del .oftrare. Ademas, contienen una actiidad que
corre paralela y permite deinir las pruebas por realizar para detectar errores asociados con la interaz.
Lstos errores podran ser de diersos tipos, por ejemplo que la combinacin de subunciones no llegue
a producir la uncin esperada, o que el eecto de un mdulo tenga un eecto aderso al esperado.
La mejor estrategia o orma de atacar esta etapa de integracin es indicada por el libro de texto como la
estrategia incremental, que permite aanzar mediante pequenos incrementos y acilita la aplicacin de
un enoque de prueba sistematica. Ademas expone algunas de las estrategias incrementales conocidas
como mas importantes.
La primera estrategia mencionada es la de integracin descendente, que permite a los mdulos
integrarse al descender por la jerarqua de control, empezando con el mdulo de control principal, y
luego los mdulos subordinados se incorporan en la estructura de una de dos maneras: primero en
profundidad o primero en anchura.
La siguiente estrategia tratada es la de integracin ascendente. Lsta empieza la construccin y la
prueba con mdulos atmicos, luego sigue en su ascenso hasta el principal. Debido a esta naturaleza,
no necesita la creacin de resguardos.

149 149 149 149
Otra de las estrategias mencionadas es la prueba de regresin, donde la idea es que paulatinamente
cada ez que se agrega un nueo mdulo a la reisin, se debe repetir el mismo subconjunto de
pruebas que ya se haban aplicado para eliminar posibles eectos colaterales.
\a como ltima propuesta tenemos la estrategia incremental de la prueba de humo, que no es mas
que la ealuacin con frecuencia definida, para todos y cada uno de los componentes que orman la
solucin de .oftrare. Lsta estrategia es de gran inters para proyectos a niel crtico, que no desean
dejar escapar ni el menor de los detalles alcanzable, pues le acerca a los jees de proyecto una
ealuacin realista de lo acontecido.

Actividad:
Lntre las paginas del libro de texto 395 - 400 se encuentra una descripcin mas detalla de cada una de las
estrategias incrementales que se mencionan en parraos anteriores. Lea y analice esta inormacin.
Obtenga conclusiones sobre la existencia de cada una de estas estrategias y las dierentes necesidades para las
pruebas en el mundo del desarrollo de .oftrare. Lxponga sus conclusiones en un pequeno ensayo.

La existencia de estrategias incrementales, tanto ascendentes como descendentes, nos llea a pensar en
la siguiente pregunta: ,cual de estas dos sera mas eiciente La necesidad de crear resguardos en las
estrategias descendentes, como la necesidad de terminar todos los mdulos para poder tener el
programa completo en la estrategia ascendente, descaliica a ambas opciones como soluciones ptimas
y mas bien prooca pensar en una solucin que amague ambas propuestas, enoque que se conoce
como prueba sndwich.
Como producto o entregable de esta etapa de pruebas se debe obtener un documento llamado
especificacin de la prueba. Lste documento debe contener un plan general para la integracin del
.oftrare junto con una descripcin de pruebas especicas mas un procedimiento de prueba.

Actividad:
Ln la pagina del libro de texto 401 encontrara una descripcin detallada de la documentacin de la
prueba de integracin, que se menciona en el parrao anterior. Lea y analice esta inormacin: ,qu
utilidad tiene para usted esta inormacin, ,cmo la usara, ,qu necesidades le permite solentar

Lstrategias de prueba para el software orientado a objetos
La naturaleza de la estrategia de pruebas de unidad para los casos en donde se a a utilizar una
arquitectura orientada a objetos es muy similar a la estrategia conencional, mas como ya dijimos no
es igual en su enoque, y por lo tanto cambia la estrategia y la tactica.
Para el enoque conencional, el elemento mas pequeno es el mdulo individual, en cambio en el
enoque orientado a objetos, hacemos reerencia a las clases, objetos ,instancias de la clase, y las
operaciones asociadas, que necesitan de la comunicacin y colaboracin entre ella y otras clases.
Lsta situacin pone a las operaciones dentro de la clase como las unidades mas pequenas de prueba
para el ambiente orientado a objetos. Lntonces, la reisin de estas unidades se a a comparar con la

150 150 150 150
reisin del detalle algortmico de un mdulo y en los datos que luyen por su interaz, para un
ambiente conencional. Ln sntesis, la prueba de clase para el .oftrare orientado a objetos es la
equialente a la prueba de unidad en el .oftrare conencional.
Para las pruebas de integracin hay limitantes en cuando a las estrategias indicadas para la parte
conencional, porque las estrategias de integracin ascendente y descendente no trabajan bien en
ambientes donde no exista un control jerarquico, como s ocurre en el ambiente tradicional, orientado
al lujo.
Ll libro de texto presenta, en cambio, dos estrategias un poco dierentes para atacar la integracin en
ambientes orientados a objetos. La primera es la prueba basada en subprocesos, la cual integra un
conjunto de clases requerido para responder a una entrada o a un eento del sistema.
La segunda estrategia, es la prueba basada en el uso, donde la primera parte es empezar la
construccin del sistema con las pruebas de esas clases ,llamadas clases independientes, que usan
muy pocas clases de seridor. Despus de que se aprueban las clases independientes, se prueban las
clases dependientes, que usan las clases independientes.
1ambin es alido para las pruebas de integracin el uso de controladores y resguardos para ambientes
orientados a objetos.

Pruebas de validacin
Ln parraos anteriores se haba explicado el concepto de alidacin dentro del ambiente de pruebas de
.oftrare. Un .oftrare es alidado cuando el cliente esta razonablemente satisecho por lo que realiza,
basado en lo que dice el documento de la etapa de analisis llamado especificacin de requisitos de
software.
Ll plan de pruebas debe contener todo lo necesario para demostrar que los requerimientos uncionales
se alcanzaron, y que las caractersticas de comportamiento, requisitos de desempeno, documentacin y
acilidad de uso estan cubiertos tambin.
Cuando se desarrolla .oftrare para un cliente, se debe aplicar las pruebas de aceptacin que, mediante
unas pruebas planeadas y ejecutadas de manera sistematica, indican que el .oftrare esta bien.
Cuando se esta desarrollando .oftrare para muchos clientes es importante que cambie el enoque y se
piense en pruebas especiales, llamadas ala y beta. La prueba alfa consiste en un grupo de usuarios que
lleara a cabo las pruebas, pero en el ambiente natural del desarrollador de manera controlada. Ln
cambio, la prueba beta consiste, en un grupo de usuarios que lleara a cabo las pruebas, pero ahora en
el ambiente natural del usuario final, de manera no controlada para el desarrollador.

Pruebas del sistema
Ln este momento ya se entiende que el .oftrare ha surido las reisiones tanto de unidad, como de
integracin y alidacin. Las pruebas del sistema abarcan un plano mayor de elementos por
considerar, pues inolucran aspectos como bararare y personas, entre otros. La idea de las pruebas de
sistema es ejercitar proundamente el sistema de cmputo. Lxisten dierentes tipos de pruebas de
sistema, los cuales amos a mencionar a continuacin:

151 151 151 151

vortavte:
1ipos de pruebas de sistema:
1. De recuperacin: obligan al .oftrare a allar de arias maneras y a eriicar que la recuperacin se
realice satisactoriamente, ya sea automatica o manual.
2. De seguridad: comprueban que los mecanismos de proteccin integrados en el sistema realmente lo
protejan de interrupciones inapropiadas.
3. De resistencia: ejecutan el sistema de manera tal que requiera una cantidad, una recuencia o un
olumen anormal de recursos.
4. De desempeo: disenadas para probar el desempeno del .oftrare en tiempo de ejecucin dentro del
contexto del sistema integrado. Normalmente se inculan con pruebas de resistencia y suelen requerir
instrumentacin de .oftrare y bararare.

Ll arte de la depuracin
La ejecucin satisactoria del plan de prueba realizado es lo que da origen a la depuracin del
software. Se dice de esta manera porque la naturaleza de la prueba es la de encontrar errores en la
aplicacin reisada. Otra orma de er la depuracin es la de tratarlo como el proceso que conecta un
sintoma con una causa.
La aplicacin de la depuracin a los resultados de las pruebas permite corregir los errores encontrados
y los que no, le permiten al ingeniero a cargo crear un nueo plan de pruebas ,casos de prueba,
enocado directamente en el sntoma que se sospecha pero que todaa no tiene solucin.
Ll tema de la depuracin es complejo, esta mas asociado a temas de la psicologa humana que a la
tecnologa del .oftrare. Lxisten algunas caractersticas de los errores que ayudan a entender porqu se
dan:

vortavte:
Caracteristicas de errores por depurar:
1. Ll sntoma y la causa pueden estar separados geograicamente.
2. Ls posible que el sntoma desaparezca ,temporalmente, al corregir otro error.
3. Ls probable que el sntoma no lo cause algn error ,por ejemplo inexactitud o redondeo de ciras,.
4. Ll sntoma podra deberse a un error humano dicil de localizar.
5. Ll sntoma podra deberse a problemas de tiempo y no de procesamiento.
6. 1al ez sea dicil reproducir con exactitud las condiciones de entrada ,aplicaciones en tiempo real,.
. Ll sntoma podra presentarse de manera intermitente.
8. Probablemente el sntoma se debe a causas distribuidas entre arias tareas que se ejecutan en dierentes
procesadores.

152 152 152 152
Al mencionar el libro de texto que normalmente el tema de la depuracin esta muy asociado a la parte
humana, lo hace basandose en estudios que demuestran que programadores con educacin y
experiencia parecida, demuestran tener dierentes habilidades con respecto a la depuracin.
Sin embargo, a alta de capacidades innatas, la existencia de algunos enoques acilita la capacidad de
aprender a depurar. le aqu algunas estrategias.
La primera tactica de depuracin que se a a mencionar, se conoce como fuerza bruta, es tal ez el
mtodo mas comn y menos eiciente. Consiste en dejar gran cantidad de marcas en tiempo de
ejecucin y luego se carga el programa con instrucciones de salida. Se espera a que el mismo sistema
termine expulsando la alla y listo, a corregir.
Ll rastreo hacia atrs es otra tcnica, algo menos comn que la de uerza bruta. Inicia en el sitio en
donde se ha descubierto un sntoma, luego se recorre hacia atras el cdigo uente ,manualmente, hasta
hallar el sitio de la causa.
Ll ltimo enoque es el de participacin binaria. Se toman los datos asociados con el error y se
clasiican para intentar aislar las causas. Con una hiptesis` de la causa se usan los datos para probar
dicha hiptesis. Luego en caso positio de dicha aloracin, se reinan de nueo los datos aliosos y se
uele a intentar aislar el error.

Actividad:
Ln las paginas 413 - 414 del libro de texto, se encuentra una descripcin de la depuracin, tipo automatica.
Lea sobre este tipo de apoyo en la depuracin de los errores, para entender cmo la inormatica apoya
tambin esta actiidad del ingeniero de .oftrare. Llabore una lista propia de pasos por seguir para conseguir
tal depuracin.

153 153 153 153


61. Cuando el proyecto es grande, ,cuales deberan ser los lineamientos por seguir
para garantizar que el equipo de pruebas a a llear a cabo su trabajo de manera
exitosa e imparcial
62. ,Por qu es dicil aplicar pruebas de unidad a un mdulo altamente acoplado
63. Describa con sus propias palabras qu es eriicacin y alidacin.
64. Lea la siguiente premisa: ^o e. o.ibte robar ta catiaaa, .i vo e.ta ab avte. ae qve
eviece ta rveba, vo e.tara ab cvavao tervive`. ,Por qu considera usted que esto se
airma de la calidad
65. ,Lxiste algn modelo de desarrollo de sistemas al que le sea aorable realizar
todas las pruebas hasta el inal del proceso

154 154 154 154
Tcnicas de pruebas del software

oto ba, vva regta ara ai.evar ca.o. ae rveba: abarcar toaa. ta. fvvciove.,
ero vo ai.evar aeva.iaao. ca.o.. 1suneo Yamaura

8umario

lundamentos de las pruebas de .oftrare
1cnicas de caja negra y caja blanca para pruebas de .oftrare
Mtodos de pruebas orientados a objetos y orientados al niel de clase
Disenos de casos de prueba de interclase
Pruebas de entornos especializados: arquitecturas y aplicaciones

Capitulo

155 155 155 155

SUB1LMAS PGINAS
lundamentos de las pruebas de .oftrare 419
1cnicas de caja negra y caja blanca para pruebas de .oftrare 422
Mtodos de pruebas orientados a objetos y orientados al niel
de clase
441
Disenos de casos de prueba de interclase 449
Pruebas de entornos especializados: arquitecturas y aplicaciones 452

156 156 156 156

ener el cdigo desarrollado segn las especiicaciones recibidas en el analisis y diseno llena de
satisaccin a todas las partes inolucradas, tanto a los desarrolladores del producto como a
clientes y usuarios inales que esperan beneiciarse en alguna medida. No es para menos,
despus de tan ardua y desgastante labor para ambas partes.
Pero cabe aca una pregunta importante: ,opera el programa de manera tal, que satisaga las necesidades
del cliente tanto en el aspecto uncional, como en la calidad de sus resultados
Aunque es posible intentar la instalacin y utilizacin del sistema para que el usuario inal realice
algunas pruebas sueltas, solo se tiene una manera seria y responsable de dar una respuesta aceptable, y
esa orma no es otra que la de establecer un mecanismo para aplicar diferentes tecnicas de prueba
al .oftrare que se acaba de construir.
Lste captulo busca ese objetio: describir las dierentes consideraciones tcnicas que se deben seguir
cuando se trata de montar un diseno de casos de prueba que permita al usuario clariicar que las
interacciones que a a llear contra el sistema, le an a deoler el resultado que espera y con la calidad
necesaria.

157 157 157 157
Desarrollo

Iundamentos de las pruebas del software
Ll undamento base de las pruebas es encontrar errores en la aplicacin por reisar. Lstas pruebas
deben tener elementos en sus caractersticas que permitan encontrar errores, y a la ez esto se realice
con el mnimo esuerzo y con acilidad.
Algunas caractersticas de este tipo pueden ser las siguientes:

vortavte:
Caracteristicas importantes para la creacin de .oftrare con acilidad para pruebas:
1. Operatividad: cuanto mejor uncione, con mayor eiciencia podra probarse.
2. Observabilidad: lo que se e es lo que se prueba.
3. Controlabilidad: cuanto mejor se controle el .oftrare, mejor se automatizaran y se mejoraran las
pruebas.
4. Capacidad para descomponer: con esto se aislaran los problemas mas rapidamente y se acilitara la
opcin de probar de manera independiente los mdulos.
5. Simplicidad: cuanto menos haya que probar mas rapido se hara.
6. Lstabilidad: cuantos menos cambios haya, menores alteraciones habra en la prueba.
. Iacilidad de comprensin: cuanta mayor inormacin se tenga, con mayor inteligencia se hara la
prueba.

Ademas, las pruebas deben contener atributos que aciliten su ejecucin, tales como:
Lleada probabilidad de encontrar un error.
No ser redundante.
Debe ser la mejor de su clase`.
No debe ser ni muy simple ni demasiado compleja.

1ecnicas de caja negra y caja blanca para pruebas de software
Ln trminos generales, se puede decir que las pruebas de caja negra se realizan desde auera del .oftrare
y las pruebas de caja blanca se eectan desde adentro.
Se a a iniciar con la descripcin de las pruebas de caja blanca y las dierentes tcnicas asociadas a ellas,
tales como la de ruta basica y la de estructuras de control.

158 158 158 158
Las pruebas de caja blanca buscan explorar la parte procedimental del .oftrare, con esto se busca
probar las rutas lgicas dentro del cdigo y la colaboracin entre componentes.
La prueba de la ruta bsica es una tcnica que permite al disenador de los casos de prueba obtener
una medida de la complejidad lgica de un diseno procedimental, y usarla como gua para deinir un
conjunto basico de rutas de ejecucin.
Ll libro de texto explica la notacin de grfica de flujo que sire para representar el lujo de control de
la prueba. Cada construccin estructurada tiene su representacin en esta graica.

Actividad:
Ln las paginas 423 - 424 del libro de texto se da la explicacin de cmo esta conormada la notacin de
grfica de flujo y cmo se llea a cabo su aplicacin, al representar el diseno procedimental con grfica de
flujo, a partir de un diagrama ,liguras 14.1, 14.2a y 14.2b del libro de texto,.
Lea y analice tanto el texto descriptio asociado, como la graica de lujo y el diagrama de lujo. Obsere el
mapeo que corresponde en cada caso y relacinelo mentalmente con el cdigo imaginario que origina esta
secuencia dentro del lujo.

Otro concepto importante dentro del tema de la ruta basica es la ruta independiente. Lste concepto
se relaciona con cualquier ruta del programa que ingresa por lo menos un nueo conjunto de
instrucciones de procesamiento o una nuea condicin.
Desde el punto de ista de la graica de lujo ,igura 05,, signiica que una ruta independiente debe
recorrer por lo menos una arista que no se haya recorrido anteriormente.

Iigura 0S Diagrama de flujo y grfica de flujo.
La suma de una nuea arista para un camino ya deinido crea lo que se conoce como el conjunto
bsico de rutas independientes. Lste conjunto basico es casi imposible de completar para cualquier
diseno procedimental existente de ciertas proporciones, ya que existen ^ cantidad de posibles
relaciones que haran excesiamente grandes las pruebas para todos los casos deinidos.

159 159 159 159
La mtrica de .oftrare llamada complejidad ciclomtica permite deinir una medida cuantitatia de la
complejidad lgica de un programa, y con esto resoler el problema anterior.
Lsta mtrica proporciona el lmite superior del nmero necesario de casos de prueba ,rutas
independientes encontradas, para garantizar que cada instruccin del programa se haya ejecutado por
lo menos una ez.

Actividad:
Ln las paginas 426 - 42 del libro de texto se da la explicacin de cmo esta conormado el mtodo de
complejidad ciclomatica. Analice las dierentes maneras que soporta esta mtrica y eale manualmente, si lo
expuesto ah es correcto para la graica 14.2b.

Como ya se mencion, el mtodo de la ruta basica esta asociado con la parte procedimental del cdigo
uente de un programa. Se a a describir ahora la ruta basica ista como una serie de pasos por realizar
para deriar el conjunto basico:

vortavte:
Pasos a realizar para deriar el conjunto bsico de la ruta de pruebas:
1. Utilizar el diseno o el cdigo como base para dibujar la graica de lujo correspondiente.
2. Determinar la complejidad ciclomatica de la graica de lujo resultante.
3. Determinar el conjunto basico de rutas linealmente independientes.
4. Preparar los casos de pruebas que orzaran la ejecucin de cada ruta en el conjunto basico.

Actividad:
Ln las paginas 42 - 429 del libro de texto se tiene la explicacin, mediante un ejercicio, de todos los pasos
descritos en el cuadro anterior. Ljecute y compruebe usted este ejercicio para conirmar la creacin del
conjunto basico.

Lxisten otras pruebas de estructuras de control dierentes a las pruebas de la ruta basica, que ayudan a
expandir la cobertura de las pruebas y mejoran la calidad de las mismas. La prueba de condicin es
uno de estos mtodos de diseno para casos de prueba que ejercitan las condiciones lgicas ,simples o
compuestas, a niel de cdigo en algn mdulo.
Otro tipo de prueba es la del flujo de datos la cual selecciona rutas de prueba en un programa de
acuerdo con las ubicaciones de las deiniciones y los usos de las ariables en el programa.
Por ltimo, se tienen las pruebas de bucle, que buscan recorrer y alidar la construccin de cada bucle
en un segmento del .oftrare. Dentro de este grupo de pruebas, se han deinido 4 clases de bucles:
simples, concatenados, anidados y los no estructurados.

160 160 160 160
Cada una de estas pruebas basadas en estructuras de control tiene todo un conjunto de reglas para
llear a cabo su implementacin. Sera importante que reise las paginas correspondientes del libro de
texto ,paginas de la 431 a la 433,, o que llee a cabo una inestigacin aparte para ampliar su
comprensin.
lasta este momento, todo ha girado en torno de las pruebas de caja blanca. Ahora se describiran a
ondo las pruebas de caja negra.
Las pruebas de caja negra consisten en la ealuacin de la interfaz del .oftrare. Se relacionan
directamente con la parte funcional del sistema, sin importar su constitucin interna.
Lstas pruebas complementan las de caja blanca, y permiten aumentar las probabilidades de descubrir
errores de los siguientes tipos:
De interaz.
Ln estructuras de datos o en acceso a bases de datos externas.
De comportamiento o de desempeno.
De inicializacin o de trmino.
lunciones incorrectas o altantes.

La ubicacin de este tipo de pruebas es hasta el inal ,una ez construido el .oftrare,, a dierencia de las
pruebas de caja blanca que se dan al inicio del proceso de pruebas.
Los metodos grficos de pruebas son un tipo de prueba de caja negra. Lstos mtodos permiten llear
a cabo pruebas de .oftrare a partir de la graicacin de objetos y relaciones. Lsto permite realizar una
serie de pruebas para ejercitar cada objeto y sus relaciones y, a partir de esto, descubrir errores.
Antes de ingresar en el area de pruebas, es importante comprender cuales son los objetos modelados y
cuales son las relaciones entre ellos.
De inicio, el ingeniero de .oftrare crea una graica en la cual incluye voao. ,objetos,, evtace. ,relaciones,, el
e.o ae voao a.ociaao ,propiedades de nodo, y el e.o ae evtace ,propiedades de enlace,. Al tener esto listo,
se idean una serie de pruebas que cubren la graica desarrollada para ejercitar los objetos ,y sus
relaciones, y que salgan a lote posibles errores.

Actividad:
Ln la pagina 435 del libro de texto se tiene la explicacin de la notacin graica mencionada mediante un
ejercicio. Ljecute y compruebe este ejercicio mentalmente o con ayuda de papel y lapiz. Lsto coniene para
entender cual es el alcance de este tipo de pruebas.

1ambin se tienen algunos mtodos de prueba de comportamiento que usan graicas, tales como:

161 161 161 161
Ll modelado del flujo de transaccin.
Ll modelado de estado finito.
Ll modelado del flujo de datos.
Ll modelado relacionado con el tiempo.

Siguiendo con el tema de cajas negras, el libro de texto menciona algunos mtodos de caja negra
importantes. Ll primer mtodo es el de particin equivalente.
Lste mtodo busca diidir el dominio de entrada de un programa en clases de datos a partir de las
cuales pueden deriarse casos de prueba. Con este mtodo se busca deinir un caso de prueba que
descubra cierta clase de errores, y as reducir el nmero total de casos de prueba que deben
desarrollarse.
Se menciona en el libro que la mayora de los errores se presentan normalmente en los lmites del
dominio de entrada y no en el centro del dominio. Ll anlisis de valores limite es una tcnica que
complementa la participacin equivalente y que permite atacar esta area del dominio al llear a una
seccin de casos de prueba los alores lmite deinidos. Ll analisis de valores limite extiende la
particin de la participacin equialente al concentrarse en los datos de las aristas de una clase.
Otra prueba de caja negra que el libro recomienda es la de la tabla ortogonal. Lsta tabla es til en los
casos donde se tienen problemas con dominio de entrada relatiamente pequeno, pero a la ez
demasiado grande para llear a cabo una prueba de tipo exhaustia.

Actividad:
Ln las paginas 434 - 440 del libro de texto ienen claramente explicados los dierentes mtodos de caja
negra descritos en parraos anteriores, as como el sustento matematico o cientico para cada mtodo.
Ademas, se agregan ejemplos que clariican los procesos. Lea estos pasos de implementacin con los
ejercicios dados para complementar la lectura de esta gua de estudio. Analice: ,qu utilidad tiene para usted
dicha inormacin, ,cmo la usara

Metodos de pruebas orientadas a objetos y a nivel de clase
Las pruebas de sistemas orientados a objetos ,OO, estan muy relacionadas con el tema de las clases y
la colaboracin entre ellas. Cuando ya se tiene el cdigo desarrollado, la prueba OO debe empezar por
lo pequeno, con una serie de pruebas disenadas para ejercitar las operaciones de clase y examinar si
existen errores a medida que una clase colabora con la otra.
Ademas, las pruebas OO se deben concentrar en secuencias apropiadas de operacin que permitan
ejercitar los estados de una clase especica.
Algunos atributos asociados a la OO, aunque uncionan excelentemente dentro del ambiente de
objetos, no acilitan las pruebas para este paradigma de desarrollo de sistemas. Ll encapsulamiento

162 162 162 162
por ejemplo, perjudica la realizacin de pruebas ya que diiculta obtener el estado concreto y abstracto
de un objeto.
Por otro lado, la herencia tambin iene a complicar las pruebas para la OO. Se debe recordar que
cada nueo contexto de uso requiere una nuea prueba, y esto aumenta cuando se usa la herencia entre
una superclase y las subclases deinidas.
Ln ambiente OO se tiene un tipo de prueba que esta basada en fallas, con el objetio de disenar
pruebas que tengan una alta probabilidad de descubrir posibles allas. Lste tipo de prueba tiene alidez
solo cuando el estudio del analisis y del diseno existente arroja pruebas de que al orzar la
implementacin del sistema, este dara allos que corregir.
Las pruebas de integracin en el ambiente OO, se encargan de buscar allas en llamadas a operacin
o en conexiones entre mensajes. Se han deinido tres tipos de allas dentro de este contexto:
Resultado inesperado.
Operacin incorrecta,mensaje empleado.
Inocacin incorrecta.

Ll eje de las pruebas de integracin tiene como in determinar si existen errores directamente en el
cdigo que llama, no en el cdigo que es llamado.
Ll libro de texto menciona la existencia de un enoque de pruebas que es basado en escenarios. Lste
tiene la particularidad de que su enoque esta en el usuario y no en el producto. Lste enoque descubre
errores de interaccin, al ser basado en los casos de uso asociados a los actores que casi siempre
ejecutan labores que inolucran interaccin entre arios subsistemas.
Ln el mundo de la OO, se deine como estructura de superficie a la parte obserable externamente
para dicho sistema. Ls importante denotar que la orma de probar estas estructuras es mediante
objetos bien deinidos por el encargado de pruebas, que permitan exponer dicha estructura y as
encontrar tareas omitidas.
Por otro lado, la estructura a fondo representa los detalles tcnicos de un programa OO, o sea, la
estructura que se comprende al examinar el diseno, el cdigo o ambos. La prueba asociada a esta
estructura esta deinida para ejercitar dependencias, comportamientos y mecanismos de comunicacin
que se han establecido como parte del modelo de objetos.

Metodos de pruebas aplicables al nivel de clase
Las clases estan compuestas por mtodos y atributos que permiten deinir tanto el estado de un objeto
,instancia de la clase, como tambin su comportamiento.
Ls importante entender que aunque an a existir mtodos condicionantes y que siempre existiran en
un orden establecido, se tienen otros mtodos que podran cambiar su orden de ejecucin.

163 163 163 163
Lsto acrecienta el problema de las pruebas, ya que hay muchas posibilidades de permutaciones entre
estas clases y no se pueden probar todas.
La tcnica de generar listas de ejecucin al azar de los posibles mtodos asociados a un caso
particular es una buena tcnica para darse cuenta de qu tan propensos son estos mtodos de presentar
allas a uturo.
1ambin la tcnica de particin al nivel de clase apoya la realizacin acelerada de pruebas. La idea
consiste en ordenar las clases de entrada y salida en categoras y se disenan casos de prueba para
ejercitarlas. Se tienen tres modalidades de particin:
La basada en estado.
La basada en atributos.
La basada en categorias.

La de estado acomoda las operaciones de las clases segn su capacidad para cambiar el estado de la
clase. Las de atributo se encargan de ordenar las operaciones segn el niel de aectacin a los atributos
que utilizan, y la de categora acomoda las operaciones de las clases segn su uncin genrica.

Diseo de casos de pruebas de interclase
La relacin interclase se presenta con uerza cuando se esta en la etapa de integracin de un sistema
que esta orientado a objetos. Lxisten algunos pasos que sugiere el libro de texto para llear a cabo los
casos de prueba aleatorios para las clases mltiples.

vortavte:
Secuencia de pasos para generar casos de prueba aleatorios para las clases mltiples:
1. Ln cada clase cliente use una lista de operaciones de clase para generar una secuencia de pruebas
aleatorias.
2. Ln cada mensaje generado determine la clase colaboradora y la operacin correspondiente en el
objeto servidor.
3. Ln cada operacin del objeto servidor determine los mensajes que transmite.
4. Ln cada uno de los mensajes determine el siguiente nivel de operaciones inocadas e incorprelos en
la secuencia de prueba.

Ll enoque de clases mltiples es muy similar al de clases indiiduales. Se inicia con la segregacin de
una clase importante, pero se da una expansin de la misma hasta alcanzar a las demas clases mediante
la mensajera que comparten entre s.
Ll diagrama de estado de una clase proporciona al encargado de pruebas un modelo de
comportamiento dinamico de la clase y de las clases que colaboran con ella. La idea de estas pruebas
asociadas al comportamiento es cubrir todos los estados permisibles, tomando en cuenta las clases

164 164 164 164
que se ean inolucradas y asignar as tantos diagramas de estado como sea necesario para cubrir dicho
comportamiento.

Pruebas de entornos especializados: arquitecturas y aplicaciones
1odo lo relacionado con el tema de las pruebas estudiado hasta el momento puede ser asociado con
casi cualquier sistema en dierentes entornos y arquitecturas. Pero existen algunos casos en donde tanto
los entornos como las arquitecturas, tienen una concepcin dierente a lo tradicional.
Lsto requiere que se d un enoque especializado en las pruebas, de manera que permita que cada uno
de estos casos se tome como casos aislados, y por lo tanto su tratamiento sea dierente. 1al es el caso
de las interaces graicas de usuario, de arquitecturas tipo cliente,seridor, la documentacin y las
unciones de ayuda y, por ltimo las pruebas de tiempo real.

Actividad:
Ln las paginas 452 - 456 del libro de texto se explica puntualmente estas situaciones especiales para ciertos
entornos y arquitecturas. Lea estas descripciones para complementar la lectura de esta gua de estudio.
Lxponga sus conclusiones en un pequeno ensayo del tema de entornos especializados.

165 165 165 165

Ln la pagina 459 del libro de texto encontrara algunos problemas y puntos por considerar acerca del

66. Indique por lo menos 3 ejemplos en los cuales la prueba de caja negra da la
impresin de que todo esta bien`, mientras que las pruebas de caja blanca
indican al menos un error. Llee a cabo el ejercicio tambin pero ahora de
manera inersa entre la prueba de caja blanca y caja negra.
6. Seleccione un componente de .oftrare que se haya disenado recientemente y
aplquele un conjunto de casos de prueba para asegurar que todas las
instrucciones se hayan ejecutado con la prueba de la ruta basica.
68. Ln palabras propias, describa dentro de un sistema orientado a objetos ,por qu
la clase es la mejor unidad razonable para la prueba
69. ,La prueba exhaustia para los sistemas pequenos garantiza que el programa es
totalmente correcto
0. ,Por qu se tiene que oler a probar subclases que crean instancias a partir de
clases existentes si esta ya se ha probado por completo, ,es posible usar los
casos de prueba disenados para la clase existente

166 166 166 166

Referencias

Bruegge, B., Dutoit, A. ,2002,. Ingeniera de .oftrare orientado a objetos. Mxico D.l.: Prentice lall.

Larman, C. ,2003,. UML y Patrones. Segunda edicin. Madrid: Prentice lall.

Sommerille, I. ,2002,. Ingeniera de .oftrare. Sexta edicin. Mxico D.l.: Addison \esley.

167 167 167 167
Glosario de trminos

Arista: es, en geometra, el segmento de recta que se orma por la interseccin de dos planos. 1ambin
se conoce con este nombre al segmento comn que tienen dos caras ecinas de un poliedro.
Coloquialmente, se dice que las aristas de un problema son los bordes que hay que limar para
solucionarlo.

C++: es un lenguaje de programacin disenado a mediados de los anos 1980 por ;arve trov.trv. Con
l se busca extender el lenguaje de programacin C con mecanismos que permitan la
manipulacin de objetos. Ll C-- es un lenguaje hbrido, ademas, en este lenguaje se suman dos
paradigmas: la programacin estructurada y la orientada a objetos, por esto se suele decir que el
C-- es un lenguaje multiparadigma. Actualmente existe un estandar, denominado ISO C--, al
que se han adherido la mayora de los abricantes de compiladores mas modernos.

Java: es un lenguaje de programacin orientado a objetos desarrollado por vv Micro.,.tev. a principios
de los anos 90. Jaa toma parte de su sintaxis de los lenguajes C y C--, pero su modelo de
objetos es mas simple y elimina herramientas de bajo niel, que suelen inducir a muchos errores,
como la manipulacin directa de punteros o memoria.

Nodo: punto de interseccin o unin de arios elementos que conluyen en el mismo lugar. Por
ejemplo en una red de ordenadores cada una de las maquinas es un nodo, y si la red es Internet,
cada seridor constituye tambin un nodo.

Orientacin a objetos ,OO,: es el conjunto de disciplinas que desarrollan y modelan .oftrare para
acilitar la construccin de sistemas complejos a partir de componentes.

Patrn de diseo ,ae.igv atterv., en ingls,: es una solucin a un problema de diseno. Ademas, son la
base para la bsqueda de soluciones a problemas comunes en el desarrollo de .oftrare y otros
ambitos reerentes al diseno de interaccin o interaces. Para que una solucin sea considerada
un patrn debe haber comprobado su eectiidad resoliendo problemas similares en ocasiones
anteriores y ser reusable, lo que signiica que es aplicable a dierentes problemas de diseno en
distintas circunstancias.

168 168 168 168
Enlaces electrnicos relacionados con el tema

CAP1ULO ASPLC1O PGINA
12 Pagina que trata sobre diseno de
interaces
http:,,www.useit.com,
12 Pagina sobre patrones de diseno
de interaces de usuario
http:,,www.hcipatterns.org,tiki-index.php
13 Pagina sobre recursos tiles para
pruebas de .oftrare
http:,,rank.mtsu.edu,~storm,
13 Otra pagina sobre recursos
tiles para pruebas de .oftrare
http:,,www.sqatesters.com,
13 Nuea pagina sobre recursos
para pruebas
http:,,www.io.com,~wazmo,qa,
14 Pagina que habla sobre la
caracterizacin de la prueba de
.oftrare
http:,,www.e-quallity.com.mx,articulos,SG-
200505-Luis05.pd
14 Pagina sobre la prueba de
.oftrare de caja negra y caja
blanca
http:,,lsi.ugr.es,~ig1,docis,pruso.pd

GE0827 Análisis de Sistemas I - 2009 - Informática

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GE0827 Análisis de Sistemas I - 2009 - Informática

Uploaded by

Copyright:

Available Formats

UNIVLRSIDAD LS1A1AL A DIS1ANCIA

You might also like