Ingenieria Del Software Capitulo 5

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



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



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?



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





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.



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.



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



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~



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.



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.



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.



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.



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)



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



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



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.



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.



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.



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.



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.



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].



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.



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



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.



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.



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.



. 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?

http://c2.com/

http://c2.com/



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-



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.



Documents

Ingenieria Del Software Capitulo 5