Upload
patricio-juarez-1270
View
582
Download
0
Embed Size (px)
Citation preview
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 1/29
I I I
L A PRACTICA:
UNA VISION GENERICA
En un Iibro que explora las vidas y los pensamlentos de los mgenieros de
software, Ellen Ullman [ULL97)representa un fragmento de vida al relatar
los pensamientos de un practicante bajo presion-
No te ng o id ea d e q ue h ora e s, NOh ay v en ta na s e n e sta o fld na , ta mp oc o re lo ], 5 61 0e l
LED parpadean te en rojo de u n h om o d e m ic ro on da s, e l cual parpadea 12:00, 12:00,
12:00, 12:00. Joel y yo hemos e st ad o p ro gr ama nd o p or cUas .T en emo s un "b icho", e l
n ec to d em on io d e u n e rro r. P or e so la p uls ac io n r oja sin t ie rn po s e s ie nt e b ie n, c omo
un a lectu ra de n uestro s cereb ro s, los c uale s se h an sincro nizado de a lg una m anera
a la mtsma ve loddad del p a rp adeo . ..
lE n que estamos t raba jando? . .. Los d eta lle s s e m e e sc ap an a ho ra . Podr lamo s e st ar
a yu da nd o a g en te p ob re y e nfe rm a 0a ju st an do u na s er ie d e r ut in as d e b aj o n iv el p ar a
verificar b it s e n un protocolo de una base de datos d is tr ib ul da , n o me imp or ta . M e d e-
berta importer: en otra parte de m i s er =-mas tarde, q uiz a c ua nd o s alg am os d e e ste -
cuarto lleno de com putadoras- m e lm portara m ucho por que, para quien y con que
prop6sito estoy escribiendo softw are. Pero ahora no. H e pasado a traves de una
m em bran a con de el m und o rea l y SU S 1JSOS1 8 n o im po rta n. S oy un i ng en ie ro d e so ft -
wa re . . ,
Sin duda, una imagen oscura de la practica de la ingenieria del software, pero
con la que, despues de reflexionar, muchos de los lectores de este Iibro seran
capaces de identiflcarse,
CONCEPTOS
CLAVE
pmdpi e s w .
.1 ,,1is . . .11 7
......... 12 6
....••• 119
.. ....w.Ici
G g I . . . . . . 1 2 1
1 0 c o c I f I a I c I6 I l 2 3
. . . . . . . . . .dia . .. .. .. 1 0 9
Ia.......d e l s e f t w w e 10 7
" , . . . . . . 1 1 3Ia."..... .124
preg t l l f as
V A IH . . . . . . .lIS
r e s o I u c i 6 I t d.
".w...•.... 106
104
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 2/29
CAPitULO 5 LA PRACTICA: UNA VISI6N GENERICA 105
Las personas que crean software de computadora practican el arte, la maestria 0
la disciplina' Hamada ingenieria del software. Pero, ,que es la "practica" de la inge-
nieria del software? En un sentido generico, la practica es una colecci6n de concep-
tos, principios, metodos y herramientas a las que un ingeniero de software recurre a
diario. La practica permite a los gerentes coordinar proyectos de software e ingenie-
ros de la especiaJidad para construir programas de computadora. La practica multi-
plica un modele de proceso de software con los c6mos tecnicos y de gesti6n nece-
sarios para realizar el trabajo. La practica transforma un enfoque fortuito en algo
mas organizado, mas efectivo y con mas probabilidades de alcanzar el exito.
En el capitulo 2 se introdujo un modelo de proceso de software gene rico compues-
to de una serie de actividades que establecen un marco de trabajo para la practica
de la ingenieria del software. Las actividades genericas del marco de traba]o -comu-
nicaci6n, planeaci6n, modelado, construcci6n y despliegue- y las actividades som-
brilla establecen la arquitectura de una esqueleto para el trabajo de ingenieria del
software. Todos los model os de proceso de software presentados en los capitulos 3
y 4 pueden organizarse en este esqueleto arquitectonico. ~Pero que cabida tiene ahi
la practica de la i ng e ni er ia d e J s o jlwar e? En las secciones siguientes se consideraran
los conceptos y principios genericos que se aplican a las actividades del marco de
trabajo.?
Algunos escrilores utilizan uno de estos terminos y excluyen los OtIOS.En realidad, la ingenieria del
software eslas tres cosas a la vez.
2 Seexhorta al lector para que revise las secciones relevantes dentro de este capitulo, conforme se
discutan 105metodos especificos de la ingenieria del software y las actividades sombrilla en los ca-
pitulos posteriores del libro.
1 1 11 1 I 1 1 1
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 3/29
106
f r O N S I J O S .5 e p o d ri o o r g u m e n ta rq u e e l e n fo q u e d e
P o l y a c o n s i s t e e ns im p le s en ti d o c o m u n .
E s v e r da d . P e ro e ss o r p r e n d e n t e 1 0
f re c u en c io c o n 1 0 q u e
e l s en ti d o c om u n n oe s c o m u n e n e l
m u n d o d e l s o f tw a r e .
l ' l l l i l l l l l l l l l l l l l l l l m l l l m l ~
P A RT E D OS P AA cn CA D E L A IN GE NIE RlA D EL S OF IW A RE
5.1.1 La esencia de 1apract1ca
En un libro clasico, H ow to S olve It,escrito antes de que existieran las computadoras
modernas, George Polya [POL45] puntualiz6 la esencia de la resoluci6n de proble-
mas y, en consecuencia, la esencia de la practica de la ingenieria del software:
I. E nte nd er e l pro blema (comunicaci6n y anallsis).
2. r lanear una so luc ion (modelado y disefio de software).
3. llevar a cabo el plan (generaci6n de c6digo).
4. E xam inar el r esu ltado pa ra p robar Ia p recis ion (realizacion de pruebas y asegu-
ramiento de la cal idad).
En el contexte de la ingenieria del software estos pasos de sentido cornun conducena una sene de preguntas esenciales [adaptadas de POL45j:
Entender el problema.
• ,iA q uie n Ie in t er es a l a s olu cio n d el p ro blema? Es dec ir , (_quienesson los clientes?
• , !,Cua lesaspec tos se desconocen? (_Quedatos, funciones, caracteristicas y
comportamientos se requieren para resolver de manera apropiada el
problema?
• dEl p ro blema puede d iv id ir se e n c ate go rfa s? (_Esposible representar problemas
menores que puedan entenderse con mayor facilidad?
• d El pro blema p ue de reptesentatse de maner a g ra fic a? (_Sepuede crear un
modele de analisis?
Planear la solucion,
• .!S e ha bia n v is to p ro blemas s im ila re s a nte s? (_Existenpatrones reconocibles en
una soluci6n potencial? (_Hayun software existente que implemente los datos,
las funciones, las caracteristicas y los comportamientos que se requieren?
• ,;,S eh a r es ue ito u n p ro blema s im ila r? Si es ast, (_Ioselementos de la soluci6n
pueden reutilizarse?
• , ;,Sepueden de fin lr lo s subp rob lemas? Si es asi, tlas soluciones para los subpro-
blemas parecen faciles?
• dSepuede re pre se nta r u na s oiu cio n de mod o q ue c on du zc a a u na im pleme nta -
c ion e fec ti va? tSe puede crear un modelo de disefio?
Llevar a cabo el plan.
• ,;,L asolucioti ma rc ha c on fo rme a l p la n? tEl c6digo Fuente se puede seguir
con forme al modele de disefio?
• d Es p ro ba ble q ue c ad a p arte d e la s olu ci6 n d el c om po ne nte s ea cotrectar (_Seha
revisado el disefio y el c6digo, 0mejor aun, se han aplicado al algoritmo
pruebas de correcci6n?
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 4/29
CAPiTuLo 5 LA PAACTICA. UNA VISIONGENERICA 107
Exarninar el resuItado .
• ( _ E s p os ib le p ro ba r c ad a p ar te d e la s olu cio n d el c om po ne nte r l_Seha implemen-
tado una estrategia de prueba razonable?
• .ias o lu ci on p ro d uc e r es ul ta d o s a c or d es con l os d a to s, fu n ci on e s, r a sg o s y
comportamlentos que se requiercnr l_Elsoftware ha sido validado contra todos
los requisitos de los clientes?
"r..... d e c a d a p r ob le m a e x is le u n g r a n a d e d e sr ub r i m ie n to . ·
5.1.2 Principlos esenciales
EIdiccionario define la palabra principio como "una ley 0 supuesto importante quese requiere en un sistema de pensarniento". A traves de este libro se examinan prin-
cipios en muchos grados diferentes de abstraccion. Algunos se enfocan en la inge-
nieria del software como un todo, otros consideran una actividad generica y especi-
fica del marco de trabajo (por ejernplo, comunicaci6n con el c lie n te ), Y otros se cen-
tran en acciones de la ingenieria del software (como disefio arquitectonico) 0 tareas
tecnicas (escribir un escenario de usa). Sin importar que tan espedficos son, los
principios ayudan a establecer un conjunto solido de pracrica de ingenieria del soft-
ware. Par esa razon son importantes.
David Hooker [H0096) ha propuesto siete principios esenciales, los cuales se
enfocan en la practica de la ingenieria del software como un todo, que se reprodu-
een enseguida.'
EIprimer principio: la razon por la que todo existe
Un sistema de software existe por una razon: p ar a o jr ec er un va lo r a s us u su ario s.
Todas las decisiones deben tomarse con esto en mente. Antes de especificar un
requisito de un sistema, antes de sefialar una pieza de funcionalidad del Sistema,
antes de determinar las plataformas del hardware 0 los procesos de desarrollo, uno
debe haeerse preguntas como: l_esto agrega un valor real al sistema? Si la respuesta
es negativa no se debe hacer. Todos los d ema s p rt nc lp lo s e sta n apoyados en este.
El segundo principio: MS (mantenerlo simple)
EI disefio de software no es un proceso fortuito. Existen muchos factores que deben
considerarse en cualquier esfuerzo de diseno. T o do e l d is ei io d e be set ta n s im ple c om o
s ea p o si bl e, p er o no ma s s im p le . Esto facilita un sistema de mas facil comprensi6n yentendimiento. Esto no quiere decir que las caracteristicas, hasta las internas, deban
descartarse en nombre de la s imp lic id ad. Aderna s , los disefios mas elegantes por 10
general son los mas simples. Simple tampoco significa "rapido y malo". De heche, se
3 Reproducido con permiso del autor [H(X)961. Hooker def ine patrones para estos pr incip ios en:
http://c2.com/cgi/wilci?5evenPrinciplesOfSoftwareDevelopment.
, 1 1 1 1
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 5/29
108
&~
'"~C~VE
S i e l s o f iw o r e t i e n e u nv a l o r . o , t g c o m b i o r o 0
1 0 l o rg o d e s u v i d o U t i l .
P o r e s o r a z o n , e ls o ftw a r e d e be
c o ns t r u s s e d e f o r m o
q u e s e I e p u e d o d o r
m o n t e n i m i e n t o .
PARTE DO S pRAcnCA DE LA INGENIERlA DEL SOFTWARE
requiere de mucha reflexion y trabajo sobre multiples iteraciones para simpli ficar. EI
resultado buscado es un software que se mantenga y sea menos propenso al error.
"&ill der II ~ 1 1 1 1 0 s i m p I i c i d a d , I a c u a I e sh i m u y p o r e n c i m a d e II~ .
A I D " , .
El tercer principio: mantener la vision
Una v is io n c la ra es e se nc ia l p ar a e l e xito d e u n p ro ye cto d e s oftw a re . Sin la vision clara
el proyecto podria terminar con "dos [0 mas] significados" en uno. Sin una integri-
dad conceptual un sistema amenaza con tomarse en una masa confusa de disefios
incompatibles, unida por un tipo inadecuado de tomillos ...
Arriesgar la vision arquitectonica de un sistema de software debilita y al final
rompe hasta un sistema bien disefiado. Tener a un arquitecto capaz de mantener la
vision y reforzar 10 acordado ayuda al aseguramiento de que un proyecto de soft-
ware sea exitoso.
El cuarto principio: 10 que uno produzca, otros 10 consumiran
En muy pocas ocasiones un sistema de software con fuerza industrial se construye
y utlliza de manera aislada. De alguna u otra forma, alguien mas utilizara, manten-
dra, documentara 0 dependera de su capacidad de entender el sistema. Por 10 tanto,
siernpre debe especificarse. diseiiarse e implementarse con la idea de que alguien
mas tendra que entender 10 que se realice. La audiencia de cualquier producto de
software es potencialmente grande, por 10 que se debe especificar tomando en cuen-
ta a los usuaries. Se debe disefiar teniendo en mente a quienes 10 implernenten, asicomo codificar considerando a aquellos que deben mantener y extender el sistema.
Tal vez alguien tenga que depurar el codigo escrito y eso 10 convertira en un usua-
rio del codigo. EI hecho de facilitar el trabajo a otro agrega valor al sistema.
El quinto principio: estar abierto aJ futuro
Un sistema con una larga vida tiene mas valor. En los ambientes computacionales
de la actualidad, en los que las especificaciones cambian a cada momento y las pla-
taformas de hardware son obsoletas despues de algunos meses, la vida del softwa-
re se mide, de modo tipieo, en meses en lugar de afios. No obstante, los verdaderos
sistemas de software "con fuerza industrial" deben durar mas tiempo. Estos sistemas
tendran exito si estan listos para adaptarse a estes y otros cambios. Los sistemas que
logran el exito son aquellos que han sido disefiados de esta manera desde el princi-
pio. Nunca se d eb e d ise iia r p ar a lle ga r a u na e sq uin a. Uno siempre se debe preguntar:
".!.que tal si?", y prepararse para todas las respuestas posibles, al crear sistemas que
resuelvan el problema general, no un problema especifico." Es muy probable que
esto conduzca a la reutilizacion de un sistema entero.
4 Nota del autor: esta recomendaci6n puede ser peligrosa si selIeva hasta el extremo. EIdisei\o para
el "problema general" algunas veces requiere compromisos de desempei\o y puede implicar un ma-
yor estuerzo para el proyecto.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 6/29
CAPiTuLo 5 LA pRAcnCA: UNA VISI6N GENERICA 109
E l sexto princtpio: planear para la reutilizacion
La reutil izaci6n ahorra tiempo y esfuerzo." A J alcanzar un alto grado de reutil izaci6n
se logra una de las metas mas dificiles en el desarrollo de un sistema de software.
La reutilizaci6n de c6digo y disefios ha sido proclamada como un beneficio impor-
tante del uso de tecnologias orientadas a objetos. Sin embargo, la recuperaci6n de
la inversion no es automatica. Las posibilidades de reutilizaci6n que proporciona la
programaci6n orientada a objetos (0 convencional) se podran considerar si se tiene
una vision a futuro y una planeaci6n. Existen muchas tecnicas para Ilevar a cabo la
reutilizaci6n en cada etapa del proceso de desarrollo del sistema; las relativas al
disefio detallado y al nivel de c6digo son muy conocidas y estan bien documentadas.
La nueva bibliografia se EStelenfocando en la reutilizaci6n del disefio en la forma de
patrones de software. Sin embargo, esto es 5610una parte de la batalla.
La comunicaci6n de oportunidades para la reutilizaci6n a otros integrantes de la
organizaci6n es primordial. ;.C6mo se puede reutilizar algo cuya existencia se ignora?
La p ta ne acion a de la nta da pa ra fa re utiliza cion re du ce eJ costo e increm enta ef valor de los
componen te s r eu ti Ji zab le s y lo s sistemas e n q ue d ic ho s c om po ne nte s se in co rp ora n.
E l septimo princtpio: pensar
Este ultimo principio tal vez sea el que mas se pasa por alto. Ca si siempr e, c ua nd o se
tien e un p en sa mie nto c la ro y c omp ie to a nt es de la a cc io n, s e ptoducen los t ne jo r es r esul -
tados. Cuando se reflexiona acerca de algo existe una mayor probabilidad de hacer-
10bien. Siempre se obtiene conocimiento de la manera de hacerlo bien de nuevo. Si
se piensa en algo y aun asi se hace mal, esto se convierte en una experiencia valio-
sa. Un efecto colateral del pensamiento es aprender a reconocer. cuanoo atgutcn no
sabe algo, en que punto se puede investigar la respuesta. Cuando el pensamiento
claro se ha introducido en el sistema es cuando surge su valor real. La aplicacion de
los primeros seis principios requiere una reflexlon intensa, por 10que las rccornpcn-
sas potenciales son enormes.
5i todos los ingenieros de software y todos los equipos de desarrollo tan s610
siguieran los siete principios de Hooker, muchas de las dificultades que se han expe-
rimentado durante la construcci6n de sistemas complejos basados en computadora
se podrian eliminar.
Antes de que los requisitos del cl iente puedan analizarse, modelarse 0especificarse,
estes deben recopilarse por medio de una actividad de comunicacion (tambien lla-mada obtencion de requ isi toss . Un cliente tiene un problema que se puede ajustar a
5 Nota de l autor. aunque esto es c ie r to pa ra quienes reutilizan el so ftwa re en p royec tos futures, Jareu-
t il izaci6n puede resultar cara para quienes deben diseiiar y construir componentes reutilizables. Al-
gunos estudios indican que el disefio y la construcci6n de componentes reuti lizables pueden costar
entre 25 y 200 por ciento mas que el software solicitado. En algunos casos. la diferencia de costo no
se puede justificar.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 7/29
110
~ONIUO_
A n te s d e c O ff l u n ic o r s e
d e b e e s lr Jr s e g u ra d e
e m e n d e r e l p u n lr J d e
v i s t a d e 1 0 a f r o p a r t e ,s o b e r u n p o c o d e s u sn e c e s i d o d e s , Y
e n l o n c e s o p i n o r .
I 'U ~;IIW II If!DI _ •
PARTE DOS PRACTICADELA INGENIERiADEl.SOFIWARE
una soluci6n basad a en computadora. Un desarroUador responde a la solicitud
ayuda del cJiente. La comunicaci6n ha comenzado. Pero el camino desde la com
nicaci6n hasta el entendimiento suele estar Ueno de baches.
La comunicaci6n efectiva (entre pares tecnicos, con el cliente u otros participan
del software y con los gerentes de proyecto) esta entre las actividades mas desaflarv
que enfrenta un ingeniero de software. En este contexto se examinan los principi
conceptos de comunicad6n de acuerdo con la manera en que se aplican en la co
nicaci6n con el cliente. Sin embargo, muchos de los principios se aplican del
modo a las fonnas de comunicacion que ocurren dentro de un proyecto de software.
Principio # 1: Escuchar. Se debe centrar la atencion en las palabras de
habla, en vez de fonnular la respuesta a dichas palabras. Es necesario pedir -
explicacion si alga no esta claro, pero deben evitarse las interrupciones constantNunca se debe ser conflictivo con palabras 0 actitudes (por ejemplo, dirigir la mi::
da a los lados 0 sacudir la cabeza) cuando una persona habla.
Principio #2: Prepararse antes de comunicar. Se debe invertir algun tiem
en entender el problema antes de reunirse con otros. Si es necesario, se puede r
lizar una mvesngac ion para entender eJ negocio y dominar la jerga. Si se tiene la r
ponsabilidad de conducir la reunion, es recomendable preparar una agenda del
antes de la junta.
Principio #3: Alguien debe facilitar la actividad, Cualquier reuni6n de com
nicaci6n debe tener un Ifder 0mediador I) para mantener una conversaci6n ct:-
mica y en una direcci6n productiva; 2) para medlar en cualquier conflicto que
rra: 3) para asegurar que se sigan los otros principios.Principio #4: La comunicacion cara a cara es 10mejor. Pero, por 10genera
funciona mejor cuando esta presente otra representacion de la informacion reievan-
teoPor ejemplo, un participante podria crear un esquema 0un documento que sirva
como foco de la discusion.
Principio #5: Tomar notas y documentar las decisiones. Las cosas suelen
caer en malentendidos. Alguien que participe en la comunicacion debe servir como
"grabadora" y escribir todos los puntos y decisiones importantes.
Principio #6: Buscar la coiaboracion. La colaboracion y el consenso se pre-
sentan cuando el conocimiento colectivo de los miembros del equipo se combina
para describir las funciones 0caracteristicas del producto 0sistema. Cada pequefia
colaboraci6n sirve para construir confianza entre los miembros del equipo y crear
una meta comun para dicho equipo.
Principio #7: Conservar el enfoque, examinar un modulo a la vez. Entre
mas gente este implicada en una comurucacion, mas posibilidades existen de que la
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 8/29
CAPiTuLo 5 LA PRfi.cnCA: UNAVISlONGENtRiCA 111
discusion salte de un topico al siguiente. EImediador debe mantener la conversacioncentrada en un modulo sin dejar un tema hasta que este haya side resuelto (sin
embargo, vease el principia #9).
proporciona los requisitos b6sicos del producto; 4)
coord ino los recursos econ6micos para el proyeclo. En un
negocio de produclos 0sistemas, con frecuencia el cliente
as el depar tamento de mercodolecnia. En un ambiente de
T 1 e I diente puede ser un componente 0departamento del
negocio.
Un usuorio final as lo persona 0grupa que: 1) en reolidad
usara el software que se construye para alcanzar a lgunpropOsito de negocios, y 2) de~nir6 los detalles operativos
de l software de formo que el propOsito del negocio pueda
alcanzarse.
La diferencia entre clientes y usuarios finales
Los ingenieros de software se comunican con
muchos participantes diferentes, pero los clientes
nos ~nales tienen el impacto mas signi~cativo
, Irobojo tecnico que sigue. En algunos casos el
yel usuorio son uno mismo, pero en muchos
"'-::":lDS e I diente y el usuario ~nal so n personas
_~'II!S. que trabojan para diferen tes administradores en
organizaciones de negocios.es I e persona 0 grupa que: 1) en un inicio
software que se vo a construir; 2) de~ne los
generales de negocios para e l software; 3)
Principio #8: 5i algo no esta claro, se bace un dibujo. La comunicaci6n ver-
bal solo lIega hasta cierto punta. Can frecuencia un esquema 0figura puede propor-
cionar daridad cuando las palabras fallan al realizar su trabajo.
Principio #9: a) Una vez que se llega a un acuerdo sobre algo, se debe (;on-
tinuar; b) si no se puede lIegar a un acuerdo, se debe continuer; C) 51una
caracteristica 0uncion no esta clarayno se puede clarificar en el momento,
se debe continuar. La comunicacion. como cualquier actividad de ingenieria del
software, requiere de tiempo. En lugar de que se itere sin fin, 105particlpantes dcben
reconocer que hay muchos t6picos que requieren analisis (vease el principia #2) y
que "continuar" algunas veces es la mejor forma agilitar la comunicaci6n.
Principio # 10: La negociacibn no es un concurso 0un juego. Fundona
mejor cuando ambos partes ganan. En muchas ocasionea los ingcnicros de soft
ware y el cliente deben negociar funciones y caractertsttcas, pnoncaoes y r c c n a s de
entrega. Si el equipo ha colaborado de buena forma. todas las partes tienen una meta
comun, Por 10 tanto, la negociaci6n demandara el comprornieo de todas las panee.
II.... MII io: Lugar de trobojo
de ingenierio del software.
•• _..: Jamie lazar, miembro del equipa de
VtnOd Raman, miembro del equipa de
Ed Robbins, miembro de l equipa de software.
UI conver_iOn:
Ed: iQue han oklo ocerco de esIe proyecto de
HogorSeguro?
Vinod: La reuniOn de inicio esI6 programOda para Ia
proximo semana.
I I~
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 9/29
112 PARTE DOS pRAcnCA DE LA I N G E N I E R i A DELSOFTWARE
hogom05 alga de tarwa en.. cnIUIIII"p~
de 1 0 reuni6n de inicio. Doug dijo qu eM co Ia bo r6 ra mo s" c on nuestro c I i e n i a ,
que o p r e n d o m o s c6mo hcado..
Eel: P r o b a b I e m e n t e serio mejor
oficino. L a s l lamodos I e I e l 6 n i c a S
tipo de osuna.
Jamie: Ambos est6n en 1 0 Q;IJl~ .......
juntos a nues I roJ primeraa cor_licado!
Vinod: Vi que Doug Ieia un _ .._~
requisiaw• P o d r i o opos tar
principios para 1 0 b u e n a con__ •
prestado mai\ano.
Jamie: Bueno idea ........
Vinod (sonrieIldo): 5 1 , c l a r o .
Conjunto de tareas genericas para la comunicacion
1 . I de n li fi co r 0 1 d ie nte p rim o r io y o lr os• Solidos y en tr a da s re su l ta n te s .
po r li ci pont e s ( s ec c i6n 7.3.1).
2 . R eu nir se c on e l c li en ie p ri mo r io p ar a
la s " pr eg un ta s li br es d e c on te xt e" ( se cc i6 n 7 .3 .4 ), la s
c uo le s de fi nen :
• las n ecesid ad es y v a la re s d e l n e go ci o.
• l os c ar ac te ris ti ca s y n ec es id a de s d e l u s ua ri o f in al .
• las so lid os v isibles q ue se hay an req uerid o p ara
e l u suar io .
• la s r es tricc io nes d el n eg ocio .
3 . D eso rro llar u n en unciada escrito d e u na p 6g in a
s ob re e l a m bito d el p ro yec io , e l c u al e st6 su je to a
revision.
4 . R ev is or e l en un cia do d el a mb ito co n lo s in te re sad os
e n e l s oftw are y a ju sto rlo s eg un 1 0 requerido.
5 . C olab orar can el ciien te y el u su ario final p oradefinir:
• E scen arias d e u so v isib les p oro el clien te co n el
u sa d e l F o rma to e stOnd a r6 ( se cc i6 n 7.5).
• C ar ac le ri st ic as , f un cio ne s y c om p or tom ie nt os
impo rl an te s d el s o ftwar e.
• R ies go s d e n eg oc io s d efin id os p ar e l ciie nte
l s ec c i6n 25 .3 ) .
6 . D es orr ollar u na b re ve d esc rip ci6 n e sc r ita (p ar
e je m pl o, u no s er ie de l is to s ) de e scenar i os ,
s o li do s /e nt ra d as , c ar ac le rl st ic as /f u nc io n es y r ie sg o s.
7. lleror con e I d ie nte p or a r ef in er lo s e sc en ar io s,
sol idos /ent radas , ca raderi s ticas/ funcianes y riesgos.
8 . A sig nar p riarid ad es d efin id as p or el ciien te a co da
e sc en a ri o d el u s ua ri o, c ar ac te ri st ic a, f u nc i6 n y
c ompo r lam ie n to ( se cc i6 n 7 .4 .2 ) .
9 . Revisor toda la in fo rm a cio n r ec op il ad a d ur an te l a
a ct iv id ad d e c om u nic ac i6 n c on e l d ie nt e y otros
porlicipontes, y aju sto rla d e la fo rm a q ue se
requiera.
10 . P r ep o ra rs e p o ra 10 a ct iv id a d d e ploneccien
( c ap i tu l as 23 y 24).
6 Los formatos para escenar ios de uso se discuten en el capitulo 8.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 10/29
CAP iT uLo 5 LA pRAcnCA UNA V1S16N GENER ICA 113
La actividad de comunicaci6n ayuda al equipo de software a definir sus metas y obje-
tivos generales (por supuesto, sujeto al cambio con forme pasa el tiernpo). Sin
embargo, entender estas metas y objetivos no es 10mismo que defmir un plan para
llegar a ellos. La actividad de pianeacion abarca un conjunto de practicas tecnicas y
de gesti6n que permiten al equipo de software definir un mapa del camino mientras
se viaja a traves de su meta estrategica y objetivos tacticos.
"& I I . .. .. . a d 6 n l*llia b a t a l o s i e m p r e h e e n c o n f r o o o q u e l o s p la n es s on i n U t i I e s , p er o q u e I I I p Ia M G d 6 a 1$
" ' , I O . M e . -D w f I I d D. Is.........
Existen muchos enfoques diferentes para la planeaci6n. Algunas personas son
"minimalistas", y argumentan que el cambio con frecuencia obvia la necesidad de un
plan detallado. Otros son tradicionalistas, y dicen que el plan proporciona un mapa
efectivo del camino, y mientras mas detal lado sea este, men or probabi lidad habra de
que el equipo pierda el rumbo. Ademas, otros son "agilistas" y ergumentan que tal
vez un "juego de planeaci6n" rapido sea necesano. pero que el mapa del camino sur-
gira cuando comience el "trabajo real" sobre el software.
<-Quehacer? En muchos proyectos la sobreplaneaci6n consume tiempo y n o p ro -
duce frutos (dernasiadas cosas cambian), pero la planeaci6n insuficiente es una
receta para el caos. Como la mayoria de las casas en la vida, la planeacton se debe
producir can moderaci6n, 10 suficiente para proporcionar una guia utH para el equi-
po -no mas, no menos.
Sin importar el rigor con el que se conduzca la planeaci6n, los siguientes princi-
pios son validos en todo momento.
Principio # 1: Entender los alcances del proyecto. Es imposible utilizar un
mapa de carreteras si no se sabe el sitio a donde se quiere ir. EI hecho de enterider
los alcances proporciona al equipo de software un destino.
Principio #2: lnvo/ucrar al cliente en la activiaaa de ptaneacum. EI cnerue
define prioridades y establece las restricciones del proyecto. EI ajuste de estas reali-
dades a menudo requiere que los ingenieros de software negocien las 6rdenes de
entrega, los limites de tiempo y otros asuntos relacionados con el proyecto.
Principio #3: Reconocer que la planeacitm es itcrativa. EI plan de un pro-
yecto nunca se graba en una piedra. En cuanto comience el trabajo es rnuy probable
que las casas cambien. En consecuencia, debe ajustarse el plan para adaplarlo a los
cambios. Ademas, los rnodelos iterativos e mcrementaies del p ro ceso rn cran la r e o i a -
neaci6n (despues de la entrega de cada incremento de software) basada en la retroa-
limentaci6n recibida de los usuarios.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 11/29
114
E I t 6 r m i n o g r o n u lo r id a ds e r e f i e r e 0 1 d e l o l l e ( o ne l Q u e a lg u no s
e le m e nt os d e 1 0
p l on e o c i6 n s e
r ep r es e n to n a d i ri ge n .
I I 1 1 1 1
PARTE DOS pRAcnCAD E L A IN GE NIE RiA D EL S On wA RE
Principio #4: Bstimar con base en el conocimiento disponible. La finalidad
de la esnmacion es proporcionar un indicio del esfuerzo, costa y duraci6n de las
tareas. con base en el conocimiento que el equipo tiene del trabajo que se va a rea-
lizar. Si la informaci6n es vaga 0poco confiable, las estimaciones tendran, de igual
forma, poca confiabilidad.
Principio #5: considerar el riesgo cuando se define el plan. Si el equipo ha
detinido riesgos que tienen un alto impacto y una alta probabilidad, es necesario un
plan de contingencia. Ademas, el plan de proyecto (que incluye el calendario) se
debe ajustar para incluir la posibilidad de que uno 0 mas de estes riesgos se tome
un problema real.
Principio #6: Ser realista. Las personas no trabajan el 100 por ciento de cada
dia. EI ruido siempre entra en cuaIquier comunicaci6n humana. Las omisiones y la
ambigOedad son hechos de la vida. Los cambios ocurriran. Hasta los mejores inge-
nieros de software corneten errores. Estas y otras real idades deben considerarse
mientras se establece el plan del proyecto.
" H e x i f o e s t 6 m m e n f un c iO n d e l ~ l i d o c o rn u n c o n si sl en f e q u e d e l g e n io . ·
All",
Principio #7: Ajustar Jagranularidad mientras se define el plan. La granu-
Iaridad se refiere al grado de detalle que se introduce conforme se desarrolla el plan.
Una "granuIaridad fina" en eI plan proporciona detal les significativos de las tareas de
trabajo, los cuales se planean en incrementos reIativamente cortos de tiempo (deforma que el ajuste y eI control se den con frecuencia). Un plan de "granularidad
gruesa" proporciona tareas de trabajo mas arnplias, las cuales se planean en perio-
dos mas largos. Por 10 general, la granularidad cambia de tina a gruesa conforme el
tiempo limite del proyecto esta mas lejos de la fecha actual. En las siguientes serna-
nas 0meses el proyecto se puede planear con detalle significativo. Las actividades
que no se realizaran por muchos meses no requieren una granularidad tina (hay
demasiadas cosas que pueden cambiar).
Principio #8: Definir cOmo se intentard asegurar la calidad. EI plan debe
identificar la forma en que el equipo de software pretende asegurar la calidad. Si
habra revisiones tecnicas formales.? estas se deben calendarizar. En caso de que se
util ice programaci6n en pareja (capitulo 4) durante la construcci6n esta debe estar
detinida de manera explicita en el plan.
Principio #9: Describir como se pretetuie incluir el cambio. Incluso a la
mejor planeaci6n puede superarla el cambio incontrolable. EI equipo de software
debe identificar la forma en que se incluiran los cambios conforme se realiza el tra-
bajo de ingenieria del software. Por ejemplo, i.el c1iente puede sol icitar un cambio en
7 Las revisiones tecnicas formales se estudian en el capitulo 26.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 12/29
CAPiTuLo 5 LA pRAcnCA UNA V1S16NGENtruCA 115
cualquier momento? ;.5i se presenta una solicitud de cambio el equipo esta obliga-do a implementarlo de inmedlato? ;.C6mo se evaluan el impacto y el costa del cam-
bio?
Principio #10:Adaptar el plan a menudo y bacer los ajustes cuando estos
se requieran. Dia tras dla los proyectos de software van por detras del calendario
establecido. Por ello, es de mucha ayuda adaptar el progreso a diario. Se deben bus-
car areas problematicas y situaciones en las que el trabajo calendarizado no vaya de
acuerdo con el trabajo que se ejecuta en realidad. Cuando se encuentran desfases,
el plan se ajusta en concordancia con ello.
En la busqueda de mayor efectividad, todos los integrantes del equipo de softwa-
re deben participar en la actividad de planeacion. Solo entonces son miembros del
equipo "comprometidos" con el plan.
En un excelente documento sobre procesos y proyectos de software, Barry
Boehm [80E961 establece: "Se necesita un principio de organizacion que se reduzca
para proporcionar planes [de proyecto] simples para proyectos simples." Boehm
sugiere un enfoque dirigido a los objetivos, fundamentos y calendarios del proyecto,
a las responsabilidades, enfoques tecnicos y de gestion y a los recursos requeridos.
Ello llamo ptincipio WHH (why, what, when, who, where, how, how), debido a una
serie de preguntas que conducen a una definici6n de caracteristicas clave del pro-
yecto y el plan de proyecto resultante:
iPor que esta en desarrollo este sistema? Todas las partes deben cveluar la
validez de las razones del negocio para el trabajo en el software. Dicho de otra
manera, eel proposito del negocio justi fica el gasto de personal, tiempo y dinero?
;.Que se hara? Se debe identificar la funcionatidad que se construira s. por ende.las tareas requeridas para realizar el trabajo.
lCufmdo se terminara? Es necesario establecer un flu]ode trabajo y un ticmpo
limite para las tareas clave del proyecto, asi como tcennncar 105 runoarnemos requc-
ridos por el cliente.
iQuiim es el responsable de una funcion? Se deben definir el papel y la res-
ponsabilidad de cada miembro del equipo de software.
;.En d6nde se ubican dentro de la organizaci6n? No todos los papeles y res-
ponsabilidades residen dentro del mismo equipo de software. EI cliente, los usuarios
y otros participantes tarnbien tienen responsabilidades.
;.C6mo se realizara el trabajo en los sentidos tecnico y de gesti6n? Una
vez que se establece el ambito del producto. es necesario definir una estrategia tee-
nica y de gesti6n para el proyecto.
lCufmto se necesita de cada recurso? La respuesta a esta pregunta se obue-
ne al desarrollar estimaciones (capitulo 23) con base en las respuestas a las prcgun-
tas anteriores.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 13/29
I I II 11,la lllllllllllllll •
116 P AR TE DO S p RA cnC A D E LA IN GE NlE RiA D EL S OF IW AR E
Las respuestas a las preguntas WHH de Boehm son importantes independiente-
mente del tarnano 0 la complejidad de un proyecto de software. Pero, {_como se ini-
cia el proceso de planeaci6n?
' P a a s o m o s q u e lo s d e s a r r o l l a d o r e s d e s o f tw o re e sl a n p er d ie nd o u n o v e r d a c l v i t a l : 1 0 r n o y o r i a d e l a s 0 I g I I I I i z t d 0 a I s lID
_10 q u e h o c e n . E I a s p ie n so n q u e 10 a be n , p e ro n o e s osl· _ . . . . .
ConJW1tode tareas genericas para Ia planeacion
1. Reevaluar el ambito del proyecto
(secciones 7.4 y 21.3).
2. Evaluar los riesgos (secci6n 25.4) .
3. Desorrollar 0 refinar los escenarios del usuario
[secciones 7.5 y 8.5).
4. Extraer hmciones y coraderisticas a partir de los
escenarios [seccion 8.5).
5. Definir las funciones y caraderlsticos tecnicas que
forman 10 infroestructuro del softwore.
6. Agrupar las funciones y caracterlst icas (escenorios)
de ocuerdo con 1 0 priori dad del clienle.
7. Crear un plan de proyecto con uno granuloridad
grueso (capltulos 23 y 24).
Dofinir 01 numero proyectodo de incrementos desoftware.
Establecer un calendario general d e l proyecto
(copitulo 24).
Es!ablecer las fechas de entrega proyectadas para
coda incremento.
8. Crear un pion con granularidad fino para 1 0
ileraci6n actual (capitulos 23 y 24).
Definir tareas de trabajo para coda funci6n y
caraderistica [seccion 23.6).
Estimor el esfuerzo para coda !area de trabajo
(secci6n 23.6).
Asignor responsobilidad para coda !area de
trabojo [seccion 23.4).
Definir las produdos de trabajo que seron
producidos.
tdentificar los metodas para el aseguramiento de
10calided que se usoren (capitulo 26).
Describir los metodas para el cambio en 1 0 gestion
(capitulo 27).
9. Rastrear el progreso de manera regular (secci6n
24.5.2).
Observar los areas problemcficcs (par ejemplo, el
desfose del calendario).
Hacer los ajustes que se requieran.
Los modelos se crean para obtener un mejor entendimiento de la entidad real que se
construira, Cuando la entidad es un objeto fisico (por ejemplo, un edificio, un avion,
una maquina), se puede construir un modelo identico en forma y tamafio, pero en
menor escala. Sin embargo, cuando la entidad es software, el modelo debe tomar
una forma diferente. Debe ser capaz de representar la informacion que el software
transforma, la arquitectura y las funciones que permiten que ocurra la transforma-
cion, las caracteristicas que desean los usuaries, y el comportamiento del sistema
con forme se realiza la transformacion. Los modelos deben cumplir estos objetivos
en diferentes grados de abstraccion (pr imero al presentar el software desde el punto
de vista del cliente y despues aI representar el software en un nivel mas tecnico)
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 14/29
CAPiTuLo 5 LA pRAcnCA; ! INA V1S!6N GENEruCA 117
En el trabajo de la ingenieria del software se crean dos clases de modelos: mode-los de analisis y modelos de disefio. Los mode/os de atuillsis representan los requisi-
tos del cliente al presentar el software en tres dominios diferentes: el dominio de la
informacion, el dominio funcional y el dominic del comportamiento. Los modelos de
diseiio representan caracteristicas del software que ayudan a los profesionales a
construirlo de manera efectiva: la arquitectura (capitulo 10), la interfaz del usuario
(capitulo 12), y el detaUe al nivel de componentes (capitulo II).
En las secciones siguientes se presentan los principios y conceptos basicos que
son relevantes para el model ado del analisis y el diseno. Los metod os tecnicos y la
notacion que permiten que los ingenieros de software creen modelos de anal isis y
disefio se presentan en los capitulos posteriores.
"t I priner p r a i I I e m a d e l i n g e n i e r o e n r u a l q u ie r s i t u a t i O n d e d is e i io e s d e sc u b ri r c u a l e s r ea lm e n t e e I p r o W e m a .·
. . . .5.4.1 Principlos del modelado del anCilisis
En las pasadas tres decadas se ha desarroUado un gran nurnero de metodos de
modelado del anausis. LoS investigadores han identillcado los problemas del a n a u -
sis y sus causas y han desarrollado una variedad de notaciones de model ado y los
conceptos heuristicos correspondientes para manejarlos. Cadametodo de analisis
tiene un punto de vista unico. Sin embargo, todos los rnetodos de a na lis ls e sta n re la -
cionados por medio de una serie de principios operativos:
Principio # 1: E1 dominio de informacion de un problema debe represen-
tarse y entenderse. EIdominio de informacion 10 forman los datos que fluyen hacia
el sistema (a partir de los usuarios finales, otros sistemas 0dispositivos externos),
los datos que fluyen desde el sistema (a traves de la interfaz del usuario, interfases
de red, reportes, graf icas y otros medios) y los almacenamientos de datos que se
recopilan y reorganizan los objetos consistentes de infonnaci6n (es decir, los datos
que se mantienen en forma permanente).
Principio #2: Se deben definir las funciones que eiecuta el software. Las
fund ones del software proporcionan un beneficio directo a los usuanos finales y
tarnbien aporta soporte interno a aquellas caracteristicas visibles para el usuario.
A1gunas funciones transforman los datos que fluyen hacia el sistema. En otros casos,
las funciones efectuan algun grado de control sobre el procesamiento interne del
software 0 elementos externos del sistema. Las funciones se pueden describir en
muchos grados diferentes de abstraccion, que van desde un enunciado general del
prop6sito hasta una descripci6n detallada de los elementos del p r o c e s a r r n e r n o q u e
deben utilizarse.
Principio #3: se debe te pre se nta r e l componamiento Oe1s o n w a r e (comouna consecuencia de eventos externos}. AI comportamiento del software de cornpu-
tadora 10 guia su interacci6n con el ambiente externo. La entrada que proporcionan
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 15/29
118 PARTE DOS PRACTICADELA INGENJERiADEI.SOITWARE
los usuarios finales, los datos de control que aporta un sistema extemo 0 los datos
de monitoreo que se recolectan a traves de una red ocasionan que el software se
comporte de una manera especif ica.
Principio #4: Los modelos que presentan informacion, funcion y compor-
tamiento deben partirse de forma que descubran el detalle de una manera
estratificada (0 ierarquicat. El modelado del analisis es el primer paso en la reso-
lucian de problemas en la ingenieria del software. Esto permite al profesional enten-
der mejor el problema y establecer una base para la solucion (disefio). Los proble-
mas complejos son dificiles de resolver por completo. Por esta razon, se utiliza una
estrategia de "divide y ganaras". Un problema grande y complejo se divide en sub-
problemas hasta que cada subproblema es relativamente faci l de entender. Este con-
cepto se llama particion, y es una estrategia clave en el modelado del analtsis.
Principio #5: La tarea del andlisis debe moverse de la informacion esencial
bacia el detalle de implementacion. El modelado del analisis comienza con la
descripcion del problema desde la perspectiva del usuario final. La "esencia" del pro-
blema se describe sin ninguna consideraci6n de la forma en la que se implementa-
ra la soluci6n. Por ejemplo, un videojuego requiere que el jugador "instruya" al pro-
tagonista en que direcci6n seguir cuando este se mueve dentro de un laberinto peli-
groso. Esa es la esencia del problema. El detalle de implementacion (descrita en
forma normal como una parte del modelo del disefio) indica como se implementara
la esencia. Respecto del videojuego se podria aplicar la entrada de voz. De manera
altemativa, se podria digitar un coman do del teclado, 0se podria apuntar un joystick
(0 un mouse) en una direcci6n especif ica.
CcnJunto de tareas genericas para eI modeIado del anCzHsls
1. Revisor los requisitos del negocio, los 3. ModeIar el dominio de 10 informaciOn (secci6n 8.3).
caracterislicas/ necesidades del
usuario, los solidos visibles para el
usuario, los restricciones del negocio, y otros
requisitos te<:nicos que se hoyan determinodo
durante los adividodes de comunicodOn con el
cliente y de planeoci6n.
2. Expondir y refinar los escenarios del usuario (secciOn
8.5).
Representor todos los objetos impartontes de
informaciOn.
Definir los otributos para coda objeto de
informoci6n.
Representor los relaciones entre los objetos de
informociOn.
4. ModeIor el dominio fundonal (secci6n 8.6).
Definir a todes los adores.
Representor 10 forma en que los adores
interaciUan con el software.
Extraer funciones y ccrocterisficos a partir de los
escenarios del usuario.
Revisor los escenarios del usuorio para verificar
que esten completos y su exoclitud (secciOn 26.4).
Mostrar 10 forma en que los funciones modifican
los objetos de datos.
Refinor los funciones pora proporcionar los
detolles de 10eloborocion,
Escribir uno norraciOn del procesomiento que
describo cado funciOn y subfuncion.
Revisor los modelos funcionoles [seccien 26.4).
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 16/29
CAPiTuLo 5 LA pRACTlCA: UNA VISIONGENEruCA 119
5. Modelar el dominio del comportamiento (secc i6n
8.8).
Identificar los evenlos exlemas que ocasionan
cambios en e I comportamiento denlro del
sistema.
Ident if icar los estados que representon codo forma
de comportamiento observable desde el exterior.
Presenlor el modo en el que un evenlo lIeva 0 1
sistema a cambiar de un estodo a olro.
Revisor los modelos de comporlamienlo [seccion
26.4).
6. Anolizar y modelar la intertase del usuario (capftulo
12).
Dirigir el an61isis de tareas.
Crear prota tipos de la imagen en pontalla,
7. Revisor tados los modelos en cuanta a que esren
compietos, su consistencia y los omisiones.
5.4.2 Prtnciplos de modelado del d1seiioEl modele de diseno del software es el equivalente al plano de una casa para un
arquitecto. Comienza con la representacion de la totalidad del objeto que sera cons-
truido (por ejemplo, una reproducci6n tridimensional de la casal y con lentitud 10
retina para proporcionar una guia para construir cada detalle (por ejemplo, el dise-
no de la plomeria). En forma similar, el modelo del disefio que se crea para el soft-
ware proporciona una variedad de diferentes vistas del sistema .
. . . . . " . . . . . U e i i o*_j u s to : a v e r ig u o d o e s t o , p e rs ig u e lo r e s u eh a m e n l e; n o p o r . . . r e d1 m . . . . .
.......... II a s r es u el to e f ed u a r. ·
No hay pocos metodos para derivar los diferentes elementos de un orseno de son-ware. Algunos metodos se guian mediante los datos al permitir a la estructura de
datos dictar la arquitectura del programa y los componentes de procesamiento resul-
tantes. A otros los conduce el patron al utilizar informacion acerca del dominio del
problema (el modelo de analisis) para desarrollar estilos arquttectonicos 'jpatrones
de procesamiento. Incluso otros estan orientados a objetos, al usar los objetos del
dominio del problema como los conductores para la creaci6n de estructuras de datos
y los metodos para manipularlos. Aun asi, todos ellos siguen un conjunto de princi-
pios de diseno que se pueden aplicar sin importar el metodo que se utilice:
Principio # 1:E1diseiIo debe ser rastreable basta el modelo de atuilisi», El
modelo de analisis describe el dominio de la informaci6n del problema, las funcio-
nes visibles para el usuario, el comportamiento del sistema y un conjunto de clasesde analisis que empaqueta los objetos del negocio con los metodos que les sirven.
El modele de disefio traduce esta informacion a una arquitectura: un conjunto de
subsistemas que implementan las funciones mas Importantes y u n c o m u n t o d e dtse-
nos a1 nivel de componentes que son la realizaci6n de las c1ases de anal isis. Excepto
el modelo asociado con la infraestructura de software, los elementos del modele de
diseno deben ser rastreables hasta el modelo de anaJisis.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 17/29
120
r H I J 4 i i5 m 1E n c s . W W W c .
.. 1....,.1DesIp/se_e n t o n tr o r ( o m e n t o l io s
~ssobreel
p r o c e s cl i e d i ~ c t
J u nt o ( o n I l 1 1 O
e x p o 5 i Q 6 n d e It J
e s l t t i < a d e l l t i s e i i o .
Il ',I
P AR TE DO S P AAC l1CAD E L A I NG E NJ ER lA D E L S O FTWARE
Principio #2: Siempre se debe considerar la arquitectura del sistema que
se va a construir. La arquitectura del software (capitulo 10) es el esqueleto del sis-
tema que se va a construir. Este afecta las interfases, las estructuras de datos, el flujo
y el comportamiento del control del programa, la manera en que se pueden realizar
las pruebas. la faci lidad de mantenimiento del sistema resultante, y mucho mas. Por
todas estas razones, el diseno debe iniciarse con las consideraciones del disefio
arquitectonico. SOlo despues de que se ha establecido la arquitectura, es posible
considerar los aspectos al nivel de componentes.
Principio #3: El diseno de datos es tan importante como el diseiio de fun-
ciones de procesamiento. EI disefio de datos es un elemento esencial del disefio
arquitectonico. Lamanera en que se real izan los objetos de los datos dentro del dise-
no no puede dejarse a la suerte. Un disefio de datos bien estructurado ayuda a sim-
plificar el flujo del programa, facilita el diseno y la irnplementacion de los compo-
nentes del software, y confiere mas efidencia al procesamiento en general.
Principio #4: Las interfaces (infernos y extern as) deben disefiarse con cui-
dado. Lamanera en que fluyen los datos entre los componentes de un sistema tiene
mucho que ver con la eficiencia del procesamiento, la propagacion del error y la sim-
pl icidad del disefio. Una interfaz bien disefiada facil ita la integracion y ayuda a quien
realiza la prueba a val idar fund ones de componentes.
Principio #5: El disefio de intetfaz del usuario debe aiustarse a las necesi-
dades del usuario final. S in emb arg o, e n ca da c as o, d eb e re sa lta rs e la fa cilid ad d el
uso. La interfaz del usuario es la manifestacion visible del software. Sin importar que
tan sofisticadas sean sus funciones intemas, sin importar que tan comprensibles
sean las estructuras de datos, no importa que tan bien disefiada este su arquitectu-
ra, un disefio de interfaz pobre siempre conduce a la percepcion de que el software
esta "mal" hecho.
Principio #6: El diseiio al nivel de componentes debe set independiente del
modo funcional. La independencia funcional es una medida del "significado senci-
110" de un componente de software. La funcionalidad que entrega un componente
debe ser cohesiva, es decir, debe centrarse en una y solo una funcion 0 subfuncion."
Principio #7: Los componentes deben estar apareados entre si en forma
minima y vinculados con el ambiente extemo. El apareamiento se consigue de
much as maneras: via interfaz de componente, por mensajes, a traves de datos glo-
bales. A medida que aumenta el nivel de apareamiento, la probabilidad de propaga-
cion del error tarnbien aumenta y la facilidad de mantenimiento general del softwa-
re disminuye. Por 10 tanto, el apareamiento de componentes debe mantenerse tan
bajo como sea posible.
8 Enel capitulo 9 se puede encontrar una exposicion adicionaI acerca de la conesion.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 18/29
CAPiTuLo 5 LA PRAcnCA UNA VlSI6N GENEruCA 121
Principio #8: Las representaciones del diseiio (modelos) deben ser fdcil-mente comprensibles. EI proposito del diseiio es comunicar informacion a los pro-
fesionales que generaran codigos. a aquellos que probaran el software, y a quienes
tal vez mantengan el software en 10futuro. Si el disefio es dificil de entender, no ser-
vira como un medio efectivo de cornurucacion.
Principio #9: El diseiio debe desarrollarse de manera iterativa. En cada ite-
radon el diseiiador debe buscar la mayor simplicidad. Como casi todas las acti-
vidades creativas, el disefio ocurre de modo iterativo. Las primeras iteraciones sir-
yen para refinar el diseno y corregir errores, pero las iteraciones posteriores deben
buscar que el disefio sea tan simple como sea posible.
Cuando se aplican estos principios de manera apropiada, el ingeniero de softwa-
re crea un diseno que muestra los factores internos y externos de cali dad.Losfacto-re s de cal idad extemos son aquellas propiedades del software que los usuarios pue-
den observar facilmente (como velocidad, confiabilidad, correccion, facilidad de
uso). Los factores de ca l idad in te rno s son importantes para los ingenieros de softwa-
re, ya que conducen hacia un disefio de alta calidad desde un a perspectiva tecnica.
Lograr factores de calidad internos requiere que el disefiador entienda conceptos
basicos de disefio (capitulo 9).
Modelado agtl
E n su [ib ro so bre m ode la do 6 gil. Scot t Ambler
(AMB02) d ef in e u no s er ie d e p rin cip io s9
~ ,. ,.. ." "'" c ua nd o e l a na lis is y e l d i se i\ o s e c on du ce ndel contexto de 1 0 f il os ol ia d el d es ar ro ll o a gi l de
(capitulo 4):
#1: La m eto p rim a rio d el e qu ip o d e so ftw are e s
c on str uir so ftw are , n o c re ar m o de lo s.
# 2 : V ia ia r lig ero ; e s d ec ir, n o d eb en c re orse mOs
'TIOdeIosde los necesor ios .
. # 3: I nt en to r p ro du ci r e l mo de lo mOs s imp le que
d es cr ib ir a e l p ro bl ema 0e I software.
# 4: C on str uir m o de lo s d e f orma q ue e sto s sean
CIIustobles 0 1 cambio.
# 5: Se r c ap oz de e nu nc ia r u n p r0 p6 si to e xp ti dt o
para coda m odelo que se cree.
. # 6 : Ad ap to r l os mo de lo s d es or ra ll od os 0 1
Principia II 7: Trotar de construi r- rnodelos utiles, per-o
o Iv id or se d e c on st ru ir mo de lo . p er fe ct o. ,
Principio # 8: No v olv er se d ogma lic o o ce rc o d e 1 0 .inlaxisde l modelo. Si e sle c orn un ic o su c on le nid o d e mon er o
exitoso, 1 0 r ep r es ent cc ion e s s ecundo ri a.
Principia # 9: Si e I in stin to in dic a q ue u n m od elo n o e s e l
ca rre clo a uoq ue e ste lu zc a bie n e n e l popel.
p ro bo bl emente e xi st e u na rczon p or a e sto r
preocupodos.
Princlpios 10: Obte ne r r elr oo lim e nta ci6 n I an p ro nto c omo
sea posible.
S in im po rto r e l m od elo d e p roc eso q ue se e lijo 0os
procticos especificas de 1 0 in ge ni er ia d el s of tw a re q ue se
a pliq ue n, to do s lo s e qu ip as d e s of tw ar e q uie re n s er 6 gile s.
Po r 1 0 ta nto , e sto s p rin cip io s s e d eb en a plic ar s in im p orta r
el m o d e I o de p ro ce so d el so ftw are q ue se haya
seleccionodo.
9 Los prindpios mencionados enesta s ec ci6 n s e han abreviado y adaptado para los prop6silos d e e st e
libro.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 19/29
122 P A R T E D O S P R A C O C A DE LA l N G E N I ER lA D E L S O F T W A R E
Conjunto de tareas genericas para e1diseiio
1 . U tiliz ar e l m o de lo de cnolisis,
s e le cci an a r un e s ti lo a rqu it ed6ni co
(p atro n) a pro pia do p ara e l software
(capitulo 10).
2. D ividir el m odelo de a no lis is e n s ub sis tem as d e
disefio y u bic ar e slo s d en tr o d e la a rq uile du ra
(capitulo 10).
T en er la c erte zo d e q ue c ad a su bsiste ma es
c oh er en te e n e l s en ti do f un ci on al .
D i se no r i nt er fa se s d e s ub si st ema .
U b ic ar la s closes 0 f un ci on es d e onclisis para
coda .ubi .lema.
Mediante 1 0 u tiliz ac io n d el m o de lo d el d om in io d e
la i nf orma cio n, d is en ar e str uc tu ra s d e d olo s
apropiodo s.
3. Diseiior 1 0 interfaz del usuorio (cap itu lo 12).
Rovitor los rotultodo. dol on61i.i. de Iorea s.
E sp ec ific ar la se cu en cia d e a cc iO n c on b ase e n lo s
e sc en ar io s d el u su ar io .
C rear un m odelo de com partam iento de la
interfoz.
D ef in ir lo s o bje lo s d e la in te rf az y me ca nis mo s d e
control.
Rev is o r e l d is e i' io d e 1 0 interfaz y a ju st ar lo c omo
s ea n ec es ar io [ se cc io n 26.4).
4. Cood uc ir e l d is ei 'i o a l n iv el d e c omp on en te .
E s pe cif ic or ta do s lo s a lg or itr no s e n u n g ra dor el at iv ament e b aj o d e a bs tr ac ci on .
Re f in a r l a i nt e rf a z de c ad a c omp an en te .
De f in ir l es estrucfures de dalos en el nivel de
c ompo ne nt e [ se cc ie n 26.4).
Revi so r e l d is ei 'i o e n e l n iv el d e c omp an en te s
[seccion 26.4).
5. D es ar ro llo r u n mo de lo d e d es plie gu e (seccion 9.4.5).
La actividad de construcci6n abarca una serie de tareas de codificacion y realizacion
de pruebas que conducen al software operativo que esta listo para entregarlo al
cliente 0usuario final. En el trabajo de la ingenieria del software modema la codifi-
caci6n puede ser. I) la creaci6n directa de codigo fuente de un lenguaje de progra-
macion: 2) la generacion autornatica de codigo Fuente al util izar una representacion
intermedia del disefio del componente que sera construido, 3) la generacion auto-
matica de codigo mediante un lenguaje de programacion de cuarta generacion (por
ejemplo, Visual C++).
"Ondt 9 f I I I l p a r t e d e m i v i d a h e s i d o u n l i s g o o d e l s o l t w o r e , a s o m O a d o m e f u r t iv a m e n I e 1 1 1 " _pi I ' I I I I I IS. C k a s i o n a b e n t e , 8 IIW 8 I lI r o u n o jo y o r ea l, u n p ro g ro m a b i e n e s l r u d u r a d o e s a i I o alii .......
. . . . . . d e s a r r o I a c I o d e f o r m a q u e c od a c om p on en te a s s i m p le y o r g a n i z a d o , y . .. .. pIA .. II.....
. . . . _ _ c o n fdidod.·
EIenfoque inicial de las pruebas esta al nivel de componentes. con frecuencia lla-
mad as pruebas de unidad. Los otros niveles de prueba incluyen: 1) pruebas de inte-
graci6n (realizadas mientras el sistema esta en construccion) 2) ptuebas de validacion,
las cuales evaluan si los requisitos han sido satisfechos para el sistema completo (0
para el incremento de software); y 3) ptuebas de aceptacion , que realiza el cliente en
un esfuerzo encarninado a ejercitar las caracterist icas y funciones.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 20/29
CAPITuLo 5 LA pRACTlCA:UNA VJSl6N GENtruCA 123
Existe una serie de principios y conceptos aplicables a la codificaci6n y las prue-bas. Estos se presentan en las secciones siguientes.
5.5.1 Principios y conceptos de codificacion
Los principios y conceptos que guian la tarea de codificaci6n estan alineados de
manera muy cercana aJ estilo de la programaci6n, los lenguajes de la programaci6n
y los metodos de programaci6n. Sin embargo, existe un conjunto de principios fun-
damentales que pueden establecerse:
Principios de preparacioru Antes de escribir una linea de c6digo se debe estar segu-
rode:
1. Entender el problema que se intenta resolver.
2. Entender los principios y conceptos basicos del disefio.
3. Escoger un lenguaje de programaci6n que satisfaga las necesidades del soft-
ware que se va a construir y el ambiente en el que este va a operar.
4. Seleccionar un ambiente de programacion que proporcione herramientas que
faciliten el trabajo.
5. Crear un conjunto de pruebas de unidad que seran aplicadas una vez que se
complete el componente que se va a codificar.
Principios de codiflcacion: Cuando se comience a escribir el c6digo se debe estat
s eg ur o d e:
1. Restringir los algontrnos al seguir Ia pracnca de la programacton estructuraoa
[BOHOOj.
2. Seleccionar las estructuras de datos que satlsraran las necesidades del diseno.
3. Entender la arquitectura del software y crear interfases que sean consistentes
con ella.
4. Mantener la l6gica condicional tan simple como sea posible,
5. Crear cicios anidados en una forma que los haga faciles de probar.
6. Seleccionar nombres de variables signiflcarivas y seguir otros estancares lo-
cales de codificaci6n.
7. Escribir c6digo que tenga dacumentaci6n propia.
8. Crear una configuraci6n lineal (por ejemplo, sangrias y lineas en blanco que
ayuden a la comprensi6n del c6digo).
Principios de valldacioru Despues de haber compkuuio los prim eros poses de cedi-
ficacion, se debe estar segura de:
1. Conducir un ensayo de c6digo cuando sea apropiado
2. Realizar pruebas de unidad y corregir los errores que se hayan cescubierto.
3. Refabricar el c6digo.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 21/29
124
I,
PARTE DO S pRAcnCA D£ LA INGENIERlA DEL SOFTWARE
Los libros sobre codificaci6n y los principios que la guian incluyen trabajos recien-
tes sobre el estilo de programaci6n [KER78], construcci6n practlca de software
[MCC93], perlas de programaci6n [BEN99J. el arte de la programaci6n [KNU99J.
aspectos de la programaci6n pragmatica [HUN99]. y muchos otros.
ConJW1tode tareas genericas para la construcci6n
1. Construir 1 0 infroestructuro Codificcr los olgorihnos internos y los funciones de
orquileclOnico (capitulo 10). procesomiento relocionodos.
Revisor el diseno orquitect6nico.
Codificor y probor los componentes que forman 1 0
infraeslructuro orquiledOnica.Adquirir palrones orquilect6nicos reutilizobles.
Probor 1 0 infroeslruclura para osegurar 1 0
integridod de 1 0 interfoz.
2. Construir un companente del software (capitulo 11).
Revisor el disefio 0 1 nivel de componente.
Crear uno serie de pruebos de unided para el
camponente (secciones 13.3.1 y 14.7).
Codificor las eslructuras de datos y 1 0 interfase del
componente.
Revisor el codigo conforme esle se escribe [seccion
26.4).
Buscor 1 0 exaclitud.
Asegurorse de que se han mantenido los
est6ndores de codificaci6n.
Asegurorse de ",ue el codigo se documenlo a sf
misma.
3. Realizer pruebos de unidod 0 1 componente.
Dirigir Iodos las pruebos de unided.
Corregir los errores descubiertos.
Aplicar de nuevo las pruebos de unided.
4. Integrar el componenle terminado a 1 0 infraestrudura
orquitect6nico.
, C u m e s s o n
l o s o I I ie t iv o s
d e l a s p r ue b a s 0 1
software?
5.5.2 Principios de las pruebas
En un libro clasico sobre las pruebas real izadas al software, Glen Myers [MYE79]
establece una serie de reglas que bien pueden servir como objetivos de las pruebas:
• Las pruebas consisten en un proceso en el que se ejecuta un programa con la
intenci6n de encontrar un error que aun no se descubre.
• Un buen caso de prueba es aquel en el que hay una gran probabilidad de
encontrar un error que aun no se descubre.
• Una prueba exitosa es aquella que encuentra un error que aun no se
descubria.
Estos objetivos implican un cambio radical desde el punto de vista de algunos desa-
rrolladores de software. Estes se oponen a la visi6n inusual de que la prueba exito-
sa es aquella en la que no se encuentran errores. EI objetivo aqui es disefiar pruebasque de manera sistematica descubran diferentes c1ases de errores y que 10 hagan
con un gasto minima de tiempo y esfuerzo.
Davis [DAV9S] sugiere un conjunto de principios para las pruebas.'? el cuaJ se ha
adaptado para aprovecharlo en este libro:
10 Aqui sepresenta solo un pequeno subconjunto de los principios de Davis para las pruebas. Paraob-
tener mas informacion vease [DAV95].
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 22/29
CAPITuLo 5 LA pRACTICA UNA VISION GENtruCA 125
Principio # I:Todas las pruebas deben ser rastreables hasta los requisitosdel cliente." El objetivo de las pruebas realizadas al software es descubrir errores.
De aqui se desprende que los defectos mas severos (desde el punto de vista del clien-
tel son aquellos que hacen fallar el programa al tratar de satisfacer sus requisitos.
Principio #2: Las pruebas se deben planear mucho antes de que comience
el proceso de prueba. La planead6n de las pruebas (capitulo 13) puede comenzar
tan pronto como el modelo de analisis este completo. La definicion detallada de los
casos de prueba puede comenzar en cuanto el modele de disefio haya sido solidifi-
cado. Por tanto, todas las pruebas se pueden planear y diseriar antes de que se haya
generado cualquier codigo.
Principio #3: El ptincipio de Pareto es aplicable para las pruebas de soft-
ware. Para establecerlo de manera simple, el principio de Pareto implica que 80 por
ciento de los errores descubiertos durante las pruebas con probabi lidad seran ras-
treables hasta 20 por ciento de todos los programas. El problema, por supuesto, es
aislar estos componentes sospechosos y despues probarlos.
Principio #4: Las pruebas deben comenzar lien 10 pequeiio" y progresar
bacia "10grande". Las primeras pruebas que se planean y ejecutan, por 10 general.
se enfocan en los componentes individuaJes. Conforme progresan las pruebas , el
enfoque cambia en un intento de encontrar errores en grupos integrados de compo-
nentes y, por ultimo, en el sistema completo.
Principio #5: Las pruebas exhaustivas no son posibles. El numero de per-
mutaciones entre las rutas. incluso de un programa con un tarnano rnoderado. es
excepcionaImente grande. Por esta raz6n es imposible ejecutar cada combinaci6n
de rutas para las pruebas. Sin embargo, se puede cubrir de manera adecuada la logi-
ca del programa para asegurar que se hayan ejercitado todas las condiciones al nivel
de componentes (capitulo 14).
Con/unto de tareas genericas para las proebas
Diseiior pruebos de unidod para
coda componente de l software
(secci6n 13.3.1)
Revisor coda pruebo de unidad para oseguror uno
coberturo apropiada.
Dirigir 10pruebo de unided.
Corregir los errores descubiertos.
Aplicor de nuevo los pruebos de unidod.
2 . Desorrollor una eslro legio de in legroc i6n (secci6n
13.3.21.
Estoblecer e I orden y 10eslrolegio que se usoro
para 10integroci6n.
Definir los Mconslrucciones* y las pruebos
requeridas para ejercitorlas.
II Esteprincipio se refiere a las pruebas funcionales; es decir, a las que seenfocan en los requisites.
las pruebas estructurales (que se enfocan en los detaUesarquitectonicos 0l6gicos) pueden no refe-
rirse en forma directa a los requisites especificos.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 23/29
126
I II I' II I' ID ,D 1 m I lI D I I _ _
PA RTE DO S PRA cnCA D E L A lNG ENIE R iA D E L SO flW AR E
5. D irigir lo s pru ebos con m ucho orden.
R eo li zo r lo s p ru eb os d e r ec up er oc io n [s ec cio n
13.6.1).
R eo li za r lo s p ru eb os d e s eg ur id ad [s ec cie n
13.6.2).
R eo li zo r lo s p ru eb os d e te ns io n [ se cc io n 1 3.6 .3 ).
R eo li zo r lo s p ru eb os d e desempefio [seccion
13.6.4).
D irig ir p ru eb os d e h um o a d io rio .
D irig ir p ru eb os d e req resio n co do v ez q ue seo
necesorio.
3 . D eso rro liar u na es trate gia d e v olid ocio n (sec ciO n
13.5).
E s tob le ce r l os c ri te r io s de vo li doc ion .
D efin ir las p ru eb as re qu erid as p ara v olid ar e l
software.
4 . D irig ir la s p ru eb as d e in teg racio n y v alid aciO n.
Co r re g ir l os e r ro res de scubi er to s .
A plicar d e nuev o los p rueb os co da vez que seo
necesorio.
6. C oordino r con el diente los pruebos de cceptocion
[ se cc ion 13 .5 .3 ) .
C O N S I J 0 s .S e d e b e I e n e 1 I o
s e r , u J d o d d e q ue e l
s o b e q u e
esper!lI a n te s d e q u e
5e e n l r e g u e el i n c r e -
d e s o f t w a r e .
D e o/ro m o n e r a , el
e s p e r a r o m a s1 0 q v e 58 /e P U l i d e
Como se mencion6 en el capitulo 2, la actividad de despJiegue abarca tres acetones.
entrega, soporte y retroalimentaci6n. Como el software moderno es evolutivo por
naturaleza. el despliegue no se presenta una sola vez, sino varias veces conforme el
software avanza hacia su terrninaci6n. Cada cicio de entrega Ie proporciona al cl ien-
te y a los usuarios finales un incremento de software operativo que provee funcio-
nes y caracterist icas utiles. Cada cicio de soporte proporciona documentaci6n y asis-
tencia humana para todas las funciones y caracteristicas introducidas durante todos
los ciclos de despliegue que se han presentado hasta la fecha. Cada cicio de retroa-
limentaci6n ofrece al equipo de software una guia importante que conduce a modi-
ficaciones en las funciones, caracteristicas y el enfoque que se tom a para el siguien-
te incremento.
La entrega de un incremento de software representa un fundamento importante
para cualquier proyecto de software. Cuando el equipo se prepara para crear un
incremento, se debe seguir una serie de principios clave:
Principio #1: Se deben administrar las expectativas que el cliente tiene del
software. Con demasiada frecuencia, el cliente espera mas de 10que el equipo ha
prometido entregar y de inmediato se presenta un desacuerdo. Esto genera una
retroalimentaci6n improductiva que arruina la moral del equipo. En su libro sobre laadministraci6n de expectativas, Naomi Kartun [KAR94] establece: "EI punto inicial
para administrar las expectativas es volverse mas consciente ace rca de 10 que se
comunica y de la forma en que se hace", Sugiere que un ingeniero de software debe
ser cuidadoso de no enviar al cliente mensajes conflictivos (como prometer mas de
10que se puede entregar de manera razonable en el marco de tiempo con el que se
cuenta. 0entregar mas de 10que se promete para un incremento de software y des-
pues menos de 10 prometido para el siguiente).
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 24/29
CAPiTuLo 5 LA pRAcnCA: UNA VISION GENEruCA 127
Principio #2: Se debe ensamblar yprobar un paquete de entrega completo.Se debe ensamblar un CD-ROM u otro medio que contenga todo el software ejecu-
table, archivos con los datos de soporte, documentos de soporte y otra informaci6n
relevante para que despues 10prueben los usuarios reales. Todos los protocolos de
instalaci6n y otras caracteristicas operativas se deben ejercitar posteriormente en
todas las configuraciones de c6mputo posibles (por ejemplo, hardware, sistemas
operatives, dispositivos perifericos. arreglos de red).
Principio #3: Se debe establecer un regimen de soporte antes de entregar
el software. Un usuario final espera responsabi lidad e informacion exacta cuando
surja una pregunta 0problema. Si el soporte es ad hoc 0, aun peor. inexistente, el
cliente se siente insatisfecho de inmediato. El soporte debe ser planeado, el material
de soporte se debe preparar y se deben establecer mecanismos para mantener unregistro apropiado con que el equipo de software pueda realizar una evaluaci6n
categ6rica de los tipos de soporte solicitados.
Principio #4: Se debe propordonar material instructivo apropiado a los
usuarios finales. El equipo de software entrega mas que el software en 51;en caso
de ser necesario, se debe desarrolLar un entrenamiento apropiado, se deben propor-
cionar directrices para la resoluci6n de problemas, y se deben publicar descripciones
acerca de "cual es la diferencia con este incremento de software".'!
Principio #5: E1software con errores se debe arreglar primero y entregar-
se despues. Ante la presion del tiernpo. algunas organizaciones de software entre-
gan incrementos de baja calidad con una advertencia para el cliente de que los erro-
res "se eliminaran en la pr6xima version". Esto es un error. En el negocio del soft-ware se dice: "Los clientes olvidaran que se les entreg6 un producto de alta calidad
unos pOCOSdias despues, pero nunca olvidaran los problemas que les causo un pro-
ducto de baja calidad. EI software se los recuerda todos los dias".
EI software entregado proporciona un beneficia para el usuano final, pero (am-
bien provee una retroalimentacion uti! para el equipo de software. Al utilizar el incre-
mento, los usuarios finales deben ser motivados a comentar sobre las caracteristi-
cas y funciones, facilidad de usc, confiabilidad y cuatesquiera otras caractertsncas
apropiadas. La retroalimentaci6n debe recopilarla y registrarla el equipo de softwa-
re y aprovecharla para 1)hacer modif icaciones inmediatas al incremento entregado
(si es necesario); 2) definir los cambios que seran incorporados en el pr6ximo incre-
mento planeado: 3) real izar las modificaciones necesarias al diseno para ajustarlo a
los cambios: y 4) revisar el plan (incluyendo el calendario de entrega) del proximo
incremento para reflejar los cambios.
12 Durante la actividad de comunicad6n el equipo de software debe determinar los tipos de materia-
les de ayuda que quieren los usuarios.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 25/29
1 I I I : w ' ! a m n a u _
128 PARTE DOS PRACOCA D£ L A ING EN JE RiA D EL SOFTWARE
Conjunto de tcaeas genericas para eJdespJjegue
1. Crear medios de entrega. Estoblecer una bose de datos para el reparte de
problemas/ errores.Ensomblar y prober lodes los
archivos ejecutables.
Ensamblar y prober todos los archivos de datos.
Crear y prober toda la docurnentccion del usuario.
Implementor las versiones electronicas (per
ejemplo, pd~.
Implementor archivos de Nayude" con hipertexto.
Implementor una guia para 1 0 resolucion de
problemas.
3. Establecer mecanismos de refrcolimentocion del
usuario.
Definir el proceso de retroolirnentocicn.
Definir las formas de retroalimentaci6n (en popel a
electronica)
Establecer la bose de datos de retroalimentaci6n.
Definir el proceso de evaluaci6n de 1 0
retroalimentaci6n.
4. Diseminar los medios de entrega a todos los
usuanos.
5. Dirigir las funciones de saparte continuos.
Proparcionar asistencia en la instalaci6n y el
tnICIO.
Proporcionar asistencia continua y de resolocion
de problemas.
6. Recopilar 10retroalimentaci6n del usuario
Registrar la retroalimentaci6n.
Evaluor 10 retroalimentaci6n.
Comunicarse con los usuarios sabre 1 0
retroalimentaci6n.
Prober 10$medio. de enlrego eon un grupo
pe9ueflo de usuarios representotivos,
2 . E stoble,e r 1 0 persona 0grupo encorscdo de l
soporlo humClno.
Crear 1 0 documenmcion 0 las herromientas de
soperte par computadoro.
Establecer meconismos de contocla (per ejemplo,
un sitio web, relefono, correa elecfronicc].
Estoblecer mecanismos para la locolizoci6n de
problemas.
Establecer mecanismos para el reporte de
problemas.
La practice de la ingenieria del software incJuye conceptos, principios, metodos y
herramientas que aplican los ingenieros de software durante el proceso de softwa-
re. Cada proyecto de ingenieria del software es diferente, aun asi existe un conjunto
de principios y tareas aplicables para cada actividad del marco de trabajo del proce-
so, sin importar el proyecto 0 producto.
Si se pretende dirigir una buena practica de la ingenieria del software, es necesa-
rio un conjunto de puntos esenciales tecrucos y de gestion. Los puntos tecnicos
incIuyen la necesidad de entender los requisitos y las areas de incertidumbre del pro-
totipo, asi como la necesidad de defmir de manera explicita la arquitectura del soft-
ware y el plan de integracion de componentes. Los puntos esenciales de gestion
incluyen la necesidad de deftnir prioridades y especificar un calendario realista que
las ret1eje, la necesidad de precisar medidas de control del proyecto apropiadas para
la calidad y el cambio.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 26/29
CAPiTuLo 5 LA PRA.cnCA: UNA V1SJ6N GENtruCA 129
Los principios de comunicacion con el cliente se enfocan en la necesidad de redu-
cir el ruido y mejorar el canal de comunicacion conforme progresa la conversacion
entre el desarrollador y el cliente. Ambas partes deben colaborar para que se esta-
blezca la mejor comunicacion.
Los principios de planeacion se enfocan en las directrices encaminadas a cons-
truir el mejor mapa para realizar el trabajo que conducira a terminar un sistema 0
producto. EI plan se puede disefiar solo para un incremento de software, 0 se puede
definir respecto del proyecto completo. Independientemente de ello, el plan debe
indicar que se hara, quien 10hara y cuando se completara el trabajo.
EI model ado incluye tanto el analisis como el disefio, al describir representacio-
nes del software que se vuelven mas detal ladas de manera progresiva. La finalidad
de los modelos es solidificar la comprension del trabajo que se realizara y propor-
cionar una guia tecnica para quienes implementaran el software.
La construccion incorpora un ciclo de codificacion y pruebas en el cual primero
se genera el c6digo fuente y despues este se prueba para detectar errores. La inte-
gracion combina los componentes individuales e involucra una serie de pruebas que
se enfocan en los aspectos del funcionamiento general y de las interfases locales.
Los principios de codificaci6n definen las acciones genericas que deben ocurrir antes
de que se escriba el c6digo, mientras este se crea y despues de que se haya comple-
tado. Aunque existen muchos principios para las pruebas, s610 uno es el dominante:
las pruebas se forman con un proceso en el que un program a se ejecuta con el obje-
tivo de encontrar un error.
Durante el desarrollo del software evolutivo se presenta el desarrollo para cada
incremento de software que se presenta al cl iente, Los principios clave para la entre-
ga consideran administrar las expectativas del c1iente y dotar al usuario con infor-
macion de soporte para el software. [I soporte necesita una preparacion previa. La
retroalimentacion perrnite al cliente sugerir cambios que tienen un valor de negocios
y proporcionan al desarrollador una entrada para el proximo ciclo iterativo de b
ingenieria del software.
[AMB021 Ambler, S.y R. Jeffries, Agi le Mode l ing , Wiley, 2002.
[BEN991 Bentley, J., Programm ing Pearl s, 2a. ed., Addison-Wesley, 1999.
[BOE 961Boehm, B., "Anchor ing the Software Process", en IEEEsoftware , vol. 13, nurn. 4, julio
de 1996, pp. 73-82.
rBOHOO) Bohl, M. y M. Rin, Too ls f o r S lTUc tu r ed De s ign : An I nt ro d uc tio n to P ro g ramm in g L o gi c,
Sa. ed., Prentice-Hall, 2000.
[DAV95] Davis, A., 201 P r in c ip le s oJ so j lwar e De v el opmen t, McGraw-Hill, 1995.
[FOW99] Fowler, M. er a l., R ef ac to tin g : I mp ro vi ng t he D e si gn o f E xi st in g C o d e , Addison-wesley,1999.
[GAR95] Garlan, D . y M. Shaw, "An Introduction to sonware Architecture", en Advances inS o ftw a re E n gi ne er in g a n d KnOw le d ge E ngi ne er in g , vol. 1 (V. Ambriola y G. Tortora, eds.).
World Scientific Publishing Company, 1995.
[HIGOOI Highsmith, J., Adapt iv e s o ftware De v el opmen t: An E vo lu ti on a ry A p pr oa c h t o Manag in gComp l ex s y st em s , Dorset House Publishing, 2000.
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 27/29
. I I I r I I U I I . . _
130 PA RTE D OS P A AC l'IC A D E L A IN G E N IE R iA D EL S O f 1W A R E
[HOO96] Hooker, D., "seven Principles of Software Development", septiembre de 1996, disponible
en http://c2.com/ cgi/wilciSevenPrinciplesOfSoftwareDevelopment.
[HUN95] Hunt, D., A. Bailey y B. Taylor, The Art oj Facil itation, Perseus Book Group, 1995.
[HUN99] Hunt A., D. Thomas y W. Cunningham, The Pragmatic programmer, Addison-Wesley,
1999.
DUS99] Justice, T. et al., The Facilitators Fieldbook, AMACOM, 1999.
[KAN93] Kanner, c., J. Falk y H. Q. Nguyen, Testing Computer Software, 2a. ed., Van Nostrand
Reinhold, 1993.
lKAN96] Kaner, S. et al., The Faci litator's Guide to Preparatory Decision Making, New society
Publishing, 1996.
[KAR94] Karten, N.,Managing Expectations, Dorset House, 1994.
[KER78] Kernighan, B. y P.PIauger, The Elements oJProgramming Style, 2a. ed., McGraW-Hili,
1978.
[KNU98] Knuth, D., The Art oj Computer Programming, 3 volumenes, Addison-wesley, 1998.
[MCC93] McConnnell, S., Code Complete, Microsoft Press, 1993.
[MCC97] McConnell , S., "Software's Ten Essentials", en IEEE SOftware, vol. 14, num. 2, rnarzo-
abril, 1997, pp. 143-144.
[MYE78] Myers, G., Composite Structured Design, Van Nostrand, 1978.
[MYE79] Myers, G., The Art of Scftwar« Testing, wiley, 1979.
[PAR72] Parnas, D.L., "On Criteria to Be Used in Decomposing Systems into Modules", en
CACM, vol. 14, num. I, abril de 1972, pp. 221-227.
lPOL451 Polya, G., H ow to Solve u. Princeton University Press, 1945.
[ROS751 ROSS,D., J . Goodenough y C. Irvine, "Software Engineering: Process, Principles and
Goals", en IEEE Computer, vol. 8, num. 5, mayo de 1975.
[SHA95al Shaw, M. y D. Garlan, "Formulations and Formalisms in Software Architecture", Volume
Iooo-Lectiu» Notes in Computer SCience,Springer-Verlag, 1995.
[SHA95b] Shaw, M. et. al., "Abstractions for Software Architecture and Tools to Support Them",
en IEEE 'Trans.SOftware Engineering, vol. SE-2I, num. 4, abril de 1995, pp. 314-335.
ISTE74] Stevens, w . , G. Myers y L. Constantine, "Structured Design", en IBM Systems Journal,
vol. 13, num. 2,1974, pp. 115-139.
[TAY90] Taylor D. A., Object-Oriented Technology: A Manager's Guide, Addison-Wesley, 1990.[ULL97] Ullman, E., Close to the Machine: Technophilia and its Discontents, City Lights Books,
1997.
[WlR71] Wirth, N., "Program Development by Stepwise Refinement", en CACM, vol. 14, num. 4,
1971, pp. 221-227.
[W0095] Wood,). y D. Silver, Joint Application Design, Wiley, 1995.
[ZAH901 Zahniser, R. A., "Building Software in Groups", en American Programmer, vol. 3, nums.
7-8, [ulio-agosto de 1990.
5.1. tntentese resumir en un parrafo breve los "siete principios para el desarrollo de software"
de David Hooker (seccion 5.1). Trittese de extraer la esencia de su guia en s610 unas cuantas
oraciones y sin usar las palabras de Hooker.
5.2. i .Existen otros puntos tecnicos "esenciales" que se puedan recomendar a los ingenieros de
software? Enunciar cada uno de eUosy explicar por que se han incluido.
5.3. i .Existen otros puntos "esenciales" de gesnon que se puedan recomendar a los ingenieros de
software? Enunciar cada uno de eUosy explicar por que se ha incluido.
5.4. Un principio importante de la comunicacion establece "prepare antes de cornunicar".
"Como podria esta preparaci6n manifestarse por si misrna en los prirneros trabajos que se
realizan? i.Cuitles productos de trabajo podrian resultar como consecuencia de la preparaci6noportuna?
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 28/29
CAPiTULO 5 LA PAAcnCA- UNA VIS16N GENEruCA 131
5.5. Hagase una invest igacton de la "faci li tacton" para la act iv idad de comunicaci6n (ut iHcen-se las referencias que se proporcionan u otras) y preparese un conjunto de directrices que se
enfoquen solo en la Iacil itacion.
5.6. lEn que difieren la comurucacion agil y la comunicacion de la ingenieria de software tra-
dicional? lEn que son similares?
5.7. GPorque es necesario continuar?
5.S. Realizar una investigaci6n de la "negociacicn" para la actividad de comunicaci6n y prepa-
rar un conjunto de directrices que se enfoquen 5610en la negodacion,
5.9. Descr ib ir 10que signi fica granularidaa en el contexto de un calendario de proyecto.
5.10. GPorque son importantes los modelos en el trabajo de la ingenier ia de software? GSiempre
son necesarios? lSon calif icadores para su respuesta acerca de la necesidad?
5.11. lCuales son los tres "dominies" que se consideran durante el modelado del analisis?
5.12. Tratar de agregar un principio adicional a los enunciados para la codificacion de la sec-
cion 5.6.
5.13. lQue es una prueba exitosa?
5.14. lSe esta de acuerdo con el siguiente enunciado?: "debido a que entregamos multiples
incrementos al cliente, no debemos preocupamos por la calidad en los primeros incrementos;
los problemas se pueden resolver en iteraciones posteriores. Expliquese la respuesta.
5.15. lPor que es importante la retroalimentacion para el equipo de software?
La comunicaci6n con el cliente es una actividad muy importante en la ingenieria del software;
no obstante, algunos profesionales no dedican t iempo a leer acerca de el la. Los l ibros de Pardee
(Ib Sa ts JY a nd D elig ht Yo ur C o stum er, Dorset House, 1996) y Karten [KAR94J proporcionan una
gran perspectiva de los metodos para la interacci6n efectiva con el cliente. En muchos libros
sobre la gesti6n de proyectos se consideran los conceptos y pnnopios de la comumcaclon y laplaneaci6n. Las ofertas utiles reiauvas a la gesuon de proyectos mciuyen. Hughs y coueren
( So ft wa re P ro je ct M a na ge me nt, segunda edici6n, McGraw-Hili, 1999). Phillips ( Th e S oJ hv ar e
P ro je ct M a n ag er 's H a nd bo o k, IEEE Computer Society Press, 1998), McConnell ( So ft w ar e P r oj ec t
S ur vi va l G u id e, Microsoft Press, 1995) y Gilb ( P r in C i p le s O J soj lWGJe E Il g i n e e n n g M a n a g e m e n l.Addison-wesley, 1998).
casi cualquier l ibra sobre ingenieria del software cont iene una exposic ion uti ) sabre los con-
ceptos y principios para el analisis. el disefio y las pruebas. Entre las mejores ofertas estan los
libros de Endres y sus colegas (H an db oo k c f So ftw ar e a nd S ystem s E ng in ee rin g, Addison-Wesley,
2003), Sommerville ( So ft w ar e E n gi ne er in g , sexta edtcion, Addison-Wesley, 2000), Pfieeger
( So ft wa re E ng in ee rin g: T he or y a nd P ra cti ce , Prentice-Hall, 200 I) Y Schach ( Ob je ct -O r ie nt ed a n d
C l a s si c al S o ft w a re E n g in e er in g , McGraW-Hil i, 2001). Davis ha recopi lado una ampl ia coleccion de
principios de software en [DAV95].
Los conceptos y principios del model ado se consideran en muchos Iibros dedicados al ana-
Iisis de requisitos 0 al diseiio de software. Young ( Effe c ti ve R eq ui re m en ts P ra c ti ce s, Addison-
Wesley, 200 1)resalta un "equipo conjunto" de c1ientes y desarrol1adores que elaboren los requi-sitos colectivamente. Weigers ( So ft w a re R e qu ir em en t s, Microsoft Press, 1999) presenta muchos
requisitos clave de ingenieria y requisitos de las practicas de gestion. Sommerville y Kotonya
( Re qu ir em e nt s E n gi ne er in g : P r oc es s a n d T ec hn iq ue s. Wiley, 1998) analizan los conceptos y las tee-
nicas de "obtenci6n" y otros pr incipios de la ingenier ia de requis itos.
Ell ibro de Norman ( Th e D e si gn ojE ve ry da y T hi ng s. Currency/Doubleday. 1990) es una lectu-
ra obligada para cualquier ingeniero de software que intente hacer el trabajo de disefio
Winograd y sus colegas ( Br in gin g D es ig n t o S oft wa re . Addison-wesley. 1996) han editado una
excelente coleccion de ensayos que tratan sobre los aspectos pract ices del disefio de software.
Constantine y Lockwood ( So ftw a re /o r U se . Addison-Wesley, 1999) presentan los conceptos aso-
5/8/2018 Ingenieria Del Software Capitulo 5 - slidepdf.com
http://slidepdf.com/reader/full/ingenieria-del-software-capitulo-5 29/29
13 2
. I I I I . I I I ; I R Il I I l l ~ I I •
PARTE DOS PRA.cnCA DE LA INGmIERiA DEL SOf"IWARE
ciados con el "disefio centrado en el usuario". Tognazzini (To g o n so ftw are D esig n, Addison-
Wesley, 1995) presenta una valiosa exposici6n f ilos6fica de la naturaleza del disef io y el impac-
to de las decisiones sobre la calidad y la capacidad del equipo para producir un software que
proporcione un gran valor a su c1iente.
Hay cientos de libros que tratan sobre uno 0mas elementos de !a actividad de construcci6n.
Kernighan y Plauger [KER78] escribieron un texto clasico sobre el estilo de programaci6n;
McConnell [MCC93) presenta directrices pragmaticas para la construcci6n practica de software;
Bentley [BEN99J sugiere una amplia variedad de perlas de programaci6n; Knuth [KNU98] ha
escrito una serie clasica de tres volumenes sobre el arte de !a programaci6n, y Hunt [HUN99)
sugiere directrices pragrnaticas de programaci6n. La bibl iografia sabre pruebas ha f lorecido en
la decada pasada. Myers [MYE79] se conserva como un clasico. Los Iibros de Whitaker (How to
B r ea k SO ft w a re , Addison-wesley, 2(02), Kaner y sus colegas (L es so ns L ea rn ed in S Oftw a re T es tin g,
Wiley, 2001) Y Marick (T he c ra ft O f s o ftw a re T es tin g, Prentice-Hall, 1997) presentan conceptos y
pr incipios importantes sobre las pruebas, asi como una guia pragmatica considerable.
En Internet existe una amplia variedad de fuentes de informacion sobre la practica de la
ingenieria del software. En el sitio web de SEPA se puede encontrar una lista actualizada de
referencias en la red mundial, las cuales son relevantes para la practica de la ingenieria de soft-
ware:
http://www.mhhe.com/pressman.